Мобайл ферст. Простая, отзывчивая навигация Mobile First

Разработка мобильных приложений

О Mobile First написано достаточно много и есть хорошие книги на эту тему. И все равно большинство разработчиков и компаний не используют его в своих проектах или не знают вообще об этом подходе.

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

• Что такое Mobile First и его плюсы
• Реализация подхода
• Статистика результатов

Что такое Mobile First? В этом году количество пользователей, использующих мобильные устройства для доступа к сети Интернет, достигло 60%. Поэтому мобильный трафик становится более значимым и владельцы вебсайтов должны считаться с этой статистикой. Как показывает практика, пользователи мобильных телефонов и планшетов проводят меньше времени в сети и предпочитают сайты из первых строчек поисковой выдачи. В то время как пользователи ПК могут проводить больше времени в поисках информации. Поэтому ваш вебсайт должен быть хорошо оптимизирован для поисковых систем (SEO) и отвечать всем требованиям Mobile First, что бы прибывание пользователя на вашем сайте было максимально удобным и понятным через его мобильное устройство.

Поэтому одни из самых важных требований в Mobile First разработке это:

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

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

О важности этого подхода недавно писал поисковой гигант Google:

«Мы будем увеличивать значение показателя mobile-friendly в нашем рейтинге результатов. Эти изменения повлияют на мобильный поиск на всех языках мира и окажет значительное влияние на результаты поиска. Следовательно, пользователям будет легче находить результаты оптимизированные под их устройства.»
Видео о значимости Mobile First от Olivier Rabenschlag – глава Агентства Творческого Развития Google.

Плюсы Mobile First подхода Напомню, что на сегодняшний день количество пользователей использующих мобильные устройства для серфинга в интернете достигло 60%. И поэтому использование Mobile First при разработке вебсайта дает большие преимущества для этих пользователей в первую очередь.

• Один вебсайт для всех устройств
• Пользователи получат важное содержание страницы в первую очередь
• Быстрая загрузка страниц при низкой скорости подключения
• Удобный интерфейс для навигации в мобильном экране
• Минимальное количество веб ресурсов требуемое для отображения основного содержимого – экономия мобильного Интернет трафика
• Топовые позиции в результатах поиска Google

Реализация Реализация подхода будет продемонстрирована с помощью фреймворка Moff.js (Mobile First Framework) . Это JavaScript фреймворк, который заточен для Mobile First разработки.

Мы будем рассматривать подход на примере страницы с детальной информацией об автомобиле.

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

Подробный список данных на странице:

Представим, что основное из этого списка это главная картинка, название производителя, модели, комплектация, цена, список характеристик и оборудование.

Mobile First page. Company Name Company description 2015 Nissan Versa Note

Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum.

• Model: Versa Note
• Body: 4D Hatchback
• Engine: 1.6L 4-Cylinder DOHC 16V
• Fuel: Gasoline

Standard

• Brake assist
• Dual front side impact airbags
• Rear window defroster
• Passenger door bin
• Driver door bin
• Occupant sensing airbag
• Traction control
• CD player
• Trip computer
• Electronic Stability Control
• Front anti-roll bar
• Power steering
• Rear window wiper
• Front reading lights
• Overhead airbag
• ABS brakes

Created by Company.com

• Copyright
• Contact
• Sitemap

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

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

@media (min-width: 768px) { /*Tablet and desktop styles*/ }

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

See more images...
Здесь мы используем Data Events хелперы, которые помогают получить информацию при ее запросе. При клике на ссылку отправится ajax запрос по адресу указанному в атрибуте href . Результат запроса будет записан в элемент, который указан в аттрибуте data-load-target . Важным моментом будет то, что атрибут data-load-screen указывает при каких значениях экрана тумбы будут загружены автоматически. Размеры экранов взяты из CSS фреймворка Twitter Bootstrap . И в атрибуте data-load-module указываем идентификатор зарегистрированного модуля, который будет подключен после вставки результата ajax запроса.

Отправляется ajax запрос на URL указанный в ссылке и результат вставляется на страницу

Подключается зарегистрированный модуль (vehicle-gallery)

Подключаются зависимости (jQuery и Slick-carousel)

Загружается основной файл модуля

Инициализация модуля

Далее рассмотрим регистрацию этого модуля.Объявление класса модуля Moff фреймворк имеет систему модульности с помощью, которой мы реализуем класс модуля vehicle-gallery.

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

