Контактный телефон
Время работы
Пн-Пт, с 10:00 до 19:00
По любым интрересующим вас вопросам
Для СМИ и партнёров
Адаптивный веб-дизайн мобильной версии сайта - фото 1

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

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

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

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

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

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

Мобильные версии сайтов - пережиток прошлого

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

Позвольте мне процитировать Итана Маркотте, который придумал термин “адаптивный веб-дизайн”:

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

Итан Маркотте.

Адаптивный, мобильный и быстрый

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

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

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

Хотя в данном случае нельзя говорить о существовании универсального способа решения проблемы, который можно применять к документам любого типа, мы можем использовать пару приёмов, для того чтобы усовершенствовать нынешнюю версию адаптивного веб-дизайна своего сайта и максимально улучшить его функциональность:

  • Передавайте каждый документ на любые устройства через один и тот же URL и сохраняйте его контент. Однако вовсе не обязательно, чтобы он имел одну и ту же структуру.
  • Если вы начинаете разработку “с нуля”, придерживайтесь подхода “сначала мобильные устройства” (англ. mobile first).
  • Проверяйте на разных устройствах, что происходит при загрузке данных и при применении display: none. Не ограничивайтесь изменением размера окна браузера на своём стационарном ПК.
  • Используйте инструменты оптимизации для оценки и улучшения функциональности веб-сайта.
  • Передавайте адаптивные изображения через JavaScript до тех пор, пока производителями браузеров не будет предложено лучшее решение (такое, как, например, srcset).
  • Загружайте только те файлы JavaScript, которые вам нужны на текущем устройстве с помощью условной загрузки и при необходимости после события onload.
  • Предлагайте пользователям мобильных устройств предварительный просмотр (англ. initial view) документа или передавайте им сначала контент первого экрана (англ. above-the-fold content).
  • При разработке адаптивного дизайна применяйте одну или несколько технологий, таких как условная загрузка, адаптивность в зависимости от группы устройств, серверный слой (например, адаптивный подход).
Условная загрузка

Не всегда можно полагаться на медиа-запросы в CSS, потому что браузеры загружают и парсят все селекторы и стили для всех устройств (подробнее обсудим это ниже). Это значит, что мобильный телефон будет загружать и парсить CSS для более крупных экранов. А из-за блочной вёрстки (англ. blocks rendering) CSS вы будете терять ценные миллисекунды скорости мобильного интернет-соединения.

Замените медиа-запросы CSS на запрос JavaScript matchMedia на тех устройствах, контекст которых, как показывает ваше тестирование, не меняется. Например, мы знаем, что iPhone не может динамически преобразовывать размеры с iPad, поэтому простая загрузка CSS отлично подходит для него.

Мы также можем использовать инструмент для определения возможностей устройства (англ. feature detection), например, Modernizr, для того чтобы более грамотно разработать пользовательский интерфейс и функциональность сайта, учитывая при этом не только размеры экрана.

Адаптивность в зависимости от группы устройств

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

Даже если мы храним один и тот же документ на стороне сервера, мы можем в зависимости от группы устройств ввести спецификации для клиента. Например, мы можем использовать большое всплывающее меню на экранах размером 6 дюймов и больше и маленькие “меню-гамбургеры” на экранах размером меньше 6 дюймов. Для каждой группы устройств мы можем использовать технологии адаптивного дизайна, чтобы приспосабливаться к разным сценариям, таким как переключение между альбомной и книжной ориентацией экрана или переключение между экранами iPhone (шириной 320 пикселей), 5-дюймовых устройств на базе Android (360 пикселей) и фаблетов (400 пикселей и более).

Серверный слой

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

Комбинация адаптивного дизайна с компонентами серверного слоя - идея не новая. Специалисты называют это “адаптивный дизайн и компоненты серверного слоя” (англ. RESS) и считают, что такой вариант лучше, чем просто адаптивный веб-дизайн в плане скорости и юзабилити при условии использования одного и того же кода для каждого серверного слоя.
К сожалению, в последнее время эти технологии не пользуются большой популярностью в профессиональных кругах. Чтобы убедиться в этом, загляните в любой блог или журнал для веб-разработчиков и сравните количество упоминаний понятия “RESS” c количеством упоминаний слова “адаптивный”. Причина в том, что мы - front-end разработчики. Любые манипуляции, касающиеся сервера, кажутся нам проблематичными, и мы не хотим их выполнять.

