Архитектура веб-сайта

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

Да, мобильный веб-сайт это в первую очередь просто веб-сайт, но, при этом, некоторые детали могут очень отличаться.

Навигация

Прежде чем приступить к написанию кода, ты должен еще на стадии создания концепции мобильного сайта определить, что будет в дереве навигации для пользователя. Чтобы справится с этой задачей, ты должен понимать, какие услуги и информация могут быть доступны для мобильных пользователей. Всегда помни о законе 80/20: 80% твоего декстопного сайта не принесет никакой пользы мобильным пользователям. Поэтому тебе нужно сосредоточиться на оставшихся 20%.

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

Вот некоторые рекомендации, которым ты должен следовать:

• определи основные варианты использования: найти ближайший магазин, найти цены на товар, позвонить, выполнить поиск;
• выясни наиболее типичный вариант поведения на сайте пользователя мобильного устройства, принимай во внимание свой опыт, интуицию, статистические данные и тесты юзабилити;
• сделай все возможное, чтобы пользователь совершал законченное действие на сайте не более чем за три клика или по глубине не далее трех страниц;
• определи примерно три основных раздела после главной страницы (если нужно больше, тогда нужно разделить свой сервис на большее число мобильных страниц);
• всегда предлагай пользователю ссылку на декстопный сайт;
• выясни, нужно ли для твоего сервиса определять местоположение пользователя;
• сведи к минимуму размер формы ввода данных для пользователя;
• избегай использования стартовых или приветственных экранов;
• сделай все возможное, что бы предугадать желания пользователя в зависимости от контекста и его истории просмотра страниц, чтобы уменьшить количество необходимых кликов и страниц в выборке.

Ситуация

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

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

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

Пример плохой навигации

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

Когда ты заходишь на сайт, то видишь страницу приветствия с ссылкой «Начать». Потом нужно выбрать из списка интересующий тебя автобус. Потом открываются названия конечных остановок и нужно определить направление движения. После выбора направления нужно определить остановку, на которой ты планируешь сесть на автобус. И здесь список из примерно 50 адресов в алфавитном порядке. Если ты не знаешь точного названия улицы, на которой находится интересующая тебя остановка, то тебе придется сделать примерно 25 кликов, чтобы найти нужную.

Теперь когда ты нашел нужную остановку, нужно определится какой нужен тип автобуса: обычный или для людей с ограниченными возможностями. И вот, наконец, сервис дает тебе информацию, когда подойдет ближайший автобус. Итого, чтобы получить результат, нужно пройти 6 страниц и выбрать из списка с 50-ю элементами.

В моем городе в будние дни автобусы ходят через короткие промежутки — от 5 до 8 минут. И в какой ситуации получается можно эффективно пользоваться этой службой? Вероятно ночью или в выходные дни. В первый раз, когда я воспользовался этим сервисом, это была ночь (около 1 ночи). И что я получил после прохода 6 страниц? Сообщение «Информация недоступна»! Сервис не работал ночью!

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

Прогрессивное улучшение

Постепенное улучшение (Progressive enhancement) — простая, но очень эффективная техника в веб-дизайне, которая определяет слои совместимости и позволяет пользователю получить доступ к основному контенту, сервисам и функционалу с расширенными возможностями для браузеров с лучшей поддержкой стандартов и в боле простом виде, для боле слабых браузеров.

Термин был введен Стивеном Чампеоном в году и в то время этот метод не применяли целенаправленно к мобильному вебу, хотя как раз для мобильного веб-дизайна он подходит идеально. Концепция прогрессивного улучшения подрывает типичную концепцию веб-дизайна известную как "graceful degradation" («постепенное ухудшение»), при которой разработка осуществляется под последние технологии и браузеры и такие проекты на старых браузерах автоматически работают с меньшим (урезанным) функционалом. Как мы сможем дальше убедиться, такая техника не слишком полезна при разработке под мобильные браузеры, потому что в мобильном мире есть серьезные проблемы с совместимостью. Если мы разрабатываем сайт для наиболее продвинутых типов мобильных устройств (для iPhone, например), то вполне возможно, что он не будет работать на устройствах более низкого класса.

Концепция прогрессивного улучшения основывается на следующих основных принципах:

• базовый (основной) контент должен быть доступен для всех браузеров;
• базовый функционал также должен быть доступен во всех браузерах;
• контент должен быть размечен семантически;
• улучшение разметки обеспечивается подключением внешнего CSS;
• улучшение поведения обеспечивается подключением внешнего JavaScript;
• в конце добавляем «фишки» специфические для некоторых браузеров.

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

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

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

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

1. Создай валидную и семантическую разметку, в которой будет только контент: без CSS, без frames или iframes, без JavaScript или Ajax. Весь контент и весь функционал сайта (кроме некоторых нестандартных функций вроде геолокации) должен работать с этой простой версией.
2. Вставь в документ любые специальные теги или классы, требуемые для каких-нибудь специфических для устройства функций, вроде ссылки обратной связи или формы контроля загрузки файла.
3. При желании, на стороне сервера реши, какой MIME-тип будет использоваться и распознай устройство.
4. Опять же по желанию, на стороне сервера, замени специальные теги, проставленные в шаге 2 с реальной разметкой в зависимости от возможностей устройства.
5. Добавь кусок CSS для основных устройств, один для high-end и один для каких-нибудь специфических смартфонов (например, для Android и iPhone). Можно прописывать сразу все стили в CSS применяя CSS media queries или использовать серверный механизм, чтобы определить какой именно CSS файл применить.
6. Добавь фрагмент ненавязчивого JavaScript для валидации формы и некоторых основных функций.
7. Добавь ненавязчивый Ajax для обновления контента, включая обработку события onclick для каждой ссылки.
8. Добавь ненавязчивый JavaScript и кусок CSS для расширенных функций (анимация, эффекты, геолокация, автономное хранение и т.д).
9. При необходимости добавь при помощи нового «слоя» поддержку виджета.

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

Подход «Разные версии»

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

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

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

Low-end устройства

Базовая разметка XHTML, максимальная ширина экрана 176 пикселей, базовая поддержка CSS (цвет текста, цвет фона, размер шрифта), невозможность применения JavaScript.

Mid-end устройства

Базовая XHTML разметка, в среднем ширина экрана составляет 240 пикселей, средний уровень поддержки CSS (блочная модель, изображения), базовая поддержка JavaScript (валидация, редирект, диалоговые окна).

High-end устройства

Поддержка XHTML или HTML 4 разметки, в среднем ширина экрана составляет 240 пикселей, отличная CSS поддержка (на уровне настольного компьютера), поддержка Ajax DOM, опциально возможна поддержка сенсора, изменения положения (для экрана шириной в среднем 320 пикселей).

Продвинутые смартфоны

HTML 5, большой размер экрана и высокое разрешение, поддержка сенсора, CSS расширений (анимация, эффекты), Ajax, хранилище, геолокация.

Старые устройства (по желанию)

WML (рассмотрим позже).

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

Куда дальше

• следующая — Дизайн и юзабилити
• предыдущая — Глава 2. Мобильные браузеры. Эпохи мобильного Интернета
• содержание

По теме

• :: Концепция прогрессивного улучшения