Moff.modules.create("VehicleGallery", function() { var _module = this; var _mainImage; function setMainImage() { _mainImage = _module.find(".vehicle_images_main img"); } function initializeSlickJs() { $(_module.find(".vehicle_images_thumbs-list")).slick({ infinite: true, slidesToShow: 5, slidesToScroll: 1 }) } function handleMainImage() { $(_module.scope).on("click", ".vehicle_images_thumbs-item img", changePreview); } function changePreview() { var index = this.src.match(/thumb(\d+)/); _mainImage.src = "images/preview" + index + ".jpg"; } this.scopeSelector = ".vehicle_images"; this.init = function() { setMainImage(); initializeSlickJs(); handleMainImage(); }; });
Во время инициализации класса мы запускаем slick-carousel для создания карусели из наших тумб и устанавливаем обработчик для их просмотра.

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

Moff.amd.register({ id: "vehicle-gallery", depend: { js: ["/bower_components/jquery/dist/jquery.min.js", "/bower_components/slick-carousel/slick/slick.min.js"], css: ["/bower_components/slick-carousel/slick/slick.css"] }, file: { js: ["js/vehicle-gallery.js"] }, afterInclude: function() { Moff.module.initClass("VehicleGallery"); } });
В нашем примере мы указали в зависимостях jQuery и его плагин slick-carousel, который создает из тумб карусель. Зависимости грузятся синхронно, в той очередности, в которой вы указываете. И после зависимостей грузится класс модуля vehicle-gallery.js. Далее, после загрузки файла модуля и его зависимостей мы инициализируем модуль в с помощью события afterInclude.

Статистика результатов. Подведем итоги результатов создания Mobile First страницы.

Нижний график показывает, что не оптимизированная страница на 73% тяжелее, чем страница адаптированная под требования Mobile First. Таким образом мы можем сэкономить 186.94 KB , которые возможно и не понадобятся пользователю при просмотре вашей страницы.

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

В этой статье рассмотрен только один пример загрузки дополнительной информации. Полный пример можно будет посмотреть на сайте фреймворка.

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

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

Подход «Mobile First»

Термин “mobile first” последнее время довольно популярен. Он означает, что нужно начать с создания макета для мобильного телефона, но оптимизированного сразу и под экраны с большим разрешением. Таким образом, ваш макет для мобильных телефонов становится главным и основным, и это позволяет не делать других отдельных макетов. Вот так просто!

Используя гибкие, но простые макеты изначально, вы можете обеспечить лучшую поддержку различных браузеров, как с большим так и с маленьким полем отображения- которые не способны отображать полностью отзывчивые макеты. Поэтому если говорить о макетах, то термин “Mobile first” на самом деле значит “прогрессивные улучшения.”
- Итан Маркотт (Ethan Marcotte)

Min-width Медиа Запросы

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

/* Маленькие экраны(по умолчанию) */ html { font-size; 100%; } /* Средние экраны (640px) */ @media (min-width: 40rem) { html { font-size: 112%; } } /* Большие экраны (1024px) */ @media (min-width: 64rem) { html { font-size: 120%; } }

1. Не все браузеры созданы одинаково

Разные браузеры отображают ваш CSS код по разному. Чтобы избежать этого, правильно будет использовать специальные скрипты для сброса значений в единый вид, например Normalize.css , который позволяет отображать элементы практически одинаково в любом браузере. Запомните это перед созданием вашего собственного файла стилей.

2. Добавляйте Viewport Мета Тег

Разместите его в блоке вашего HTML. Он включит медиа запросы в макетах для различных девайсов.

Блочная Модель CSS

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

Очищаемая зона вокруг контента.

Рамка (Border) Рамка находящаяся вокруг padding.

Очищаемая зона вокруг рамки.

3. Используйте box-sizing: border-box

Напишите этот код вначале вашего CSS файла. * — выберет все элементы на вашей странице.

*, *:before, *:after { -moz-box-sizing: border-box; -webkit-box-sizing: border-box; box-sizing: border-box; }

Выбор за Вами .clearfix:before, .clearfix:after { content: " "; display: table; } .clearfix:after { clear: both; } .clearfix { *zoom: 1; }

Flow Opposite

Добавляйте класс .flow-opposite к колонкам которые должны отображаться на мобильных устройствах первыми, но быть справа на больших экранах.

