Comments 7
Кек, мою статью с описанием как правильно рассчитывать отступы компонентов тоже заминусовали.
Решение-то где?
Решение лежит в 3 снизу абзаце.
Как уже написал автор, отдельный компонент не представляет из себя никакой ценности для продукта, сделать хороший (относительно UI/UX) компонент можно довольно быстро. Задача дизайнера — создать систему, интеграция которой обойдётся минимальным количеством костылей, в которой не будет кейса, где один и тот же компонент будет заюзан в N разных вариантах (не путать с состоянием компонента).
В моей жизни мне удалось поработать только один раз в жизни на проекте, где дизайнер настолько грамотно сделал систему, что наш фронтендер точно знал, где, что и почему должно находиться.
На последних 2 проектах был полный хаос в системе дизайна, который приводил к тому, что 1 новая страница в интерфейсе сервиса делалась 2 недели ввиду огромного количества вопросов дизайнеру.
Автор, огромное спасибо за эту статью!
Накидать базовых, оторванных друг от друга компонентов — это лишь первый этап (Атом).
Дальше начинается самое интересное — это проработка возможности комбинации атомов в молекулы, организмы, шаблоны (попутно порождая возможность адаптивности атомов/молекул/шаблонов). Для человека, который применяет данный подход — это кропотливый труд, с множеством удивительных хитростей, опытов и открытий. Но стоит применить данный подход однажды — и в следующие разы вы попросту не позволите себе совершить нечто вроде «Шаблон #5».
Справедливости ради стоит отметить — что дизайнер, который умеет верстать сразу понимает как нужно делать компоненты, и проектировать страницы. Вот почему для дизайнера интерфейсов важно уметь верстать… Иначе весь дизайн становится похож на учебник по вождению, от автора — который ни разу не садился за руль (уроки кама сутры от девственницы… если угодно).
PS
Если дизайнер понимает философию ООП, знает что такое CRUD, реляционная модель, и применяет это всё совместно с атомарным подходом — то это позволяет ему переиспользовать один и тот же компонент в зависимости от условий, порождая при необходимости экземпляры компонента наполненные данными контекста (что несомненно ускоряет разработку дизайна и упрощает работу программистам).
Решение проблемы поднятой в данной статье — это получить дизайнера интерфейсов, который понимает как работает код.
одиннадцать по-разному стилизованных селектов в одном UI-ките – это крайне продуманное решение.
Давно пользуюсь таким лайфхаком — игнорирую разнобой в «ui-ките». Очень помогает сохранить энергию.
Поясню:
Есть пять разных видов какого-то контрола, которые визуально отличаются, но цель контрола одинаковая. Выбрал один и использую его везде, даже если по дизайну в каком-то месте используется другой вариант.
Когда встаёт вопрос — а почему здесь не по дизайну? Эскалирую на менеджеров и спрашиваю — мне пилить новые фичи, или делать новый вид селекта только для этого места? также сразу озвучиваю риски усложенения кода, поддержки и сроки реализации.
Обычно встают на мою сторону — типа что за вопрос, конечно фичи делай.!
Также заметил следующую закономерность. Обчычно «здесь не по дизайну» — это даже не дизайнеры подымают вопрос, а ручные тестировщики которым нужно показать хоть какую-то деятельность. Дизайнер может и не заметил бы, и вполне понимает без обид что да, здесь он проглядел и почему-то нарисовал другой селект… мало ли запара у человека, или параллельно ведёт несколько проектов.
P.S. вот даже сейчас, смотрю разные кнопки «отмена» — где-то серенькие просто, где-то с обводкой, где-то как ссылки. И разные паддинги у кнопок (вот захотелось дизайнеру подогнать ширину кнопки под какой-то наружный элемент). Я не трачу энергию на спор и выяснение почему так. Просто игнорю этот разнобой и использую везде одинаковые кнопки. Встанет вопрос — буду обсуждать по схеме выше..)
Главное чтоб продукт работал, визуальные вещи потом можно подправить при сильной необходимости.
Они рисуют дыры в бюджете. Что не так с вашими дизайнерами?