UX и HTML5: давайте поможем пользователям заполнить вашу мобильную форму (часть 1)

Формы — это одно из основных основных взаимодействий пользователей с вашими веб-сайтами (и мобильными приложениями). Они связывают людей вместе и позволяют им общаться. Они позволяют им комментировать статьи и объяснять автору, насколько они категорически не согласны с тем, что они написали. Они позволяют людям общаться прямо в приложении для знакомств, чтобы встретить «единственного». Будь то форумы, заказы продуктов, онлайн-сообщества, создание учетной записи или онлайн-оплата, формы являются важной частью онлайн-жизни пользователей.

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

Рекомендуемая литература : World Wide Web, а не Wealthy Western Web .

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

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

Примечание . Хотя большая часть улучшений кода в этой статье связана с Интернетом (поскольку я не знаю Swift или Java), рекомендации по удобству использования применимы и к мобильным приложениям .

Дизайн формы 101: приоритет сканируемости и читабельности

«Форма — это имя, значение, пары в структуре для хранения данных на компьютере, выдаваемые человеком в виде меток и полей ввода». Это прямая цитата Люка Вроблевски на конференции. Как и он, я считаю, что большинство проблем с удобством использования форм возникают из-за этой тенденции предоставлять структуру базы данных пользователям.

Сильная информационная архитектура

Чтобы создать более совершенные формы, вам сначала нужно сделать несколько шагов в сторону от структуры вашей базы данных. Попытайтесь понять, как пользователи хотят заполнять формы. Именно здесь вам может пригодиться тестирование юзабилити и пользовательские исследования ваших форм. Пользовательские ментальные модели — это концепция UX, которая может помочь вам в этом. Nielsen Norman Group описывает это как «то, что пользователь думает о системе». Попросите тестировщика подумать вслух и рассказать, как бы он заполнил форму. Каких шагов они ожидают? Что на первом месте? Что будет дальше? Это даст вам лучшее представление о том, как структурировать форму более удобным для пользователя способом.

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

Если форма длинная, не выставляйте все по умолчанию . Будьте умны в том, что вы показываете. Используйте ветвление с умом, чтобы отображать только те поля, которые нужны пользователям. Например, в форме оформления заказа не отображайте все подробные поля для всех вариантов доставки. Это будет ошеломлять пользователя. Отобразите достаточно информации, чтобы помочь им выбрать правильный вариант доставки. Затем отобразите только детали и поля, связанные с этим выбором.

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

Наконец, заранее спланируйте локализацию: что произойдет, когда ваша форма будет переведена? Что будет, скажем, с немцем? Будет ли работать ваш дизайн?

Размещение этикеток и оптимизация ввода

Одноколоночный макет работает лучше всего

Из-за нехватки места вы не получаете бесконечных вариантов размещения меток и полей на мобильных экранах:

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

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

Дополнительные сведения о размещении меток см. в документе Baymard Institute «Удобство использования мобильных форм: размещение меток над полем».

Ярлыки должны быть четкими и видимыми и работать без контекста

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

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

• По возможности избегайте жаргона, аббревиатур и специфического для отрасли языка.
• Быть последовательным. Если вы однажды использовали слово «клиент» в ярлыке, придерживайтесь этого слова. Избегайте использования «клиентов» позже, потому что это может запутать пользователей.
• Размер шрифта должен быть достаточно большим. Как можно скорее протестируйте свою форму на реальных устройствах и соответствующим образом отрегулируйте размер.
• Некоторым пользователям текст, написанный заглавными буквами, может быть трудночитаемым. Возможно, вы захотите избежать использования текста, набранного заглавными буквами, на этикетках.
• Копия этикетки должна быть короткой и поддающейся сканированию. Если поле нуждается в пояснении, не помещайте его в метку. Вместо этого используйте описание поля.

Рекомендация по размеру входных данных