В одних случаях front-end разработчик будет сам контролировать скрипт на сервере; в других случаях этим займётся удалённая команда back-end разработчиков, с которыми front-end разработчик не захочет взаимодействовать каждый раз, когда ему нужно будет немного исправить пользовательский интерфейс. Я прекрасно понимаю его мотивацию.

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

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

Адаптивный дизайн, функциональность и технические данные

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

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

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

Прежде чем делать выводы, давайте обратимся к некоторым данным.

Мобильное интернет-соединение

Системы 4G доступны не везде, но даже если бы все вокруг сегодня ими пользовались, ситуация скорее всего отличалась бы от той, которую вы себе представляете. 4G соединение используется менее чем на 3% мобильных телефонов. Только в США количество использующих 4G людей достигло 22%, но даже эти счастливцы 40% времени не пользуются им.

Обычно мы оцениваем скорость передачи данных в системах мобильной связи. В случае с 3G этот показатель достигает 5 МБ/с, в случае с 4G - 50 МБ/с. Но обычно скорость передачи данных - не самый важный аспект опыта взаимодействия пользователя с мобильным браузером. Хотя высокая скорость позволяет передавать большие по объёму файлы (такие как видеоролики с YouTube), она приносит мало пользы при загрузке большого количества маленьких файлов, время ожидания для которых большое и фиксированное. Время ожидания - это время возврата, за которое первый байт каждого пакета данных передаётся устройству после получения запроса.

Время ожидания в сетях сотовой связи обычно больше, чем для других способов интернет-соединения. Время ожидания для DSL-соединения в США составляет 20-45 миллисекунд, при 3G-соединении - 150-452 миллисекунд, а при 4G - 100-180 миллисекунд. Иначе говоря, время ожидания для мобильного Интернета в 5-10 раз больше, чем для домашнего Интернета.

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

Адаптивный дизайн для сетей сотовой связи

Рассмотрим кейс. Keynote - компания, которая специализируется на разработке функциональности сайтов, - опубликовала информацию о том, насколько функциональными были сайты, на которых размещалась реклама Суперкубка в 2014 году. Аналитические материалы говорят сами за себя: время ожидания для проводного Интернета или Wi-Fi варьируется от 1 до 10 секунд, а для мобильной интернет-сети - от 5 до 60 секунд. Только подумайте: Суперкубок рекламируют те, у кого на загрузку сайта уходит целая минута!

Адаптивный веб-дизайн мобильной версии сайта - фото 2

Функциональность сайтов, на которых размещалась реклама Суперкубка в 2014 году.

В том же докладе сказано, что 43% проанализированных сайтов имеют мобильную версию, средний размер которой составляет 862 КБ; 50% сайтов имеют адаптивный дизайн, и их средний размер составляет 3211 КБ (почти в 4 раза больше); а 7% имеют только версию для стационарного ПК, которая загружается и на мобильных устройствах. Очевидно, что веб-сайты, имеющие адаптивный веб-дизайн, больше по размеру, чем сайты, разработанные специально для мобильных устройств.

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

Браузеры, основанные на облачной технологии

Если вы всё ещё сомневаетесь, что функциональность - проблема мобильного Интернета, подумайте о тех производителях, которые предлагают браузеры, основанные на облачной технологии, чтобы улучшить пользовательский опыт, в том числе об Opera Mini - мобильном браузере на базе Asia (который, по данным StatCounter, занимает 11% долю на мировом рынке) - о Silk от Amazon Fire и о Google Chrome (в его настройках есть специальная опция).

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

Недооценка потенциала мобильного интернета

Интернет-сообщество всегда недооценивало важность мобильных браузеров. Я привык слышать высказывания людей о том, что выбор мобильных браузеров сегодня ограничивается Safari для iOS и Chrome для Android и что для разработки адаптивного дизайна нам нужно всего лишь позаботиться об экранах шириной 320 пикселей. На самом деле всё гораздо сложнее.

Сегодня более 10 браузеров занимают 1%-ю долю рынка. Даже если брать в расчёт только браузеры, встроенные по умолчанию в iOS и Android, ситуация окажется непростой. Грубо говоря, 50% пользователей мобильных устройств заходят в Интернет через iOS, 38% - через Android, 3% - через Windows Phone, 5% - через Opera Mini (на различных ОС), а 4% - через другие платформы.

64% пользователей Android сегодня используют встроенный браузер Android, который отличается от Google Chrome и существует в различных версиях. Более того, на некоторые новые устройства Galaxy от Samsung установлена своя версия браузера Android.

