Каковы видение системы дизайна Discourse?

Я бы с радостью создавал кастомные темы и компоненты, которые соответствуют системе дизайна Discourse и гармонично вписываются в приложение, обеспечивая единообразие.

Однако, просто глядя на код и изучая то, как в ядре определяются и применяются стили, мне трудно понять общую картину и envisioned направление развития системы дизайна.

Я постараюсь разбить это на три основные темы: цвет, типографика и отступы.

Цвет

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

В новом коде ядро использует обе модели. Есть ли долгосрочный план продолжать использовать их параллельно, или же существует иное видение?

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

Типографика

В настоящее время определены три различных типа прогрессии размера шрифта:

Эти определения не обновлялись уже более двух лет. Следует ли вообще использовать их в новом коде? Честно говоря, я никогда не трогал определения множителей, так как сложно определить итоговый размер шрифта. Также я не понимаю определения базового шрифта. Определенная шкала была бы следующей:

  • 13px - 14px - 15px - 17px - 19px

Но когда я смотрю на реальные размеры шрифтов, используемая по умолчанию шкала выглядит примерно так:

  • 13px - 15px - 17.25px - 22px - 26px

Отступы

Я вижу, что новые элементы, такие как боковая панель, вводят корневые переменные для отступов. Например:

image

Это, безусловно, упрощает настройку макета боковой панели. Однако это не распространяется на другие элементы макета. С другой стороны, я не вижу введения фундаментальных переменных отступов, которые позволили бы обеспечить более согласованную настройку макета во всем приложении. Планируется ли это в дорожной карте?

В целом

Было бы здорово узнать, есть ли планы перейти к более последовательной и простой системе дизайна?

Сейчас кажется, что слишком много несвязанных и автономных определений, что сильно затрудняет создание последовательного и ритмичного макета с ощущением легкости (и радости :slight_smile: ).

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

Это пересборка, где каждое значение отступа выбрано из очень простой геометрической прогрессии (2px/4px/8px/16px/32px/64px). А размеры шрифтов взяты всего из 4 значений:

С точки зрения дизайна просто не кажется необходимым такое количество уникальных определений, которое сейчас присутствует во всем приложении?

14 лайков

Это то, что мы хотели сделать, и к чему постепенно шли, шаг за шагом, но это не может произойти сразу. Каждое изменение, которое мы вносим, может вызвать регрессии тем на тысячах сайтов (и нам приходится исправлять многие из них для наших клиентов), поэтому внесение даже небольших изменений занимает много времени.

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

Нет никакого заранее заданного направления, кроме стремления к большей согласованности. Мы рассматривали возможность отделения базовых стилей, чтобы стандартный «безтемовый» Discourse содержал значительно меньше CSS (что могло бы упростить поддержку тем), но пока это лишь идея.

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

Наименьший/меньший/больший/наибольший размеры предназначены для настройки размера текста пользователем. В большинстве случаев их не нужно изменять.

Шкала em примерно основана на классической типографской шкале (например, The typographic scale). Более равномерно распределённая шкала, например 13–15–17–19, не создаёт достаточного контраста, и всё остаётся довольно маленьким, если не использовать много шагов. На классической шкале промежутки между значениями увеличиваются вместе с размером, что создаёт больший контраст.

Идея шкалы на основе em заключается в том, что всё в приложении может масштабироваться пропорционально, и отдельные разделы приложения также могут масштабироваться пропорционально. Таким образом, я могу сделать что-то вроде:

.sidebar-wrapper {
  font-size: 20px; 
}

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

Внутренняя обратная связь похожа на вашу: разработчики хотят точно знать, какой размер шрифта они получат, независимо от контекста, что является недостатком системы. В идеале нам не нужно было бы беспокоиться о точных размерах и можно было бы просто сказать: «это должно быть на шаг больше, потому что я хочу, чтобы оно было крупнее», но такая ментальная модель, похоже, не даётся легко.

Существует желание перейти к системе на основе rem, но, как упоминалось ранее, это изменение, вероятно, займёт много времени, поскольку затронет так много существующих сайтов. Я также предпочёл бы базовый размер по умолчанию в браузере 16 пикселей вместо наших 15 пикселей, но история аналогичная (раньше было 14 пикселей! так что мы хотя бы сделали один шаг вперёд).

Шкала rem используется для заголовков в обработанном содержимом постов, поскольку вложение тегов заголовков с использованием em позволяло пользователям бесконечно увеличивать текст, что приводило к проблемам с макетом.

Да, этот вопрос поднимался несколько раз… (Я снова звучу как заезженная пластинка, но…) это должно быть очень постепенным изменением, чтобы избежать регрессий на существующих сайтах. В настоящее время мы добавляем общие переменные в конкретных областях по мере их обновления, что является шагом в правильном направлении.

Скорость, с которой происходит всё это, понятно, немного разочаровывает, но большую часть истории Discourse у нас вообще не было штатного дизайнера на полную ставку. За последние пару лет команда дизайнеров выросла до семи человек (включая выделенных дизайнеров, работающих над проектами для клиентов, которые в основном происходят вне публичного поля зрения), так что, надеюсь, теперь мы сможем двигаться к большей согласованности быстрее.

12 лайков

Спасибо за разъяснения, Крис! Это действительно полезно.

Так что я сталкиваюсь с этим лишь в очень малом масштабе. Однако я считаю, что иногда было бы полезно изменить общее представление о продукте, чтобы показать, что Discourse развивается быстро.

Это было бы неплохо, но я полагаю, что всё равно потребовались бы более простые точки управления. Просто шаблонов очень много. Даже если каждый из них будет иметь более простой CSS, если я не смогу изменять их скоординированным образом, это всё равно будет много работы.

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

5 лайков

Думая об этом дальше… у меня могло бы быть несколько видений системы дизайна Discourse.

Discourse Design System-95

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

Система, абстрагирующая некоторые высокоуровневые компоненты. Для Discourse это могло бы касаться модерации, признания, информации и т. д.

Общая система паттернов для онлайн-разговоров. Похоже на фундаментальный масштаб системы, такой как Material Design.

2 лайка