Блог Михаила Озорнина: заметки с тегом фронтенд

Как выглядит хороший макет

Михаил Озорнин — Tue, 11 May 2021 10:19:02 +0300

В продолжении тредов Романа Шамина про дружбу дизайнеров и фронтендеров решил вытащить в блог одну из статей наших гайдов — про то, что такое «хорошо переданный макет». Все вытащенные из гайдов статьи доступны по тегу гайдлайны.

Треды Романа Шамина:
teletype.in/@romanshamin/what-design-want-from-frontend
teletype.in/@romanshamin/what-frontend-want-from-design

Дальше привожу статью из наших командных договоренностей.

О чем эта статья

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

Эта статья описывает как хорошо передать макет в разработку.

Хранение и состав макетов

Список самих экранов

Уровень «Минимально достаточный»
Всем членам команды продукта понятно где и как искать макеты:

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

Договоренности команды о процессе выкладывания макетов записаны.

При обновлении макетов уведомляется проектная команда (аналитик, фронтенд, тех. писатель, QA).

Состав экранов

Уровень «Минимально достаточный»
Для фичи понятен набор экранов, на которые вносятся изменения: какие экраны новые, какие экраны дорабатываются.

Если экранов несколько, то понятны переходы между экранами.

Уровень «Хорошо»
Доступна актуальная схема экранов продукта (карта сайта).

Если в фиче несколько экранов, то для них сделан кликабельный прототип с переходами между экранами.

Экраны

Структура экранов

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

Как ведут себя блоки экрана при прокрутке и ресайзе.

Уровень «Хорошо»
У продукта есть понятная сетка, описаны типовые лейауты страниц: список, дашборд, форма редактирования, страница просмотра и т. д.

Элементы на странице

Уровень «Минимально достаточный»
По каждому визуальному элементу на макете понятно, что это такое: текст, компонент, иконка, паттерн.

По каждому компоненту понятно, что это за компонент, какой его режим используется, понятно, если в коде нет этого компонента или функции существующего компонента.

Понятны размеры элемента, его взаимоотношения с соседними элементами.

Понятно как элемент тянется, что будет, если в элементе будет меньше или больше контента.

Уровень «Хорошо»
Все элементы описаны, разработчик знает где искать документацию на каждый используемый тип элемента: текст, компонент, иконку, паттерн.

Размеры элементов и отступы между элементами логичны, ожидаемы и понятны.

Примеры:

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

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

Хорошо: Размеры блоков понятны

Хорошо: Размеры блоков понятны, блоки расположены предсказуемо по сетке

Кегли

Уровень «Минимально достаточный»
Для каждого текста на странице понятен стиль или mixin, который нужно взять, эти стили и mixin’ы однозначно определяются из самого макета.

Эти mixin’ы не противоречат компонентам, паттернам или аналогичным элементам других экранов продуктов.

Уровень «Хорошо»
Есть актуальная таблица миксинов, описаны общие принципы их использования.

Примеры:

Плохо: Кегль не замапплен, неясно какой типографический миксин взять

Хорошо: Кегль и цвет замапплен, понятно что указать

Цвета

Речь идет про цвет любого интерфейсного элемента: текста, иконки, рамки, фона, блока, линии.

Уровень «Минимально достаточный»
Не используются цвета не из палитры проекта.

Переменные цветов подписаны, разработчику легко понять, какую переменную использовать (копировать hex-код не норм).

Уровень «Хорошо»
Составлена таблица цветовых токенов: default text, disabled text, error icon для всех используемых в проекте тем.

В макетах прилинкованы цвета из этой таблицы (не error-500, а validation-text-color).

Примеры:

Плохо: Цвета не замаплены, неясно какой цвет выбирать

Хорошо: Цвета замаплены, понятно что указать

Отступы

Уровень «Минимально достаточный»
Понятны сами отступы между всеми блоками на странице и их внутренняя логика.

Отступы на макете не противоречат компонентам (например, в компоненте «кнопка» отступы 6 16, а на макете 6 12).

