Начало новой эры адаптивного веб-дизайна

Начало новейшей эры адаптивного веб-дизайна

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

Как это началось — Фиксированные экраны

На рубеже 1000-летий мы начали создавать интерфейсы для фаворитных в то время экранов с размерами, быстрее всего, 640×480. В большинстве случаев мы даже не планировали прокрутку экрана либо же имели внутренние полосы прокрутки для перехода к определенным областям либо фрагментам текста. Излишне говорить, что большая часть Веба в то время также была построена или на Flash, либо на HTML с таблицами для макета. Это было до телефонов, и по мере развития технологий мы пережили 1-ый фундаментальный переход к адаптивному дизайну. Мы прошли длинный путь, CSS сильно изменился, и в 2010 году — получили особые инструменты для работы.

Начало новейшей эры адаптивного веб-дизайна

Адаптивный дизайн

С выпуском CSS3 мы получили доступ к медиа-запросам, и скоро после этого Итан Маркотт, в конце 2009, года ввел термин «Адаптивный дизайн». Более 10 лет мы создавали макеты для Веба с помощью адаптивного веб-дизайна (RWD) как подхода, который позволяет адаптировать проектируемые нами приложения к разным устройствам и размерам экрана.

Концепции Mobile-first и прогрессивное улучшение стали вправду популярными подходами в первые дни, когда мобильные телефоны еще не понимали медиа-запросы либо JavaScript, и было много CSS, которые просто еще не поддерживались.

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

Что далее – Component Driven

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

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

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

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

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

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

Юзеры могут устанавливать медиа-запросы на основе предпочтений

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

Это ни в коем случае не полный перечень, но чтобы дать вам некоторые идеи, медиа-запросы на базе предпочтений могут включать:

CSS

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

Другой пользующийся популярностью медиа-запрос — @prefers-color-scheme — позволяет нам переключать дизайн на светлый либо темный режим в зависимости от предпочтений юзера и настроек их операционной системы. Он не зависит от тумблера пользовательского интерфейса, который пользователь должен использовать для перехода в черный режим, переключение произойдет автоматически.

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

Контейнерные запросы для вдохновления новейшей жизни в вашу систему дизайна

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

Кратко, контейнерные запросы позволят нам устанавливать правила на базе родительского контейнера, а не всей странички. Это означает, что любой компонент является более самодостаточным, согласованным с современными системами дизайна и становится модулем plug-and-play, которые можно перемещать на всякую страницу или макет без необходимости пересматривать его на базе его новой среды.

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

Даже сам Итан Маркотт разъясняет, почему контейнерные запросы имеют такое огромное значение, на которое мы должны направить внимание.

Учитывая различные форм-факторы

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

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

Для чего нам это нужно?

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

Начало новейшей эры адаптивного веб-дизайна

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

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

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

Создатель: Francois Brill

По материалам webformyself.com

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *