Итак, мы установили, что мобильные технологии открывают множество новых перспектив. Но если ваш прежний опыт связан с дизайном обычных сайтов, то как перейти к проектированию мобильных веб-приложений? Конечно, вам пригодится уже наработанный инструментарий, знания и навыки, однако могу предположить, что вам все-таки придется пересмотреть свои взгляды на организацию процесса разработки, способы взаимодействия с пользователями и дизайн приложений.
Мы не будем подробно говорить о веб-дизайне — коснемся лишь тех областей, в которых мобильный веб максимально отличается от обычного. Прежде чем отправиться в путь, давайте разберемся, что из имеющегося багажа может понадобиться нам в дороге.
4
Организация
ГОВОРИМ МЫ О МОБИЛЬНОМ ВЕБЕ или об обычном, базовые принципы информационной архитектуры — правильная разметка кода, баланс ширины и глубины, основы поведения пользователя — остаются неизменными. Но для правильной организации взаимодействия с мобильным вебом также необходимо:
• хорошо понимать, как и почему люди используют мобильные устройства;
• отдавать приоритет контенту перед навигацией;
• предоставлять пользователям возможность взаимодействовать с составными элементами сайта;
• обеспечивать ясность и лаконичность контента.
Поведение пользователей
Я уже говорил об ограничениях и особенностях поведения пользователей, определяющих уникальность дизайна для мобильных устройств. Сайты для обычных компьютеров имеют свои ограничения и особенности, и автоматически переносить то, что вы делали раньше, на мобильные устройства бессмысленно. Поэтому сначала необходимо осознать преимущества мобильного Интернета, а затем — понять, как объединить собственные возможности и потребности клиентов.
Пристальный взгляд на эту область может пролить свет на то, как люди обычно используют мобильные устройства.
В книге Tapworthy («Куда следует нажимать») Джош Кларк уделил особое внимание трем основным поведенческим моделям владельцев мобильных устройств: «Микрозадачи», «Ориентирование на местности» и «Мне скучно». Эти модели практически совпадают с поведенческой классификацией, принятой в компании Google: «Мне это нужно срочно», «Я повторяю то, что часто делаю» и «Я делаю это, потому что мне больше нечем заняться». Как эти типы поведения ни назови, использование мобильных устройств обычно предполагает один из следующих видов взаимодействия:
• поиск (срочная информация, местный масштаб): мне нужен ответ прямо сейчас (часто связанный с моим местоположением);
• изучение/развлечение (скука, местный масштаб): у меня есть немного свободного времени, я хочу отвлечься;
• проверка/статус (повторяющееся занятие / микрозадачи): то, что для меня важно, постоянно изменяется или обновляется, и я хочу быть в курсе;
• редактирование/создание (срочные изменения / микрозадачи): мне необходимо безотлагательно что-то сделать.
Поскольку люди чаще всего задействуют мобильные устройства именно в подобных целях, знание специфики их поведения в той или иной ситуации поможет вам определить, как проектировать мобильные приложения, чтобы их структура и организация соответствовали потребностям пользователей. К примеру, на мобильном сайте Flickr обычно выполняются четыре основные операции. «Последние действия» и «Новые фото ваших контактов» позволяют пользователю понять, что происходит с фотографиями на его странице и на страницах друзей, а «Интересные снимки» и «Фотографии, сделанные рядом с вами» дают возможность заполнить свободное время (рис. 4.1).
Еще один пример — мобильное приложение для управления проектами Basecamp: здесь основное внимание уделяется возможности легко зарегистрироваться или войти в аккаунт, редактировать и создавать новые сообщения и т. п. И хотя люди заходят на Flickr и Basecamp с совершенно разными целями, разработчики хорошо продумали, как пользователи будут взаимодействовать с их сайтами, и правильно их организовали.
Учитывая особенности поведения владельцев мобильных устройств, вы, естественно, будете адаптировать сайт под их потребности и действия в реальных ситуациях. Поскольку доступ к мобильному веб-ресурсу возможен в любое время и в любом месте, вы должны сделать так, чтобы ваш сайт был полезен пользователям, где бы они ни находились. Иными словами, вам придется изучить человеческое поведение.
Недавно я познакомился с отличным примером подобного подхода. Один из авторов блога Mobile in Higher Ed (http:// bkaprt.com/mf/39) Дейв Олсен дал следующий комментарий к картинке с сайта xkcd.com, приведенной на рис. 4.2:
…разглядывая правую часть диаграммы Венна, я вдруг подумал: «А ведь это очень похоже на нынешний и будущий контент нашего мобильного сайта». […] Отказ от всего лишнего, максимальный учет размера экрана устройства и сетевых ограничений делает сайт гораздо более полезным.
Точнее и не скажешь.
Контент важнее навигации
Общее правило при разработке мобильных приложений гласит: контент всегда должен иметь приоритет над навигацией.
За какой бы информацией люди ни приходили на ваш сайт — будь то новости, часто обновляющиеся данные о котировках ценных бумаг и результатах спортивных матчей, сведения местного характера или другие виды контента, — им нужен немедленный ответ: на то, чтобы изучать карту вашего сайта, у них просто нет времени.
Слишком многие мобильные сайты (даже рассмотренные выше Flickr и Basecamp) начинают диалог с пользователями не с контента, а с элементов навигации. Время в мобильном Интернете зачастую очень ценно, а обмен данными стоит денег, поэтому сделайте все для того, чтобы пользователи получали необходимую им информацию как можно быстрее.
Именно так работают мобильные версии сайтов YouTube и ESPN: на экране появляется простой заголовок, сообщающий, на чей сайт вы зашли, а вся навигация сведена к одному действию. Остальную часть страницы занимает либо актуальный контент (ESPN), либо список популярных видеороликов (YouTube) (рис. 4.3).
Использование и взаимодействие
Минуточку! Если контент всегда важнее навигации, то как найти на мобильном сайте необходимую информацию? Разве без навигации это возможно? Разумеется, она необходима, но для того, чтобы использовать сайт и взаимодействовать с ним, вовсе не требуется создавать громоздкую систему навигации, способную похоронить под собой сам контент.
Например, мне нравится, что на мобильном сайте Facebook актуальный контент занимает основную часть страницы.
Но при этом в верхней ее части разработчики разместили сразу три навигационные панели, из-за чего на экране умещается всего одна новость. Мобильный сайт Google Finance содержит актуальные данные, но этот контент спрятан под пятью навигационными панелями. Иными словами, драгоценное экранное пространство заполнено навигационными опциями, которые могут и не потребоваться пользователям, в то время как на их месте могла бы находиться полезная информация (рис. 4.4).
Недавно Facebook изменил дизайн мобильного сайта, уменьшив число элементов навигации (рис. 4.5). Если не считать фильтров «Главные истории» и «Последние» в ленте новостей, их стало вдвое меньше (пять вместо десяти). Так держать!
Примеры сайтов YouTube и ESPN (рис. 4.3) показывают, что контент важнее навигации, однако они по-разному решают задачи доступа к основному содержанию и навигации. Чтобы перемещаться по сайту YouTube, необходимо использовать иконку, открывающую отдельную страницу с элементами меню (рис. 4.6). То есть для того, чтобы перейти к навигации, пользователю необходимо совершить действие, которое выводит его из общего контекста сайта (на отдельную страницу).
Кроме того, он должен заранее знать, что иконка с решеткой в шапке сайта — это вход в навигационное меню.
В шапке мобильного сайта ESPN есть хорошо заметная кнопка «Меню», при нажатии на которую открывается обширный (и многоуровневый) перечень пунктов навигации (рис. 4.7). Это позволяет посетителю выбирать направление движения по сайту, не покидая текущей страницы. Кроме того, навигационное меню дублируется в подвале большей части разделов веб-ресурса, что соответствует логике их просмотра: дойдя до конца страницы, пользователь решает, что делать дальше — и облегчает взаимодействие с сайтом при управлении одной рукой. Дизайнеры мобильного сайта YouTube не предусмотрели такой возможности, поэтому их пользователи просто доходят до конца страницы, так как дальше им двигаться некуда (рис. 4.8).
Меню в подвале страницы удобно для дальнейшего перемещения по сайту, но все же оно не должно дублировать все элементы навигации. Лучше, если кнопка меню в верхней части экрана будет просто направлять пользователя к списку навигационных пунктов, расположенному в нижней части страницы (после контента). Мы, например, применили этот прием при разработке мобильного сайта Bagcheck (рис. 4.9). Помимо этого в меню в нижней части каждой страницы мы добавили ссылку на верхнюю часть страницы. Это дает пользователям возможность вернуться в начало раздела, если потребуется еще раз просмотреть его содержимое.
Такой дизайн предполагает минимум навигационных элементов (в сущности, единственную ссылку в начале страницы). Он позволяет пользователям продолжить взаимодействие с сайтом после того, как они достигли конца страницы. Содержание меню не дублируется, а главное, для его работы требуется всего лишь ссылка-якорь, отсылающая посетителя в нижнюю часть страницы. Никаких скриптов JavaScript, оверлеев, отдельных навигационных страниц… Это своего рода HTML0 (который, как я слышал, поддерживается большинством браузеров, за исключением Internet Explorer).
Каждая страница Bagcheck имеет уникальное навигационное меню, позволяющее более детально изучать контент сайта (рис. 4.10). Перейти в другие разделы посетители могут, также воспользовавшись и главным меню.
Возможности контекстной навигации крайне полезны.
На мобильном сайте Gmail (рис. 4.11) контекстное меню расположено в верхней части экрана. Поскольку навигация по сайту напрямую связана с отображаемым в окне сообщением электронной почты, размещение элементов навигации в подвале страницы было бы не очень эффективным. А в этом случае все необходимые функции остаются наверху и всегда доступны.
Возвращаясь назад
Всегда интересно наблюдать за тем, как мигрируют решения в области дизайна. Например, в шапке многих нативных приложений для iPhone есть кнопка возврата к предыдущей странице (рис. 4.12). У мобильных устройств компании Apple нет физической кнопки для возврата к предыдущему окну, iOS также не предлагает пользователю каких-либо системных инструментов для этой операции.
C iPhone кнопка «Назад» перекочевала в шапку многих сайтов, хотя зачастую она совершенно не нужна. Многие устройства (Android, Blackberry, Windows Phone 7 и т. д.) имеют физические кнопки «Назад» (рис. 4.13). Такая кнопка есть даже на панели управления мобильного браузера Apple (рис. 4.14). И появление еще одной в шапке мобильного сайта способно лишь запутать пользователя. У него может возникнуть вполне обоснованный вопрос: «А она предназначена выполнять то же действие?»
При разработке дизайна мобильного сайта пусть кнопка «Назад» останется уделом нативных приложений. Если вы хотите помочь пользователю вернуться на предыдущий уровень, дайте этому навигационному элементу другое название.
Привязка к низу страницы
У многих нативных приложений для iPhone навигационные панели зафиксированы в нижней части экрана, что позволяет управлять приложением при помощи большого пальца. И в отличие от мобильного браузера в нативных приложениях отсутствует нижняя панель инструментов, пожирающая драгоценное экранное место. На примере сайта Yahoo! Mail можно увидеть, как инструменты управления браузером влияют на отображение мобильной веб-страницы. Две панели браузера и два фиксированных меню сайта Yahoo! Mail оставляют крайне мало места для просмотра содержимого почтового ящика (рис. 4.15).
Мобильным сайтам приходится учитывать особенности не одного, а множества браузеров для различных операционных систем. А на устройствах с физическими кнопками определенные проблемы может создавать программное меню, расположенное в нижней части окна (рис. 4.16). Подобное соседство неминуемо приведет к тому, что пользователи будут промахиваться и, выбирая необходимый пункт меню, нажимать на физические кнопки устройства.
Разрабатывая нативные мобильные приложения, вы можете учесть наличие кнопок, расположенных под экраном устройства. Однако мобильные сайты должны работать на любых устройствах, независимо от того, есть у тех такие кнопки или нет.
Таким образом, если для нативных приложений навигационное меню в нижней части экрана может стать неплохим решением, то в случае мобильных сайтов эта идея, скорее всего, окажется не столь удачной с точки зрения юзабилити. Если вам нужно фиксированное меню, пусть лучше оно будет располагаться сверху. Именно так поступил Twitter, разрабатывая новый дизайн своего мобильного сайта (рис. 4.17).
Ясность и отсутствие лишних деталей
Как я уже говорил в первой части книги, владельцам мобильных устройств порой достаточно «одного глаза и одного пальца». Ждать, что они сядут за стол и начнут сосредоточенно изучать ваш сайт, не стоит. Более вероятно, что в этот момент их будет отвлекать множество факторов. Мы вряд ли можем рассчитывать на безраздельное внимание пользователей, поэтому мобильный дизайн должен быть ясным, не содержать лишних деталей и давать пользователям возможность быстро достигать нужных целей — желательно, обходясь минимумом навигационных опций.
Окно создания письма программы Yahoo! Mail — отличный пример того, как, отказавшись от всего лишнего, разработчики дали пользователям возможность сосредоточиться на основной задаче (в данном случае — на написании сообщения).
На экране присутствует всего одна навигационная кнопка — «Отменить» (рис. 4.18). Остальной интерфейс нацелен на выполнение текущей задачи.
Другой пример: сайт спортивного канала ESPN, отображающий в реальном времени ход матчей Национальной баскетбольной ассоциации, содержит такое количество навигационных кнопок, что схема самой площадки фактически смещена за пределы экрана. А ведь посетители заходят на эту страницу для того, чтобы наблюдать за ходом игры, а не перепрыгивать от одного пункта меню к другому.
Уменьшив число навигационных опций на экранах мобильных устройств и тем самым снизив вероятность, что пользователь, спеша выполнить задачу, нажмет не на ту кнопку, вы сможете предотвратить множество ошибок.
Структура мобильного сайта
Проектируя мобильный сайт, продумайте, как совместить в дизайне особенности поведения владельцев мобильных устройств и их потребительские нужды.
• Анализ основных способов взаимодействия (поиск, изучение/развлечение, проверка/статус и редактирование/создание) позволит понять, как владельцы мобильных устройств будут использовать ваш сайт, а значит, разработать структуру, соответствующую их потребностям.
• Уделив внимание в первую очередь контенту и лишь потом навигации, вы предоставите посетителям возможность максимально быстро получить доступ к нужной информации или произвести необходимые действия.
• Продуманное и правильно расположенное навигационное меню помогает пользователям более детально изучить содержание страницы и облегчает переход к другим разделам сайта.
• Уменьшение числа навигационных опций и акцент на выполнение основных задач позволяют пользователям быстрее достигать поставленных целей. Это особенно важно, когда у них мало времени или они находятся не в самых удобных условиях.
• Но даже если владелец мобильного устройства заходит на ваш сайт в свободное время, находясь у себя дома и удобно расположившись в кресле, будьте уверены: он по достоинству оценит простоту и функциональность вашего дизайна!
Продуманная структура мобильного сайта позволяет пользователям быстро находить необходимую информацию. Отыскав ее, они начинают действовать. Давайте посмотрим, что и как они делают.
5
Действия
ДЛЯ УСТРОЙСТВ С МАЛЕНЬКИМ ДИСПЛЕЕМ, помещающихся на ладони, сенсорный экран — это естественный выбор. В сущности, благодаря ему мобильное устройство (а не только клавиатура или трекбол) превращается в интерактивную поверхность. Именно поэтому телефонов, экран которых реагирует на прикосновение, производят все больше. К примеру, доля смартфонов с тач-скрином в общем объеме продукции компании Nokia постоянно растет (рис 5.1).
И хотя некоторые из этих устройств имеют также и аппаратные средства ввода информации — трекпады, колесики прокрутки и клавиатуру, при взаимодействии с Интернетом их владельцы все чаще используют именно сенсорный, или, точнее, тач-интерфейс, в основе которого лежит управление устройством при помощи пальцев. Но как обеспечить всем посетителям возможность взаимодействовать с сайтом посредством прикосновений? Для этого, прежде чем приступать к проектированию тач-интерфейса, необходимо:
• определить размер и расположение зон тактильного касания (тач-зон);
• изучить наиболее распространенные тач-жесты и понять, с какой целью они используются;
• продумать, чем заменить операции, которые раньше выполнялись наведением курсора;
• не забыть о средствах «непрямой манипуляции».
К малому через большое
При разработке мобильных веб-приложений дизайнеры зачастую идут по пути простого уменьшения всех элементов обычного сайта. Места на экране немного, а значит, чем меньше, тем лучше, не так ли? В этом подходе есть логика, но все же в процессе проектирования следует придерживаться противоположного направления и увеличивать элементы — иногда даже до размеров, превышающих привычные (рис. 5.2).
Человеческие пальцы — не самый точный инструмент.
Им не хватает аккуратности компьютерной мыши. Они разных размеров. Кроме того, они то и дело соскальзывают, не попадая в нужный участок экрана. Поэтому чем важнее выполняемая задача, тем крупнее должна быть зона касания — только тогда людям с «одним глазом и одним пальцем» будет удобно взаимодействовать с вашим сайтом.
Действительно ли это так важно? Результаты исследований показывают, что почти в половине случаев нажатие на рекламные баннеры в мобильном браузере происходит случайно (). Продуманные размеры и правильное расположение зон касания позволяют пользователям уверенно и точно нажимать на экран. Но до каких пределов следует увеличивать размеры тач-зоны?
В руководстве iOS Human Interface Guidelines ( mf/42) Apple рекомендует, чтобы размер зоны для нажатия составлял 44 × 44 пункта. В качестве единицы измерения Apple использует пункты, а не пикселы, поскольку экраны разных устройств имеют разное разрешение (об этом поговорим ниже). А чтобы правильно учитывать различия в экранном разрешении (или ppi), лучше задавать размеры тач-зон в физических единицах.
Microsoft также применяет этот подход в руководстве для Windows Phone 7. В нем указано, что оптимальный размер тач-зоны составляет 9 мм, минимальный — 7 мм, а минимальное расстояние между различными зонами — 2 мм. Другие руководства для разработчиков (например, от Nokia и даже Ubuntu) рекомендуют примерно такие же размеры, как и у Microsoft; за основу принят средний размер человеческого пальца. Лаборатория Touch Lab Массачусетского технологического института (MIT) определила, что средний размер зоны для касания подушечкой пальца составляет 10–14 мм, кончиком — 8-10 мм ().
К подобным рекомендациям следует прислушаться, однако это вовсе не означает, что размеры любой иконки или кнопки на вашей мобильной странице обязаны составлять ровно 9 × 9 мм. Указанным параметрам должна соответствовать активная тач-зона, в то время как ее визуальное отображение может быть вдвое меньше. Иллюстрация из «Руководства Microsoft» (рис. 5.3) показывает, какие значения атрибутов margin или padding следует задавать, чтобы тач-зоны имели правильный размер, а элементы визуального интерфейса при этом не выглядели бы одинаково.
Помимо этого в «Руководстве Microsoft» подробно описаны случаи, когда размер тач-зоны должен превышать 9 мм: «Если пользователям приходится часто нажимать на элемент интерфейса; если результат ошибочного нажатия необратим или имеет неприятные последствия; если элемент интерфейса расположен слишком близко к краю экрана; если на него трудно нажимать или он является составной частью в цепочке последовательных действий — как в случае набора телефонного номера» ().
Другими словами, когда речь идет о прикосновениях к экрану мобильного устройства, следует всегда придерживаться принципа «чем больше, тем лучше». Правильное расположение и надлежащий размер тач-зоны позволяют избежать куда более серьезных проблем, чем простое соскальзывание пальца.
Посмотрите внимательно на стартовую страницу мобильного сайта Quora (рис. 5.4). Заметили, где могут возникнуть проблемы?
Действительно, кнопки Cancel и Login расположены слишком близко друг к другу. Здесь неправильные размеры и расположение тач-зон (помните о правиле двух миллиметров?) могут привести к тому, что пользователь, вместо того чтобы войти в свой аккаунт, покинет сайт.
Еще один пример: окно расширенного поиска на мобильном сайте Flickr, где элементы интерфейса также расположены слишком близко друг к другу (рис. 5.5). В данном случае «больше» однозначно было бы лучше, чем «меньше».
Куда мы нажимаем?
Ранее я уже упоминал, что размещение активных элементов интерфейса в нижней части экрана наиболее соответствует положению мобильного устройства в руке пользователя. Однако все не так просто. Расположение основных тач-зон зачастую зависит от того, каким пальцем (большим или указательным) владелец мобильного устройства нажимает на экран, а также от того, левша он или правша.
Большинство людей в мире — правши (от 70 до 90 %) и взаимодействуют с мобильным устройством посредством большого пальца. Соответственно, чаще всего приложения оптимизируются именно под управление большим пальцем правой руки. Это означает, что элементы интерфейса, соответствующие основным действиям, будут находиться в средней или нижней части экрана и располагаться слева направо (рис. 5.6).
Деструктивные функции, такие как отмена или удаление, выносятся за пределы зоны комфорта пользователя. Если вы держите мобильное устройство в правой руке и управляете им при помощи большого пальца, вам придется приложить некоторое усилие, чтобы дотянуться до левого верхнего угла экрана. Это не очень легко и не слишком удобно. Следовательно, вы лишний раз задумаетесь, действительно ли вам необходимо удалить результаты проделанной работы.
Изучите язык жестов
Тач-зоны позволяют управлять мобильным сайтом, но само взаимодействие происходит при помощи жестов. И хотя в технической документации для различных платформ жесты обозначаются и описываются по-разному, на сегодняшний день существует стандартный набор жестов, применяемый пользователями при работе с мобильными приложениями.
Для того чтобы лучше разобраться в этом вопросе, я вместе с Дэном Уиллисом и Крейгом Вилламором изучил техническую документацию для следующих платформ:
• iOS и OS X компании Apple;
• Android компании Google;
• Windows Phone 7, Windows 7 и Surface компании Microsoft;
• Web OS компании Palm;
• библиотеку поддержки жестов GestureWorks в среде программирования Flash компании Adobe;
• и даже для графического планшета Bamboo компании Wacom, поддерживающего тач-интерфейс.
К счастью, проведенный анализ показал, что у этих систем больше общего, чем различий. Фактически основной набор жестов одинаков для всех платформ: они соответствуют основным действиям, которые выполняют пользователи при работе с сенсорными экранами: нажатие (tap); двойное нажатие (double tap); перемещение (drag); пролистывание (swipe); уменьшение масштаба (pinch); увеличение масштаба (spread); продолжительное нажатие (press and tap); продолжительное нажатие с перемещением (press and drag); а также несколько разновидностей поворотов. Поскольку некоторые мобильные веб-браузеры не поддерживают определенные жесты или резервируют их для системных операций, этот список может быть сокращен всего до трех операций — нажатие, перетаскивание и пролистывание (рис. 5.7).
Несомненно, разработчикам важно знать, какие жесты возможны в принципе, но еще более важно понимать, как пользователи при помощи жестов взаимодействуют с интерфейсом мобильных устройств. Если человек собирается произвести какое-то действие или перейти к другому объекту или странице, какие из этих жестов он выполнит? Созданное по итогам нашего аудита «Справочное руководство по жестам для тач-интерфейсов» отвечает на эти и некоторые другие вопросы () (рис. 5.8).
Руководство начинается с описания основных задач, которые обычно решают пользователи — например, изменить параметры, удалить объект или пролистать список. Рядом с каждым из потенциальных действий приведены применяемые на большинстве платформ (и чаще всего выполняемые пользователями) жесты.
Руководство находится в открытом доступе и содержит файлы шаблонов для каждого жеста в форматах PDF, EPS, OmniGraffle и Visio, которые можно свободно использовать при создании макетов и прототипов.
Устройства с тач-интерфейсом стремительно завоевывают популярность, а значит, будут появляться все новые дизайнерские решения. Например, такое действие, как «потянуть вниз для обновления», которое раньше было доступно лишь для отдельных приложений, сегодня получает широкое распространение, так что нетрудно предположить, что в ближайшее время пользователи попробуют применить их и на вашем сайте. Поэтому смело экспериментируйте с жестами! (рис. 5.9–5.10).
Не стоит бояться NUI [6]
Я всячески приветствую распространение естественного пользовательского интерфейса (NUI). Я верю, что потенциал этого подхода позволит нам войти в новую эру программирования. Такие его принципы, как превращение контента в интерфейс, прямое взаимодействие пользователя с контентом, а также отказ от визуальных элементов, не относящихся к контенту, открывают перед нами новые пути использования цифровой информации и медиа.
Уходят в прошлое те времена, когда для того, чтобы увеличить изображение, приходилось использовать окна, иконки, меню и указатели (WIMP). Теперь для этого достаточно коснуться фотографии и развести пальцы в стороны. Такому «прямому» взаимодействию не только легче научиться (спросите об этом детей и пожилых людей, активно использующих iPad) — оно лучше отражает наше представление о реальном мире.
Сегодня мы находимся на стадии перехода от графического к естественному пользовательскому интерфейсу. Далеко не все пользователи смогут быстро освоить управление жестами, и, судя по всему, выполнять основные операции на мобильных сайтах нам по-прежнему придется при помощи кнопок. Однако это не должно становиться препятствием для экспериментов с жестами в тех случаях, когда это оправданно, например для дополнительных настроек или «горячих» команд.
Старайтесь сделать так, чтобы предусмотренные в интерфейсе жесты были как можно более естественными: пользователям будет легче к ним привыкнуть. Недавнее исследование, проведенное среди пользователей девяти стран, показало, что люди разных культур для выполнения одинаковых действий применяют одни и те же жесты (). Так что если говорить об использовании тач-интерфейсов, у всех нас есть много общего.
И наконец, проблемы переходного периода можно частично решить, добавив на страницы вашего сайта подсказки, анимацию и заметные графические элементы. Сначала их нужно размещать более активно, показывая посетителям, где и как они могут использовать жесты, но с течением времени следует постепенно сокращать их количество. И помните о том, что, если подсказок становится слишком много, использование жестов уже не будет таким естественным, как вы того хотели бы.
При работе с тач-интерфейсом ожидания пользователей и замысел разработчиков не всегда совпадают. Например, несмотря на то, что на мобильном сайте ESPN данные о набранных командами очках представлены так, будто их можно просматривать, пролистывая страницы, — чтобы перейти от одного блока к другому, приходится использовать стрелки (рис. 5.11).
Выбор наведением
Раз уж мы заговорили о подсказках, следует отметить, что привычные подсказки, возникающие при наведении курсора (состояние on hover, когда указатель мыши находится над определенным участком страницы), не подходят для приложений с активным экраном. Это и понятно: курсора, который можно было бы наводить, здесь просто нет. И хотя пальцы тоже отбрасывают тень, я не знаю ни одного мобильного устройства, которое воспринимало бы это в качестве функции наведения.
Следовательно, необходимо пересмотреть все действия, которые прежде выполнялись при помощи указателя мыши.
И это прекрасно! На самом деле на обычных сайтах значение наведения часто бывает переоценено. Когда пользователь подводит курсор мыши к объекту, это еще не означает, что он хочет, чтобы на экране появилась подсказка или меню (рис. 5.12). В отличие от нажатия наведение курсора не всегда предполагает действие.
Меню, появляющееся при наведении мыши, обычно представляет собой список дополнительных действий, не настолько важных, чтобы отображать их на экране постоянно. Оно часто содержит опции, которым не хватило места в основном экранном меню. Однако при переходе на мобильные версии сайтов об этих опциях не следует забывать.
При создании мобильных сайтов у вас есть следующие варианты размещения опций выпадающего меню:
• меню располагается непосредственно на экране;
• меню появляется при нажатии на экран, а выбор необходимых функций производится пролистыванием;
• меню выносится на отдельную страницу;
• и мой любимый: вообще отказаться от выпадающего меню.
На экране.
В тех случаях, когда содержание выпадающего меню имеет принципиальное значение, наиболее правильно размещать его непосредственно на экране. Именно такое решение использовал Twitter в первоначальном варианте своего мобильного сайта.
На обычном сайте Twitter при наведении курсора на сообщение появлялось меню со следующими опциями: «В избранное», «Ретвитнуть» и «Ответить» (рис. 5.13). По мнению разработчиков, эти действия достаточно важны, поэтому в мобильной версии сайта они расположили их непосредственно на экране (рис. 5.14).
При нажатии и пролистывании.
При открытии обычных сайтов в некоторых мобильных браузерах стандартное выпадающее меню отображается при нажатии на экран. Это оправдано в тех случаях, когда опции такого меню логически связаны со следующим действием пользователя. Однако если его содержание добавляет к процессу лишние шаги, это может мешать перемещению посетителей по сайту, а значит, вызывать у них раздражение.
Пролистывание — жест куда менее очевидный и понятный пользователю, чем нажатие. И чаще всего при проектировании мобильного интерфейса он требует дополнительных усилий со стороны разработчиков. С другой стороны, этот жест редко бывает случайным, а значит, производимое им действие не будет мешать посетителям в процессе их естественных перемещений по сайту. Если вы намерены использовать пролистывание на своем сайте, то имеет смысл добавить подсказку или небольшую анимацию, объясняющую, как оно работает (рис. 5.15).
Следует также иметь в виду, что для действий, выполняемых при помощи неочевидных жестов (например пролистывание), нужно предусмотреть альтернативы.
Так, на мобильном сайте Yahoo! Mail функции меню, открывающиеся при пролистывании, дублируются также в отдельном окне (рис. 5.16).
На отдельной странице.
Если выпадающее меню включает большой объем информации, то на мобильном сайте имеет смысл размещать его на отдельной странице. Такой подход использовал Barnes & Noble (рис. 5.17). То, что на обычном сайте было большим (и навязчивым) выпадающим меню, в его мобильной версии теперь занимает отдельную страницу.
Полный отказ.
Если изначально в выпадающем меню не было особой необходимости, то в мобильной версии сайта лучше и вовсе от него избавиться. Отказ от лишних действий или информации, не представляющей ценности для пользователя, не только сделает интерфейс проще, но и облегчит разработку и поддержку сайта. Так что смело избавляйтесь от всего лишнего!
Вы можете выбрать любой из описанных выше подходов — главное, убедитесь, что при переходе от обычной версии сайта к мобильной вы не забыли ни об одной из функций выпадающего меню.
Не трогать!
Вы надеялись, что мы уже покончили со всеми проблемами?
А как насчет сайтов для устройств с бесконтактным или гибридным интерфейсом? Мобильные устройства с механизмами непрямого воздействия — такими как трекпады, трекболы, колесики прокрутки или физическая клавиатура (цифровая или QWERTY) — позволяют при взаимодействии с Интернетом не водить пальцами по экрану.
Когда пользователи перемещаются по веб-страницам при помощи описанных выше средств промежуточного контроля, CSS-состояние: hover часто применяется для того, чтобы выделить выбранный элемент интерфейса, не прибегая к Java Script. И хотя правильнее в таких случаях было бы задействовать состояние: focus, таблицы стилей многих сайтов не содержат его явного описания. Поэтому такие мобильные браузеры, как OperaMini, используют: hover, чтобы выделить активный элемент интерфейса, выбранный пользователем в данный момент.
Добавив в таблицу стилей описание состояний: hover и: focus для всех ссылок, кнопок и меню вашего мобильного сайта, вы облегчите его использование на устройствах, оборудованных средствами непрямой манипуляции.
Когда речь идет об устройствах, не имеющих тач-интерфейса, можно вообще не беспокоиться о состоянии: focus. И хотя в настоящее время подавляющее большинство производителей смартфонов отдают предпочтение сенсорным экранам, не все устройства, выпущенные ими ранее (да и те, что продолжают выпускать), имеют тач-интерфейс. Экраны старых моделей обычно меньше, поэтому тач-зоны заняли бы слишком много места и использовать жесты было бы невозможно. А значит, возникает необходимость в некоторой адаптации.
Ниже я еще расскажу о методике прогрессивного улучшения, позволяющей уменьшать размер интерактивных зон так, чтобы это не создавало неудобств для пользователей.
Но поскольку я обещал, что не стану слишком углубляться в технические аспекты и постараюсь сделать эту книгу как можно более краткой, то предоставлю право подробно рассказать о прогрессивном улучшении тем, кто разбирается в этом вопросе лучше меня ().
Камера, мотор, начали!
Мобильных устройств с сенсорным экраном и тач-интерфейсом становится все больше, поэтому необходимо постоянно работать над тем, чтобы у пользователей не возникало проблем при взаимодействии с нашими сайтами.
Поэтому:
• при определении размера и расположения тач-зон применяйте принцип «чем больше, тем лучше»;
• постарайтесь как можно лучше изучить «язык жестов», использующихся при работе с активным экраном, и то, как пользователи применяют их для навигации и управления сайтом;
• смело используйте принципы естественного пользовательского интерфейса (NUI), благодаря которым внимание посетителей сайта сосредоточивается на контенте, а не на оболочке;
• выберите наиболее подходящий для мобильного сайта способ внедрения функций, реализованных на обычном сайте в виде выпадающего меню;
• при проектировании мобильного сайта не забывайте об устройствах без сенсорного экрана и с гибридным интерфейсом.
Теперь, после того как мы разобрались с основами, давайте обратим наше внимание на самое важное из действий — ввод.
6
О вводе
ОДНО ИЗ ГЛАВНЫХ ПРЕИМУЩЕСТВ Интернета заключается в том, что он позволяет человеку не только изучать и использовать контент, но и участвовать в его создании. В мобильных технологиях правильная организация ввода данных — вопрос не менее важный, чем их отображение. Однако организация этого процесса также имеет свои особенности. Поэтому:
• думайте о мобильных приложениях как о предоставленной пользователю возможности создавать что-то новое, причем там и тогда, где и когда его посетит вдохновение или придет интересная мысль;
• используйте оптимизированные для мобильных устройств теги label — это поможет предельно ясно формулировать вопросы;
• чтобы упростить ввод данных, применяйте различные типы ввода, атрибуты и маски;
• выбирайте правильный дизайн для последовательных, нелинейных и контекстных форм;
• используйте любые возможности для того, чтобы минимизировать количество полей для ввода данных.
Упрощение ввода
Дизайнеры обычно не склонны соглашаться друг с другом. Именно поэтому кажется удивительным, что в появившихся за последние годы руководствах по дизайну мобильных приложений можно найти множество примеров единого мнения по вопросу ввода данных. Первоначально почти все разработчики были согласны с тем, что мобильные устройства — не самый удобный инструмент для ввода данных. В книге Mobile Web Design and Development («Дизайн и разработка мобильных сайтов») Брайан Флинг писал:
Неписаный закон веб-дизайна: в мобильном контексте использование форм должно быть ограничено.
У нас есть множество веских причин, чтобы освободить пользователя, оперирующего «одним глазом и одним пальцем», от необходимости вводить информацию, но найдется и немало поводов, чтобы позволить им более активно взаимодействовать с мобильными устройствами. В конце концов, в 2010 году только в США в день отправлялось свыше четырех миллиардов текстовых сообщений, причем большинство из них создавалось при помощи не самой удобной цифровой клавиатуры обычных телефонов. Очевидно, что потребители хотят переписываться через мобильные устройства и ради этого готовы даже терпеть некоторые неудобства.
Но некоторых трудностей вполне можно избежать. Современные мобильные устройства упрощают ввод информации — этой цели служат увеличенные сенсорные экраны, микрофоны, видеокамеры и многое другое. Дизайнерам мобильных сайтов пора перестать бояться ввода данных и начать воспринимать мобильные устройства как наиболее удобное средство для получения разнообразного контента от всех категорий пользователей.
Мобильные устройства всегда при нас. Поэтому всякий раз, когда нас посещает вдохновение, мы можем поделиться своими мыслями с друзьями или принять участие в создании онлайн-контента. Возможность определить местоположение пользователя и ориентация устройства, запись аудио, видеокамера и многое другое предоставляют нам массу новых возможностей для ввода информации, при этом нет необходимости прибегать к помощи такого неточного инструмента, как палец.
Самое важное — перестать бояться того, что пользователи не станут выполнять то или иное действие лишь потому, что в данный момент они вышли в Сеть с мобильного устройства. Ведь приобрел же какой-то человек самолет стоимостью 265 тысяч долларов через приложение eBay для iPhone (, ). Осознав, что ввод данных следует поощрять и всячески ему содействовать, можно перейти к дизайну.
Мобильные вопросы
То, каким образом мы просим пользователей вводить данные, во многом предопределяет их ответы. В Интернете большинство вопросов задаются через формы, а для того, чтобы правильно сформулировать вопрос, формы содержат подсказки — теги label. В мобильных интерфейсах эти теги имеют ряд ограничений и предоставляют определенные возможности, что и определяет то, как они должны быть спроектированы.
Экран мобильного устройства невелик — следовательно, необходимо адаптировать веб-формы под его размер. В большинстве случаев разместить элементы label справа или слева от поля ввода не удается — просто нет места для двух колонок. Поэтому их лучше всего выравнивать по верхнему краю: это позволяет не только оптимизировать пространство экрана (даже когда они достаточно длинные), но и сохранить их видимыми при открытии виртуальной клавиатуры, занимающей половину имеющегося пространства.
В регистрационной форме мобильного сайта Twitter (рис. 6.1) элементы label находятся над полями ввода, а под ними располагается пояснительный текст. Эти элементы остаются видимыми даже при открытии виртуальной клавиатуры. И раз уж мы заговорили о Twitter, известно ли вам, что за первые пять месяцев 2010 года 16 % его новых пользователей зарегистрировались при помощи мобильных приложений ()?
А что 40 % всех твитов поступают именно с мобильных устройств ()? Или даже эти цифры не смогут убедить вас в том, что проблема ввода данных через мобильный интерфейс имеет первостепенное значение?
Элементы label, располагающиеся над полем ввода, — хорошее решение. Но если они находятся внутри поля формы — еще лучше. И вот доказательство: практически все мобильные платформы в своих приложениях поддерживают элементы label, находящиеся внутри полей ввода. Однако в мобильном веб-дизайне внедрение такого решения может потребовать от разработчика дополнительных усилий.
На первый взгляд элемент label внутри поля ввода кажется отличным решением, однако для его реализации придется преодолеть ряд препятствий.
Итак, элемент label внутри поля ввода формы:
• Никогда не должен становиться частью ответа. Это правило выглядит простым, но на практике подобное происходит достаточно часто (например, при ошибке в коде или неполной загрузке страницы). Вы никогда не обнаруживали, что слово «найти» неожиданно становилось частью вашего поискового запроса?
• Не должен быть похожим на текст, который вводится в поле. В противном случае пользователь (и вполне обоснованно) может предположить, что программа уже ввела ответ за него. При тестировании веб-интерфейсов я сталкиваюсь с такими ситуациями постоянно.
• Как только пользователь начинает вводить текст в поле, label обычно исчезает и больше не появляется. Таким образом, заполнив форму, он не может проверить, на какой именно вопрос отвечал.
Две последние проблемы наглядно иллюстрирует форма регистрации на мобильном сайте сервиса почтовых рассылок MailChimp (рис. 6.2). С началом ввода имени находящийся внутри поля элемент label исчезает. (Хочу отметить: с точки зрения спецификации HTML5 это вполне нормально, поскольку в данном случае применяется атрибут placeholder, представляющий собой подсказку, а не название поля.) Цвет текста в заполненном поле (lukew) почти неотличим от названия следующего поля (password). Рассматриваемая форма очень проста, и описанную проблему вряд ли можно считать значительной. Однако чем более сложной будет становиться форма, тем большим может быть и масштаб проблемы.
И все же решение вышеописанной проблемы существует. Рассмотрим в качестве примера регистрационную форму мобильного приложения для управления проектами Basecamp, где название поля остается видимым вплоть до того момента, как вы начинаете вводить в него текст. (Эта опция не входит в штатный функционал веб-браузеров, и поэтому в данном случае разработчикам пришлось немного потрудиться.) Разница между текстом ответа и названием поля очевидна, поэтому пользователь вряд ли их перепутает (рис. 6.3).
Мобильные ответы
Спроектировать хорошую веб-форму для мобильного сайта совсем не сложно — достаточно просто задавать правильные вопросы при помощи элементов label. А вот сделать так, чтобы пользователям было легко давать правильные ответы, — задача куда более серьезная. К счастью, проектирование мобильных приложений не только накладывает ограничения, но и предоставляет целый ряд возможностей, позволяющих найти выход из этой ситуации.
Стандарты…
Если вы уже проектировали сайты, то наверняка знакомы с различными типами полей веб-форм. Наиболее часто используются следующие типы полей: чекбокс (checkbox), поле ввода пароля (password), радиокнопка (radio), выпадающий список (select), поле выбора имени файла (file pick), кнопка отправки (submit) и обычное текстовое поле (plain text). Придерживаясь этого стандарта, вы значительно облегчите пользователям взаимодействие с вашим мобильным сайтом (табл. 6.1).
Например, когда вы применяете стандартный выпадающий список, браузер устройства с активным экраном может представить его в виде большого количества элементов довольно крупного размера, а не как стандартное выпадающее меню, которое можно увидеть на стационарных компьютерах (рис. 6.4–6.5). Различные мобильные платформы будут по-разному отображать эти списки, однако в любом случае выбрать подходящий вариант с их помощью будет значительно проще. То же справедливо и в отношении кнопок отправки, радиокнопок, сообщений об ошибках и многого другого.
Есть, однако, и исключения. Несмотря на то что реализованный на мобильных платформах функционал меню обычно облегчает выбор из списка, иногда мобильные ограничения дают о себе знать. Например, если меню оказывается слишком длинным, то при масштабировании страницы оно часто выходит за пределы экрана, что осложняет выбор необходимых опций (рис. 6.6).
Иногда длинный список не разворачивается на весь экран, а прокручивается в небольшом окне, что также крайне неудобно. На таких устройствах, как iPhone, одновременно можно видеть не больше четырех-пяти пунктов меню. Поэтому если размер меню выходит за вертикальные или горизонтальные ограничения стандартного выпадающего списка, лучше выделить для него отдельную страницу.
В некоторых случаях лучше вообще отказаться от выпадающего меню — без него сделать выбор зачастую и проще, и быстрее. Как показывает практика, в случае тач-интерфейса выпадающее меню предполагает выполнение минимум четырех действий: сначала требуется нажатие, чтобы открыть меню, потом пролистывание — чтобы его просмотреть, затем снова нажатие — чтобы выбрать нужный вариант ответа, и еще одно нажатие — чтобы закрыть список и вернуться назад к форме. Если же форма содержит несколько выпадающих меню (рис. 6.7), то нажимать на экран приходится очень интенсивно.
К счастью, эту задачу можно решить при помощи пользовательских элементов управления, специально разработанных для устройств с тач-интерфейсом. Например, в мобильной версии туристического сайта Kayak (рис. 6.8) для ввода количества бронируемых номеров и числа проживающих вместо выпадающих меню применяется элемент управления «спиннер». Чтобы ввести новое значение, достаточно один раз нажать на кнопку «+» или «—». Это отличное решение для полей с ограниченным диапазоном выбора, таких как на сайте Kayak, где вы можете заказать не более двух гостиничных номеров.
На сайте Kayak необходимые поля проще заполнять еще и потому, что в них предустановлены значения, которые выбирает большинство посетителей (). Чаще всего клиентам требуется один номер, и, сделав «1» значением по умолчанию, разработчики сэкономили пользователям время и силы — ведь теперь тем не нужно вводить число вручную или выбирать его из списка.
Исследование, в ходе которого проводилось сравнение эффективности взаимодействия с пустыми формами и формами, содержащими значения по умолчанию, показало, что владельцы мобильных устройств заполняют формы второго типа в четыре раза быстрее, чем формы первого (http:// bkaprt.com/mf/52; PDF). Согласитесь, такая экономия времени дорогого стоит.
Выбирать даты путешествия на сайте Kayak также невероятно просто. В отличие от сайта American Airlines, где этой цели служат аж три выпадающих меню (рис. 6.7), клиентам Kayak достаточно отметить соответствующие даты в большом, занимающем почти весь экран календаре (рис. 6.9). И снова разработчики избавили пользователей от необходимости производить массу ненужных манипуляций.
Проектируя мобильную версию сайта, которая предполагает нестандартные способы ввода данных, не забывайте об устройствах без тач-интерфейса или с гибридным интерфейсом. Убедитесь, что посетители смогут взаимодействовать с вашим сайтом при помощи средств непрямой манипуляции (трекболов, трекпадов и т. д.), — укажите порядок элементов выпадающего меню, а также установите значения состояний: focus и: hover.
Новые стандарты.
Чтобы задать нестандартные поля для мобильного сайта, необходимо написать специальный код. Однако мобильные веббраузеры стремительно развиваются, и те элементы, которые сейчас требуют специальных действий, в недалеком будущем могут стать частью стандартной разметки ( mf/53). Более того, уже сегодня существует ряд решений, позволяющих значительно упростить ввод данных.
Начну с того, что в рамках стандарта HTML5 новые типы полей облегчают ввод данных определенного формата. В мобильном Safari и аналогичных ему браузерах при заполнении поля url (веб-адрес) открывается виртуальная буквенно-цифровая клавиатура с кнопками «.», «/» и «.com». При указании типа поля e-mail возникает виртуальная клавиатура с символами «.» и «@». А при указании типа поля number появляется цифровая клавиатура (рис. 6.10).
Спецификацию HTML5 можно использовать без опасений — браузеры, не поддерживающие новые типы полей, обнаружив неизвестный им тип поля, интерпретируют его как стандартный текст. (Изучить типы полей, поддерживаемых популярными мобильными веб-браузерами, можно в сравнительной таблице, составленной Питером-Полом Кохом ()).
Применение специальных типов полей форм дает положительные результаты даже на тех устройствах, браузеры которых не имеют виртуальной клавиатуры (поддерживающие HTML5 или менее распространенные спецификации, такие как CSS-MP или Wireless CSS), поскольку пользователям для ввода числовых данных не требуется переключаться в соответствующий режим. Кстати о числах: телефоны изначально создавались, чтобы набирать на них цифры, и большинство из них имеют виртуальную или физическую цифровую клавиатуру. Поэтому для ввода числовых последовательностей, таких как номер телефона или цена, задайте единое поле и предоставьте пользователям возможность набрать правильное значение на клавиатуре.
Несмотря на появление новых типов полей, основная часть данных по-прежнему вводится в формате обычного текста.
К счастью, и в этой сфере дополнительные атрибуты полей позволяют сделать жизнь мобильных пользователей проще.
Среди них:
• автоматическое добавление прописных букв (autocapitalize) — отключайте этот атрибут при вводе адресов электронной почты, паролей, веб-адресов и других данных, где имеет значение регистр; включайте при вводе имен собственных, таких как географические названия или имя/фамилия;
• автоматическое исправление (autocorrect): отключайте этот атрибут при вводе адресов электронной почты, паролей, веб-адресов и других нетекстовых данных; включайте при вводе текста и данных в свободной форме; не забывайте удалять лишние пробелы в конце слов, возникающие в режиме автоисправления текста.
Повторю еще раз: браузеры, не поддерживающие эти атрибуты, просто проигнорируют их, поэтому вы можете смело использовать их в своих формах. В современных браузерах ваши формы покажут все, на что они способны, и потребители будут вам благодарны — особенно после того, как увидят, что введенная ими информация не была уничтожена излишне активными штатными средствами автокоррекции, встроенными в операционную систему устройства.
Маски для особых случаев
Новые типы полей и дополнительные атрибуты позволяют владельцам мобильных устройств вводить данные быстро и точно. Но вы можете сделать их жизнь еще проще, добавив к полям соответствующие маски, задающие параметры ввода и ограничивающие объем вводимых данных.
Маски ввода поддерживают большинство мобильных операционных систем, поэтому неудивительно, что они есть во многих нативных приложениях. В случае мобильных браузеров основная задача по интеграции масок ввода в веб-формы ложится на плечи разработчиков и JavaScript. Так что полезно знать, что заставляет маску корректно работать.
В простейшем виде маска определяет верный формат вводимой информации. Например, вам необходимо получить адрес электронной почты пользователя на домене me.com — маска ввода позволит отсечь любую информацию, не соответствующую заданному формату. В данном случае поле адреса электронной почты будет содержать на конце «@me.com». Таким образом, вы сможете ограничить ввод символов после знака «@», гарантировав, что написанный электронный адрес будет содержать доменное имя me.com (рис. 6.11).
Как это работает? Пользователь вводит адрес электронной почты, при этом часть текста внутри поля, а именно «@me.com», остается видимой на экране. Система проигнорирует любые символы, набранные после знака «@». Это позволяет не только снизить вероятность ошибки, но и уменьшает число символов, вводимых владельцем мобильного устройства. И то и другое создает существенное преимущество.
Если вы хотите быть уверены, что ваша маска помогает пользователям вводить информацию, а не создает им дополнительные трудности, при добавлении масок к полям ввода следует учитывать несколько моментов. Прежде всего нужно точно указывать, какой формат данных предполагает то или иное поле. В описанном выше примере информация о домене была доступна пользователям сразу и оставалась видимой все время, пока они вводили адрес электронной почты.
Аналогичный пример — маска, используемая для ввода идентификационного номера налогоплательщика (рис. 6.12). В этом случае она будет не только игнорировать ввод дефисов (поскольку они уже включены в формат), но и любых нецифровых символов. ИНН должен содержать только цифры и два дефиса, и применение подобной маски к полю ввода не позволяет ошибиться и написать вместо цифры букву.
Однако не всегда маски позволяют получить ожидаемые результаты: некоторые из них могут настолько непредсказуемо меняться, что способны сбить вас с толку. Пример одной из таких масок показан на рис. 6.13: увидев маску ввода номера телефона, пользователь предполагает, что номер будет иметь следующий формат: «XXX–XX–XXXX» (лично я в таком случае предложил бы маску «_-_»). Но стоит ввести в поле первую цифру, как формат номера исчезает, а вокруг набранных символов появляются скобки — весьма неожиданно, не так ли? Процесс автоматического форматирования данных будет продолжаться до тех пор, пока пользователь не введет последнюю цифру.
В итоге телефонный номер будет состоять из цифр, скобок, пробела и дефиса — то есть выглядеть совсем не так, как предполагала его первоначальная маска. Для общепринятых данных, таких как номер телефона, возможно, это и не столь важно. Но общее правило работы с масками ввода гласит: изначально видимые маски ввода проще и удобнее, чем скрытые или появляющиеся постепенно.
Огласите весь список, пожалуйста!
Элементы label и поля ввода — это кирпичики, из которых строится форма. И эти кирпичики необходимо складывать так, чтобы они стимулировали взаимодействие компаний и их клиентов. Другими словами, важно, чтобы поля ввода были правильно организованы. По большому счету существуют три сценария ввода информации, которые мы должны принимать во внимание: последовательность взаимосвязанных вопросов, нелинейное обновление и контекстный ввод с целью немедленного реагирования.
Последовательный набор полей — это группа вопросов, которые необходимо задать, чтобы завершить определенные действия. Самый простой пример такого сценария — формы регистрации и оформления заказа. К этой группе относятся любые вопросы, на которые пользователь должен последовательно ответить, чтобы достичь конкретной цели (покупки, подписки на услуги и т. д.).
Несомненно, когда дело касается мобильного Интернета, правильная организация элементов label и полей ввода играет немаловажную роль, но все же одним из наиболее важных факторов является объем информации, запрашиваемой у пользователя. Чем меньше вопросов вы будете задавать, тем лучше.
Сравните первоначальный вид формы Get Online на мобильном сайте Boingo (рис. 6.14) и ее вид после проведенного мной редизайна (рис. 6.15): этот пример позволяет понять, от скольких элементов можно смело отказаться, чтобы сделать ваш сайт более лаконичным. Когда речь заходит о мобильных формах, следует действовать радикально — сокращать, сокращать и еще раз сокращать.
Однако сразу задавать пользователю все имеющиеся вопросы необходимо далеко не всегда, ведь зачастую тому требуется лишь изменить (или обновить) некоторые поля формы.
А если для редактирования открыты все имеющиеся поля, ему непросто найти среди них те, в которые он планировал внести изменения, — и особенно трудно это сделать на маленьком экране мобильного устройства.
В этом случае более чем оправданным будет применение нелинейного подхода к проектированию формы. В качестве примера давайте рассмотрим профиль пользователя на мобильном сайте Bagcheck. Как правило, мы достаточно редко редактируем свои данные; и еще реже изменяем их полностью. Поэтому на сайте Bagcheck процесс редактирования профиля организован следующим образом: в соответствующих полях формы отображены все пользовательские данные, и, чтобы изменить те или иные из них, необходимо просто нажать на соответствующую строчку, вызвав диалоговое окно (с клавиатурой и курсором в поле) или отдельную страницу для редактирования.
При проектировании форм необходимо принимать в расчет высоту виртуальной клавиатуры (обычно она занимает примерно половину экрана). Оптимально, если клавиатура не будет закрывать поле ввода и кнопки формы.
И последний (но от этого не менее важный) сценарий, позволяющий легко и быстро создавать и редактировать контент, — это контекстный ввод. В этом случае в тексте обозначается область, которую пользователь может редактировать. Форма контекстного ввода обычно состоит из одного поля. Взгляните на мобильный сайт Quora, где можно комментировать ответ, не покидая текущей страницы (рис. 6.17). Такая схема позволяет оперативно реагировать на сообщения других пользователей и вполне соответствует привычным способам взаимодействия с мобильными устройствами.
Формы и поля ввода… а что еще?
Сегодня возможности мобильных устройств позволяют выйти далеко за рамки ограничений обычных форм ввода. Геолокация, ориентация устройства, ввод аудио и видео, технология коммуникации ближнего поля (NFC) и многое другое позволяет пользователям создавать и редактировать контент, не заполняя форму.
В качестве иллюстрации давайте подробно рассмотрим функцию определения местоположения пользователя. Резервируя гостиничный номер на мобильном сайте Kayak, вы можете ввести данные о том, где находитесь, с клавиатуры или выбрать текущее местоположение, просто нажав на иконку справа от поля ввода. Мобильный сайт Twitter позволяет добавлять к вашему сообщению информацию о текущем местоположении посредством единственного нажатия (рис. 6.18).
В обоих случаях пользователи избавлены от необходимости вводить текст.
Есть и другие интересные примеры. Задействуя видеокамеру мобильного устройства, приложение Google Goggles способно идентифицировать книги, вина, картины и ориентиры на местности. С его помощью можно сканировать визитные карточки или переводить иностранные тексты (рис. 6.19). Только представьте, какой объем текста понадобилось бы ввести, чтобы добиться аналогичного результата.
Технология коммуникации ближнего поля (NFC) предоставляет нам дополнительные возможности. Мобильные устройства считывают передающиеся на радиочастотах метки (RFID). Для того чтобы ваше устройство начало взаимодействовать с объектом, транслирующим в эфир свою метку («цифровой штрихкод»), достаточно просто оказаться с ним рядом. Хотите больше узнать о продукте? Достаточно подойти к нему на расстояние, позволяющее уловить сигнал, и вся необходимая информация появится на экране вашего мобильного устройства. О каких полях и формах тут может идти речь?
И все же давайте вернемся к сегодняшним реалиям мобильного веба. Имея доступ к API мобильного устройства, нативные приложения могут управлять вводом аудио и видео, NFC-взаимодействием (там, где оно доступно) и другими функциями. И хотя в настоящее время широко обсуждается возможность доступа к камере и NFC-приемнику через браузер, законченных решений в этой области пока нет. Но динамика развития мобильных технологий такова, что новые подходы и идеи появляются чуть ли не каждый день. Не волнуйтесь, в скором времени при разработке веб-приложений вы сможете использовать функции API в полной мере.
Ввод до упаду
Мобильные устройства существуют уже немало лет, но до недавнего времени возможности ввода контента с их помощью оставались рудиментарными. Сегодняшнее сочетание технических характеристик устройств, скоростного доступа в Интернет и растущего желания пользователей поделиться информацией «здесь и сейчас» открывает перспективы, которыми не стоит пренебрегать.
• Активно поощряйте пользователей создавать и редактировать информацию при помощи мобильных устройств.
• Убедитесь, что элементы label оптимизированы под мобильные устройства и предельно четко формулируют заданный вами вопрос.
• Везде, где возможно, применяйте форматирование ввода, атрибуты и маски, чтобы избежать проблем, связанных с ошибками, возникающими при вводе данных.
• Рассмотрите возможность использования кастомизированных элементов, если они действительно помогут пользователям вводить информацию легко и точно.
• Правильно применяйте сценарии последовательного, нелинейного и контекстного ввода информации.
• Используйте все имеющиеся возможности для расширения способов ввода информации через мобильное устройство.
Мы изучили ввод данных, средства взаимодействия и общую организацию информации на мобильных устройствах. Теперь давайте поговорим о великом множестве устройств, для которых предназначаются все эти элементы. Итак, переходим к следующей главе: верстка.
7
Верстка
ПРИНЦИПЫ ОРГАНИЗАЦИИ КОНТЕНТА и элементов интерфейса, применяемые при разработке дизайна обычных сайтов, несомненно, могут быть полезны и при проектировании мобильных веб-приложений. Но как быть уверенными в том, что эти принципы будут актуальны для любых мобильных устройств — как существующих сегодня, так и тех, что появятся в ближайшее время?
Для этого необходимо:
• принять тот факт, что в обозримом будущем мобильная индустрия будет развиваться столь же стремительными темпами;
• «сообщать» мобильным браузерам, что созданный вами сайт оптимизирован для просмотра;
• создавать «гибкие» (flexible), «резиновые» (fluid) и «отзывчивые» (responsive) макеты веб-страниц;
• хорошо представлять, в чем состоят технические различия между устройствами;
• проектируя мобильные сайты, избавляться от всего лишнего и ненужного.
Лишь изменения постоянны
Пока я обдумывал и писал эту книгу, мобильная отрасль несколько раз претерпела кардинальные изменения. Прежние лидеры рынка мобильных платформ утратили свои позиции. Появились устройства с новыми возможностями, а значит, и новыми ограничениями. Производители устройств, разработчики мобильных платформ и операторы сотовой связи объявили о партнерстве.
Добро пожаловать в мобильный мир, где постоянны лишь изменения! Этот мир продолжает стремительно меняться, поэтому я сосредоточусь на тех тенденциях, которые в последнее время незыблемо задавали параметры разработки дизайна для мобильных устройств. Речь идет о появлении более мощных процессоров, увеличении скорости передачи данных, росте популярности тач-интерфейса и совершенствовании веб-браузеров.
Так что же делать веб-дизайнеру, оказавшемуся в этом море постоянной нестабильности? Плыть по воле волн? Ни в коем случае. Вы все еще на Диком Западе, а значит, придется стать ковбоями. Рискуйте, экспериментируйте, творите и примите как данность, что в настоящий момент далеко не все границы между устройствами, браузерами и веб-стандартами нанесены на карту.
Итак, седлайте скакунов — и в путь! Вооружившись принципами и методами мобильной верстки, попробуем укротить непокорные мобильные устройства. (Обещаю, ковбойских метафор больше не будет.)
Вы здесь ради них
Главное в мобильном веб-дизайне — «сообщить» мобильным браузерам, что вы потратили время и силы, чтобы адаптировать ваш сайт для каждого из них. Я помню об обещании не углубляться в программные коды, но все же здесь необходимо привести синтаксис тега viewport как важнейшей части любого мобильного сайта.
Процитирую Питера-Пола Коха, много писавшего о применении этого атрибута ():
По умолчанию атрибутивное значение viewport устанавливается равным ширине, которую разработчик считает оптимальной для просмотра сайтов на обычных компьютерах. Задав для тега viewport значение device-width [10]Параметр device-width делает ширину окна просмотра браузера равной ширине экрана устройства.
, вы можете быть уверены, что ширина страниц вашего сайта будет соответствовать ширине экрана того устройства, на котором ее будут просматривать.
Тег viewport позволяет также преодолеть различия в разрешающей способности дисплеев мобильных устройств. Разрешающая способность, измеряемая в пикселях на дюйм (ppi), показывает число пикселей, из которых состоит горизонтальная или вертикальная линия длиной в 1 дюйм, отображенная на экране конкретного устройства. iPhone первого поколения имел экран с диагональю 3,5 дюйма и разрешением 320 X 480 px; таким образом, разрешающая способность этого экрана составляла 164 ppi. У смартфона Google Nexus One был 3,7-дюймовый экран с разрешением 480 X 800 px, а следовательно, его разрешающая способность равнялась 252 ppi. Почему это так важно?
Разрешающая способность определяет физические размеры элементов, отображающихся на экране. Чем выше ppi, тем меньше физические размеры каждого пикселя. Посмотрите, как графический объект — в данном случае набор кнопок — выглядит на мониторе Apple Cinema Display, ppi которого составляет примерно 94 единицы, как и у большинства мониторов настольных компьютеров. А теперь взгляните, как те же кнопки отображаются на экране смартфона Nokia N900 с разрешающей способностью 266 ppi. Разница заметна невооруженным глазом. То, что в первом случае было крупным и читаемым, во втором стало крошечным и практически нечитаемым (рис. 7.1).
Если вы создаете приложение с расчетом на то, что его будут просматривать на устройствах, имеющих разную разрешающую способность экрана, то подобный нюанс может стать проблемой. Однако решить ее довольно легко — для этого достаточно при разработке дизайна вашего сайта включить в него тег viewport, который распознают все мобильные браузеры. Как заметил Питер-Пол Кох (), браузеры для iPhone первого поколения (разрешающая способность экрана 164 ppi), Google Nexus One (252 ppi) и iPhone 4 (329 ppi) используют значение параметра device-width, равное 320 px, что позволяет обеспечить столь необходимое постоянство отображения веб-страниц.
Следующий вопрос: просмотр изображений высокого разрешения. В отличие от интерпретируемых браузером объектов (формы, кнопки, текст, линии и другие визуальные элементы) растровые изображения автоматически не адаптируются к разрешающей способности того или иного экрана. На дисплеях с высокой разрешающей способностью они будут иметь правильные физические размеры, но при этом отображаться недостаточно четко и резко (рис. 7.2).
Чтобы решить эту проблему, вам потребуется сделать два комплекта изображений: с высоким (удвоенным) и стандартным разрешением. Затем, используя медиазапросы CSS3 (media queries), JavaScript или серверный сценарий, необходимо дать браузеру команду загружать на устройства с высокой разрешающей способностью изображения из первого набора ().
Если идея с двумя комплектами изображений вас не привлекает (да и кому она может понравиться?), максимально задействуйте возможности визуального оформления, заложенные в CSS. Градиентные заливки и скругленные углы в дизайне мобильного сайта Yahoo! (рис. 7.2) создаются средствами CSS3 и поэтому отлично выглядят на экранах как с высоким, так и с низким разрешением. Благодаря их использованию разработчикам не пришлось тратить время на создание нескольких версий каждого изображения, а посетители были избавлены от необходимости их загружать.
Мобильные браузеры, не поддерживающие визуальные эффекты CSS3, вместо градиентных заливок и скругленных углов будут отображать однотонный фон и прямые углы. Ничего страшного.
Однако следует иметь в виду, что чрезмерное увлечение CSS3-эффектами может существенно влиять на производительность, поскольку на некоторых устройствах многочисленные тени и градиентные фоны замедляют загрузку страницы. К счастью, движки мобильных браузеров постоянно совершенствуются, так что в ближайшее время и эта проблема будет решена.
Гибкость и отзывчивость
Несмотря на то что некоторые мобильные устройства, имея разную разрешающую способность экрана, используют одну величину атрибута viewport, только значения ширины страницы нашего сайта будет явно недостаточно. Взять хотя бы тот факт, что, даже если бы все устройства имели device-width, равный 320 пикселям, нам все равно пришлось бы предусмотреть разную ширину страницы для экрана в вертикальном и горизонтальном положениях.
Чтобы справиться с этой, а заодно и с любыми другими проблемами, связанными с шириной страницы, мы должны сделать верстку максимально адаптируемой к устройствам отображения. И как бы мы ни называли такой макет — гибким (flexible) или резиновым (fluid), — дизайн, при котором страница сужается и расширяется в зависимости от размера экрана, является обязательным атрибутом мобильного вебдизайна. При таком подходе элементы интерфейса (например, поля поиска и элементы меню на мобильном сайте Google Places, рис. 7.3) меняются в зависимости от доступного им пространства.
Гибкий макет — вещь важная, но это только начало.
Отзывчивый веб-дизайн
С увеличением диапазона размеров экранов мобильных устройств для корректного отображения веб-страниц гибкого макета оказывается недостаточно. Только представьте, сколько существует возможных вариантов размещения элементов вашего сайта на устройствах с шириной экрана 768 px и 320 px. Экран с горизонтальным разрешением 768 px предлагает в два с половиной раза больше свободного пространства! Очевидно, мы можем сделать что-то гораздо более интересное, чем просто растянуть страницу до границ окна! И здесь нам на помощь приходит технология отзывчивого веб-дизайна.
Этот подход включает гибкий макет на основе сетки, гибкие изображения, медиазапросы CSS3 и (иногда) немного JavaScript — все вместе эти элементы позволяют создавать дизайн, который будет адаптироваться к изменениям разрешения экрана и размеров области просмотра. Технология отзывчивого веб-дизайна предполагает, что вы начинаете разработку вашего сайта с создания его мобильной версии, а затем постепенно совершенствуете его или приводите в соответствие с требованиями для вновь появляющихся устройств.
На практике это означает выбор определенных значений ширины экрана, которые станут «контрольными точками», задающими новые параметры отображения страницы и ее графических элементов (изображений, видео). Другими словами, «контрольная точка» — это условный оператор, определяющий, соответствует ли устройство определенному критерию (например, ширина окна браузера менее 600 px). Если условие выполняется, браузер использует новый набор параметров отображения страницы (как правило, новую таблицу стилей CSS, а иногда и новый код JavaScript), а сайт видоизменяется, масштабируясь под доступное пространство. О деталях этого процесса можно узнать, прочитав отличную книгу Итана Маркотта «Отзывчивый веб-дизайн».
Таблицы стилей CSS определяют наличие и расположение элементов на странице, а также размер изображений. Однако изменения не должны быть ни кардинальными, ни еле заметными (рис. 7.4).
Итак, применяя принципы отзывчивого веб-дизайна, мы можем масштабировать нашу веб-страницу под размеры экрана устройства, на котором ее будут просматривать. Но устройства отличаются не только размерами экранов.
Взаимодействие с устройствами
Современные устройства предполагают не только многообразие характеристик и ограничений, но также и различные способы взаимодействия. Сравните телевизоры со встроенным доступом в Интернет, настольные компьютеры, ноутбуки, планшеты, смартфоны и обычные телефоны — каждое из этих устройств уникально по нескольким параметрам:
• Поза, которую принимает их владелец: сидит в кресле на расстоянии нескольких метров от экрана, в течение нескольких часов непрерывно находится за рабочим столом, сидит на диване, или лежит в кровати с устройством в руках, или использует его несколько раз в течение дня там, где это удобно.
• Основной метод ввода данных: жесты/дистанционное управление, мышь/клавиатура, нажатие/сенсорный ввод, цифровая клавиатура.
• Размер экрана: настенный, настольный, переносной, наладонный или еще меньше.
Комбинация этих параметров зачастую определяет способ взаимодействия пользователя с устройством. Каждый из этих способов требует определенного подхода к дизайну пользовательского интерфейса, поскольку то, какие именно задачи решает владелец при помощи своего устройства, во многом зависит от условий, в которых он находится в данный момент, так же как, например, проектирование сайта и элементов управления зависят от методов ввода данных и размеров экрана.
В результате разработчикам веб-приложений во многих случаях приходится создавать уникальное решение для каждого интерфейса. Например, сервис потокового видео Netflix спроектировал отдельные сайты для телевизоров со встроенным доступом в Интернет, планшетов, настольных компьютеров и смартфонов (рис. 7.5). Конечно, создание такого числа вариантов занимает немало времени, зато каждый из разработанных интерфейсов максимально учитывает особенности взаимодействия пользователей с конкретным устройством.
Разумеется, вы можете спроектировать единый пользовательский интерфейс, но результатом такого «универсального» решения, скорее всего, станет необходимость идти на компромиссы и соглашаться с наличием множества ненужных элементов. К тому же единый дизайн не способен в полной мере учесть ограничения и возможности использования тех или иных устройств.
Например, телевизор со встроенным доступом в Интернет позволяет просматривать текстовые списки, оптимизированные под обычный мобильный телефон, но вряд ли кто-то захочет это делать. И напротив, веб-приложение, оптимизированное под планшетные компьютеры, вполне подойдет и для стационарных ПК, поскольку у первых экран меньше, средства взаимодействия с пользователем проще, а кнопки и ссылки крупнее. И хотя при разработке этого интерфейса не учитывались ни поза, которую принимает владелец устройства, ни методы ввода данных, ни размеры экрана обычного компьютера, он все равно будет функциональным.
Понимание особенностей взаимодействия пользователей с различными устройствами помогает задать критерии, определяющие новые параметры отображения веб-страницы и ее графических элементов — ведь сайт должен не только хорошо выглядеть, но и хорошо работать. Расположение и масштаб элементов должны соответствовать доступному пространству и учитывать имеющиеся средства ввода данных (например, тач-зоны не могут быть меньше определенного размера).
В сочетании с принципами отзывчивого дизайна такой подход обеспечит эффективную работу вашего сайта на любых мобильных устройствах — как существующих сегодня, так и будущих.
Чем проще, тем лучше!
На всякий случай, если до сих пор эта мысль не прозвучала достаточно убедительно, повторю: основное правило разработки мобильных интерфейсов — чем проще, тем лучше. Тач-зоны должны быть достаточно крупными, чтобы мы могли управлять ими при помощи своих не всегда точных пальцев. Отзывчивый дизайн должен помогать сайтам адаптироваться к изменениям разрешения экрана и размеров области просмотра. По мере увеличения объемов контента и появления устройств с новыми характеристиками мобильные приложения должны оставаться простыми и удобными в использовании.
Все это подталкивает нас к тому, чтобы на экранах мобильных устройств располагалось как можно меньше элементов — это позволит пользователям легко управлять нашими сайтами, быстро достигать поставленных целей и допускать меньше ошибок. Поэтому, проектируя мобильный сайт, оставляйте лишь то, что действительно необходимо вашим пользователям, независимо от того, какие задачи они будут решать — искать или изучать информацию, проверять обновления или создавать и редактировать контент.
Избавляясь от всего лишнего, вы не только облегчаете процесс создания мобильного сайта, но и помогаете пользователям сосредоточиться на выполнении основных задач. И если они вдруг начнут просить, чтобы и обычные сайты стали такими же, как мобильные версии, знайте: вы на правильном пути.
Проектирование пространства
Мобильный ландшафт продолжает видоизменяться, поэтому дизайн наших сайтов должен быть готов к тому, чтобы полностью отвечать потребностям пользователей независимо от времени и места их взаимодействия с веб-приложением, технических характеристик мобильных устройств или размеров их экранов.
• Примите тот факт, что в обозримом будущем мобильная индустрия продолжит развиваться столь же стремительными темпами.
• Используйте тег viewport, чтобы «сообщать» мобильным браузерам, что в процессе разработки сайта вы о них не забыли.
• Не забывайте о разрешающей способности экранов и старайтесь показывать изображения высокого разрешения на устройствах, позволяющих это делать.
• Применяйте принципы отзывчивого веб-дизайна, чтобы адаптировать свои сайты к различным устройствам отображения.
• Создавая отзывчивый веб-дизайн или используя серверные процедуры, учитывайте особенности взаимодействия пользователей с различными устройствами.
• Сводите число элементов сайта к минимуму, позволяющему сохранять функциональность.
Перечень рассмотренных в этой книге принципов и методов разработки мобильных веб-приложений, каким бы широким он ни был, нельзя считать исчерпывающим. Новые решения появляются практически каждый день. Мобильная вселенная постоянно расширяется, и даже само понятие мобильного устройства начинает размываться. Принципы мобильного веб-дизайна еще только формируются, и основные изменения ждут нас впереди. Держите руку на пульсе!