Уровень «Хорошо»
Описана интерфейсная микросетка и описание модулей.

Логика отступов описана, есть типовые отступы и их завязка на сетку.

Пиктограммы

Уровень «Минимально достаточный»
Разработчик знает, как вообще подключаются пиктограммы в проект.

Понятно, что это за конкретная пиктограмма, как ее подключить и вставить.

Уровень «Хорошо»
Есть общий список пиктограмм, их коды, параметры вставки в код продукта и документацию.

Иконки версионируются, к продукту или в документацию можно подключить нужную версию пакета иконок.

Примеры:

Плохо: Иконка не замаплена, нужно искать её в наборе самостоятельно

Хорошо: Указано какая иконка и из какого набора. Примечание: mc — префикс одного из наших наборов иконок.

Текст

См. также Правильный процесс вычитки (ссылки нет, статья не вытащена наружу).

Уровень «Минимально достаточный»
Рыба в макете правильная с точки зрения состояний, смысла и точная с точки зрения чисел и значений.

Нет никаких Значение-1, Значение-2, Значение-3 и Лорем ипсумов.

Из текста понятно, о чем он: это важно, чтобы техписатели могли его понять и улучшить.

Уровень «Хорошо»
Текст в состоянии production-не стыдно, техписатели только полируют его.

Состояния

Другие состояния

Уровень «Минимально достаточный»
Понятно, как сделать все остальные состояния: переключенные вкладки, переключатели, чекбоксы и радиокнопки (если они влияют на компоновку интерфейса).

Отрисованы или описаны (если этого достаточно) все варианты дропдаунов, селектов и других выпадаек.

Кроме самих этих состояний описаны переходы между ними.

Уровень «Хорошо»
Если блоки меняются значительно, то лучше не пытаться описать отдельные выпадайки, а нарисовать блоки целиком, чтобы было меньше путаницы

Пример:

Хорошо: Нарисованы альтернативные состояний экрана

Загрузка

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

Как должен вести себя продукт, если загрузка медленная, элементов много, или загрузка не удалась.

Пустое состояние

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

Уровень «Хорошо»
Пустые состояния систематизированы, используются типовые решения.

Пример:

Валидация

См. Валидация данных

Уровень «Минимально достаточный»
Понятно, когда и как срабатывает валидация.

Как и когда показывается.

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

Уровень «Хорошо»
Валидация соответствует общему гайдлайну.

Валидация способствует не попаданию с ситуацию срабатывания валидации.

Много данных

Уровень «Минимально достаточный»
Понятно как работает экран, когда во всех потенциальных местах (текст, списки, таблицы) будет много данных.

Все вытащенные из гайдов статьи доступны по тегу гайдлайны.

См. также

Гайд Контура: guides.kontur.ru/principles/layouts/
Чек-лист Prit4er1: notion.so/5c03c7554ff542da9c77a6f420935282

Как включить темную тему на сайте

Михаил Озорнин — Thu, 13 Dec 2018 10:49:51 +0300

Темная тема — модно, все включают её себе в макоси (на следующий день, конечно, выключают обратно). Часто выключают потому, что сама тема темная, а весь контент вокруг (письма, сайты) — светлые. Светлый контент бьет по глазам своей яркостью.

Некоторые сайты включают темную тему исходя из времени суток. Например, Авиасейлз:

Скоро наступит будущее (UPD. Наступило в macOS 10.14.4)

В самой новой версии Сафари (Safari Technologies Preview) уже появился детект темной темы внутри браузера. В macOS 10.14.4 эта поддержка появился в обычном сафари.

Из браузера можно узнать установлена ли темная тема у посетителя и сделать немного магии. Светлая:

Темная:

Тем, у кого есть новый Сафари 68+ можно попробовать здесь:

mikeozornin.ru или mikeozornin.ru/blog

Как включить детект

Чтобы включить темную тему используется медиа-запрос prefers-color-scheme:

@media (prefers-color-scheme: dark) {
    //какие-то отличия темной темы, от светлой
}