Если возможно, размер элемента ввода должен соответствовать размеру ожидаемого контента . Это поможет пользователям быстро заполнить форму и понять, что от них требуется.

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

Не разделяйте входные данные только ради форматирования . Это особенно раздражает на мобильных устройствах, где пользователи не могут использовать клавиатуру для навигации между полями. Требуются дополнительные нажатия только для перехода к следующему полю для заполнения формы. Вы можете подумать: «Но я автоматически переведу фокус на следующее поле, когда наберу необходимое количество символов в этом поле». Это может сработать. Но вы получите контроль над пользовательским интерфейсом, который становится непредсказуемым для пользователя. Кроме того, было бы неприятно, если бы вы автоматически отправили их в следующее поле, а им нужно было что-то исправить в последнем поле. Наконец, сложнее угадать, что является обязательным с разделенными входами. Итак, давайте перестанем играть в игру «А что, если» и просто не будем разделять входные данные.

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

Маски помогают предотвратить ошибки, направляя пользователей к правильному формату. Не раскрывайте их постепенно — покажите формат напрямую. Кроме того, избегайте поддельных значений в маске . Пользователи могут подумать, что он уже заполнен. Вот почему я заменил цифры маленьким «X» в своей демонстрации. Найдите то, что лучше всего подходит для вашего типа ввода.

Наконец, помните, что некоторые данные могут различаться в зависимости от страны, а иногда и формат (например, номера телефонов). Планируйте соответственно.

Описание эффективных полей

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

Для чего можно использовать описания?

Описания могут помочь пользователям во многих отношениях. Вот несколько примеров.

• Что именно вы просите?
  

  По какой-либо причине, связанной с базой данных, некоторые транспортные компании запрашивают поля «Адрес 1» и «Адрес 2». Это сильно сбивает с толку пользователей, но здесь у вас может не быть выбора. Добавьте поля описания, чтобы помочь пользователям понять, что им нужно указать в каждом поле.

  

  То же самое касается акронимов и аббревиатур. Я знаю, я сказал, что вы должны избегать их, но иногда вы не можете. Например, если вы работаете над сложными формами для определенной отрасли, они могут иметь свой собственный набор сокращений. Любой новый пользователь, которому необходимо заполнить форму, может быть незнаком (пока) с этими сокращениями. Наличие описания где-нибудь поможет им.

• Зачем вам эта информация?
  Пользователи могут не захотеть предоставлять вам личную информацию, если они не понимают , зачем она вам нужна и что вы будете с ней делать . Но иногда вам все же необходимо запросить такую ​​информацию по юридическим причинам (например, дату рождения для веб-сайта, продающего алкоголь). Использование здесь описаний полей поможет пользователям понять, зачем нужна такая информация.
  
  

  На веб-сайтах электронной коммерции вы можете запросить номер телефона пользователя на случай, если курьеру потребуется связаться с ним. Это законная причина. Итак, опять же, используйте описания, чтобы объяснить пользователям электронной коммерции, зачем вам нужен их номер телефона.

  

«Где найти информацию?»
Если вашим пользователям нужно найти определенную информацию где-то еще, чтобы заполнить форму, сообщите им, где ее найти. Я работал над мобильным приложением, которое позволяет пользователю отслеживать свой дом. Пользователям необходимо было связать приложение с устройством мониторинга, используя серийный номер. Найти этот серийный номер на устройстве не очень просто; это требует некоторой инструкции. Мы немного добавили ? кнопку рядом с полем серийного номера. Кнопка открывает модальное окно с изображением и некоторой индикацией, чтобы помочь пользователю понять, где найти серийный номер на устройстве мониторинга. Веб-сайты электронной коммерции делают то же самое с промо-кодами: они дают индикаторы, которые сообщают пользователям, где найти коды.