@media (min-width: 40rem) { .column.flow-opposite { float: right; } }

Практикуйтесь и совершенствуйте свои навыки

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

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

Инвестор и партнёр венчурного фонда Andreessen Horowitz Бенедикт Эванс написал материал о том, почему всё больше разработчиков переходят с парадигмы Mobile First к парадигме Mobile Native, в чём между ними разница и о чём важно помнить создателям мобильных приложений..

«Несколько лет назад ИТ-компании перешли к стратегии Mobile First. До этого в организациях были отдельные департаменты разработки под мобильные платформы и работники, которые занимались развитием мобильного направления. Теперь новая функциональность сразу появляется на смартфонах, а на ПК иногда и не переносится», - пишет Эванс.

По словам инвестора, в 2016 году всё больше компаний приходят к парадигме Mobile Native. «Это эволюция принципа Mobile First. Что будет, если попросту забыть о ПК и дешёвых мобильных телефонах? Если полностью сосредоточиться на 2,5 млрд смартфонов и полностью опустить рынок low-end-устройств. Сможете ли вы построить большую компанию?».

По мнению Эванса, выбирающим стратегию Mobile Native разработчикам следует в первую очередь обдумать несколько основных моментов:

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

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

Инвестор говорит, что с мобильным телефоном пользователи могут делать множество вещей, которые им не позволяла делать система, включавшая в себя сам компьютер, клавиатуру и мышь. Это открывает новые возможности как для самих владельцев смартфонов, так и для разработчиков. «Уже выросло целое поколение, которое готово к парадигме Mobile Native. А приложения, которые в 2007 году вызвали бы восторг, сейчас кажутся совсем простыми».

«Разработчики наконец могут отказаться от парадигмы Mobile First и применить свои навыки для того, чтобы максимально охватить возможности двух миллиардов смартфонов на планете. Это напоминает мне переход к Web 2.0 около девяти лет назад. Тогда все разработчики заявили: "А знаете, нам совсем не обязательно думать о Lynx, CGI-скриптах и диалап-соединении. Мы прошли ту точку, когда использование тега IMG казалось спорным решением, и можем думать о том, как создавать интерфейсы и предоставлять пользователям новые услуги"», - заключает Эванс.

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

В некотором смысле, больше значит лучше. Но что еще важнее, пропорции гармонизируют контент. Если основной текст имеет размер 24px , убедитесь, что он хорошо соотносится с остальной частью сайта. Тут нет каких-то жестких правил, но высота строк должна быть от 1.2х до 1.4х размера шрифта. Задайте размеры, плотность и вариации цветов на основе приоритетов. Тут многое исходит от внутреннего чутья и натренированного глаза.

Длина строки должна быть от 45 до 90 символов . Более детально общие правила типографики описаны в этом руководстве .

Работа с SVGИспользование WebKit для анимаций

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

Внизу, когда начинается автомобиль, я использовал webkit-transform вместо animate из jQuery. Быстродействие значительно улучшается при такой реализации. Вдобавок, отлично работает на Mobile Safari и Chrome.

Для параллакса я задал разную скорость для 3 разных элементов. Я использовал webkit-transform вместо CSS top position. Из-за этого скролл стал гораздо плавнее. Настройка Viewport

Нужно сделать так, чтобы устройства iOS и Android масштабировали дизайн на 0.5, чтобы все красиво работало на ширине экрана 640px. Для iPad мы смасштабируем до 1.

Смарт-баннер iOS

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

Когда люди заходят на сайт через свой iPhone или iPad, они видят красивый баннер, который перебрасывает их на App Store. Использование симулятора iOS
Проверка в Chrome на Android

Половина мобильных пользователей работают на Android. Чтобы протестировать элементы в браузере Chrome на Android, следуйте этим инструкциям .

Мне понадобилось время, чтобы освоить опцию в гамбургер меню Tools > Inspect Devices Заключение

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

Дата публикации: 2013-03-29

От автора: ранее в этом году я находился на начальных этапах перепроектирования вебсайта нашей компании. Мы уже планировали применить прямой адаптивный подход веб-дизайна, что является предпочтительным решением для поддержки множества устройств. Узнав из откровенных дискуссий на конференции An Event Apart в Бостоне об ограничениях и трудностях адаптивного веб-дизайна, я понял, что наше решение требует небольшой регулировки.

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

Постановка целей

