TV first, отзывчивая типографика или как не забыть о всех размерах девайсов

Добрый день, хабровчане! Не так давно я опубликовал перевод статьи "Полностью отзывчивый дизайн — это больше, чем просто медиа-запросы". В той публикации я пообещал рассказать вам, как я применял данную технику в своем проекте, с чем мне пришлось столкнуться и все связанные с этой техникой особенности, на которые обязательно стоит обратить внимание при разработке. В сегодняшней публикации я постараюсь выполнить свое обещание. Если вам интересен опыт практического использования техники отзывчивых шрифтов в реальном проекте, прошу под кат.

Итак, приступим. Коротко вспомним саму технику:

html {
  font-size: minimumPixel + range * ((viewportWidth - minScreenWidth) / maxScreenWidth)
}

/* Example */

html {
  font-size: calc(14px + 10 * ((100vw - 769px) / 2048));
}

Главный тезис я сформулировал так:

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

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

1. Какое приложение и с какой спецификой рассматривается в качестве примера для данной статьи?
2. Что такое отзывчивая типографика, какие она имеет минусы и плюсы?
3. Насколько эти минусы и плюсы актуальны для данной техники?
4. Реальные примеры и рекомендации применения техники на практике.

Примечание.

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

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

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

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

Начнем по порядку.

О приложении

Сначала расскажу немного о себе и о том, как я пришел к написанию этой статьи. Сейчас я работаю, как fullstack разработчик и в мои обязанности входит разработка приложения по всем направлениям его функционала. От схемы базы данных и деплоя приложения в кластер кубернетиса, до верстки веб-интерфейса под все типы устройств. До того как стать fullstack разработчиком, я долгое время работал, как backend разработчик на Python. В те времена мне тоже приходилось работать с клиентской стороной приложения, писать код на JQuery или VueJs. Но это не было основной сферой моих компетенций. В основном разного рода доработки и небольшие компоненты уже готовых клиентских систем. Затем, чуть более года назад, мне предложили начать новый проект и сделать его MVP. С последующей разработкой и развитием в полномасштабное SPA веб-приложение. Это должна была быть аналитическая BI-система. Основные особенности этой BI-системы, ради которых заказчику понадобилась абсолютно новая разработка, лежат в большей степени в плоскости backend-разработки. Это тема для отдельной статьи (которую, возможно, мне стоит написать в будущем), поэтому не будем тут сильно останавливаться. А вот про требования, которые были выдвинуты к фронт-части приложения стоит поговорить более детально.

На одном из совещаний по составлению дорожной карты была сформулирована полу-шуточная формулировка — TV first. А как мы знаем, в каждой шутке есть доля правды. Активной сферой использования подобного приложения станут телевизоры. Их обычно размещают на стенах или стендах в опенспейсах. На них выводятся важные показатели для бизнеса, чтобы они всегда были перед глазами сотрудников офиса. В чем особенность данного случая? Такой телевизор или телевизоры обычно расположены на значительном отдалении от пользователя. Но при этом пользователь хочет по прежнему удобно различать и читать заголовки на графиках, гистограммах, круговых диаграммах и любых других виджетах, выведенных на экран. При увеличении расширения и диагонали экрана мои пользователи не хотят видеть больше информации. Они хотят видеть примерно то же, что и на экране своего ноутбука. И в тоже самое время это же приложение должно быть доступно со всех типов мобильных устройств. Если представитель бизнеса захочет в дороге посмотреть на своем телефоне или же на планшете свежие данные, у него должна такая возможность. При этом все должно быть удобно и пропорционально. Экраны компьютеров и ноутбуков идут в этой истории, как само собой разумеющееся.

Разрабатывать MVP этой системы мне нужно было одному. Как я уже говорил, до этого момента самостоятельно с нуля я не разрабатывал клиентскую часть приложений. У меня уже были определенные компетенции по CSS, JS и верстке к тому моменту времени. При этом фронт работ вырисовывался достаточно внушительный. Я решил максимально погрузится в эту тему и найти какое-то оптимальное решение стоящих передо мной проблем. Найти такой подход, благодаря которому я смогу максимально упростить свою работу, освободить максимум времени, которое занимает верстка под все типы устройств и при этом получить такой интерфейс, который будет полностью удовлетворять потребности моих пользователей.

В процессе изучения и поиска материала я и наткнулся на статью, прием из которой мы сейчас рассматриваем. Но помимо этого приема из статьи мне удалось познакомился в целом с тем, что такое отзывчивая типографика. Давайте перейдем прямо к этой теме.

Отзывчивая типографика

Точное определение этого термина найти сложно, но в общем его можно охарактеризовать так:

Отзывчивая типографика — это способ изменения размеров основного шрифта веб-страницы, опираясь на единицы измерения области просмотра.

Техник реализации на данный момент существуют достаточно много. Ссылки на некоторые из них приведу в материалах к статье.

