Comments 36
А если еще и многократно, пока тестируешь…
Причем тут вообще «4», непонятно…
Про «дачную скатерть» сказано метко, но особой проблемы нет. Во-первых, сетка многослойная. Лишнюю разлиновку можно держать по умолчанию скрытой, если мешает. Во-вторых, «магнитная» привязка работает даже если сетка едва видимая или прозрачная. На скринах она ярче раз в 5, чем нужно — для иллюстрации.
Представьте себе open source проект, в который могут коммитить совершенно посторонние люди. Там максимальный профит от стандартизации, потому что без неё каждый лепит по-своему. Кому-то нравится паддинг 5 пикселей, кому-то 3; кто-то считает с учетом border-box, кто-то нет и т.п. Никаких ресурсов не хватит делать ревью визуально для каждого такого коммита. А при наличии системы можно и людей обучить, и ревью частично автоматизировать.
В студии профит не так очевиден, но принцип тот же.
Спасибо, хорошая статья. Мне как верстальщику приятно осознавать что где-то есть такие дизайнеры как автор:) Низкий поклон! Насчёт "магических чисел" всегда чувствовал некий дисбаланс, т.к. зачастую дизайнеры ставят размеры шрифтов и типографические значения, к которым очень хорошо назначить базовый размер 16px, но при этом паддинги и гаттеры идут бутстраповские, типа 15, 20px. Ещё один момент заметил в статье. Я не гуру в БЭМ, хотя очень его люблю. И мне всё-таки кажется, что Модификатор — это то что обычно ставят после "_", а то что идёт после имени Блока (после "") — это Элемент. По крайней мере я так делаю, на истинность не претендую. В любом случае спасибо, читать было интересно! Во многих конфликтах узнал себя и команду :)
Классический синтаксис БЭМ:
// Модифицированный элемент блока:
.block__element_modifier
// Модифицированный блок:
.block_modifier
Если где-то текст не соответствует, тыкайте меня носом, подправлю :)
Спасибо за комментарий!
Связка «&__» означает, что слой является «Элементом» (в терминах БЭМ).
должно же быть "&_" если это про Элемент.
А вот тут:
Например, «block_hover» — это компонент «блок» в состоянии :hover, а «widget_collapsed» — это компонент «виджет» в свернутом состоянии.
Я немного иначе понимаю. Опять же, я не профи в БЭМ, возможно я его неправильно использую, но я делал бы так: если есть блок widget, у него элемент title и нам нужно например его состояние collapsed. То я бы скорее отнес collapsed к Модификатору, соответственно получился бы widget_title__collapsed.
Да и я сам хорош — в своем комментарии получилась путаница, у меня там в скобках неправильно нижние подчеркивания получились:) Впрочем, как раз штука в том, что с этим я не совсем согласен:
// Модифицированный элемент блока:
.block__element_modifier
// Модифицированный блок:
.block_modifier
Я привык наоборот: block_element__modifier.
Наверное потому и глазала намозолило =)
Есть ещё несколько популярных альтернативных схем (они тоже есть там по ссылке, к концу ближе). У каждой есть плюсы, в зависмости от того, какие языки или фреймворки применяются в проектах чаще. Но ваша схема уникальна :) Нигде не встречал.
В принципе, если ваши коллеги не возражают, то можно и так, наверное. Но при смене коллектива та же путаница будет постоянно возникать. Возможно, есть смысл вернуться к классике :)
По-большей части все верно, спасибо. И отдельное спасибо за фразу со словами "немытым курсором", она зарядила меня с утра :)))
Илья, привет! Нам очень нужны такие люди как ты :) Не знаю где ты и над чем работаешь, но мы бы с удовольствием взяли тебя к нам в СМЕНу в частности работать над цифровой дизайн системой государства и на другие большие и интересные проекты :) Если интересно напиши мне плз ag@lab.ag
Спасибо за Ваш труд по написанию статьи. Для меня она оказалась той соломинкой, которая поможет не утонуть в океане информации. Перечитала и посмотрела бешеное количество информации по построению сеток. В итоге, была полная каша в голове. В статье дано чёткое объяснение: зачем, как и почему именно так для конкретных случаев. Кроме этого стало понятно, как верстать с макета на Фигме, на который я смотрела больше месяца, не зная с какого бока подступиться. Удачи Вам во всех делах.
А всего лишь нужно научить дизайнера верстать, уволить верстальщика и Фигма не будет нужна. :)
К слову, если брать именно UI, то при жестком выборе из набора «дизайнер, верстальщик, „Фигма“» я бы оставил все-таки верстальщика :)
Мне кажется, что у дизайнера который научился верстать, больше фич, чем у верстальщика, которого скорее всего заставляют быть дизайнером, а сам он, скорее всего, собирается стать программистом :).
Интересно, минусуют дизайнеры, которые считают, что им не нужно уметь верстать или верстальщики, которые боятся остаться не у дел? :)
Спасибо за статью, осилила всю. Я дизайнер, было мало понятно с именованием. Придётся прочесть второй, а может и третий раз, чтобы понять и применять)
Вам не кажется, что понятие «дизайн система», должна исключать ситуации, когда дизайнер, может создать уникальный специфичный элемент, который никогда и нигде не будет переиспользован и будет жить сам по себе вне дизайн системы, брошенный и неучтенный?
Если уникальных специфичных элементов будет много, то где будет та системность, ради которой все создавали и создают «Дизайн Систему»?
Не надо пытаться загнать в компоненты абсолютно всё. В любом проекте есть специфические вещи, которые используются однократно или имеют риск погибнуть в боях с правками заказчиков — не завязывайте на них родительские библиотечные компоненты, чтобы не зависеть от ненадёжных и слишком нетипичных узлов.
Считаю что все элементы, которые рождаются на этапе дизайна, а затем идут в работу, обязательно должны быть в конечном счете(после всех правок, игрищ и согласований) оформлены как компоненты, даже если его переиспользование в будущем под большим сомнением.
Дизайнер, может каждый день рожать уникальные компоненты, не продумывая их жизненный цикл, и как наркоман говорить, что это в последний раз, продолжая создавать все больше и больше таких элементов. Те правильные вещи, о которых вы пишите в статье, на мой взгляд, немного отрезвляют дизайнера. Его энтузиазм, запилить что-то фееричное — гаснет, так как это надо все правильно раскидать по слоям, присвоить имена элементам, продумать как оно дальше будет жить, вести и т.д.
Но если мы всё-таки говорим о какой-то универсальной дизайн-системе, цель которой организовать рабочий процесс между дизайнером, верстаком и т.д. в общем потоке разных проектов, то тут речь будет скорее о рамочном соглашении , а не жестком стандарте не все случаи жизни. Иначе система начнет мешать в работе, потому что сами задачи могут быть разнородными.
Грубо говоря, например. Делаем на потоке промо-сайты, у каждого первый экран главной страницы представляет собой обложку с ярким коллажем с анимированными элементами. Логически такая обложка — компонент. Она есть на каждом сайте, имеет стандартное место в лейауте, стандартный размер, поведение брейкпоинтов и т.п. Но поскольку начинка обложки всегда разная (и в этом, собственно, её функция) унифицировать её толком мы не можем, да и выносить в библиотеку нет практического смысла, т.к. переиспользуется только голый фрейм.
Или другого плана пример. Рисуем контентную страницу, типа лонгрида. Логически в тексте много разных переиспользуемых компонентов: абзацы, врезки, цитаты, списки, мелкий текст и т.п. Но если делать их именно компонентами (отдельными блоками-экземплярами), то при любом изменении объема текста вся колбаса поедет и нужно будет руками переставлять все блоки. Если же считать компонентом родительский фрейм (весь контейнер с текстом статьи), то его не получится переиспользовать, потому что структура врезок, цитат и т.п. не совпадёт. Переиспользуемым в данном случае является оформление элементов, а не сам текст. Поэтому в «Фигме» такие вещи выносятся в стили, а не компоненты. И соответственно, на уровне «Фигмы» такие текстовые слои лучше оставлять как есть, вне компонентов. Предполагая, что на уровне верстке они имеют произвольную разметку, которая может содержать в себе компоненты, примеси и т.д.
Словом, дизайн-система и её техническая реализация дадут некоторую разбежку по-любому. Поэтому я сторонник того, чтобы стандарт вычленялся из кейсов. То есть стандартизировалось только то, что на практике повторяется и переиспользуется.
Плюс, по чисто личному ощущению, темп развития «Фигмы» выше, и есть ненулевая вероятность, что она со временем перекроет функционал Зеплина собственным, развив свой read-only режим в полноценный интерфейс для разработчиков.
Про именование вещей — вообще не понятно причем тут дизайнеры. Что творится в кодобазе это дело разработчиков. Фронтендеры сами должны принимать все решения на эту тему.
Спасибо за труд!
Как подружить дизайнера, верстальщика и «Фигму» с помощью дизайн-системы, ломика и какой-то матери™