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

Итак, элемент 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» значением по умолчанию, разработчики сэкономили пользователям время и силы — ведь теперь тем не нужно вводить число вручную или выбирать его из списка.