Первым предпринятым шагом в нашем проекте стало создание списка преимуществ и препятствий на пути примененного нами адаптивного подхода. Наш список выглядел так:

ПРЕИМУЩЕСТВА

1. Построение, поддержка и продвижение одного вебсайта.

2. Поддержка множества размеров экранов, не только экстремально больших мониторов настольных компьютеров и маленьких портативных устройств.

3. Перспектива на будущее, так как разметка будет изменяться в зависимости от размера экрана, а не только размера современных популярных устройств.

ПРЕПЯТСТВИЯ

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

2. Из-за «безразмерной» разметки мы неспособны изменить исходный порядок такой разметки (или полностью исключить из нее неважные элементы) в зависимости от устройства или размера экрана.

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

Начиная с содержимого

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

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

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

К тому же, мы сели и поговорили с некоторыми своими текущими клиентами, представляющими большую часть аудитории нашего вебсайта, и задали им несколько вопросов, в числе которых: «За каким контентом вы заходите на наш вебсайт, сидя за монитором десктопа?» и: «А как насчет «таблетки» или телефона?». Интервью, конечно, были более детальными, но вы и так видите, что нас интересовало. И опять было обнаружено, что искомый контент был одним и тем же, вне зависимости от применяемого устройства.

Данные диктуют направление

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

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

Создание дизайна крайних точек

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

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

Mobile First

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

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

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

@media only screen and (min-width: 660px) { html { background: url(/images/bg-watercolor.jpg) no-repeat fixed center top; } }