Если рассматривать только размер экрана, можно сказать, что сегодня мы имеем дело с экранами шириной 320, 360, 400 и 540 пикселей только на смартфонах на базе Android. Поэтому я предполагаю, что нельзя недооценивать потенциал мобильного Интернета, а нужно, наоборот, заниматься изучением его уникальных характеристик.

Загрузка контента первого экрана за 1 секунду
Мы можем считать, что веб-сайт быстро загружается на мобильном устройстве, если контент первого экрана (т.е. контент, для просмотра которого не нужно прокручивать страницу вниз) отображается за 1 секунду или меньше. Я знаю, что 1 секунда - это очень быстро, особенно учитывая, что как минимум половина этого времени уходит на установление мобильного интернет-соединения, но всё-таки доказано, что это возможно. Отклик сайта в течение 1 секунды способствует поддержанию вовлечённости пользователей, а следовательно - увеличению коэффициента конверсии и уменьшению количества отказов.

Чтобы добиться отклика за 1 секунду, контент первого экрана должен передаваться в одном направлении через интернет-протокол (англ. TCP); помните о том, что время ожидания для 3G соединения в среднем составляет полсекунды. Для оптимальной работы функции TCP под названием “медленный старт” первый ответ должен быть не больше 14 КБ, чтобы избежать получения второго пакета данных. Это значит, что HTTP-отклик для HTML и CSS контента первого экрана должны быть не больше 14 КБ. Если нам это удастся, то мы сможем уложиться во время загрузки сайта в 1 секунду.

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

Один HTML для всех

Традиционный адаптивный дизайн предполагает передачу одного HTML-документа на все устройства: телевизоры, ПК, планшетные устройства, смартфоны и телефоны с минимальным набором функций (англ. feature phones). Звучит обнадёживающе, но мы живём в мире, где существуют проблемы мобильного интернет-соединения и не только они. Ваш адаптивный HTML может передаваться корректно на мобильные устройства, но скорость его передачи не такая быстрая, как хотелось бы, и это отрицательно сказывается на конверсии.

Если хотя бы один display: none появится в любой из ваших CSS, то ваш веб-сайт уже не будет максимально быстрым. На сайтах, которые разрабатывались “с нуля” с учётом семантики, адаптивная перегрузка практически нулевая; на сайте, HTML которого включает в себя 40 внешних скриптов, плагины jQuery и библиотеки, что является преимуществом в основном для больших экранов, адаптивная перегрузка будет максимальной. Когда используется единый HTML, для всех устройств будут назначены единые внешние ресурсы.

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

Давайте рассмотрим веб-сайт компании Starbucks. Дизайн главной страницы является адаптивным и замечательно выглядит на экранах трёх устройств, которые мы протестировали (см. представленные ниже скриншоты). Но, проанализировав технические характеристики сайта, мы обнаружили, что все версии загружают одно и то же: 33 внешних файла JavaScript и 6 файлов CSS. Разве стоит загружать на мобильное устройство, имеющее столь большое время ожидания, 39 внешних файлов, чтобы отобразить представленный ниже дизайн?

Адаптивный веб-дизайн мобильной версии сайта - фото 3

Различные интерфейсы веб-сайта компании Starbucks.

Возможно, вы думаете: “Дело в неграмотной вёрстке, а не в технологии как таковой”. И вы правы. Цель данной статьи - не раскритиковать адаптивный дизайн. Она является критикой неграмотной вёрстки адаптивного дизайна и критикой такого подхода к дизайну, при котором адаптивность ставится выше функциональности, как в примере со Starbucks. Прекрасно, если вы без ущерба для внешнего вида сайта, можете изменять масштаб экрана, но масштаб экрана - не единственно важный аспект пользовательского опыта. Функциональность также имеет важное значение для пользователей мобильных устройств.

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

Медиа-запросы применяются разными способами, например, такими:

  • один CSS файл с множественным определением @media;
  • множественные CSS файлы, привязанные к главной странице через медиа-атрибуты.

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

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

<link rel="stylesheet" href="desktop.css" media="(min-width: 801px)">

<link rel="stylesheet" href="tablet.css" media="(min-width: 401px) and (max-width: 800px)">

<link rel="stylesheet" href="mobile.css" media="(max-width: 400px)">

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

Адаптивный веб-дизайн мобильной версии сайта - фото 4

