Люди теряют интерес к сайту, если не получают от него ответ в течении трех секунд. Следуя этому условию, существуют совершенно иные условия анализа, дизайна и тестирования для мобильных версий сайтов.
Мы рассмотрим различные методы проверки взаимодействия людей с сайтом, базируясь на этом, будем разрабатывать наиболее оптимальные решения дизайна.
Все техники мобильного дизайна, основываются на двух фактах, которые не будут изменяться в ближайшем будущем – это маленькие батареи и маленькие экраны.
Маленькие батареи
Мобильные устройства используют радиоволны для коммуникаций, которые сильно влияют на заряд батареи. 2G и 3G волны осуществляют HTTP соединение в течении 2 секунд. Если взять во внимание, что пользователь теряет интерес в течении 3 секунд, то остается всего лишь одна секунда для загрузки и отображения сайта. Примите эту секунду, как стандарт для своего сайта
Маленькие экраны
В реальном мире, контент разработанный для журналов и бордов оптимизирован по размеру и дистанции, с которой будут на него смотреть.
В цифровом мире, типичный среднестатистический смартфон имеет площадь 6 квадратных дюймов.
Это не значит, что нам нужно уменьшить количество контента на странице, но можно оптимизировать процесс разработки мобильного сайта.
Примеры кода в этой статье будут поданы на .NET. Также возможно реализовать аналогичные алгоритмы на PHP, Java, C или Python.
Увеличение длительности «одной секунды»
Дизайнеры и разработчики, у которых хорошее Wi-Fi соединение, зачастую воспринимают его за эталон скорости. Дизайн, оптимизирован для разных устройств, должен подразумевать в себе то, что будет быстро загружаться при разной скорости передачи данных.
Симуляция реального мира
Многие Wi-Fi роутеры позволяют установить лимит скорости загрузки и отправки данных. Мы используем Linksys E3000 роутер, который дополняется софтом DD-WRT. Процесс настройки роутера очень прост, все инструкции можно найти на сайте DD-WRT.
После того, как софт установлен. Открываем вкладку QoS (quality of service), и активируем лимит соединения. После чего, устанавливаем скорость передачи и приема данных. Предпочтительно поставить 256 kbps на прием и 28 kbps на передачу. Таким образом, у нас есть среднестатистическое мобильное соединение.
После внесения параметров, можно вести наблюдения изменений скорости на графике.
Поверьте. Лучше изначально ограничить скорость соединения, нежели в конце разработки тестировать на медленном соединении. Так вы уменьшите затраты времени на разработку проекта.
Нельзя управлять тем, чего нельзя измерить
Это слова выдающегося менеджера Питера Дракера.
Продолжайте вести наблюдения за контентом, который просматривают пользователи, и за характеристиками их устройств. Это поможет понять, что наиболее популярно среди посетителей конкретных мобильных устройств (устройств с определенным набором технических характеристик). Возможно, большой разницы не будет, но этого не поймешь, пока не «измеришь».
Пример из практики
Одна популярная сеть заведений фаст-фудов хотела создать мобильную версию сайта. Перед созданием, они провели анализ своего веб сайта. Выявилось, что всех пользователей, заходивших с мобильных устройств наиболее интересовало: главное меню, специальные предложения, и адреса заведений.
На основе этого, был создан мобильный сайт, сфокусированный на этих областях.
На этом работа не останавливалась. Дальнейший анализ показал, что более всего пользователей интересовал поиск заведений. Главная страница мобильной версии сайта была изменена, с ориентиром на функционал поиска заведений.
Дальнейший анализ показывает, какими опциями пользуются пользователи, и что надо обрезать. Сайты для мобильных устройств должны быть минимизированы и содержать только необходимые элементы.
Ведение LOG файлов
Такие сервисы как Google Analytics и Яндекс Метрика, показывают некоторую информацию об устройствах. Но, все же остаются детали незамеченными. Например, следующий кусок кода написанный на .NET получает размеры экрана устройства и записывает в CSV файл.
// создание лог файла // размер экрана будет в дюймах File.AppendAllText( Path.Combine( AppDomain.CurrentDomain.BaseDirectory, String.Format( "App_Data\\Simple_Log_{0:yyyyMMdd}.csv", DateTime.UtcNow)), String.Format("{0:s},{1},{2},{3}\r\n", DateTime.UtcNow, Request.Path, Request.Browser["ScreenInchesWidth"], Request.Browser["ScreenInchesHeight"]));
Первая колонка – это дата и время, когда была взята статистика. Вторая – это страница, которая загружалась. Последние две – показывают ширину и высоту дисплея. Когда будет достаточно данных, можно проводить анализ. Для этого можно составить график, подобно данному ниже.
Сравнение размеров дисплеев мобильных устройств за последние 20 месяцев.
Заметьте! Также можно добавлять другие колонки: браузер, ОС, и другое.
Подобный код реально написать на PHP, Java, Python.
Почему мониторинг?
Мониторинг позволяет нам убрать не нужные элементы с главных посадочных страниц. Убранный контент не должен быть удален, его стоит разместить на других страницах. Только не на главных (посадочных), где он будет сжирать трафик и понижать скорость загрузки сайта.
Как же нам создать отдельный сайт, который идеально подойдет для конкретного мобильного устройства?
Разделяй и властвуй
Мы понимаем, что резиновый дизайн очень удобен для интерфейса пользователя. Это отлично подходит в случае, когда элементы навигации и контент идентичны, как для 6 дюймового, так и для 100 дюймового дисплея.
Средний размер дисплеев устройств
Хотя, создание отдельного сайта для мобильных устройств играет большую роль, когда необходимо создать высококачественный сайт с разделенным функционалом.
В общем, мобильные версии сайтов реализованы плохо. О чем упоминает Google [1], и предупреждает о понижении в выдаче. Ошибка заключается в переадресации из страниц базового сайта на главную страницу мобильного. Что удаляет пользователя от желаемого контента, и показывает скудную версию сайта для различных операционных систем мобильных устройств (некоторые вполне способны нормально отображать базовую версию сайта).
Следующий .NET код web.config секции, будет переадресовывать первый запрос от смартфона на эквивалентную страницу мобильной версии сайта. Важно, чтобы строка запроса и имя страницы сохранялись при переадресации.
<redirect firstRequestOnly="true" mobileHomePageUrl="~/Mobile/Default.aspx" timeout="20" devicesFile="~/App_Data/Devices.dat" mobilePagesRegex="/(Mobile|Smartphone)/" > <locations> <!--Send smartphones to an equivalent version of the original page, preserving the page name and query string.--> <location name="smartphone" url="~/Smartphone/{0}" matchExpression="(?<=^\w+://.+/).+"> <add property="IsSmartphone" matchExpression="true"/> </location> </locations> </redirect>
В большинстве случаев, переадресованные пользователи должны иметь возможность вернутся обратно на базовую версию страницы; так как они более знакомы с широкоформатной версией сайта.
Атрибут firstRequestOnly обеспечивает переадресацию только первого запроса от устройства.
Атрибут devicesFile используется для отслеживания устройств, которые не поддерживают cookies.
Атрибут timeout отвечает за то, как долго будем хранить в памяти устройство (которое будет переадресовано).
В такой концепции переадресации, также важно определить, какие страницы будут отображаться для определенных типов устройств. Атрибут mobilePagesRegex встроен в запрашиваемый URL. Если находится совпадение, то переадресовывать не будем. Это предотвращает бесконечные переадресации.
Такой простой участок кода позволяет удовлетворить требования Google и предоставить удобный интерфейс для пользователя. Пользователи, которые пожелали остаться на базовой версии сайта, также будут уважены.
Остерегайтесь облачных архитектур
Облачная архитектура очень популярна. Но, она уступает в плане отзывчивости. Передача данных из Amazon облачной структуры составила задержку в 200мс, не включая время обработки.
200 миллисекунд – это 20% эталонной секунды. Поэтому пользуйтесь осторожно. Убедитесь, что запрос реализован асинхронно, чтобы другие процессы продолжались пока ожидается ответ.
Сжатие контента
Видео, картинки, CSS, HTML – для всего этого нужны методы сжатия и оптимизации. Для видео оставим другую статью.
Изображения
Популярный способ создания троих изображений, после чего загружать определенное для каждого из типов устройств. Хорошая идея, но использовать три изображения – это лишняя головная боль; изображение никогда не будет идеально оптимизированно, потребуются средства ограниченных мобильных процессоров и ресурсы батареи.
Лучше использовать готовые решения. Или написать оптимизатор самому. Например, мы пользуемся следующим алгоритмом:
- При добавлении изображения администратором, делается копия в трех размерах автоматически (640, 480, 240).
- При клиентском запросе страницы, определяется тип устройства и выводится 1х1 прозрачный GIF пиксель.
- По завершению загрузки страницы, асинхронно вместо пикселя подгружаются нужного размера изображения (с помощью JS).
Такой подход позволит экономить пользовательский трафик, CPU мобильного устройства и заряд батареи.
HTML
Для веб сайтов, это не так критично переживать по поводу размера html файла. В мобильном сайте важен каждый байт. Не обязательно использовать инструменты сжатия кода, можно просто пользоваться короткими именами классов и ид элементов. Например, вместо Id=ImageBanner просто использовать Id=B.
Обращая внимание на такие мелочи как сжатие html и css, можно существенно сократить размер страницы.
Заключение
Важно помнить, что настройка скорости соединения и мониторинг характеристик мобильных устройств – это стартовая точка в разработке сайта.
Если остались вопросы и пожелания, смело пишем в комментариях ниже.