Чтобы отлаживать, не включая-выключая системную тему, в Сафари (в той самой Technologies Preview) есть кнопка включения темной темы локально в браузере:

Если кому-то интересно как сделана темная тема, то кроме css-файла на сайте есть less-файл на гитхабе. Но осторожно, там очень много быдлокода и костылей.

Как собрать шрифт с иконками — 2

Михаил Озорнин — Tue, 09 Jan 2018 12:12:15 +0300

С момента первого поста я доработал схему сборки, расскажу что и зачем там сделано. Сначала будет вступление-рассказ о чем все это, если вы хотите нового, прокрутите до заголовка «Новое в этой версии».

Что вообще происходит

У дизайнера есть несколько разных способов передать иконки разработчику:

отдельными файлами или спрайтом в ПНГ,
отдельными файлами или спрайтом в СВГ,
иконочным шрифтом.

Разработчики фронтенда все чаще привыкли использовать иконки в виде шрифта. Этим же способом распространяются популярные иконочные наборы (например, Font Awesome). У нас в компании разработчики тоже просят «дай шрифт». Мы некоторое время отлаживали схему сборки шрифта: как из файла Скетча автоматически получить файл, пригодный для фронтенда, не замучив дизайнера.

Рассказ может быть полезен разработчикам фронтенда и дизайнерам интерфейсов. В меньшей степени он будет полезен бекендным разработчикам интерфейсов (классический ASP.NET MVC или что-то подобное): схема будет та же, но не будет готовых файлов конфигураций и скриптов. Если кто-то расскажет как прикрутить к этому NuGet, напишите, я добавлю.

Зачем это делать, есть же фонтелло

Есть много готовых сервисов, которые собирают шрифт по загруженным СВГ-файлам, например fontello. Мы не стали использовать ни один из них, потому что с ними могут быть сложности:

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

Хорошее решение — простое, в нем минимум ручных действий.

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

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

Cложно интегрировать в общий процесс сборки продукта. Отдельно стоящий сервис тяжело встроить в общий процесс разработки и сборки, а у кого-то есть еще и процесс CI. Придется вручную собирать сервисом файл, куда-то его загружать и как-то версионировать.

Хорошее решение встраивается в процесс разработки.

Не всех устраивает внешний сервис. Многие компании не верят во внешние сервисы: они могут изменить набор функций, упасть во время подготовки релиза, стать платными или закрыться. В конце концов, их могут хакнуть. Мы — ИБ-компания, и каждый раз раздражать профессионально деформированных безопасников и разработчиков наличием внешнего сервиса не хочется.

Хорошее решение работает внутри компании.

Формируется не всё, что надо. Некоторые сервисы выдают шрифт, а иконки кодируют номерами символов. К сожалению, на эти номера полагаться нельзя. Если убрать иконку или поменять порядок, то в следующий раз сервис может выдать совсем другие коды и все иконки непредсказуемо поменяются.

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

Хорошее решение дает разработчикам все что нужно. Иконка кодируется понятным названием, коды символов и размер подставляются автоматически.

Новое в этой версии

Раньше я описывал схему сборки шрифта, которая позволяет автоматически собрать шрифтовой файл с иконками из исходника Скетча, сгенерировать для него демо-страницу и ЛЕСС-файл, а также опубликовать пакет в НПМ-репозиторий.

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

Поставка иконок в виде библиотеки Скетча

С момента написания того поста вышла новая версия Скетча — 47, в ней появились библиотеки символов. Иконки стало удобно вставлять в макеты именно с помощью библиотеки.

Чтобы сделать один символ на одну иконку и не плодить их для каждого цвета, нужно сделать так:

Сделайте по символу для каждого цвета, в которые у вас можно красить иконки.

Нарисуйте иконку и наложите её маской на символ цвета:

После этого вы сможете менять цвет иконок через оверрайды:

Образец файла: iconset.sketch

К сожалению такой скетч-файл плохо собирался в шрифт. Это происходит из-за маски.