Какую проблему пытается решить данный подход? Проблема в этом случае заключается в консистентном отображении интерфейса на всех размерах экранов. Все мы знаем, какое разнообразие диагоналей экранов появилось сейчас в распоряжении пользователей. Даже если наш макет в достаточной мере ведет себя отзывчиво, на определенных размерах экранов размеры отступов и в целом пропорции отображения могут быть сильно искажены. Можно применить технику нескольких предустановленных медиа-запросов. Эти брейкпойнты жестко меняют размеры шрифтов на нескольких заранее сверстанных расширениях. Но тут тоже не все может быть так гладко, как хотелось бы. Верстка на пограничных значениях между брейкпойнтами может все равно выглядеть не так хорошо, как мы хотим. Вариантом в этом случае может стать увеличение количества брейкпойнтов. Но все равно это дополнительная работа. Больше брейкпоинтов — больше работы. Все просто. Мы хотим сократить количество брейкпоинтов до минимума. Отзывчивая типографика как раз призвана устранить эти накладные расходы. Наш шрифт начинает реагировать на каждое изменение размера области просмотра и слегка адаптироваться под него. А в след за его изменением небольшую корректировку получат и все расстояния на странице так или иначе связанные с rem. Как это работает на практике поговорим когда будем рассматривать примеры использования. Сейчас же давайте озвучим основные минусы и плюсы этого подхода:

Минусы:

• Изменения поведения функции увеличения масштаба в браузере. Она будет работать на сайте немного другим образом, чем привыкли многие пользователи. Вместо простого эффекта лупы и приближения экрана, весь сайт будет масштабироваться под изменившееся значение области просмотра. В качестве примера можете попробовать это на сайте css-tricks
• Возможная потеря пользователем контроля над размером шрифта через настройки. Поговорим об этом отдельно чуть позже.
• Если пользователь будет в ручную изменять размер экрана, немного возрастает нагрузка на браузер.Не знаю насколько это сильная проблема, но мне довелось читать некоторую полемику в Твиттере по этому поводу. Поэтому упомянуть этот пункт стоит.

Плюсы:

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

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

Чтобы разобраться в этом вопросе, я решил сделать для себя небольшое исследование. Взять самый распространенный на данный момент браузер — google chrome. В настройках выставить очень крупный размер шрифта и посетить несколько популярных сайтов, что бы проверить, как вообще обстоят дела и какой опыт получает пользователь, использующий свои настройки шрифтов.

Тестовая группа сайтов:

• https://habr.com — крупный сайт статей российского сегмента
• https://vk.com — крупная социальная сеть
• https://medium.com — крупный сайт статей зарубежного сегмента
• https://www.rbc.ru — крупный новостной сайт
• https://www.google.com — крупный поисковик

Результаты оказались крайне печальными. Только на стартовой странице google.com шрифт поменял свой размер. Все остальные крупные сайты полностью игнорируют эту настройку. Но и с google история тоже оказалась очень грустна. Страница с поисковой выдачей тоже полностью игнорирует настройку в браузере. Только в этом случае разъехались все отступы между блоками текста.

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

Далее мне захотелось найти какое-то исследование на тему того, какой процент пользователей вообще использует настройки шрифта. Информации на этот счет крайне мало и мне удалось найти только одну статью в зарубежном сегменте интернета, где была сделана попытка провести подобный анализ. Статья на medium.com от 2018 года Pixels vs. Ems: Users DO Change Font Size, где проводился анализ пользователей на сайте https://archive.org. Число пользователей, так или иначе изменивших свой размер шрифта равнялось 3.08%. Можно ли считать один-единственный анализ одного-единственного сайта репрезентативным? Мне кажется нет. Нужно провести больше исследований на эту тему, что бы делать однозначные выводы. Если у кого-то есть ссылка на подобные исследования или вы сами проводили подобные замеры, пожалуйста поделитесь ими в комментариях.

Какие выводы мы можем сделать из всего этого? По факту многие большие и очень крупные проекты не заморачиваются на этот счет. Не могу сказать, делают ли они это основываясь на результате исследований предпочтений своей целевой аудитории или так исторически сложилось. Таких данных у меня нет, есть только сам факт этого положения дел. Должны ли все следовать их примеру или все таки стоит делать по другому? Я не буду делать однозначных выводов. Мне кажется тут каждый должен решить для себя сам. Исходя из особенностей своего приложения, взглядов на пользовательский опыт и важность этого аспекта в контексте разработки конечного продукта. Другими словами, стоит ли овчинка выделки.

Но все же эта история не столько про данную технику, сколько вообще про жесткое определение размеров шрифтов в пикселях для веб-страницы. На эту тему есть очень занимательная статья Pixels vs. Relative Units in CSS: why it’s still a big deal. Если кто-то вдруг захочет, чтобы пользовательские настройки все таки в какой-то мере учитывались при использовании отзывчивого шрифта, в примерах я покажу один вариант конкретно для этой техники.

О минусах и плюсах в контексте этого приема

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

Примеры и рекомендации

Давайте более внимательно еще раз посмотрим на формулу, задающую отзывчивый размер основного шрифта:

font-size: minimumPixel + range * ((viewportWidth - minScreenWidth) / maxScreenWidth)

