Мобильный дизайн на Drupal: подходы, технологии, решение.

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

Responsive Web Design
Этот подход представляет из себя оптимизацию вёрстки сайта и создание резинового макета, который адекватно подстраивается под разные размеры экранов.
Основной приём - разделение экрана на блоки определённой ширины, которые при уменьшении экрана сначала пропорционально уменьшаются, затем падают друг под друга, когда места становится вообще мало.
Так же есть возможность добавлять conditional css styles для разных размеров экрана, благодаря чему можно скрывать некоторые блоки или изменять внешний вид элементов.
Основной недостаток:
Одинаковый размер загружаемого сайта у мобильных устройств и десктопа. На данный момент большинство мобильных пользователей используют 3G связь, которая значительно медленнее выделенных оптических линий, к которым есть доступ у десктопных пользователей. Из-за этого существует необходимость минимизировать размер загружаемого сайта для мобильных устройств. При данном подходе это невозможно.
Достоинства:
В Друпале проделан существенный объем работ в этом направлении. Существуют специальные theme frameworks, заточенные под responsive design, например Adaptive theme, Omega and so on.
Один и тот же контент как для мобильного сайта, так и для десктопного.
Один и тот же url, неограниченные возможности кеширования.
Недостатки:
Невозможность полной оптимизации под мобильные устройства - ваш контент будет тот же самый, что и для десктоп-пользователей.

Mobile Specific Site + серверные компоненты, Пример:bbc.co.uk
Это сайт с дизайном и разметкой, сделаный специально для мобильных устройств.
У него может быть отдельный url, например m.example.com, на который происходит редирект с основного сайта, используя server-side библиотеки.
Server-side библиотеки: существуют php-скрипты, которые по заголовку User agent запроса на сервер определяют разные типы устройств и выдают соответсвующую версию сайта для них.
На мобильном сайте может быть абсолютно не только другой дизайн, но и контент, заточенный под mobile user expirience.
Основной недостаток:
Нет 100% гарантии того, что мобильное устройство определится корректно. Требует обновления списка всех мобильных устройств.
Достоинства:
Меньший объем загружаемого сайта для мобильных устройств. Поддержка кеширования всех уровеней.
В друпале для решения проблемы администрирования контента на двух сайтах есть решение в виде мультисайтинга.
Недостатки:
При этом всё равно приходится использовать приёмы responsive дизайна, потому что все мобильные устройства имеют разные размеры экранов;
Перенаправления между сайтами и разделение посетителей на два сайта может сказаться на SEO продвижении.
Шаринг ссылок пользователями - необходимо настроить корректное перенаправление на мобильную версию и обратно. Опять нет железной гарантии что это произойдет корректно.

Сущетсвует вариант размещения Mobile Specific Site и обычного сайта на одном и том же URL, выбор какой элемент выдавать тоже лежит на основе серверных компонентов, Пример: cnn.com
Основной недостаток:
Кеширование.
в друпале существуют проблемы с кешированием таких решений. Конкретно, на данный момент в 7ке используется кеширование, основанное на url страницы. При этом мобильным пользователям может показываться страницы, закешированные под дексктоп и наоборот.
Уже существуют патчи, решающие эту проблему (они подменяют метод кеширования, предоставляемое ядром друпала на свой собственный) но они пока даже не закоммичены даже в dev-ветки модулей и не прошли существенного тестирования.
Кеширование внешними средствами, такими как varnish или любым другим web accelerator'ом при таком подходе невозможно в принципе, по той же самой причине, что описано выше. (Web accelerator может быть включен на сервере, но мы будем посылать http header с пометкой о том, что все страницы сайта кешировать нельзя)
Достоинства:
Малый объем загружаемых страниц для мобильных пользователей, более быстрая загрузка.
Удобство навигации - сайт заточен именно под мобильный user expirience
Для друпала разработан ряд модулей для этого решения, такие как например browscap и mobile tools
Недостатки:
Необходимость постоянного пополнения базы данных о новых мобильных устройствах.
Нет 100% гарантии того, что мобильное устройство определится корректно
Возможные проблемы с индексацией, если User Agent поискового бота определится неправильно.
Трудоёмкость поддерживания сразу двух сайтов (в друпале есть возможность это обойти с помощью мультисайтинга)

