Системы декларативного проектирования

Когда я писал об идее декларативного проектирования, она нашла отклик у многих людей.

Я думаю, что существует общее чувство разочарования от императивного подхода к проектированию и разработке — попытка указать все точно заранее. Это просто не масштабируется. Как сказал Джейсон, традиционный процесс веб-дизайна фундаментально сломан:

Это худший из всех миров — водопадный процесс, создающий десятки артефактов, ни один из которых не отражает то, как дизайн будет выглядеть и вести себя в браузере.

Теоретически, системы проектирования могли бы помочь преодолеть эту проблему; потратьте много времени на то, чтобы компонент был правильным, и тогда его можно будет быстро развернуть в самых разных ситуациях. Но слово «правильный» здесь выполняет большую работу.

Если вы подходите к системе проектирования с императивным мышлением, то «правильный» означает «точный». При таком подходе точность рассматривается как ценность: точные интервалы, точные числа, точные пиксели.

Но если вы подходите к системе проектирования с декларативным мышлением, то «правильный» означает «гибкий». При таком подходе гибкость рассматривается как ценность: гибкие интервалы, гибкие диапазоны, гибкие выходы.

Это два принципиально разных подхода к проектированию, и все же результаты обоих подходов можно назвать системой проектирования. Термин «система проектирования» и так достаточно сложен для определения. Это еще один слой потенциального непонимания: один человек говорит «система проектирования» и имеет в виду набор очень точных, контролируемых и точных компонентов; другой человек говорит «система проектирования» и имеет в виду предопределенный набор граничных условий, которые могут быть использованы для создания компонентов.

Лично я считаю, что слово «система» является важной частью системы проектирования. Но слишком часто системы проектирования на самом деле являются скорее коллекциями, чем системами: коллекция предварительно сгенерированных компонентов, а не система для создания компонентов.

Систематический подход лежит в основе декларативного дизайна; заранее устанавливаются правила и соотношения, но детали окончательной реализации оставляются на усмотрение браузера во время выполнения.

Позвольте мне привести пример того, что я считаю декларативным подходом к компоненту. Я буду использовать «мир приветствия» компонентов системы дизайна — скромную кнопку.

Два года назад я писал о программировании CSS для выполнения цветовых функций Sass. Я описал, как такие возможности CSS, как пользовательские свойства и calc() могут быть использованы для воссоздания таких миксинов, как darken() и lighten().

Я показал несколько CSS для объявления различных цветов элементов кнопки с использованием оттенка, насыщенности и светлоты, закодированных как пользовательские свойства. Вот CodePen с некоторыми примерами различных кнопок.

Посмотрите цвета кнопок Pen Button от Джереми Кита (@adactio) на CodePen.

Если бы эти кнопки находились в императивной системе проектирования, то вывод был бы важной частью. Система проектирования предоставила бы код, необходимый для создания именно таких кнопок. Если бы вам понадобилась другая кнопка, ее пришлось бы добавить в систему проектирования в качестве вариации.

Но в декларативной системе проектирования вывод не так важен, как основополагающий набор правил. В данном случае есть такие правила, как:

Для состояния наведения кнопки светлота ее фонового цвета должна уменьшиться на 5%.

В итоге это кодируется в CSS следующим образом:

button:hover {
    background-color: hsl(
        var(--button-colour-hue),
        var(--button-colour-saturation),
        calc(var(--button-colour-lightness) - 5%)
    );
}

Войти в полноэкранный режим Выход из полноэкранного режима

В такой системе дизайна вы можете посмотреть на некоторые примеры, чтобы увидеть результаты этого правила в действии. Но эти результаты являются иллюстративными. Они не являются последним словом. Если вы не видите именно ту кнопку, которая вам нужна, ничего страшного; вы получили информацию, необходимую для создания того, что вам нужно, и при этом не выходите за рамки заданных правил, скажем, о состоянии наведения кнопок.

Такой подход кажется мне более масштабируемым. Он также кажется более эффективным.

Одна из самых трудных частей внедрения системы дизайна в организации — заставить людей принять ее. По моему опыту, никому не нравится принимать что-то, что поставляется сверху в виде готовых наборов компонентов. Это должно быть полезно: «вот, используйте эти готовые компоненты, чтобы сэкономить время и не изобретать колесо», но это может выглядеть как чрезмерный контроль: «Мы не доверяем вам в том, что вы проявите здравый смысл, поэтому придерживайтесь этих готовых компонентов».

Декларативный подход менее контролирующий: «вот заранее определенные правила и рекомендации, которые помогут вам в создании компонентов». Но за отсутствие точности приходится платить. Люди, использующие систему проектирования, должны обладать мышлением и способностью создавать необходимые им компоненты на основе предоставленных им систематических правил.

Моя интуиция подсказывает, что императивное мышление хорошо подходит для большинства современных инструментов графического дизайна, таких как Figma или Sketch. Эти инструменты работают с точными числами, а не с диапазонами и правилами.

С другой стороны, декларативное мышление все больше кажется подходящим для CSS. Язык развился и позволяет устанавливать правила через пользовательские свойства, calc(), clamp(), minmax() и так далее.

Поэтому, как всегда, здесь нет правильного или неправильного подхода. Все сводится к тому, что наиболее подходит для вашей организации.

Если ваши дизайнеры и разработчики придерживаются императивного мышления, а файлы Figma считаются источником истины, то им больше подойдет императивная система проектирования.

Но если вам повезло иметь команду инженеров-проектировщиков, которые мыслят в терминах HTML и CSS, то декларативная система проектирования станет для них мощным инструментом. Велосипед для инженеров-проектировщиков.

Оцените статью
Procodings.ru
Добавить комментарий