• «Как мне отформатировать информацию?»
  Некоторые поля требуют определенного формата . В этом случае используйте описания, чтобы пользователи знали правила форматирования заранее. Вот несколько примеров:
  • Номер телефона: нужно ли указывать международный телефонный код (+xx) перед полем?
  • Есть ли максимальная длина? Твиттер на мобильном телефоне отлично с этим справляется.
  • При работе с денежными суммами используется формат с запятой (например, 10 000) или пробелом (например, 10 000)?
  • Какой формат вы ожидаете для дат? Я позволю вам проверить в Википедии, что это за кошмар. Разница между ДД ММ ГГ и ММ ДД ГГ может вызвать массу проблем у пользователей при онлайн-бронировании.
  Обратите внимание, что многие из этих проблем с форматированием можно решить с помощью масок ввода. Мы вернемся к этому позже в статье (или вы можете сразу перейти к ней, если вам не терпится).

  

Как отображать описания

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

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

Будьте осторожны с заполнителями

Я понимаю: заманчиво удалить поля на мобильных устройствах, чтобы освободить место, и вместо этого использовать заполнители. Мы все прошли этот путь. Но, пожалуйста, не надо. Спецификация HML5 ясно говорит об этом: «Атрибут placeholder представляет собой короткую подсказку (слово или короткую фразу), предназначенную для помощи пользователю при вводе данных». И вот почему:

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

Даже если вы используете заполнители с метками, у вас могут возникнуть некоторые проблемы. Трудно отличить заполненное поле от поля с заполнителем . Я UX-дизайнер, который пишет о дизайне мобильных форм, и даже меня на прошлой неделе обманул один из них. Если это случится со мной, это произойдет и с вашими пользователями — поверьте мне в этом. Наконец, у большинства заполнителей текст светло-серый, так что у вас могут возникнуть проблемы с контрастом.

Если вы хотите углубиться в эту тему, есть отличная статья под названием «Атрибут-заполнитель не является меткой», а также Джошуа Винн и FeedbackGuru подробно объясняют, почему это плохая идея. Nielsen Norman Group также написала статью на эту тему под названием «Плейсхолдеры в полях формы вредны».

Заполнители не являются обязательными в HTML5 . С точки зрения удобства использования вам, безусловно, не нужны заполнители в каждом поле вашей формы. Но с массовым внедрением Bootstrap и других фреймворков похоже, что многие люди просто копируют и вставляют компоненты. У этих компонентов есть заполнители, поэтому я думаю, что люди чувствуют себя обязанными добавить что-то к заполнителю в коде? Если заполнители вашей формы выглядят так: «Пожалуйста, заполните — ярлык — здесь», вы делаете это неправильно.

Тем не менее метки внутри полей могут хорошо работать для коротких форм, в которых поля предсказуемы . Формы входа являются хорошим кандидатом для этого. Но, пожалуйста, не используйте заполнитель HTML5 для кода. Используйте настоящую метку в коде и перемещайте ее с помощью CSS и JavaScript.

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

Это выглядит как интересный способ получить немного места, не сталкиваясь с проблемами «заполнителей вместо меток», упомянутых выше. Тем не менее, это не решает проблему пользователей, которые могут ошибочно принять заполнитель за заполненный контент.

Снижение стоимости взаимодействия для успешных форм

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

Волшебное исследование в Интернете посоветовало мне уменьшить количество полей

Чем больше полей, тем меньше конверсий, верно? Возможно, вы сталкивались с исследованием «мы сократили нашу форму подписки с 11 до 4 полей, и это увеличило конверсию на 160%». Это классика. И если вы посмотрите на их контактную форму, это имеет смысл. Зачем пользователям заполнять 11 полей только для того, чтобы связаться с компанией? Вы не можете просить о таком большом обязательстве людей, которые едва вас знают, верно?

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

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