Браузер будет загружать все внешние CSS файлы вне зависимости от контекста.

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

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

Хотя (пока) не существует масштабируемых окон браузера, некоторые из них могут менять размер в ряде ситуаций:

  • когда в определённых браузерах меняется ориентация;
  • когда режим просмотра меняется динамически;
  • когда контент добавляется после выполнения команды onload;
  • когда поддерживается зеркалирование;
  • когда несколько приложений одновременно открыты на устройствах Samsung на базе Android (в многооконном режиме).

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

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

Реальная проблема: адаптивный дизайн как самоцель

Как говорит Лиза Дэнжер Гарднер в статье “Что мы понимаем под словом “адаптивный”?”, дизайнеры дают разные определения слову “адаптивный”, что может привести к некоторой путанице.

Давайте зреть в корень. Термин впервые появился в 2010 году в статье Этана Маркотте, после чего вышла в свет одноимённая книга. Этан понимает под “адаптивным дизайном” обеспечение оптимального опыта просмотра сайта на различных устройствах путём использования трёх технологий: резиновых сеток (англ. fluid grids), гибких по размеру изображений и медиа-запросов.

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

Когда вы ориентируетесь только на разработку адаптивного дизайна, очень легко ошибиться с выбором правильной цели. Какую основную проблему вы пытаетесь решить? Разве “адаптивность” дизайна - проблема? Наверное, нет. Но понимаете ли вы под словом “адаптивный” “совместимый с мобильными устройствами”? Если так, то вы, возможно, ошибаетесь.

Основной целью разработки веб-сайта должна быть “удовлетворённость пользователей”; именно достижение этой цели приведёт к росту конверсии, в каком бы виде она ни была представлена: будь то распространение информации пользователями, информирование или продажа. Пользователи будут довольны только в том случае, если ваш сайт отлично функционирует.

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

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

Адаптивный дизайн и пользователи

Пару месяцев назад The New York Times осуществил редизайн сайта с целью удовлетворения потребностей пользователей. В то же время тысячи других крупных компаний представляют новый адаптивный вариант дизайна своих сайтов.

Сотрудники The New York Times разрабатывают адаптивный дизайн многими способами, а некоторые люди жалуются на то, что продолжается использование отдельной мобильной версии сайта вместо адаптации макета таким образом, чтобы все версии были привязаны в одному HTML. Этой теме даже посвящена целая статья: “Новейшему приложению от The New York Times не хватает адаптивного дизайна”.

Адаптивный веб-дизайн мобильной версии сайта - фото 5

Сотрудники The New York Times разрабатывают адаптивный дизайн разными способами.

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

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

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

Вывод

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

Брэд Фрост.

Брэд Фрост абсолютно прав. Пользователям нужен сайт, который быстро загружается и легко используется. Обычно они не меняют размер окна браузера и даже не понимают, что значит “адаптивный”.

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

Выбранные The New York Times ориентиры абсолютно правильны: удовлетворённость пользователя - наша главная цель. А не инструмент, не технология и даже не залог успешности дизайнера.

Оригинал:

http://www.smashingmagazine.com/2014/07/22/responsive-web-design-should-not-be-your-only-mobile-strategy/

Автор: Максимилиано Фёртман

Веб-разработчик и разработчик ПО для мобильных устройств, консультант, преподаватель и автор книг “Programming the Mobile Web (2nd. edition)” и “Up and Running: jQuery Mobile”. Он часто выступает в качестве докладчика на таких мероприятиях, как Fluent, JSConf, TopConf, Velocity Conference и рассказывает о функциональности ПО и о мобильном HTML5. Он организовал более 200 тренингов в более чем 20 странах. Он ведёт список совместимости HTML5 с мобильными устройствами и регулярно публикует в своём блоге информацию о новых функциях мобильных браузеров.
Оставьте заявку, и мы подготовим вам предложение
Вы получите лучшее предложение уже завтра. Или как минимум практические советы, которые сможете внедрить и улучшить свою рекламу.
Что дальше:
Позвоним
Проведем
аналитику
Разработаем
прогноз
Презентуем
стратегию
Подпишем
договор
Запустим
проект
Подпишись сейчас и получи подарок
Большой и эксклюзивный чек-лист: 100+ коммерческих факторов, влияющих на ранжирование сайта
Спасибо за заявку.
Наш менеджер свяжется с вами в ближайшее время.
Кликните в любом месте для закрытия окна.