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

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

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

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

К счастью, эту задачу можно решить при помощи пользовательских элементов управления, специально разработанных для устройств с тач-интерфейсом. Например, в мобильной версии туристического сайта Kayak (рис. 6.8) для ввода количества бронируемых номеров и числа проживающих вместо выпадающих меню применяется элемент управления «спиннер». Чтобы ввести новое значение, достаточно один раз нажать на кнопку «+» или «—». Это отличное решение для полей с ограниченным диапазоном выбора, таких как на сайте Kayak, где вы можете заказать не более двух гостиничных номеров.

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

Исследование, в ходе которого проводилось сравнение эффективности взаимодействия с пустыми формами и формами, содержащими значения по умолчанию, показало, что владельцы мобильных устройств заполняют формы второго типа в четыре раза быстрее, чем формы первого (http:// bkaprt.com/mf/52; PDF). Согласитесь, такая экономия времени дорогого стоит.

Выбирать даты путешествия на сайте Kayak также невероятно просто. В отличие от сайта American Airlines, где этой цели служат аж три выпадающих меню (рис. 6.7), клиентам Kayak достаточно отметить соответствующие даты в большом, занимающем почти весь экран календаре (рис. 6.9). И снова разработчики избавили пользователей от необходимости производить массу ненужных манипуляций.

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

Новые стандарты.

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

Начну с того, что в рамках стандарта HTML5 новые типы полей облегчают ввод данных определенного формата. В мобильном Safari и аналогичных ему браузерах при заполнении поля url (веб-адрес) открывается виртуальная буквенно-цифровая клавиатура с кнопками «.», «/» и «.com». При указании типа поля e-mail возникает виртуальная клавиатура с символами «.» и «@». А при указании типа поля number появляется цифровая клавиатура (рис. 6.10).

Спецификацию HTML5 можно использовать без опасений — браузеры, не поддерживающие новые типы полей, обнаружив неизвестный им тип поля, интерпретируют его как стандартный текст. (Изучить типы полей, поддерживаемых популярными мобильными веб-браузерами, можно в сравнительной таблице, составленной Питером-Полом Кохом (http://bkaprt.com/mf/55)).

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

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

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

• Правильно применяйте сценарии последовательного, нелинейного и контекстного ввода информации.

• Используйте все имеющиеся возможности для расширения способов ввода информации через мобильное устройство.

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

Данный текст является ознакомительным фрагментом.