Кроме того, не доверяйте слепо каждой статистике и исследованиям, которые вы найдете в Интернете. Помните исследование «11 полей к 4»? Другое более недавнее исследование показало, что при уменьшении количества полей с 9 до 6 конверсия снизилась на 14%. Шокирует, не так ли? Почему? Ну, они убрали самые привлекательные поля. Короче говоря, затем они вернулись к 9 полям, поставили самые важные вверху, и вуаля, конверсия увеличилась на 19,21%.

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

Так что ты можешь сделать? Тестовое задание. Тестовое задание. И тест!

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

Оптимизация сенсорного взаимодействия

Делаем элементы управления сенсорными

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

Кроме того, не забудьте связать метки с их компонентами, сопоставив значения for и ID. Таким образом, если пользователь пропустит нажатие на метку, соответствующее поле все равно получит фокус.

Стивен Хубер провел исследование областей касания пользователей. Вы найдете резюме в «Designing for Touch». Основываясь на том, что он обнаружил, он построил небольшую пластиковую линейку: мобильный сенсорный шаблон. Инструмент может помочь вам убедиться, что ваши сенсорные области достаточно велики для мобильных форм и, в более общем плане, для мобильного дизайна.

Чтобы узнать больше о дизайне для сенсорного управления, вы можете прочитать следующее:

• «Удобный для пальцев дизайн: идеальные размеры мобильных сенсорных экранов»
• «Зона большого пальца: дизайн для мобильных пользователей»

Предоставление обратной связи

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

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

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

Соблюдайте следующий и предыдущий порядок кнопок

Наконец, используйте кнопки «Далее» и «Предыдущий» на мобильных клавиатурах. Пользователи могут использовать их для быстрой навигации по полям. Порядок tabindex должен соответствовать визуальному порядку полей и компонентов.

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

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

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

Список стран является хорошим кандидатом на роль компонента. Выпадающий список с более чем сотней стран — это кошмар взаимодействия на мобильных устройствах. Ничего страшного, если вы ищете Афганистан (в начале списка) или Зимбабве (в конце списка). Если вы ищете Люксембург, вы закончите игру прокруткой, чтобы достичь середины списка, зайдя слишком далеко к букве М, пытаясь вернуться к L и так далее.

Длинные выпадающие списки можно заменить полями ввода текста с предиктивным вводом . Когда пользователь начнет вводить L, интерфейс предложит девять стран. Если они добавят U — вуаля! — Люксембург. Четыре взаимодействия вместо двух по сравнению с шестью или семью взаимодействиями с прокруткой в ​​раскрывающемся списке.

Если вам нужно, чтобы пользователи выбирали дату, забудьте о том, чтобы разделить ее на раскрывающийся список дня, месяца и года, как люди привыкли делать в бумажных формах. Замените несколько раскрывающихся списков дат на средство выбора даты . Тип ввода HTML5 type=date работает в большинстве случаев. Но у вас могут быть особые потребности, и в конечном итоге вы создадите свой собственный инструмент выбора даты на JavaScript, особенно если вы занимаетесь бронированием (гостиницы, автомобили, авиабилеты).

В своей статье «Mobile DropDowns Revisited» Клаус Шеферс объясняет, как использование средства выбора даты для дат прибытия и отъезда ускорило взаимодействие на 60%.

Давайте придерживаться бизнеса бронирования. Предположим, пользователю необходимо добавить в свой маршрут несколько путешественников. Вы можете **заменить раскрывающийся список * на * степпер**, чтобы выбрать количество пассажиров. Степпер — это элемент управления, который позволяет пользователю увеличивать и уменьшать значения, просто нажимая кнопки + и — . Обычно это происходит быстрее, когда нужно добавить менее шести человек. Это также более интуитивно понятно. Ниже приведен пример степпера, используемого в Android-приложении Airbnb для выбора гостей и на веб-сайте Kayak, оптимизированном для мобильных устройств, для добавления пассажиров.

Последней альтернативой раскрывающимся спискам является представление списка. Параметры будут перечислены в определенном подпредставлении, например, в виде переключателей . В основном так работают настройки Android.