@ media only screen and (min - width : 660px ) { html { background : url (/ images / bg - watercolor . jpg ) no - repeat fixed center top ;

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

Создание ради дизайна, а не устройств

Начав применять адаптивный дизайн в своих веб-проектах, мы сосредоточились на известных устройствах и размерах экранов, и наши медиазапросы часто отражали именно их (iPhon’ы, iPad’ы – как в книжной, так и альбомной ориентации – лэптопы, широкоэкранные десктопы и т.д.). Со временем обнаружилось, что это не самый лучший подход, потому что адресован только тем устройствам и размерам экранов, которые популярны сегодня, а не тем, которые могли бы появиться в будущем. Одна из мощных перспективных сторон адаптивного веб-дизайна – его направленность в будущее. Поэтому для полной реализации этой сильной стороны мы отошли от построения ради устройств вместо того, чтобы позволить дизайну самому диктовать контрольные точки медиазапросов.

Метод mobile-first заложил CSS-базу нашего вебсайта. При ней в наличии, мы запустили вебсайт в браузере и масштабировали его до самого маленького размера нашей разметки (мы установили в CSS минимальную ширину 320 px). Постепенно размер окна браузера увеличивался, чтобы видеть, как отвечает на это разметка. По мере увеличения окна мы заметили, что разметка начинала деформироваться. Именно в таких точках нам потребовалось установить новые медиазапросы для подгонки разметки.

Чтобы разобраться с этим методом, мы создали графику и установили ее в качестве фона десктопа. Вертикальные линии показывали ширину в 320 px (наш самый маленький размер), потом расставлялись на каждой сотне пикселей начиная с 400, и применялись в качестве направляющих по мере масштабирования окна браузера для определения того, где дизайн начинал «ломаться», а затем мы использовали эти примерные значения в пикселях в окончательных медиазапросах, которые и добавили в CSS.

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

Одна из областей нашего вебсайта, где очевидно увеличение медиазапросов – навигация.

Адаптивная навигация

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

1. Основная навигация;

2. То, что мы называем «вспомогательной навигацией», которая ссылается на различные порталы и сервисы, используемые нашими клиентами;

3. Навигация нижнего колонтитула;

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

Так как наш CSS — mobile-first, одной из первых забот стала установка навигации для малоэкранной разметки. Этот означает отключение отображения всех разделов навигации, кроме основной навигации.

#helpNav, .subNav, footer nav { display: none; }

#helpNav, .subNav, footer nav { display : none ;

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

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

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

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

Вот CSS нашей вспомогательной навигации:

#helpNav { display: block; position: absolute; top: 1px; right: 0px; width: 100%; text-align: right; } #helpNav ul { padding-left: 10px; } #helpNav li { display: inline; padding-right: 6px; padding-left: 6px; background-color: #2f6a98; } #helpNav a { font-size: 12px; padding: 0 6px; color: #FFF; border-radius: 20px; } #helpNav a:hover { background-color: #f66606; }

#helpNav { display : block ; position : absolute ; top : 1px ; right : 0px ; width : 100 % ; text - align : right ; #helpNav ul { padding - left : 10px ; #helpNav li { display : inline ; padding - right : 6px ; padding - left : 6px ; background - color : #2f6a98; #helpNav a { font - size : 12px ; padding : 0 6px ; color : #FFF; border - radius : 20px ; #helpNav a:hover {

И области навигации подстраниц:

SubNav { display: block; width: 25%; float: left; } .subNav h4 { padding-bottom: 8px } .subNav ul { list-style: disc; color: #c65204; padding: 0 0 20px 20px; } .subNav li { padding-bottom: 14px; } .subNav a { color: #186483; font-size: 21px; font-family: "RokkittRegular", Times, "Times New Roman", serif; line-height: 1; }

SubNav { display : block ; width : 25 % ; float : left ; SubNav h4 { padding - bottom : 8px SubNav ul { list - style : disc ; color : #c65204; padding : 0 0 20px 20px ; SubNav li { padding - bottom : 14px ; SubNav a { color : #186483; font - size : 21px ; line - height : 1 ;

Наконец, навигация нижнего колонтитула:

footer nav { display: block; margin-top: 40px; } footer nav ul { list-style: none; } footer nav li { padding-bottom: 24px; width: 19%; padding: 0 5% 20px 0; float: left; } .innerNav li { width: 100%; float: none; padding-bottom: 4px; } footer nav a { color: #575454; font-size: 12px; } .innerNav a { font-weight: normal; }

footer nav { display : block ; margin - top : 40px ; footer nav ul { list - style : none ; footer nav li { padding - bottom : 24px ; width : 19 % ; padding : 0 5 % 20px 0 ; float : left ; InnerNav li { width : 100 % ; float : none ; padding - bottom : 4px ; footer nav a { color : #575454; font - size : 12px ; InnerNav a { font - weight : normal ;

Пиксели или емы

Вы заметите, что для своих медиазапросов мы применяли значения в пикселях. Применение пиксельных медиазапросов – с этого мы, подобно прочим разработчикам внешнего интерфейса, начали выполнение адаптивного дизайна, и утвердили эту практику как часть своего рабочего процесса. Однако, в духе «построения лучшего адаптивного вебсайта», я укажу статью о размерных медиазапросах, применяющих em’ы, представленную нашему вниманию во время редактирования этого раздела. По сути дела, чтобы улучшить внешний вид сайта при увеличении zoom in, очень сильно рекомендуется конвертировать px-медиазапросы в em-медиазапросы путем деления всех пиксельных значений на размер шрифта body.

Эта чудесная статья подвигла нас пересмотреть свои взгляды на медиазапросы на основе пикселей, и это еще один пример того, как мы продолжали оттачивать адаптивный метод. Тогда как мы не применяли em’ы в своих медиазапросах в этом отдельном проекте, сейчас мы с ними экспериментируем, и этот подход стоит упоминания здесь.

Основная навигация

Наша основная навигация представлена на широких экранах, как горизонтальный ряд, проходящий через весь верх разметки. На маленьких экранах структура основной навигации меняется так, что вверху каждой страницы появляется большая кнопка «Меню», которая ссылается на навигацию внизу страницы. Чтобы добиться этого, мы добавили в заголовок ссылку с ID menuLink и класс oftabButtonr, что уже почти является началом разметки. Затем поместили раздел с ID mainNav в самый конец разметки. Внутри этого раздела находится наша основная навигация, которая представляет собой просто неупорядоченный список с несколькими прочими неупорядоченными списками для меню разделов субстраниц внутри. У нас также имеется привязка-«якорь» с ID toTop, которая действует как ссылка наверх страницы.

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

#menuLink a { float: right; margin: -56px 8px 0 0; } .tabButton a { color: #FFF; font-family: "RokkittRegular", Times, "Times New Roman", serif; font-size: 20px; background-color: #45829b; padding: 10px 12px; border-radius: 10px; } .tabButton a:hover { background-color: #f66606; }

#menuLink a { float : right ; margin : - 56px 8px 0 0 ; TabButton a { color : #FFF; font - family : "RokkittRegular" , Times , "Times New Roman" , serif ; font - size : 20px ; background - color : #45829b; padding : 10px 12px ; border - radius : 10px ; TabButton a : hover { background - color : #f66606;

Меню нашей основной навигации установлено на малоэкранное отображение:

#mainNav { margin-top: 30px; width: 100%; } #mainNav #toTop a { float: right; margin: 0 8px 0 0; font-size: 20px; } #mainNav nav { padding-top: 80px; } #mainNav ul { list-style: none; } #mainNav li { background: #45829b; border-bottom: 1px solid #abc7d2; padding: 4px 10px 4px 15px; } #mainNav li:hover { background-color: #f66606; } #mainNav a { font-size: 24px; color: #FFF; font-family: "RokkittRegular", Times, "Times New Roman", serif; }

#mainNav { margin - top : 30px ; width : 100 % ; #mainNav #toTop a { float : right ; margin : 0 8px 0 0 ; font - size : 20px ; #mainNav nav { padding - top : 80px ; #mainNav ul { list - style : none ; #mainNav li { background : #45829b; border - bottom : 1px solid #abc7d2; padding : 4px 10px 4px 15px ; #mainNav li:hover { background - color : #f66606; #mainNav a { font - size : 24px ; color : #FFF; font - family : "RokkittRegular" , Times , "Times New Roman" , serif ;

Наши подменю, которые не отображаются в исходном положении, теперь можно показывать, как того требует страница. У каждого из этих подменю есть уникальный ID, такой как servicesTab, и у каждого раздела вебсайта есть класс, примененный к тэгу body. Класс раздела “Company” – companyPage. Мы применяем этот класс для назначения стилей всему разделу вебсайта. Для включения подменю мы используем класс разделов подменю, как оно требуется, когда раздел активирован.

CompanyPage #companyTab ul, .newsPage #newsTab ul, .contactPage #contactTab ul, .servicesPage #servicesTab ul { display: block; }

CompanyPage #companyTab ul, NewsPage #newsTab ul, ContactPage #contactTab ul, ServicesPage #servicesTab ul { display : block ;

Увеличиваемся

По мере вступления большеэкранных разметок - снова с медиазапросом 660px и выше - мы разительно меняем разметку основной навигации. Во-первых, отключаем отображение кнопок menuLink и toTop, потому что они больше не требуются:

#menuLink a, #toTop a { display: none; }

#menuLink a, #toTop a { display : none ;

#mainNav { position: absolute; top: 92px; margin: 18px 2% 0 2%; width: 96%; text-align: center; } #mainNav nav { padding: 5px 0; border-top: 1px solid #bacfd7; border-bottom: 1px solid #bacfd7; } #mainNav li { background: none; display: inline; border-bottom: 0; border-right: 1px solid #bebebe; padding: 0 6px 0 8px; margin: 4px 0; } #mainNav a { font-size: 16px; color: #45829b; } #mainNav a:hover { color: #f66606; }

#mainNav { position : absolute ; top : 92px ; margin : 18px 2 % 0 2 % ; width : 96 % ; text - align : center ; } #mainNav nav { padding : 5px 0 ; border - top : 1px solid #bacfd7; border - bottom : 1px solid #bacfd7; } #mainNav li { background : none ; display : inline ; border - bottom : 0 ; size : 16px ; color : #45829b; } #mainNav a:hover { color : #f66606; }

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

Следуем этому образцу несколько раз, под конец увеличив размер шрифта до 27px при достижении вебсайтом своего наибольшего размера. Таким образом, навигация вебсайта отвечает дизайну и применяемому для его просмотра экрану наилучшим образом.

Получаем помощь от CMS

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

Одна из наибольших помех адаптивному подходу состоит в том, что вы не можете предоставить различную разметку или различный исходный код в различные устройства. Это препятствие мы и хотели победить с помощью нашей CMS. В течение экспериментирования и исследований мы наткнулись на статью с названием Настоящая адаптивность с помощью ExpressionEngine (Going Truly Adaptive With ExpressionEngine). Применив подробно описанную в этой статье методику, нам удалось использовать скрипт определения устройств, чтобы установить переменную в мобильной или полноразмерной системе. Затем мы смогли загружать разметку на свой сайт в зависимости от того, которая из этих переменных нам встретилась.

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

Начинаем с маленького

Вы, конечно, могли применить эти переменные для доставки совершенно другой разметки и исходного кода в различные устройства, но наш изначальный подход был немного менее экстремальным. Так как уже решено, что любые версии нашего вебсайта получат доступ ко всему содержимому, мы изначально применили данный метод переменных для небольшого регулирования количества доставляемого контента. Например, на домашней странице нашего вебсайта мы показываем тизеры большого количества контента, находящегося на вебсайте. В разделах “Culture” и “Project Spotlight” каждому посту сопутствует изображение.

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

Синтаксис довольно прост. Единожды установив переменные - а вышеупомянутая статья объясняет, как легко это сделать, добавив в системный файл config.php маленький скрипт - вы можете применять эти переменные как оператор if.

img src = "{teaser-image}" alt = "{title}" / > { / if } { if global : site_version == "mobile" } { title } { / if }

Это – синтаксис ExpressionEngine, но вы сможете прочесть его и легко увидите, что происходит. Если встречается переменная full, то мы доставляем из вступления статьи в базе данных teaser-image. Если вместо этого встречается переменная mobile, то доставляем название статьи title.

Тот же подход применяется к разделам домашней страницы “News” и “Blog”, доставляя три коротких тизера, если встречается переменная full, и только один, если mobile. Этот синтаксис выглядит так:{ exp : channel : entries channel = "news" { if global : site_version == "full" } limit = "3" { / if } { if global : site_version == "mobile" } limit = "1" { / if } }

Здесь видно, что мы получаем доступ к каналу ExpressionEngine с названием news. Свою переменную мы применяем для определения того, сколько текущих элементов будут отображаться из этого канала, использовав параметр limit.

Продвигаемся еще на шаг

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

Для каждой статьи мы создаем два набора изображений: один полноразмерный шириной 650px, и второй – почти вполовину этого размера. Затем применяем в своей статье переменные (но сначала нужно разрешить в шаблоне своей страницы код ExpressionEngine), и добавляем разметку для обоих наборов изображений - но только один из них доставляется в браузер. Мобильные устройства получают маленькие изображения, а все остальные – полноразмерные.
Тот же подход применяется к большой рекламной области домашней страницы. Эти вращающиеся баннеры и изображения рекламируют важные вещи, такие как грядущие события, новые услуги, объявления, лучше, чем остальные области домашней страницы. Рекламный щит – другой приятный во всех отношениях элемент, который предназначен только для больших дисплеев. Снова применяем переменные для донесения раздела основного рекламного щита, а также запускающего его JavaScript’а, до подходящего устройства - что дает нам возможность эффективно рассылать разную разметку на разные устройства и устраняя еще одну помеху, обозначенную нами в начале проекта.

С помощью подхода mobile-first и нашего CMS мы способны доставить нашу домашнюю страницу до пользователей настольных компьютеров в 738.3 KB и существенно уменьшить ее всего до 174.4 KB для мобильных пользователей.

Планы альтернативных вариантов

Одним из вопросов, которые всегда тревожили меня по поводу подхода mobile-only и определения устройства: «Что происходит, если определение не срабатывает? Доставляется ли до мобильного устройства «нормальная» версия вебсайта, показывая этим недействительность вашего тщательно созданного мобильного дизайна? Эта возможность – одна из основных причин того, почему я избежал решения mobile-only, применяемого в прошлом для определения устройства.

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

К тому же из-за того, что все соответствует принципу mobile-first, элементы, не предназначенные для маленьких экранов, такие как вышеупомянутая огромная фоновая графика, вообще не отражаются. Единственное, что подведет нас – то, что мы сделали со своими переменными, сгенерированными для определения устройства. Если действие разовьется по наихудшему сценарию и определение устройства не сработает, то мобильная версия просто получит несколько дополнительных изображений, или немного разметки, или JavaScript’а. Общее впечатление все еще будет подходящим к мобильному устройству. Неплохо для «наихудшего сценария».

Прогресс, не идеал

Несколько лет назад один клиент сказал мне кое-что, о чем я помню до сих пор. Говоря о своем вебсайте, он сказал:

«Не беспокойтесь о том, чтобы сделать мой вебсайт идеальным. Просто работайте над его улучшением. Его постоянное улучшение будет движением в правильном направлении ».

Эта идея годами вдохновляла меня и напоминала о том, что нельзя отвергать лучшее только потому, что оно неидеально.

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

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

Как вы считаете?

Как вы строите адаптивные вебсайты? Вы применяете определение характеристики или определение устройств? Когда вы рекомендовали бы применять то или иное? Мы ждем ваших комментариев!