Маска правильно экспортируется в СВГ-файл, но в шрифте нет понятия маски, в итоге иконки ломались. Долгое время я вел скетч-файл в двух вариантах: простые артборды для шрифта и такие же с маской для библиотеки. Но это плохой способ: нужно добавлять и изменять пары одинаковых иконкок. Из-за этого иногда были ошибки — я что-то где-то забывал.

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

Для вырезания лишнего я подключил grunt-text-replace, вот его конфиг:

replace: {
  remove_mask: {
    src: [PATH_BUILD_ICONS + '/*.svg'],
     overwrite: true,  // overwrite matched source files
     replacements: [
      {from : / fill="(.*?)"/m,             to : ''},
      {from : /(\s*)<\/defs[\s\S]*<\/g>/m,  to : ''},
      {from : /(\s*)<defs>/m,               to : ''},
      {from : / id="(.*?)"/m,               to : ''},
      {from : /xmlns:xlink="(.*?)"/m,       to : ''},
      {from : /(\s*)<g[\s\S]*?>/m,          to : ''},
      {from : /(\s*)<\/g>/m,                to : ''},
      {from : /<svg/m,                      to : '<svg fill="#000"'},
      {from : / transform="(.*?)"/m,        to : ''},
      {from : / fill-rule="(.*?)"/m,        to : ''},]            
    }
  }

Поставка иконок в виде ТТФ-файла

У нас в компании есть команда технических писателей, которые пишут руководства по продуктам. В руководствах техписатели вставляют иконки, чтобы проиллюстрировать на что нужно нажать в интерфейсе.

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

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

Идеальным вариантом для них было бы использовать ТТФ-шрифт: он отлично рендерится на экране и при печати, хорошо автоматизируется и удобно перекрашивается.

Однако недостаточно просто включить генерирование ТТФ-файла: по умолчанию коды символов формируются сборщиком автоматически. При следующем формировании шрифта код иконки мог замениться на произвольный. Если технический писатель вставлял иконку в документ, и обновлял шрифт, часть иконок могла непредсказуемо поменяться на другие. Так, конечно, никуда не годилось.

В новой версии вместо автоматического выбора кодов символов я задаю их руками. Меинтейнер шрифтового репозитория (это я) выдает каждой новой иконке новый код и следит за тем, чтобы коды не менялись. Для этого используется секция codepoints в grunt-webfont. Каждой иконке нужно задать номер символа. У нас используется последовательная нумерация начиная с 0xF501.

codepoints : {
   'upload-to-cloud_24' : 0xF501,
   'upload-to-cloud_64' : 0xF502,
},
startCodepoint: 0xF701,

Иконкам, которым номер не выставлен вручную, код выберется автоматически. Вообще это неправильно и лучше следить, чтобы таких иконок не было. Чтобы найти такие иконки их пространство имен отличается, им выдается номер из пространства 0xF701+, поэтому они всегда будут в конце шрифта и их легко найти.

Посмотреть коды символов можно с помощью http://opentype.js.org. Выбираете Glyph Inspector, загружаете шрифт и смотрите:

Наши писатели перешли на ТТФ-файл и довольны.

Скачать и посмотреть

Я обновил репозиторий решения, там есть пример файла и сборщик. Чтобы понять как и что — прочитайте README.md. Скачивайте и смотрите:
https://github.com/mikeozornin/icon-font-public

Что дальше

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

С вопросами, багрепортами или советами — в телеграм @mikeozornin или на почту mike.ozornin@gmail.com.

Как собрать шрифт с иконками

Михаил Озорнин — Thu, 26 Jan 2017 12:21:17 +0300

Разработчики иногда просят иконки не в пнг или свг, не пнг-спрайтом, а в шрифте. Им проще его так использовать. В посте я расскажу как из скетч-файла собрать шрифт, чтобы всем было удобно в будущем.

UPD. Появилась более новая версия сборки

Зачем это делать, есть же фонтелло

