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

20.12.2023

Дата публикации: 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’ов, о чем мы ранее уже писали, но относительно этого и прочих проектов мы движемся в верном направлении.

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

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

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

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

Поисковые системы используют ряд критериев для оценки адаптивности сайта при просмотре на мобильных устройствах. Google старается упростить пользование Интернетом для владельцев смартфонов и планшетов, отмечая в мобильной выдаче адаптированные под мобильные устройства сайты специальной пометкой mobile-friendly . В Яндексе также работает алгоритм, который отдает предпочтение сайтам с мобильной/адаптивной версией для пользователей в мобильном поиске.

Проверить отображение страницы на мобильных устройствах можно на сервисах и .


Рис. 1. Мобильная выдача Яндекса и Google с пометкой о дружелюбности сайта к мобильным устройствам Что такое адаптивная вёрстка

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

Основные приёмы создания адаптивного сайта приведены в статье . Для отзывчивого дизайна ширина основного контейнера сайта задаётся в % , при этом она может быть равна как 100% ширины окна браузера, так и меньше. Ширина столбцов сетки также задаётся в % . В адаптивном дизайне ширина основного контейнера и столбцов сетки фиксируется с помощью значений в px .

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

Вёрстка главной страницы

Страница состоит из трёх основных блоков: верхний колонтитул (шапка), контейнер-обёртка для основного содержимого и сайдбара, и нижний колонтитул (футер). В качестве переломных точек дизайна возьмём 768px и 480px .

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


Рис. 2. Пример адаптивной верстки 1. Метатеги и раздел

1) Добавим в раздел необходимые файлы — ссылку на используемые шрифты, библиотеку jQuery, а также плагин prefixfree (чтобы не писать для свойств браузерные префиксы):

Адаптивная вёрстка сайта

2. Шапка страницы

В шапке страницы поместим следующие элементы-контейнеры:
логотип

Типы
  • Wi-fi настройка
  • Windows
  • Вирусы
  • Интернет
  • Программы
  • Ремонт
Популярные статьи
Новые статьи