Range или диапазон здесь позволяет регулировать насколько сильно мы хотим изменять шрифт при каждом изменении области просмотра. Мне показалось, что для моего приложения диапазон равный 10 на экранах от 769px до 2048px несколько избыточен. Как это определить? Только эмпирически работая с вашим макетом приложения или сайта. Экспериментируйте с размерами области просмотра в режиме разработчика браузера и вы сможете подобрать оптимальный шаг для вашего случая. Стоит помнить, что диапазон реальных значений шрифта несколько меньше, чем minimumPixel + range. Так, максимальным значением для экранов от 769px до 2048px при шрифте в 14px будет примерно 20px согласно формуле: 14px + 10 * ((2048 — 769px) / 2048.

Также я добавил дополнительный брейкпоинт для размеров экранов меньше 360px.

Для них я выставил такие настройки:

@media screen and (max-width: 360px) {
  html {
    font-size: calc(14px + 2 * ((100vw - 320px) / 360));
  }
}

Для больших экранов я взял шрифт 30px с диапазоном в 15.

/* Excessively large screens */
@media screen and (min-width: 2049px) {
  html {
    font-size: calc(30px + 15 * ((100vw - 2049px) / 4096));
  }
}

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

В этом подходе размер шрифта становится единственным источником правды для пропорций всего приложения. А следовательно все единицы я указываю в rem. Марджины, паддинги, высота и ширина элементов. Все измеряется в rem. Иногда используются проценты, но это крайне малая часть всех случаев.

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

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

Итоговые настройки, которые сейчас работают в приложении:

/* Small mobile */
@media screen and (max-width: 360px) {
  html {
    font-size: calc(14px + 2 * ((100vw - 320px) / 360));
  }
}

@media screen and (min-width: 361px) and (max-width: 768px) {
  html {
    font-size: calc(16px + 2 * ((100vw - 361px) / 768));
  }
}

/* Laptop and Desktops screens */
@media screen and (min-width: 769px) and (max-width: 2048px) {
  html {
    font-size: calc(14px + 5 * ((100vw - 769px) / 2048));
  }
}

/* Excessively large screens */
@media screen and (min-width: 2049px) {
  html {
    font-size: calc(30px + 15 * ((100vw - 2049px) / 4096));
  }
}

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

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

@media screen and (min-width: 361px) and (max-width: 768px) {
  html {
    font-size: calc(1rem + 2 * ((100vw - 361px) / 768));
  }
}

Теперь настройки пользователя будут влиять на базис в нашей формуле. Да, пользователь не получит ровно тот шрифт, который указал в своих настройках. Но если он хотел более большой или маленький шрифт, он его получит. Степень влияния на базис мы можем корректировать с помощью параметра диапазона, как я описал выше. Если вам нужно сохранить для пользователя возможность влиять на шрифт вашего сайта и в тоже время вы хотите использовать отзывчивые шрифты, можете присмотреться к этому варианту. Большинство браузеров используют стандартный размер шрифта в 16px. Но я находил статью, которая ставит под сомнение это утверждение: People don't change the default 16px font size in their browser (You wish!). Озвучу одно утверждение из этой статьи. Есть некоторые браузеры, вроде Opera Mini или устройства, вроде Kindle 3, которые используют другие настройки шрифтов по умолчанию. Статья от 2016 года. Можете посмотреть в ней таблицу со значениями для некоторых исключительных случаев. Список там очень специфический. Не знаю, насколько реально кто-то занимается отдельно поддержкой под эти браузеры и устройства. Но вдруг, всякое бывает. Поэтому можете обратить на это внимание.

Резюмируя практический опыт, могу сказать следующее. Приложение уже достаточно долго используется в продакшене. Мы регулярно собираем отзывы от наших пользователей и вопросы по верстке среди них не фигурируют. Поэтому на данный момент я могу только положительно охарактеризовать выбранный подход. И всегда нужно помнить: большая сила налагает большую ответственность. Для всех устройств в своем приложении, за исключением очень больших экранов, я на самом деле добавил довольно небольшое изменение шрифта от базового. И за счет этого добился тех целей, которых хотел. Сделал отображение более пропорциональным и удобным на пограничных разрешениях экранов между брейкпоинтами, а так же нашел способ сэкономить свое рабочее время. Моя потребность делать все значительно больше на большом экране продиктована исключительно потребностями моего приложения. Как поступить с вашим, решать только вам. Но обязательно хорошо подумайте о своих пользователях и чего они будут ждать от вашего продукта.

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

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

Использованные материалы:

• People don't change the default 16px font size in their browser (You wish!)
• Pixels vs. Ems: Users DO Change Font Size
• Fluid Typography
• THE STATE OF FLUID WEB TYPOGRAPHY
• Fluid typography examples
• What is Fluid Typography and should I be using it?
• Отзывчивый и адаптивный дизайн сайта
• Usage share of web browsers
• Pixels vs. Relative Units in CSS: why it’s still a big deal

P. S. Если вы бы хотели увидеть в будущем перевод какой-то из этих статей, пишите об этом в комментариях.