Становимся умнее с автозавершением

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

Места и адреса

Если пользователь ищет место или ему нужно ввести адрес, вы можете предложить автозаполнение, чтобы помочь ему. По мере ввода API будет заполнять остальную часть адреса за них. Это также уменьшает количество ошибок.

Вы можете использовать:

• API Google Адресов
• Algolia Places, основанный на OpenStreetMap.

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

Кредитные карты

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

Использование автозаполнения HTML5 (автозаполнение)

Атрибут автозаполнения HTML может предварительно заполнять поля на основе более ранних входных данных пользователя. Этот атрибут имеет состояние «включено» и «выключено». Некоторые умные люди начали работать над спецификацией, чтобы сделать ее более мощной и расширить атрибут автозаполнения для полей формы. У WHATWG тоже есть интересный список.

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

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

Случаются ошибки: обработка ошибок в мобильных формах

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

Как избежать ошибок при заполнении форм

«Профилактика лучше, чем лечение», — говорила моя мама. Это также относится и к дизайну форм: предотвращение ошибок улучшит работу вашей мобильной формы.

Явное ограничение формата

«Будьте консервативны в том, что вы делаете. Будьте либеральны в том, что вы принимаете от других». Этот принцип устойчивости можно применить и к полям формы. Если возможно, позвольте пользователю вводить данные в любом формате.

Если вы считаете, что вам нужно ограничить то, что пользователь может ввести в поле, начните с вопроса «почему». В области пользовательского опыта у нас есть техника, называемая «три почему». Если ответ «потому что база данных бла-бла», возможно, пришло время что-то изменить. Например, почему вы отказываетесь от специальных символов, таких как e, a и o, в поле имени пользователя? Я написал статью, объясняющую, насколько грубы формы для меня, когда я пытаюсь ввести «Стефани» в качестве имени пользователя. Я все еще пытаюсь выяснить вескую причину для этого (помимо причин базы данных).

Если у вас есть веская причина требовать от пользователей определенного формата, сообщите об этом заранее . Вы можете использовать заполнители HTML5, чтобы дать пользователям подсказку о том, как должны выглядеть данные, но опять же, будьте осторожны с ними. Вы также можете использовать все методы описания полей, описанные в начале этой статьи. Наконец, маски ввода могут направлять пользователей к нужному формату.

Отметка обязательных полей (и необязательных)

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

Вместо этого вы можете явно пометить как обязательные, так и необязательные поля словами «обязательный» (или «обязательный») и «необязательный». И Институт Беймарда, и Люк Вроблевски согласны с этим. Это позволяет избежать двусмысленности с длинными формами на мобильных устройствах, например, когда вы используете прокрутку, выполняете что-то еще, затем возвращаетесь и не помните, отмечены ли обязательные поля звездочкой или чем-то еще.

В конце концов, решение о том, как маркировать эти поля, будет зависеть от дизайна и длины поля, а также от контекста. Лучший способ узнать, приняли ли вы правильное решение, — снова проверить форму.

Разумные значения по умолчанию

Будьте осторожны с параметрами, выбранными по умолчанию в формах . Когда я подал заявку на свою предыдущую работу, там была информационная форма. Семейное положение было необязательным. Они сделали первый элемент в раскрывающемся списке «разведен» полем по умолчанию. Таким образом, я мог либо не отвечать (потому что это было необязательное поле) и позволить системе считать, что я разведен, либо исправить это и раскрыть свое фактическое семейное положение, даже если бы я этого не хотел.

Также обратите внимание на пол. Опять же, есть вариант для людей, которые не хотят его раскрывать; объясните, почему вы спрашиваете об их поле; еще лучше, попросите местоимения или не спрашивайте, если вам это действительно не нужно. If you are interested in this topic, I recommend “Designing Forms for Gender Diversity and Inclusion.” And if the gender is optional, again, don't auto-check the first choice, otherwise people won't be able to uncheck that radio button and choose not to answer.

