Комментарии 18
Также хочу отметить, что в многих проектах не получается работать по этим принципам. В них есть нюанс: «Время — деньги». На разработку дизайн системы тратится много времени, сил и денег, поэтому идет отказ от дизайн системы в пользу скорости.
У меня дизайн-система есть всегда, но часто она в уме. Действительно материализовать ее часто не хватает ресурсов, или не имеет смысла, т.к. с продуктом дальше работы проводится не будут.
С другой стороны есть много шаблонов (в хорошем смысле), и дизайн собирается из готовых «кирпичиков». Меняются только свойства кирпичиков, а блоки из них кочуют из проекта в проект.
Что будет происходить с сеткой при растягивании окна браузера?
Например, на ширине 320px у Вас получается 40 клеточек по горизонтали. Растягиваем окно браузера до 400px — клеточки растягиваются или контент центрируется?
Например, на ширине 320px у Вас получается 40 клеточек по горизонтали. Растягиваем окно браузера до 400px — клеточки растягиваются или контент центрируется?
Вопрос не совсем по теме данной статьи. Но представьте artboard 360px в любой программе с сеткой с размером клетки 8px. Увеличьте artboard до 720px, количество клеток увеличится. Эти сетки используются для контроля на этапе проектирования. Т.е. ты знаешь что элементы будут у тебя соответствующих размеров и отступов. А это значит что отступа не кратного 8-ми не должно быть, к примеру. Если отступ кнопки от заголовка 8 px, то 12px или 11px он уже не может быть. А поведение контента в зависимости от размера окна браузера задается по другим факторам.
Я говорю о другом: в конечном итоге эта дизайн-система будет переноситься в браузер (не будем рассматривать вариант с другими платформами). Как Вы предлагаете в браузере реализовывать эту систему? Есть лишь два пути — растягивать клетки (fluid) или переключать артборды (adaptive) через брейкпоинты в медиа-запросах. Первый вариант нам не подходит, судя по всему. Остается второй. Что делать с артбордом на ширине экрана в 500px? Центрировать или прижимать к левой/правой стороне экрана?
Дизайн система не может быть перенесена в браузер, т.к. является сервисным руководством.
А ваш вопрос не имеет смысла без указания UX составляющих. Это как спросить у английского портного:
— Какой костюм получится, если мерять в сантиметрах и кроить на ткани шириной 1,35 метра?
— Отличный костюм, сэр.
А ваш вопрос не имеет смысла без указания UX составляющих. Это как спросить у английского портного:
— Какой костюм получится, если мерять в сантиметрах и кроить на ткани шириной 1,35 метра?
— Отличный костюм, сэр.
Я о том же :)
Что такое сервисное руководство и UX-составляющая?)
Дизайн-система создается, в первую очередь, для унификации UI и чтобы дать разработчикам библиотеку готовых паттернов. Вот так примерно это выглядит на схеме от Брэда Фроста, одного из первых людей, кто стал продвигать идею дизайн-систем в массы:
У автора поста я не увидел системы. Не увидел полноценный продукт.
У Гугла есть material design style guide. Вот это полноценная дизайн система. Там описано как это должно работать на разных устройствах, как элементы перестраиваются при смене ширины браузера, сколько миллисекунд длится анимация на каждом устройстве и так далее. Я задал вполне уместный и элементарный вопрос — как создатель системы продумал адаптивность. Если он планирует только рисовать кнопочки, то это не система, а обычный UI Kit)
Дизайн-система создается, в первую очередь, для унификации UI и чтобы дать разработчикам библиотеку готовых паттернов. Вот так примерно это выглядит на схеме от Брэда Фроста, одного из первых людей, кто стал продвигать идею дизайн-систем в массы:
У автора поста я не увидел системы. Не увидел полноценный продукт.
У Гугла есть material design style guide. Вот это полноценная дизайн система. Там описано как это должно работать на разных устройствах, как элементы перестраиваются при смене ширины браузера, сколько миллисекунд длится анимация на каждом устройстве и так далее. Я задал вполне уместный и элементарный вопрос — как создатель системы продумал адаптивность. Если он планирует только рисовать кнопочки, то это не система, а обычный UI Kit)
Первое. У автора приведен простейший пример для лучшего понимания. Автор приводит 5 правил для дизайн-систем, а не готовую систему. В четвертом правиле говорится о том, что вы спрашиваете.
Второе. Брэд Фрост, прикольный чувак, удачи ему, но не первый, и даже не один из первых. Дизайн-системы существовали еще до веба, и их использование перешло в веб из печатной отрасли вместе с самим дизайном.
Третье. «Что такое сервисное руководство и UX-составляющая?» — в гугл, или напрягитесь и подумайте сами. Ответ в самом вопросе )
Второе. Брэд Фрост, прикольный чувак, удачи ему, но не первый, и даже не один из первых. Дизайн-системы существовали еще до веба, и их использование перешло в веб из печатной отрасли вместе с самим дизайном.
Третье. «Что такое сервисное руководство и UX-составляющая?» — в гугл, или напрягитесь и подумайте сами. Ответ в самом вопросе )
Документирование и приведение примеров построения интерфейсов по вашей дизайн системе позволяет наладить мост между разработчиками и UI дизайнерами
Я попросил пример построения интерфейса, но в ответ услышал лишь «дизайн система не может быть перенесена в браузер».
Разговор у нас шел в контексте веб-дизайна, поэтому должно быть очевидно, что Фроста упомянул именно в этом качестве.
Давайте так: скажите, что по вашему есть дизайн система и за что я плачу деньги, когда нанимаю человека ее создать? Что за продукт я получаю в итоге?
Картинку с кнопочками по сетке?
PS:
UX к дизайн системам имеет очень посредственное отношение. Да и мало кто вообще занимается настоящим UX: проведение исследований с фокус-группами, сбор данных и дальнейшая аналитика.
UX к дизайн системам имеет очень посредственное отношение.
Собственно UI-kit+UX и дают дизайн-систему, т.е. сервисное руководство — что делать и как, если грубо. Далее система развивается вместе с проектом. Соответственно что будет входить в сервисное руководство напрямую зависит от проекта, требований заказчика и специалиста или команды, которая этот проект реализует. Общепринятых шаблонов нет.
Сначала меня удивило, как так аккуратно получился у Вас вертикальный ритм при высоте линии в 24px и размере шрифта 14px. А теперь понял — это скрины с редактора, типа Sketch. Там высотой линии считается расстояние между базовыми линиями соседних строк (интерлиньяж). В CSS все это работает немного иначе: текст центрируется по вертикали внутри линии, а следовательно в браузуре не получится уже так красиво.
Я еще давно писал в Adobe и создателям Sketch, просил добавить в редакторы браузерный line-height, чтобы на макете было сразу видно как он отобразиться в браузере, но никакого ответа так и не получил… А фича то очень актуальная.
Я еще давно писал в Adobe и создателям Sketch, просил добавить в редакторы браузерный line-height, чтобы на макете было сразу видно как он отобразиться в браузере, но никакого ответа так и не получил… А фича то очень актуальная.
С вертикальным ритмом есть две основные проблемы: тег small и img:
1) У вас базовая высота линии 24px, размер шрифта параграфа — 14px. Следовательно, чтобы ритм не сбивался, необходимо у small сохранять высоту линии и уменьшать размер шрифта. В браузере small имеет размер 0,8 относительно базового font-size. В нашем случае это составит около 10px и тогда межстрочное расстояние чрезмерно увеличивается.
2) У картинок, вставленных через img есть одно «неприятное» свойство — они сохраняют свои пропорции при масштабировании. Следовательно, при сжимании окна браузера, картинка лежащяя ровно по горизонтальной сетке начинает уменьшаться в размере и все элементы, лежащие под ней начинают смещаться вверх.
Мой изначальный вопрос про адаптивность был вполне серьезен и я реально хотел узнать как Вы решаете все эти проблемы. Только почему то Вы посчитали, что я придираюсь к вашей системе и заняли оборонительную позицию в беседе)
1) У вас базовая высота линии 24px, размер шрифта параграфа — 14px. Следовательно, чтобы ритм не сбивался, необходимо у small сохранять высоту линии и уменьшать размер шрифта. В браузере small имеет размер 0,8 относительно базового font-size. В нашем случае это составит около 10px и тогда межстрочное расстояние чрезмерно увеличивается.
2) У картинок, вставленных через img есть одно «неприятное» свойство — они сохраняют свои пропорции при масштабировании. Следовательно, при сжимании окна браузера, картинка лежащяя ровно по горизонтальной сетке начинает уменьшаться в размере и все элементы, лежащие под ней начинают смещаться вверх.
Мой изначальный вопрос про адаптивность был вполне серьезен и я реально хотел узнать как Вы решаете все эти проблемы. Только почему то Вы посчитали, что я придираюсь к вашей системе и заняли оборонительную позицию в беседе)
Я не обороняюсь :) В данной статье попытался вложить смысл, что нужно разрабатывать дизайн систему так, чтобы любой элемент сложив с другим элементом выглядел гармонично в соответствии с правилами которые разработали. Тот же бутстрап — готовая дизайн система. Конечно при адаптивности соблюсти вертикальный ритм несколько сложнее. Есть несколько способов решить проблему с картинками — например. О размерах текста тоже можно много говорить. И разумеется при 10px размера шрифта, высота строки 24px выглядит хуже. Но тут уж надо смотреть на картинку в целом. Соблюдать ритм до конца или где-то его нарушать. Рассматривайте статью как начальную. Где рассмотрен идеальный пример и идеальное решение. Я вообще планирую записать несколько видео на данную тему. Спасибо за Ваши вопросы. Мне очень приятно, что статья вызвала интерес.
А она у нас она будет аж из трех элементов.
Спасибо за материал! У вас ошибка (выделил в цитате)
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Дизайн система по Волкову