Объединение всех этих методов: Responsive web design + Mobile Specific Site + серверные компоненты: разные HTML и CSS для разных URL
Есть возможность сначала разработать responsive design, который будет адаптироваться под разные экраны. Этим мы решим недостаток server side components, а именно проблему новых, неизвестных нам устройств - нам неважно какое устройство используется, мы лишь знаем размер его экрана и отображаем сайт адекватно.
После этой итерации сайт уже можно будет запускать и пользователи уже смогут пользоваться этими позитивными изменениями.
Затем можно развернуть мультисайтинг на Друпале, который будет иметь те же материалы, что и основной сайт, но будет иметь отдельный url и свою тему оформления.
Таким образом мы решим проблему кеширования на одном и том же url , а так же сможем оптимизировать производительность и дизайн, заточенные под мобильных пользователей.
При этом придется решить ряд технических задач: индексацию страниц поисковиками, переадресацию пользователей при шаринге ссылок (если зашли с десктопа по мобильной ссылке - перенаправлять обратно и наоборот).
Автоматическое перенаправление будет осуществляться через server side components. Если по каким-то причинам они не справятся со своей задачей (например пользователь зайдет с нового мобильного устройства, которого нет в базе данных), в работу вступит responsive design и пользователь всё равно увидит удобный и адекватный сайт.
Достоинства:
Всех предыдущих методов
Возможность разбиения работы на итерации
Недостатки:
самый дорогой метод - по сути придется платить как за responsive дизайн, так и за mobile specific дизайн
Возможно, что вероятность ошибки определения User agent через server-side скрипты не стоит этих денег.

Вывод:
Всё зависит от того, насколько идеальным хочется сделать сайт заказчику. Если ему хочется сэкономить, то он может пожертвовать временем загрузки сайта для мобильных устройств и сделать responsive design, я думаю это будет дешевле.
Если ему всё же важно донести специальный user expirience до мобильных посетителей его сайта и оптимизировать время загрузки на мобильных устройствах, то конечно стоит делать Mobile Specific Site (на мультисайтинге друпала)
Если ему важно достичь идеала и быть the best во всём, не жалко денег - тогда надо делать и responsive и mobile specific дизайны/сайты.

По правилу золотой середины выходит, что вариант создания Mobile Specific Site с редиректом на него через server-side скрипты - лучший по соотношению цена/качество.
При этом есть вариант, что у CTO есть опыт настройки такого рода сайтов, он знает все нюансы такого рода кеширования - тогда возможен вариант с отображением мобильной/десктопной версии сайта на одном и том же url, как например, cnn.com или slideshare.net
Если такого опыта нет, я бы порекомендовал всё-таки использовать разные адреса.

Какие модули я собираюсь использовать сейчас:
Для создания responsive design, неважно, для всего сайта или только для Mobile Specific версии, я предпочту использовать тему оформления под друпал AdaptiveTheme framework.
Она достаточно быстрая для любого типа сайтов, хорошо кешируется.
Имеет огромное количество настроек под любые типы разрешений и девайсов. Имеет интеграцию со многими модулями.
Активно развивается, уже готовится к выходу версия под 8ю версию Друпала.
Есть вариант использовать самую простую тему mobile для Mobile Specific сайта, но тут надо взглянуть на варианты дизайна, которые разработает дизайнер и ui manager.

Для Mobile Specific сайта мне понадобятся следущие инструменты:
Если понадобится использовать разные адреса для мобильной и десктопной версий, то настройка мультисайтинга не требует каких-то отдельных модулей, это делается настройкой файла settings.php и манипуляциями с базой данных.
Для редиректа мобильных пользователей с обычной версии на мобильную я собираюсь использовать модуль browscap
На нём основано много других модулей-расширений для мобильных сайтов, но нам в принципе достаточно на первых порах будет функционала редиректа на основе User agent.
Если мы будем использовать один и тот же url, то этот же модуль нам поможет менять тему оформления на мобильную с помощью модуля mobile switch
Для выбора технологий уникального user expirience нужно прежде всего взглянуть на тот дизайн, который нужно будет реализовывать. Например, для выпадающего меню на своём сайте я использовал Mobile dropdown jQuery plugin, но если мы решим делать выезжающую слева навигацию по аналогии с фейсбук, то можно обойтись просто css с небольшим количеством javascript.
Для определения, какие устройства поддерживают особые свойства, а какие - нет, буду использовать друпаловский модуль-обёртку для библиотеки modernizr

Гайд по настройке мобильной темы: https://drupal.org/node/1214890
Ссылка по мультисайтингу для мобильных версий: https://drupal.org/node/26357
Ссылки на исследование проблемы кеширования: https://drupal.org/node/1730962
Большое кол-во ссылок по responsive design https://drupal.org/node/1388492
Паттерны мобильной навигации: http://bradfrostweb.com/blog/web/responsive-nav-patterns/
Обзор подходов к созданию мобильных сайтов: http://sixrevisions.com/mobile/methods-mobile-websites/

Комментарии

Vasili 29.05.2016 - 23:07

Чем можно скрывать/показывать области в panels для мобильных устройств?

Vasili 31.05.2016 - 20:22

Это понятно. display:none как бы не очень кошерно.
Всё остальное для сокрытия в панелях не работает :(

Nikita Petrov 11.07.2016 - 23:41

В таком случае вам нужно настраивать поддомен m.yoursite.com, и разруливать облегченный вариант страниц туда. Не вижу смысла в таком огромном объеме работ для облегчения страниц на несколько килобайт, разве что для огромных порталов с большим количеством посетителей и, соответственно, хорошими бюджетами.

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