Есть много сервисов, которые собирают шрифт из загруженных свг-файлов. Зачем придумывать что-то своё?

Чтобы случайно не сломать шрифт. Если забыть иконку, которую уже выдавал и не загрузить в фонтеллу, то она не попадет в новый шрифт и где-то в интерфейсе пропадет иконка.
Подойдет, если дизайнеров несколько. Если дизайнеров в команде несколько, то нужна синхронизация между ними. Было бы круто, если бы каждый мог добавлять в шрифт иконки и не сломать чужой результат.
Легко встраивается в ваш CI-процесс.
Не всех устраивает внешний сервис. Внешний сервис может быть недоступен, он может внезапно обновиться, стать платным, и вообще не все готовы отдавать наружу свои иконки.
Разработчику сразу формируется и less-файл. Обмениваться кодами символов неудобно, они генерируются автоматически и могут измениться, использовать css-класс надежно, он не поменяется.

Вариант 1. Собираем и отдаём шрифт

Я выложил все необходимые файлы в репозиторий icon-font-public, скачайте его и распакуйте куда-нибудь.
Скачать: https://github.com/mikeozornin/icon-font-public/archive/master.zip

Шаг 1. Настраиваем среду

Все эти заклинания надо произнести один раз, дальше не понадобятся

1) Установить brew. Brew — это такой менеджер пакетов, который легко позволяет ставить программы и библиотеки. Выполнить в терминале команду:

/usr/bin/ruby -e "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install)"

2) С помощью brew установить шрифтообработчики:

brew install ttfautohint fontforge --with-python

3) Установить node.js, скачать тут https://nodejs.org/en/ current-версию.

4) Установить SketchTool
При установленном Sketch выполнить в терминале команду:

/Applications/Sketch.app/Contents/Resources/sketchtool/install.sh

5) Установить grunt

npm install -g grunt-cli

Шаг 2. Сборка файла шрифта

Для сборки шрифт нужно произнести в терминале заклинание:

./build.sh

Если в первый раз не сработает, сделайте скрипт выполняемым:

chmod +x build.sh

В итоге при добавлении иконки нужно будет сделать:

Нарисовать иконку.
Собрать шрифт: ./build.sh
Отдать файл шрифта и less-файл разработчику

Что все это было?

Всё, что описано выше работает так:

С помощью SketchTool всё, что может быть экспортировано, экспортируется из скетча в СВГ-файлы.
СВГ-файлы, полученные на шаге выше собираются в шрифт. Для этого запускается сборщик шрифта, который все СВГ-файлы собирает в шрифт, конвертирует его в нужный формат и формирует хтмл-страницу с превью.

Вариант 2. Собираем и отдаём шрифт npm-пакетом

Это ещё что такое?

Фронтенд-разработчики подключают библиотеки через npm-пакеты. Это привычная и удобная для них среда, кроме этого, npm-пакет сделает передачу шрифта удобней.

Шаг 1. Настраиваем среду

Нужно настроить среду как в первом варианте, и дополнительно настроить локальный npm-репозиторий. Спросите вашего фронтендера как это сделать у вас в команде. Попросите его исправить файл package.json.

Шаг 2. Сборка файла шрифта

Нарисовать иконку.
Собрать шрифт: ./build.sh
Изменить версию пакета в файле package.json
Выполнить команду grunt publish
Передать разработчику шифровку «Выпустил пакет версии xxx».

Вариант 3. Собираем и отдаём шрифт нугет-пакетом

К сожалению про нугет ничего не знаю, но если кто-то соберет рабочий вариант, добавлю.

На что обратить внимание при рисовании иконок

При экспорте иконок надо не забыть перевести все в кривые. Чего не должно быть:

Радиусов скруглений
Покрашенным рамок
Текстовых надписей

Если это будет, то иконка может выглядеть в шрифте плохо, даже если в СВГ-файле было всё ок.

Если что-то не работает

Я обкусывал наше решение, возможно что-то переобкусал. Пишите если что-то не работает, или попросите помочь вашего фронтендера, он разберется.