| Usability.Ru | Статьи | Персоналии | Коллективы | Библиотека | Глоссарий | Обучение | Форум | Ссылки |
Ярослав Перевалов
yar-home@yandex.ruРуководство по проектированию wap/web-интерфейсов мобильных устройств
Оглавление
1. Назначение и структура документа
3.1. Пользователь выполняет много задач одновременно
3.3. Экран мобильного устройства редко находится в условиях идеального освещения
4. Эргономические требования, налагаемые особенностями оборудования мобильного устройства
4.2. Параметры экранов значительно варьируются
4.3. Малоразмерный кэш и cookies
4.4. Ограниченные возможности ввода..
5. Общие эргономические требования к пользовательскому интерфейсу продукта для мобильного устройства
5.1. Выбор способа представления, вида интерфейса в зависимости от типа мобильного устройства.
5.2.2. Баланс между широкой и глубокой структурой навигации
5.2.3. Клавиши доступа (клавиши быстрого перехода)
5.2.4. Наименования ссылок и их описания
5.3. Тело страницы: расположение блоков и элементов, информационное содержимое
5.3.1. Содержимое страницы (контент).
5.4. Вёрстка и структурная разметка страниц
5.4.1. Заголовок окна страницы <TITLE>
1. Назначение и структура документа
Документ адресован разработчикам приложений для мобильных устройств.
Под разработчиками в первую очередь подразумеваются проектировщики пользовательских интерфейсов, во вторую очередь те, кто тесно связан с разработкой ПИ – аналитики, дизайнеры, программисты, верстальщики, тестеры.
Под приложениями подразумеваются в первую очередь wap-сайты.
Под мобильными устройствами в первую очередь понимаются сотовые телефоны среднего класса (на момент написания документа – сентябрь 2006 г. – это телефоны с разрешением экрана 128х128 и без указательного устройства).
Документ написан в виде творческого авторского перевода Mobile Web Best Practices (MWBP). Часть требований, излагающихся в исходном документе и относящихся не столько к ПИ, сколько к специфике разработки (например, такие технические аспекты разработки, как применение cookies или кодировки), автором опущены.
Содержание каждого раздела состоит из двух частей: в первой описывается проблематика и контекст применения, во второй даётся список достаточно чётких требований и рекомендаций по проектированию.
Автор постарался сосредоточиться на специфике интерфейсов именно мобильных устройств. Часть очевидных эргономических требований, относящихся к общему программному обеспечению и веб-интерфейсам, в рамках данного документа не рассматриваются (например, требования к консистентности, соответствия пользовательским задачам, управляемости, обратной связи, и т.д.).
Та часть, которая в разделах MWBP обозначалась как Human Test, будет в рамках настоящего документа переработана в виде отдельного приложения с чеклистами (в последствии, если будет на то воля богов), что позволит проводить достаточно формальное и технологичное тестирование качества реализации пользовательского интерфейса.
Следует заметить, что положительные результаты такого тестирования не будут означать, что создан продукт с заведомо шикарным ПИ. Этот результат будет только лишь означать, что в целом и общем соблюдены требования, излагаемые в данном документе. Для достижения высоких юзабилити-характеристик продукта следует применять весь арсенал средств юзабилити-проектирования, тестирования и экспертизы.
Тем не менее, соблюдение изложенных в настоящем документе требований позволит заведомо повысить эргономику создаваемых продуктов.
Документ создан при поддержке www.wapstart.ru
2. Сокращения и определения
Продукт – разрабатываемый сайт, система, приложение, программа для использования на мобильном устройстве.
Потребитель, пользователь – владелец мобильного устройства, использующий продукт, мобильный пользователь.
ПИ (UI) – пользовательский интерфейс разрабатываемого продукта.
МУ (MD) – мобильное устройство: сотовый телефон, смартфон, коммуникатор, и т.п. – малоразмерный аппарат, позволяющий использовать продукт.
URI - Uniform Resource Identifier, адрес сайта или ресурса, приложения, мобильного контента и т.п.
3. Эргономические требования, налагаемые особенностями рабочего окружения и условиями использования мобильного устройства
3.1. Пользователь выполняет много задач одновременно
При работе с мобильным устройством пользователь, как правило, находится в движении: едет в транспорте, стоит в очереди, идёт пешком, сидит в кафе, беседует, слушает лекцию и т.п.
Следует также отметить, что изначальная функция мобильного телефона – голосовая связь, и сеанс такой связи может также прервать работу пользователя с продуктом.
Такая деятельность (по сравнению с идеальными офисно-лабораторными условиями) отнимает существенное количество когнитивных ресурсов: пользователь часто отвлекается, прерывается для выполнения других (внешних по отношению к используемому приложению) задач.
Соответственно, хотя бы для частичной компенсации и учёта этих факторов следует выполнять следующие требования:
- Должен быть чётко обозначен контекст выполняемой в приложении операции – в первую очередь за счёт коротких, но информативных заголовков, корректного именования ссылок и командных кнопок, других объектов.
- Максимальное количество действий должно носить обратимый характер (программа должна быть терпима к случайным ошибкам пользователя – например, случайный, неправильный ввод возможен за счёт непроизвольных и случайных толчков при движении в толпе или транспорте).
- В интерфейсе не должно быть ничего лишнего, что отвлекало бы внимание пользователя или запутывало бы его в принятии решений. Структура возможных действий и их последствий должна быть максимально явной и очевидной. Каждый символ, каждый пиксель должен быть обоснован, служить цели и выполняемой задаче пользователя.
- Не следует экономить на памяти пользователя – критическая информация, важная для выполнения задачи, должна быть доступной.
3.2. Цели пользователей
Пользователи мобильных устройств часто имеют интересы, отличающиеся от пользователей стационарных устройств: пользователи МУ обычно имеют более прямые, непосредственные и целенаправленные намерения.
Например, показательной типичной целью мобильного пользователя может быть нахождение информации, непосредственно связанной с контекстом среды, в которой находится пользователь: найти информацию о расписании движения транспорта во время совершаемого путешествия.
Пользователи МУ обычно мало заинтересованы в длинных документах и их тщательном прочтении, рассматривании, изучении. Обычно эргономика МУ плохо приспособлена для чтения объёмных документов. и пользователи обращаются к таким ресурсам только как последнему средству, ввиду отсутствия доступа к информации, сформатированной в более подходящем виде.
Требования:
- Перед началом проектирования интерфейса продукта следует чётко специфицировать цели, задачи и информационные потребности пользователя продукта, описать среду и условия применения.
- Объёмную информацию (приемлемую для отображения на больших дисплеях) следует специально форматировать в виде, пригодном для отображения на МУ, например:
· выводы и итоговые данные следует помещать в начало страницы,
· ключевые слова и критические данные следует помещать в начало абзаца,
· в таблицах отображать только самые важные столбцы,
· итоговые строки выносить в начало таблицы и т.д.
3.3. Экран мобильного устройства редко находится в условиях идеального освещения
ЖК-дисплеи, широко применяемые в мобильных устройствах, чувствительны к яркому (солнечному) освещению – при таком освещении дисплеи теряют контрастность и разглядеть на них текст бывает затруднительно.
Требования:
- Следует особое внимание уделять соблюдению наивысшего контраста текста: располагать тёмный текст на светлом фоне, или наоборот – светлый текст на тёмном фоне (наивысший контраст даёт отношение чёрный/белый).
- Желательно избегать ярких фоновых заливок использования графических обоев, затрудняющих восприятие текстовой информации. Если всё-таки таковые используются, то следует применять двуцветные шрифты (чёрные символы с белой окантовкой).
- По возможности следует применять крупный шрифт или обеспечить пользователя возможностью изменять размер шрифта.
4. Эргономические требования, налагаемые особенностями оборудования мобильного устройства
4.1. Малоразмерный экран
Большинство мобильных устройств имеет ограниченный размер экрана (большинство устройств имеет экран размером 128 х 128 пикселей). На таком экране невозможно разместить много информации.
Требования:
- Информация должна быть представлена в сжатом, но информативном виде.
- Лишних и второстепенных деталей не должно присутствовать в интерфейсе
- Следует использовать принцип «вложенности», т.е. давать информацию порциями, когда каждый информационный элемент может быть более подробно расшифрован на отдельной странице.
4.2. Параметры экранов значительно варьируются
У различных устройств экраны разного размера и могут отображать различное количество цветов.
Требования:
- Следует применять вёрстку без привязки к размерам экрана, так, чтобы данные корректно отображались на экранах разного размера
- Цветовое оформление должно адекватно отображаться на экранах с различной глубиной цвета, в т.ч. и монохромных.
- Кодирование цветом допустимо только лишь как вспомогательное, но не основное.
4.3. Малоразмерный кэш и cookies
Количество информации, отображаемое на одной странице, ограничено.
Количество последовательных экранов, сохраняемых в памяти устройства, ограничено.
Количество данных о посетителе сайта, которые устройство может запомнить, ограничено.
Требования:
- Страницы с объёмным содержимым (длинные списки и тексты) следует разбивать на несколько страниц.
- Система навигации должна минимальной, но соответствовать текущим потребностям (выполняемой задаче) пользователя.
- Следует использовать оптимизированный код и небольшие CSS.
4.4. Ограниченные возможности ввода
Большинство мобильных устройств обладают весьма ограниченным набором средств ввода: клавиатура с небольшим количеством клавиш, размер клавиш маленький, чаще всего указательное устройство отсутствует.
Этот факт приводит, например, к трудностям корректного набора длинных URI с большим количеством знаков препинания, к трудностям корректного заполнения форм со многими полями и т.п.
Следует помнить о том, что не на всех устройствах есть кнопка, обладающая функциональностью кнопки Back, либо пользователи могут не догадываться о существовании такой возможности.
Пользователь обычно может вводить информацию только одной рукой (иногда только одним-двумя пальцами), т.е. скорость ввода может быть значительно низкой, а ошибки ввода – значительно частыми.
Требования:
- Следует свести количество нажатий клавиш к минимуму. Например, следует использовать как можно более короткие URI-адреса
- Следует избегать полей со свободным пользовательским вводом. Например, следует заменять поля ввода другими контролами, которые не требуют длительного ввода: разворачивающимися списками или радиогруппами.
- Количество полей, обязательных для заполнения, должно быть сведено к минимуму, необязательные для заполнения поля убрать вообще либо вынести на отдельную страницу.
- Максимальное количество полей в заполняемых пользователем формах должно быть заполнено значениями по умолчанию.
- При первом посещении пользователем формы ввода можно заполнить форму наиболее часто употребимыми (вводимыми другими пользователями) значениями по умолчанию.
- Если пользователь заполнял уже эту форму, то при повторном её посещении следует восстановить её заполненный вид (опционально – по желанию пользователя).
- Если это возможно, следует применять технику автозаполнения/автоподстановки (приложение по нескольким первым введённым символам предлагает пользователю варианты из ранее вводимых значений для подстановки в это поле).
- Следует также устанавливать по умолчанию режим ввода, язык и формат ввода там, где это уместно (чтобы у пользователя не возникало необходимости в дополнительных настройках и переключениях).
- Там, где уместно ограничить набор вводимых символов, следует сделать это. Например, при вводе телефонного номера или указания времени, вряд ли потребуется вводить буквы.
- В навигации следует обеспечивать возврат к предыдущему экрану (Back), особенно там, где это может помочь исправить некорректный или ошибочный пользовательский ввод.
- Навигационное меню (ссылки на панели глобальной навигации по основным разделам сайта, присутствующей на каждой странице) должно иметь клавиши быстрого перехода (атрибут accesskey) – это даст возможность пользователям устройств без позиционирующих указателей избежать утомительного повторного нажатия навигационных клавиш.
4.5. Пропускная способность и цена трафика
Мобильные сети могут быть существенно медленнее сетей стационарных, и часто обладают существенными временными задержками. Это особенно ярко чувствуется на страницах с объёмным содержимым и при быстрых навигационных переходах (листании страниц).
Передача данных стоит денег.
Мобильные устройства часто поддерживают только ограниченный набор типов мобильного контента. Как следствие, полученный по ссылке контент может быть такого типа, который не поддерживается мобильным устройством пользователя.
Даже если МУ поддерживает закачанный контент, полученный контент может не удовлетворить потребителя – например, большая картинка только частично отображается на экране, или проигрываются не все голоса полифонической мелодии.
Страницы могут содержать контент, который не был явно запрошен пользователем, и пользователь не ожидает его получать (это, например, может быть реклама или большие изображения) – такой нежелательный материал снижает юзабилити и повышает цену использования.
Требования:
- Следует всеми возможными способами минимизировать объём единомоментно загружаемых страниц (оптимизировать код и изображения, использовать небольшие картинки только там, где это необходимо, разбивать объёмные страницы на несколько страниц, и т.д.) – это позволит повысить скорость реакции системы и цену использования, обусловленную объёмом трафика.
- Большие изображения следует предварять миниатюрами с явным указанием размеров и объёма загружаемой картинки.
- Ссылки на любой загружаемый мобильный контент следует специфицировать в явном виде (тип, объём, размер, и т.д.).
- Реклама должна быть явным образом и конситентно обозначена.
4.6. Реклама
Следует заметить, что для МУ и для стационарных компьютеров работают зачастую различные коммерческие модели. Например, некоторые механизмы, которые обычно используются для презентации рекламных материалов, не работают хорошо на малоразмерных устройствах.
Дополнительные требования к рекламному контенту см. в п. 5.3.1.
5. Общие эргономические требования к пользовательскому интерфейсу продукта для мобильного устройства
5.1. Выбор способа представления, вида интерфейса в зависимости от типа мобильного устройства.
Существует несколько способов определения параметров мобильного устройства.
Если системе удаётся достоверно определить тип устройства, она может автоматически настроить вид отображения контента и пользовательский интерфейс наилучшим для этого устройства образом (например, выбрать представление интерфейса: для стационарного компьютера или МУ).
Однако, если такого автоматического определения не происходит, система может выбрать вид отображения по умолчанию.
Требования:
- У пользователя должен быть способ сделать выбор вида отображения (чтобы изменить вид, выбранный автоматически или вид по умолчанию). Пользовательский выбор должен запоминаться, и затем, при следующем обращении к продукту, восстанавливаться.
5.2. Навигация и ссылки
5.2.1. Панель навигации
Многие страницы спроектированы со значительными навигационными панелями и прочими ссылками в начале страницы (хлебные крошки, формы поиска и пр.). Такой подход даёт удобную и хорошо распознаваемую метафору для больших экранов, однако для маленьких дисплеев это означает появление навигации вместо собственно контента, который востребован пользователем в первую очередь.
Пользователям важно видеть наиболее важное и релевантное задаче содержимое страницы после загрузки без необходимости прокрутки.
Требования:
1. Так как пользователю очень важно понять суть контента страницы сразу, без дополнительной прокрутки, вверху страницы следует отображать минимальное количество объектов, мешающих основной цели (включая навигационные ссылки, декоративные картинки, рекламу и другие объекты).
2. Вверху главной страницы следует отображать только основную, главную навигацию, расположенную в одну линию.
Второстепенная навигация может быть размещена в подвале страницы, если в этом есть действительная необходимость.3. Альтернативное решение: навигационное меню в виде простого списка ссылок можно расположить внизу страницы, а наверху отобразить только ссылку для перехода к этому меню.
5.2.2. Баланс между широкой и глубокой структурой навигации
Тип структуры
Плюсы
Минусы
Широкая неглубокая структура: множество ссылок (все ссылки) на одной странице.
Позволяет пользователю получить доступ и просканировать сразу весь широкий спектр возможностей и выбрать конечную цель навигации за одну загрузку страницы.
Операция скроллирования на большинстве мобильных устройств затруднена (для прокрутки требуется «скачок» фокуса ввода на следующую ссылку).
Очень длинный список может не поместиться на страницу (физическое ограничение на размер страницы).
Узкая глубокая структура: навигация осуществляется за счёт многих переходов с одной навигационной страницы на другую, на каждой странице ограниченное количество ссылок.
При грамотно составленной категоризации возможен довольно быстрый переход в нужный раздел без необходимости читать весь (длинный) список конечных страниц.
Загрузка дополнительных страниц требует времени и денег.
В случае ошибки поиск цели приходится осуществлять заново.
При наличии объёмной и сложно структурированной навигации следует находить разумный компромисс между широкой и глубокой структурой.
Требования:
- Широкая структура эффективна при наличии чёткого логического правила поиска по-порядку: алфавитная, числовая, временная сортировка элементов. Даже в этом случае можно применять комбинированный метод: длинный список можно разбить на интервалы. Например, исходный алфавитный список из 90 российских городов можно предварить меню [А-Д] [Е-М] [Н-Р] [С-Т] [У-Я].
- Узкая структура эффективна при наличии однозначной устоявшейся иерархической классификации, когда трудно совершить ошибку в выборе категории. Например, исходный алфавитный список из 90 российских городов можно предварить меню [Центральный регион] [Север] [Юг] [Сибирь] [Дальний Восток].
- Компромиссным подходом можно считать реорганизацию широкого списка в соответствии с частотой запросов (на верхний уровень вынести наиболее востребованные пользователями элементы, а упорядоченный список вынести на второй уровень). Например, исходный алфавитный список из 90 российских городов можно предварить меню [Москва] [Санкт-Петербург] [Новосибирск] [Другой город…], если достоверно известно, что 90% пользователей – из трёх самых крупных городов.
- Следует знать о том, что пользователи будут разочарованы, если не достигнут цели за четыре перехода от страницы к странице.
- Для коротких списков и иерархических структур оптимальным количеством элементов выбора на странице является 5-9 элементов, для очень длинных упорядоченных списков допустимым является 15-25 элементов выбора на странице.
- При реализации узко-глубокой навигационной структуры следует не забывать о необходимости дать пользователю явную возможность вернуться на уровень вверх или к началу иерархии (Back и Home).
- При составлении списков следует помнить о том, что ключевые слова в наименовании элементов следует помещать на первое место.
- Следует не забывать также, что утомительному блужданию по длинным спискам или сложной иерархической структуре можно противопоставить (а лучше дополнить) возможность поиска элемента по подстроке или ключевому слову.
5.2.3. Клавиши доступа (клавиши быстрого перехода)
Требования:
- Навигационное меню (ссылки на панели глобальной навигации по основным разделам сайта, присутствующей на каждой странице) должно иметь клавиши быстрого перехода (атрибут accesskey) – это даст возможность пользователям устройств без позиционирующих указателей избежать утомительного повторного нажатия навигационных клавиш.
5.2.4. Наименования ссылок и их описания
Переход по ссылке для пользователя МУ означает трату средств за трафик и трату времени в ожидании реакции системы. Пользователь не должен разочаровываться в ожидаемом результате – результат должен быть адекватен той цене, которую пользователь согласился заплатить.
Требования:
- Полученный результат должен быть интересен пользователю и соответствовать тексту, описывающему ссылку.
Если ссылки будут не только «не врать», но и говорить «всю правду», то это, в конечном счете, повысит лояльность пользователей, вызовет доверие пользователей к ресурсу и повысит ценность ресурса в глазах пользователей по сравнению с конкурентами и аналогами.- Короткое, но корректное наименование ссылки должно помочь пользователю оценить затраты своих ресурсов при переходе по ссылке и определить, интересен ли ему такой переход.
- Кроме текстового описания ссылки, полезно давать информацию как о формате получаемых данных (если он отличен от XHTML, или, например, на другом языке), так и о его объёме в килобайтах и прочих возможных характеристиках (размеры в пикселях, кодеки, количество голосов полифонии и т.д.). Как минимум, следует предупреждать в явном виде, что скачиваемый файл будет «большой».
- Ключевые слова в наименовании ссылок следует помещать на первое место. Описание должно отражать суть получаемой информации (например, не должно быть ссылок вроде «щёлкните здесь»).
- Если возможно заведомо определить, что данный тип контента (доступный по ссылке) не поддерживается данным устройством, следует явным образом это обозначить в интерфейсе (надписью, цветом или индикатором), но ссылка должна оставаться быть доступной для скачивания (например, пользователь может захотеть использовать закачанный файл на другом устройстве).
5.2.5. Image Maps
Большинство мобильных устройств не имеют эффективного указующего устройства, и поэтому использование Image Maps может быть затруднено или невозможно.
Требования:
- Используйте Image Maps только если достоверное известно, что МУ поддерживает эффективно этот метод навигации.
- Если устройство поддерживает только маленькие картинки, следует разбить большую картинку на более мелкие регионы, и работать с каждым отдельно
- Если Image Maps не поддерживаются МУ, следует использовать простой список ссылок с корректными наименованиями (см. 5.2.4.).
5.2.6. Автообновление, перенаправление и размножение окон
Каждая из этих функций, вероятнее всего, приведёт пользователя в замешательство, заставит заплатить дополнительные деньги, либо приведёт к временным задержкам в реакции системы.
Многие устройства не поддерживают многооконного режима, и, следовательно, попытка открыть новое окно приведёт к непредсказуемому результату (здесь не рассматривается встроенная в некоторые модели функция редактирования в отдельном окне).
Автоматическое обновление будет, скорее всего, неожиданным для пользователя и может повлечь за собой незапланированные траты пользователя за трафик, создаваемый такой страницей, если это окно останется открытым.
Перенаправление (redirect) со страницы приведёт к «блужданию» запроса, что вызовет дополнительную временную задержку.
Требования:
- Не следует использовать технику открытия новых окон (атрибут target).
- Следует избегать автообновляющихся страниц (лучше добавить явную функцию ручного обновления данных).
- Если автообновление страницы всё-таки применяется, то следует в явном виде предупредить пользователя об интервале обновления страницы и о том, какой трафик создаёт эта страница – чтобы пользователь знал, что ему придётся за это платить.
- Если автообновление страницы всё-таки применяется, то следует в явном виде дать возможность пользователю остановить автообновление.
- Следует отказаться от редиректа. Если всё-таки он используется, то следует применять не более одного редиректа на странице и минимизировать количество таких страниц.
5.2.7. Ссылки на внешние ресурсы
Каждый прилинкованный к странице ресурс (картинки, стилевые листы, и т.д.) требует отдельного запроса. Это может существенно увеличить время загрузки страницы.
Требования:
- Следует минимизировать количество картинок на странице и следует объединить все стилевые листы в один лист на страницу.
5.3. Тело страницы: расположение блоков и элементов, информационное содержимое
5.3.1. Содержимое страницы (контент)
Пользователи МУ зачастую ищут какую-то специфическую информацию, нежели просто просматривают страницы.
Пользователи сканируют текстовые блоки (заголовки, абзацы, списки и т.д.) на предмет ключевых слов, описывающих цель поиска.
Как правило, экранное пространство невелико, и следует использовать его рационально.
Пользователи оплачивают трафик, поэтому тот контент, который пользователь не запрашивал в явном виде и не ожидает увидеть (особенно это касается всякого рода рекламы), может вызвать раздражение и негативное отношение к ресурсу.
Требования:
- Следует изучить и специфицировать потребности посетителей ресурса и в первую очередь предложить востребованную информацию.
- Следует отображать только ту информацию, которая уместна при использовании МУ.
- Следует использовать лаконичный и простой, чистый и целенаправленный язык в описаниях.
- Следует придерживаться единого литературного стиля в текстовых описаниях.
- Следует выносить суть (выводы и итоги) статьи или информационного раздела в начало в виде введения-вступления, для того, чтобы пользователь мог лучше ориентироваться в контексте и определять полезность информации, следующей ниже. Это утверждение касается и таких текстовых блоков, как заголовок, абзац, список – ключевые слова и важная информация должна выноситься в начало блока.
- Реклама, если она есть, должна быть:
- сбалансирована по количеству относительно полезного контента
- явной – рекламные блоки следует выделять особым образом
- ненавязчивой – не должна «кричать» и сильно мешать использовать полезный контент
- ожидаемой (в пользовательском соглашении следует явным образом оговорить рекламные аспекты).
5.3.2. Объём страницы
Если объём страницы достаточно большой, это может привести к нежелательному увеличению времени загрузки. Кроме того, МУ обычно имеют ограничения на объём отображаемой страницы.
С другой стороны, если страница слишком короткая, пользователь будет вынужден выполнить множество переходов, чтобы прочитать нужную ему информацию – это может привести к неприятным задержкам, так как каждый переход требует дополнительного времени для загрузки страницы.
Необходимо найти разумный баланс между множеством страниц и прокруткой. Есть мобильные устройства с жёсткими ограничениями на объём отображаемой страницы, а есть устройства, прокрутка страницы в которых неудобна или затруднительна, в то же время есть устройства, в которых время загрузки страницы велико.
Требования:
- Следует разбивать объёмные страницы на несколько страниц: страницы должны быть удобными в использовании, но ограниченными по объёму.
- Рекомендуемый объём HTML-страницы не должен превышать 10 килобайт; весь объём страницы (включая картинки, стилевые листы и прочие прилинкованные объекты) не должен превышать 20 килобайт.
- При разбиении длинного текста на части, следует разрыв делать не посреди предложения, а в конце осмысленного информационного блока.
5.3.3. Прокрутка
Вёрстка страницы должна быть организована так, чтобы пользователь с помощью простых повторяющихся действий мог исследовать весь предлагаемый контент на странице (например, путём многократного нажатия клавиши «стрелка вниз»).
Однако, некоторые объекты невозможно просмотреть без применения горизонтальной прокрутки, например, большие картинки и карты.
Если некоторый элемент страницы требует горизонтального скроллирования (например, картинка размером шире экрана), это не может служить основанием тому, что остальному контенту страницы (например, простому тексту) также требуется горизонтальная прокрутка.
Недопустимые примеры:
- Картинка сдвигает связанный текст вправо настолько, что он перестаёт быть виден на экране без горизонтальной прокрутки.
- Картинка размером шире экрана приводит к насильственному увеличению ширины текста, идущего выше и ниже до размеров ширины картинки, вплоть до правой границы страницы, выходящей за пределы экрана – в этом случае пользователю приходится использовать горизонтальную прокрутку для чтения каждой строчки текста.
Требования:
- Следует избегать горизонтальной прокрутки везде, где наличие горизонтальной прокрутки не обусловлено контекстом применения продукта.
- Если невозможно избежать представления картинки размером больше чем экран, то следует отобразить эту картинку на отдельной странице, с обратной ссылкой на основную страницу, а на основной странице сделать ссылку на страницу с картинкой в виде миниатюры и текста, сообщающего размер и объём картинки.
- Размер картинок должен не превышать 120 х 120 пикселей, если только большие размеры не продиктованы требованиями решаемой задачи.
5.3.4. Графические изображения, картинки
Популярный в вебе механизм применения однопиксельной графики для абсолютного позиционирования не работает на большинстве экранов МУ.
Графические изображения размером заведомо больше чем экран и/или глубиной цвета больше, чем возможности дисплеев МУ, просто нагружают и засоряют трафик, оплачиваемый пользователем.
Требования:
- Не следует использовать графические изображения как «распорки» для вёрстки (spacing).
- Не следует использовать изображения, которые не могут быть корректно отображены устройствами (имеются в виду ограничения по цвету и размеры). Следует избегать картинок большого разрешения, если только они не содержать критическую для пользовательских целей информацию (например, карты).
Рекомендуется использовать изображения размером не более 120 х 120 пикселей и объёмом не более 20 килобайт.- Следует оптимизировать каждое графическое изображение как по размерам, так и по глубине цвета. Также следует проверять, насколько оптимизированное изображение адекватно отображается на дисплеях.
- Не рекомендуется применять графические обои:
- читабельность текста понижается,
- не поддерживаются всеми типами устройств,
- увеличивают трафик.
Попытайтесь определить, зачем нужны обои и достичь этой цели другими, более щадящими средствами.
5.3.5. Цвет
Поскольку МУ редко находится в условиях с идеальным освещением, то информация, оформленная цветом, может быть не видна пользователям.
Требования:
- Добейтесь того, чтобы информация, поставляемая в цвете, была также доступна и в монохромном режиме. Иными словами, цветовое кодирование информации (например, отображение состояний объекта) должно быть не основным, а вспомогательным. Тестируйте интерфейс на монохромных дисплеях.
- Не следует злоупотреблять цветовым оформлением – на части устройств это может отразиться некорректно или понизить читабельность.
- Добейтесь удовлетворительного контраста текстовой информации. Тестируйте интерфейс при ярком солнечном свете.
- Не применяйте синий и пурпурный (лилово-фиолетовый) цвет в оформлении текста во избежание перепутывания такого оформления с гиперссылками, особенно на устройствах, в которых ссылки не подчёркиваются.
5.4. Вёрстка и структурная разметка страниц
5.4.1. Заголовок окна страницы <TITLE>
Заголовок окна страницы не на всех устройствах виден пользователю, тем не менее, он должен быть корректно оформлен.
Требования:
- Заголовок окна страницы должен быть коротким:
- короткий заголовок уменьшает объём страницы
- место под заголовок как правило ограничено, и длинный текст обрезается при отображении на экране
- Заголовок окна страницы должен быть содержательным:
- помогает пользователю ориентироваться и определить суть содержимого страницы, когда отображается на мобильном устройстве
- используется поисковыми машинами для корректной индексации
- используется устройствами в качестве наименования по умолчанию для закладки, ведущей на эту страницу
5.4.2. Фреймы
Многие МУ не поддерживают фреймы
У пользователей возникают проблемы в распознавании фреймов и во взаимодействии с ними.
Требования:
- Не следует применять фреймы при вёрстке страниц:
5.4.3. Таблицы
Не все устройства поддерживают работу с таблицами
Не все устройства корректно отображают объёмные и сложные таблицы.
Таблицы не удобны в применении на маленьких экранах: чтобы прочитать объёмную таблицу, приходится применять горизонтальную прокрутку.
Если в таблице присутствуют навигационные ссылки, то для их достижения будет осуществляется автоматическая прокрутка как в горизонтальном, так и в вертикальном направлениях, что может дезориентировать пользователя.
- Не следует использовать вложенные таблицы
- Не следует применять таблицы для вёрстки страниц.
- Там, где это возможно, следует избегать табличного форматирования информации.
- Не следует использовать таблицы без полной уверенности в том, что они будут поддерживаться и корректно отображаться на применяемых МУ.
5.4.4. Структурная разметка
Требования:
- Применяйте корректную структурную разметку страницы (заголовки и подзаголовки):
- Это позволяет пользователю лучше адаптироваться к контенту
- Это позволяет корректно использовать разбиение текста на страницы и составление оглавления как навигационного меню.
- Заголовки корректно обрабатываются поисковыми роботами и повышают релевантность страниц в результатах поисковых запросов
- Не следует применять заголовки исключительно для создания шрифтового стилевого оформления.
- Следует соблюдать корректную иерархию уровней и подуровней в применении заголовков.
5.4.5. Нетекстовые элементы
Загрузка картинок на МУ увеличивает время и стоимость загрузки страницы.
Многие МУ не поддерживают встроенные объекты и скрипты, следует это учитывать при проектировании.
Даже если устройство поддерживает выполнение скриптов, не стоит использовать скрипты, если есть другой способ выполнить задачу. Выполнение скриптов увеличивает энергопотребление МУ и приводит к убыстренному разряду батарей.
Требования:
- Следует сделать так, чтобы страница была читабельной в режиме «только текст» – это, кроме всего прочего, позволит пользователю составить представление о контенте ещё до того, как все изображения прогрузились полностью.
- Следует обеспечить корректными подписями все нетекстовые элементы (атрибуты альтернативного рендеринга, такие как title, alt,longdesc).
- Не следует в качестве основной функциональности использовать встроенные объекты (джава-апплеты, флеш-ролики и т.п.) и скрипты.
- Избегайте таких фишек, как динамическое управление изображениями через CSS и представление текста с помощью графических изображений.
- Если скрипты всё-таки применяются, не используйте триггеры onmouse и onkey, используйте onclick.
5.4.6. Размер изображений
Требования:
- Следует специфицировать размер изображений средствами языка разметки, если изображения достаточно большие.
- Следует трансформировать изображения на сервере и отдавать их уже в преобразованном виде, если изображения достаточно большие, это позволить сэкономить как трафик, так и ресурсы мобильного устройства.
5.4.7. Единицы измерения объектов
Если использовать не абсолютные размеры объектов в пикселях, а относительные, то это позволит браузеру адаптировать контент под размеры дисплея.
Исключением из правила является ситуация, когда размер изображения специальным образом подгоняется под особенный дисплей. В этом случае описание изображения на языке разметки может специфицировать точные размеры изображения в пикселях. Это делается для того, чтобы при заполнении страницы текстом при загрузке не было повторной перерисовки страницы при загрузке картинок (картинки загружаются после текста).
Устройства могут реализовать замысел автора более точно, если поля, рамки и страницы специфицированы в пикселях.
Требования:
- Используйте относительные единицы измерения (такие как проценты, em, ex, bolder, lager, thick и т.п.) при вёрстке страницы.
- Не используйте абсолютные спецификации размеров (в пискселях).
5.4.8. Листы стилей
Различные мобильные устройства по-разному поддерживают стилевые листы:
- полная поддержка стилей, включая кэширование внешних листов
- поддержка без кэширования листов
- не поддерживается элемент style
- не поддерживается более одного стилевого листа
- стили вообще не поддерживаются
Применение стилевых листов в общем случае ведёт к минимизации объёма страниц и к сокращению времени загрузки.
Требования:
- Используйте стилевые листы для управления вёрсткой и внешним оформлением представления, даже если МУ не поддерживают стили.
- Организуйте документ так, чтобы в случае необходимости контент оставался читабельным даже без стилевого оформления.
- Следите за тем, чтобы стилевые листы имели небольшой объём, оптимизируйте листы так, чтобы они содержали только те стили, которые реально используются в оформлении страниц.
- Для каждой страницы старайтесь использовать не более одного внешнего стилевого листа. Если стилевые листы кэшируются устройством, правильным подходом будет использовать один и тот же лист для всех страниц сайта.
5.4.9. Оптимизация
Оптимизация и валидация кода ведёт к сокращению трафика, и, как следствие к сокращению расходов пользовательских ресурсов (платы за трафик и времени ожидания загрузки).
Требования:
- Используйте короткий, но эффективный язык разметки.
- Используйте язык разметки только для структурного описания данных (XML-стиль), оформление выносите в CSS.
- Публикуйте только проверенные валидатором страницы (должна быть выполнена автоматизированная проверка корректности кода).
- Публикуйте только обработанные оптимизатором страницы (без пустых строк и неиспользуемых пробелов).
5.4.10. Тип контента
Передача контента, который не сможет отобразиться/проиграться на МУ, стоит пользователю потерянных денег и времени. МУ может сообщать о предпочтительном формате, и этом случае рекомендуется удовлетворить предпочтение МУ, т.к. это может обеспечить наиболее полное исполнение полученного контента.
Требования:
- Отсылайте контент в формате, поддерживаемом МУ. Определить форматы, поддерживаемые конкретным устройством, можно с помощью различных профайлов устройств, таких как HTTP User-Agent header, HTTP Accept headers и UAProf.
- Если это возможно, отсылайте контент в предпочтительном для МУ формате
5.4.11. Сообщения об ошибках
Возникают неизбежные случаи, когда пользователи не имеют доступа к мобильному контенту или информации, которую они пытаются получить.
Обеспечение простой навигации по выходу из сообщения об ошибке особенно актуально для мобильный устройств, когда:
- браузеры не имеют явной и легкообнаружимой кнопки Back,
- пользователи могут легко потерять контекст выполнения задачи,
- повторный ввод адреса страницы затруднён
- есть трудности с исправлением ошибок.
Поставщик информационных услуг не может контролировать ситуации и вид отображения сообщений об ошибках в случае:
- ошибок сети или неверных сетевых настроек
- обрыва связи
- некорректного ввода адреса.
Однако также существуют случаи, когда корректные сообщения об ошибках должны полностью поддерживаться сервис-провайдером. Эти сообщения должны выдаваться в соответствии с недочётами, допущенными мобильным пользователем. Эти сообщения должны помогать ему определить:
- характер недочёта (например, временный ли он или постоянный),
- возможность попытки повторного доступа к искомой информации,
- возможные пути разрешения возникшей проблемы.
Также следует обеспечить пользователя возможностью выхода из контекста сообщения об ошибке: на страницу, предшествующую ошибке или в начало соответствующей части сервиса, откуда он может попытаться повторить попытку выполнить операцию, либо пропустить операцию, вызывающую ошибку и перейти к следующему шагу.
Требования:
- Обеспечьте краткие, но информативные сообщения об ошибках. Сообщение должно содержать:
- Что, где и по какой причине произошло (на понятном пользователю языке, без технического жаргона и специфики).
- Описание характера ошибки (например, временная она или постоянная).
- Описание того, что пользователь должен предпринять, чтобы исправить или уменьшить последствия ошибки. Обеспечить, по-возможности, меню вариантов дальнейших действий.
- Контактные адреса службы поддержки (телефон, форма отправки SMS, e-mail)
- Сообщение должно быть написано в корректном и уважительном стиле по отношению к пользователю. У пользователя не должно складываться ощущения вины за возникшую ситуацию.
- Следует по возможности минимизировать ошибки ввода (например, не позволять вводить недопустимые символы, и широко применять значения по умолчанию либо ранее вводимые пользователем данные).
- Желательно, чтобы сообщения о некритических ошибках (при возникновении которых пользователь может продолжать работу) не прерывали работу пользователя, а были доступны в фоновом режиме.
- Следует обеспечить пользователя явной навигацией для перехода от сообщения об ошибке к информации, соответствующей пользовательским задачам. Например,
- Ссылка Назад (Back), возвращающая предыдущую страницу (особенно для устройств, не обладающих легкодоступной кнопкой или клавишей Back).
- Ссылка Повторить (Retry) в тех случаях, когда уместна попытка повторения.
- Ссылка На главную (Home) для возврата к основной функциональности приложения.
- Страницы об ошибках, поставляемые веб-сервером по-умолчанию, такие, как 404 (страница не найдена) и 500 (внутренняя ошибка), следует по возможности заменить на более дружелюбные, эстетически привлекательные и функциональные (например, обеспечить навигацию верхнего уровня или на главную страницу приложения).
- Сообщения об ошибках должны быть выполнены на том же языке, на котором представлено приложение, и в том формате, который поддерживается МУ.
5.4.12. Шрифты
МУ часто имеют слабую поддержку различных шрифтовых гарнитур и эффектов (полужирный, курсив и т.д.). В результате, применение гарнитуры, размера или эффекта шрифта может не отразиться на дисплее конкретного МУ либо, хуже того, привести к непредсказуемым последствиям (например, сделает текст нечитабельным).
Требования:
- Не полагайтесь на шрифтовое оформление. По возможности, следует избегать применения шрифтов различных стилей. Следует использовать шрифтовое оформление, используемое браузером МУ по умолчанию.
- Допустимо управление тремя размерами шрифта (крупный, нормальный, мелкий) и полужирным / простым начертанием, но корректность отображения следует тестировать на устройствах различного типа.
5.5. Пользовательский ввод
5.5.1. Табулирование элементов интерфейса
Очень важно, чтобы пользователь перемещался по ссылкам, поля ввода и другим объектам в строгом логическом порядке.
Требования:
- Следует уделить внимание консистентному и корректному переходу фокуса пользовательского ввода между элементами пользовательского интерфейса (корректное использование атрибута
tabindex).5.5.2. Метки полей и контролов
Требования:
- Метки контролов (элемент
label) должны распознаваться пользователями быстро и однозначно.- Метки следует располагать визуально близко к контролам, к которым они относятся. Следует управлять вертикальными и горизонтальными полями метки – метка должна располагаться ближе к своему контролу, а не к соседнему.
- Наименования меток должны быть короткими и чёткими. Ключевое слово предпочтительно ставить на первое место.
- В конце метки предпочтительно ставить двоеточие (оно визуально подчёркивает назначение метки и помогает корректно обрабатывать страницы голосовыми машинами для слепых).
Литература
- Mobile Web Best Practices
- Interaction in 4-Second Bursts: The Fragmented Nature of Attentional Resources in Mobile HCI // Antti Oulasvirta, Sakari Tamminen, Virpi Roto and Jaana Kuorelahti // CHI 2005
Дата публикации: 15 октября 2006 г.
©Usability.Ru
Публикация материала только с согласия автора. При публикации ссылка на
Usability.Ru обязательна!
| Usability.Ru | Статьи | Персоналии | Коллективы | Библиотека | Глоссарий | Обучение | Форум | Ссылки |