Сначала мобильные! - Люк Вроблевски 6 стр.

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

При работе с тач-интерфейсом ожидания пользователей и замысел разработчиков не всегда совпадают. Например, несмотря на то, что на мобильном сайте 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. И хотя в настоящее время подавляющее большинство производителей смартфонов отдают предпочтение сенсорным экранам, не все устройства, выпущенные ими ранее (да и те, что продолжают выпускать), имеют тач-интерфейс. Экраны старых моделей обычно меньше, поэтому тач-зоны заняли бы слишком много места и использовать жесты было бы невозможно. А значит, возникает необходимость в некоторой адаптации.

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

Но поскольку я обещал, что не стану слишком углубляться в технические аспекты и постараюсь сделать эту книгу как можно более краткой, то предоставлю право подробно рассказать о прогрессивном улучшении тем, кто разбирается в этом вопросе лучше меня (http://bkaprt.com/mf/47).

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

Поэтому:

• при определении размера и расположения тач-зон применяйте принцип «чем больше, тем лучше»;

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

• смело используйте принципы естественного пользовательского интерфейса (NUI), благодаря которым внимание посетителей сайта сосредоточивается на контенте, а не на оболочке;

• выберите наиболее подходящий для мобильного сайта способ внедрения функций, реализованных на обычном сайте в виде выпадающего меню;

• при проектировании мобильного сайта не забывайте об устройствах без сенсорного экрана и с гибридным интерфейсом.

Теперь, после того как мы разобрались с основами, давайте обратим наше внимание на самое важное из действий — ввод.

6 О вводе

ОДНО ИЗ ГЛАВНЫХ ПРЕИМУЩЕСТВ Интернета заключается в том, что он позволяет человеку не только изучать и использовать контент, но и участвовать в его создании. В мобильных технологиях правильная организация ввода данных — вопрос не менее важный, чем их отображение. Однако организация этого процесса также имеет свои особенности. Поэтому:

6

О вводе

ОДНО ИЗ ГЛАВНЫХ ПРЕИМУЩЕСТВ Интернета заключается в том, что он позволяет человеку не только изучать и использовать контент, но и участвовать в его создании. В мобильных технологиях правильная организация ввода данных — вопрос не менее важный, чем их отображение. Однако организация этого процесса также имеет свои особенности. Поэтому:

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

• используйте оптимизированные для мобильных устройств теги label[8] — это поможет предельно ясно формулировать вопросы;

• чтобы упростить ввод данных, применяйте различные типы ввода, атрибуты и маски;

• выбирайте правильный дизайн для последовательных, нелинейных и контекстных форм;

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

Дизайнеры обычно не склонны соглашаться друг с другом. Именно поэтому кажется удивительным, что в появившихся за последние годы руководствах по дизайну мобильных приложений можно найти множество примеров единого мнения по вопросу ввода данных. Первоначально почти все разработчики были согласны с тем, что мобильные устройства — не самый удобный инструмент для ввода данных. В книге Mobile Web Design and Development («Дизайн и разработка мобильных сайтов») Брайан Флинг писал:

Неписаный закон веб-дизайна: в мобильном контексте использование форм должно быть ограничено.

У нас есть множество веских причин, чтобы освободить пользователя, оперирующего «одним глазом и одним пальцем», от необходимости вводить информацию, но найдется и немало поводов, чтобы позволить им более активно взаимодействовать с мобильными устройствами. В конце концов, в 2010 году только в США в день отправлялось свыше четырех миллиардов текстовых сообщений, причем большинство из них создавалось при помощи не самой удобной цифровой клавиатуры обычных телефонов. Очевидно, что потребители хотят переписываться через мобильные устройства и ради этого готовы даже терпеть некоторые неудобства.

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

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

Самое важное — перестать бояться того, что пользователи не станут выполнять то или иное действие лишь потому, что в данный момент они вышли в Сеть с мобильного устройства. Ведь приобрел же какой-то человек самолет стоимостью 265 тысяч долларов через приложение eBay для iPhone (http://bkaprt.com/mf/48, http://bkaprt.com/mf/49). Осознав, что ввод данных следует поощрять и всячески ему содействовать, можно перейти к дизайну.

То, каким образом мы просим пользователей вводить данные, во многом предопределяет их ответы. В Интернете большинство вопросов задаются через формы, а для того, чтобы правильно сформулировать вопрос, формы содержат подсказки — теги label. В мобильных интерфейсах эти теги имеют ряд ограничений и предоставляют определенные возможности, что и определяет то, как они должны быть спроектированы.

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

В регистрационной форме мобильного сайта Twitter (рис. 6.1) элементы label находятся над полями ввода, а под ними располагается пояснительный текст. Эти элементы остаются видимыми даже при открытии виртуальной клавиатуры. И раз уж мы заговорили о Twitter, известно ли вам, что за первые пять месяцев 2010 года 16 % его новых пользователей зарегистрировались при помощи мобильных приложений (http://bkaprt.com/mf/25)?

А что 40 % всех твитов поступают именно с мобильных устройств (http://bkaprt.com/mf/50)? Или даже эти цифры не смогут убедить вас в том, что проблема ввода данных через мобильный интерфейс имеет первостепенное значение?

Элементы 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). Различные мобильные платформы будут по-разному отображать эти списки, однако в любом случае выбрать подходящий вариант с их помощью будет значительно проще. То же справедливо и в отношении кнопок отправки, радиокнопок, сообщений об ошибках и многого другого.