Сначала мобильные!

Вроблевски Люк

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