Smart defaults, on the other hand, can help users avoid mistakes when filling a form. Unless you're in a Dr. Who episode, you're not supposed to book a hotel in the past. Booking.com understands that. When you open the date-picker on the website, the default date is set to the current date and you can't select a date in the past. When you select a return date, the default is the day after the departure date.

Less Painful Password Experience

I've written about password-less authentication, but you can't always use those techniques. Users will eventually have to create a password and enter it in a mobile form. And most of the time, that experience sucks. Here are a few ideas on how to make it better and help users avoid mistakes.

• When Creating An Account
  I won't get into the details of what kind of passwords you should require and how many characters they should be composed of — plenty of articles on that topic are on the web — just make up your mind about your password criteria. When users create an account, be proactive, not reactive. For the love of Cthulhu, don't let people guess. Tell users your password criteria up front .
  
  A lot of websites now show you a gauge for password strength telling you in real time what is missing . This is an interesting and excellent pattern. KLM uses it in its sign-in form:

  

  But there are still some big problems with this design.

1. They don't tell users their password criteria up front. Users who want to generate a password (using a password manager, for instance) must first guess that they need to first interact with the field in other to see the password criteria.
2. They limit the password's length to 12 characters, but they never tell users how many characters are left. Sure, let's add "counting the dots" to the cognitive load of building a password with so many criteria. After 12 characters, you can keep on typing on the keyboard, and nothing will happen.
3. What happens if, like me, you reached the 12-character limit but haven't met all of the criteria? Well, you would just have to delete the entire password and start over again.
4. Finally, you must enter the password twice. How is a user supposed to remember and retype the password that they just created based on those criteria while counting the dots?
5. Back to 1, generating a password with a password manager.

If KLM wanted to make this form better, it could provide a mask/unmask option for the password. Doing so, it would not need to ask for the same password twice. Users could visually check that the password they typed is the one they want.

• При входе в систему
  В форме входа параметр маски/снятия маски пароля значительно улучшит взаимодействие с пользователем.
  У Amazon есть интересная история повторения паролей в форме входа. Раньше была версия, в которой нельзя было увидеть пароль. Следующая итерация позволила пользователям раскрыть это. Тогда пароль по умолчанию раскрывался, и вы могли его скрыть. Вот как это выглядело в 2015 году:

  

  Amazon протестировал последнюю версию, и у 60% людей возникли подозрения. Таким образом, они заменили снятый флажок «скрыть пароль» установленным флажком «показать пароль». Это будет отображать пароль меньшими символами под полем, пока пользователь печатает. Вот как это выглядело на момент написания этой статьи:

  

  Как видите, всегда есть место для улучшения.

Встроенная проверка

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

Вместо этого сообщения об ошибках должны располагаться рядом с самими ошибками .

Проверка в реальном времени

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

Несколько советов:

• Как упоминалось ранее, поля пароля выиграют от проверки в реальном времени и обратной связи при каждом нажатии клавиши.
• Вы также можете проверять имена пользователей в режиме реального времени при создании учетных записей, чтобы убедиться, что они доступны. Твиттер хорошо с этим справляется.
• Не проверяйте каждое нажатие клавиши. Подождите, пока пользователь закончит печатать. (Используйте blur JavaScript для веб-форм или просто подождите несколько секунд, чтобы обнаружить бездействие.)

Примечание . *Михаэль Коневич написал хорошую статью «Встроенная проверка в формах: разработка опыта». Он объясняет концепцию « вознаграждайте раньше, наказывайте поздно ».*

«Если пользователь вводит данные в поле, которое было в допустимом состоянии, выполните проверку после ввода данных».

«Если пользователь вводит данные в поле, которое было в недопустимом состоянии, выполните проверку во время ввода данных».

Цвет имеет значение

