Помните времена, когда адаптивный дизайн веб-страниц был критически важным навыком в вашем резюме?

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

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

Я имею в виду, есть 2 основные причины, по которым мы вообще беспокоимся:

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

Отзывчивость страницы

С начала революции прошло восемь лет. Мы изменили Adobe CS4 на CC 2018 или перешли на Sketch. Флэш стал музейным экспонатом! Появились десятки инструментов для прототипирования и A / B-тестирования, и, наконец, наши компании начали бороться за найм фронтенд-инженеров.

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

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

  • 740px -1299px: скрыть четвертый столбец прогноза.
  • ≤ 1139px: согласовать текущий прогноз с будущим
  • ≤ 979px: скрыть 3-й столбец прогноза
  • ≤ 739px: скрыть все столбцы прогнозов, скрыть метку над текущим прогнозом, скрыть текущее местоположение, отобразить переключатель.

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

Как быстро можно сменить шаблон?

Давайте представим, что мы являемся частью команды дизайнеров Guardian. Долгое время мы хотели дать больше места контенту с правой стороны. A / B тесты показали, что левый столбец можно уменьшить примерно на 50 пикселей.

Наш виджет прогноза не скрывал последний столбец. Он будет сдавлен и выйдет за желоб.

Но поскольку мы не вносим изменения в шаблоны каждый день, давайте зададим еще один вопрос: «Можно ли разместить виджет под содержанием статьи?» Ответ - нет." Мы не знаем, как будет выглядеть компонент, и нашим разработчикам придется заново переписывать все медиа-запросы CSS. Наконец, нам нужно поддерживать и то, и другое, когда дело доходит до изменений в шаблоне. Вау - это становится дорого и требует много времени.

Наша конструкция работает до тех пор, пока у наших компонентов есть достаточно места, чтобы дышать.

Когда мы проектируем компоненты в соответствии с размером области просмотра, они не реагируют на ограничивающее их пространство. Мы можем описать их поведение только через элементы упаковки (родители, бабушки и дедушки, прабабушки и дедушки), размещенные на странице. Целые головоломки работают, пока вы продолжаете выполнять ручную кропотливую работу по склеиванию головоломок. Поскольку они приклеены, вы не сможете быстро переместить элемент с одного места на другое. Ваши компоненты не реагируют; ваша страница есть.

Отзывчивость контейнера

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

Мы попытаемся изолировать наш виджет прогноза и описать его поведение на основе доступного пространства. При внедрении нашего компонента в более широкую экосистему дизайна потребуется лишь минимальный объем работы.

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

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

Молекулы - это простые системы, построенные из атомов (для простоты я пропустил поле местоположения):

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

Вы заметили, как мы добавили вертикальную отзывчивость? Повторяю свой вопрос: вы заметили, как мы добавили вертикальную адаптивность?

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

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

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

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

В 2010 году у нас были медиа-запросы. Что у нас есть сейчас?

Когда дело доходит до гибких решений, больше нет святого Грааля.

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

Для некоторых из этих реализаций требуется плавающая система справа, для других - flexbox или CSS-сетка. Решения, отвечающие за реагирование на JavaScript, к лучшему или худшему, были реализованы уже давно, чтобы восполнить пробел *. Наконец, продолжается дискуссия о «контейнерных запросах». Нам всем нужно доверять нашим разработчикам, чтобы найти лучшее решение.

TL;DR

Мы хотим думать о наших компонентах как об отдельных частях, привязанных к родительскому объекту, а не к странице. Тем не менее, когда дело доходит до адаптивного дизайна, поведение компонентов определяет их отношение к размеру точки останова (области просмотра / устройства).

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

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

  1. Отзывчивость JavaScript затрудняет рендеринг на стороне сервера. Кроме того, если мы реализуем это неправильно, пользователи быстро заметят неряшливость при изменении размера окна.

Особая благодарность рок-звезде LendInvest UX-дизайнеру Нику Бэйли за его работу над иллюстрациями.