Я не говорю, что цвет имеет значение только из-за моего нынешнего рыжего, розового и лилового цвета волос. Цвет действительно имеет значение в дизайне формы.

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

Говоря о дальтонизме: цвет не должен быть единственным способом передать сообщение об ошибке . Это критерий доступности.

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

Восстановление после ошибок: написание удобных для пользователя сообщений об ошибках

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

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

Вы не робот, как и ваши пользователи

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

• Никогда не показывайте необработанное сообщение об ошибке, например «Произошла ошибка типа 2393. Серверу не удалось завершить операцию». Вместо этого объясните, что произошло человеческим языком и почему это произошло .
• Никогда не показывать тупиковое сообщение об ошибке, например «Произошла ошибка». Вместо этого предложите способы устранения ошибки . Напишите действенный текст.
• Никогда не показывайте расплывчатое сообщение об ошибке, например «Не удалось найти сервер с указанным именем хоста», с кнопкой «Повторить попытку». Вместо этого сделайте сообщения об ошибках информативными и последовательными . Пожалуйста, не говорите, как робот.
• Не думайте, что люди знают контекст сообщения. Ваши пользователи не разбираются в технологиях. Вместо этого объясните им простым языком, без технического жаргона, как устранить эту ошибку .

Остерегайтесь языка, который вы используете в сообщениях

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

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

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

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

Чтобы помочь вам лучше написать сообщение об ошибке, я предлагаю вам прочитать следующее:

• «Контрольный список микрокопий из 6 пунктов для продуктовых команд без UX-райтеров»
• «Искусство сообщения об ошибке: четкий и полезный текст на случай, если что-то пойдет не так»

Время отправить форму

Пользователь заполнил форму, ошибок больше нет, все выглядит хорошо. Наконец пришло время отправить форму!

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

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

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

Если вам интересно, должна ли кнопка подтверждения появляться до или после кнопки отмены, я тоже (и многие другие люди). Если вы создаете нативное приложение, придерживайтесь рекомендаций ОС. Это стало особенно забавно, так как Android изменил положение кнопок в своей четвертой версии. В Интернете это сложнее, потому что нет реальных руководств. Независимо от ОС, вот несколько общих рекомендаций по кнопкам отправки, оптимизированным для мобильных устройств:

• Дайте призыву к действию описательные, действенные глаголы.
• Обеспечьте визуальную обратную связь, когда пользователь коснется ее.
• Если у вас есть две кнопки, выделите главное действие .
• Если вы не работаете над очень конкретной корпоративной формой бэк-офиса (в этом случае у вас будет много проблем с оптимизацией для мобильных устройств), избегайте кнопки сброса . Пользователи могут спутать ее с кнопкой отправки и случайно потерять все свои данные.

Заключение

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

Кроме того, проведите регрессионное и автоматизированное функциональное тестирование — опять же, на реальных устройствах. Мобильного эмулятора Chrome недостаточно для тестирования сенсорных форм. Я говорю это, потому что я запустил веб-сайт электронной коммерции с формой поиска, которая не работала на мобильных устройствах. Мы только проводили автоматизированное тестирование с использованием эмулятора. Вот что произошло. Форма поиска была скрыта под значком поиска. Вы могли нажать на кнопку, которая открыла окно с полем поиска. Он работал, эмулируя наведение мыши как событие касания. Мы протестировали нажатие на кнопку, и коробка открылась. Никто не пытался запустить поиск. Таким образом, никто (даже клиент) не видел, что поле поиска исчезало, как только пользователи пытались с ним взаимодействовать. Что случилось? Когда элемент ввода получил фокус, кнопка потеряла состояние наведения и закрыла блок с полем. Автоматическое тестирование не смогло это обнаружить, потому что входные данные не теряли фокус. Итак, мы запустили интернет-магазин без функции поиска на мобильных устройствах. Не супер опыт.

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