чего не знают веб-разработчики, хотя должны знать / Хабр
Многим известно, что в мобильной версии Safari можно отсканировать свою банковскую карту. Но многие ли разработчики умеют создавать формы, поддерживающие эту возможность?
Готов поспорить, что немногие.
Дело осложняет полное отсутствие документации от Apple по работе этой функции. Но тут есть один момент. Функция сканирования банковских карт является подмножеством автозаполнения — браузерного функционала, давно игнорируемого веб-разработчиками. Понятно, почему они не уделяли ему должного внимания: когда регулярно заполняешь форму тестовыми данными, автозаполнение обычно мешает. Но для наших пользователей это важная функция. В Google выяснили, что при использовании автозаполнения пользователи на 30% быстрее заполняют формы. Так что давайте изучим работу автозаполнения, разберёмся, как создавать формы, поддерживающие кросс-браузерное автозаполнение, и воспользуемся преимуществами новых возможностей наподобие сканирования банковских карт.
До недавнего времени не существовало стандартов, регламентирующих реализацию автозаполнения. В каждом браузере это делалось по-своему, и было доступно очень мало документации, описывающей браузерный механизм определения контента, который нужно внести в то или иное поле.
Несмотря на такую анархию, можно выделить два основных подхода:
1. Поля с заранее заданным автозаполнением
Chrome, Opera и Safari обнаруживают наиболее важные поля в форме и позволяют выбирать, какими данными браузер должен автоматически их заполнить. К примеру, Opera умеет автоматически заполнять адреса и реквизиты банковских карт. Эта функциональность настраивается здесь:
Каждый из трёх браузеров имеет свой набор полей, к которым может применить автозаполнение, но поддержка основных полей платёжных форм реализована практически везде.
Для использования автозаполнения большинству пользователей не придётся обращаться к этим настройкам.
2. Автозаполнение любых полей
Если предыдущий подход можно сравнить со скальпелем, применяемым к заранее выбранным полям, то этот сродни бензопиле, режущей всё на своём пути.
Microsoft Edge и Firefox после отправки заполненной формы сохраняют все введённые данные вместе со значением атрибута name
. Если в будущем браузер встретит поле с таким же атрибутом name
, то к нему будет применено автозаполнение. В дополнение к name
Firefox также обращает внимание на атрибут id
.
У этого подхода есть проблемы с безопасностью и приватностью, поэтому давно поддерживается значение
, отключающее автозаполнение, чтобы браузер не хранил и автоматически не заполнял деликатную информацию.
Какой подход лучше?
Хотя второй подход позволяет работать с большим количеством полей, я как разработчик предпочитаю вариант с заранее заданными полями. Так гораздо проще определять, какую информацию должен заполнять браузер, да и легче настраивать тестовые профили.
Кроме того, при втором подходе вам нужно сначала отправить заполненную форму, чтобы браузер сохранил у себя данные для последующего автозаполнения. Без отправки он не запомнит введённую вами информацию. Также мне неприятно думать, что браузер может хранить реквизиты моей банковской карты в незашифрованном виде, если не определит тип поля.
Разумеется, Microsoft и Mozilla заинтересованы в обеспечении безопасности и приватности, и я уверен, что они предусмотрели какие-то защитные механизмы. Но лично мне гораздо спокойнее видеть в настройках браузера, что он распознаёт и чётко отделяет данные по банковской карте.
Учитывая всё сказанное, я не знаю предпочтений конечных пользователей. Вторая система может применяться шире, но я видел немало обращений в службу поддержки, когда люди пытались убрать данные автозаполнения из истории браузера.
Будет интересно посмотреть, как изменятся Edge и Firefox после того, как начнут поддерживать новый стандарт автозаполнения.
Поведение, которое нужно отслеживать
Иногда браузерам требуется более одного поля определённого типа, чтобы предложить вам варианты автозаполнения. Например, ниже показано, как Safari не станет автоматически заполнять одиночное поле имени владельца банковской карты, но если рядом есть поле для номера карты, то браузер предложит это сделать.
Тем не менее, если присутствует только поле номера карты, Safari предложит его заполнить. Согласно моему опыту, из-за этого поведения браузера бывает непросто тестировать отдельные ситуации с одиночными полями. Однажды во время тестирования я столкнулся с тем, что Opera потребовала наличия трёх полей для применения автозаполнения, но больше мне не удалось воспроизвести такое поведение.
Если ваша форма создана с поддержкой автозаполнения (об этом ниже), то пользователи не должны встречаться с такими ситуациями. Я просто упоминаю это на случай, если вы также встретите подобные странности в процессе отладки и тестирования автозаполнения.
К счастью, ситуация с автозаполнением улучшается. Недавно в HTML5 был расширен атрибут autocomplete
, подсказывающий браузеру, какие данные нужно вводить в разные поля. Этот атрибут существует уже несколько лет и сначала мог принимать два значения: on
и off
. По умолчанию autocomplete
имеет значение on
, то есть браузер может сохранять отправленные данные и автоматически заполнять поля. Но для некоторых полей автозаполнение нежелательно. В этом случае атрибуту autocomplete
можно присвоить значение off
, говорящее браузеру, что это поле заполнять не надо.
Недавно были добавлены новые значения атрибута — autofill detail tokens. Эти токены помогают браузеру понять, какая информация нужна для заполнения поля.
Один из типов токенов называется autofill field names (наименования полей автозаполнения). Они говорят браузеру, какой тип информации вводится в поле. К примеру, один из токенов этого типа —
organization
. Вот что о нём сказано в спецификации HTML5:
Наименование компании, относящееся к человеку, адресу или контактной информации в других полях, связанных с этим полем.
Пример поля с автоматическим заполнением названия организации будет выглядеть так:
<input type="text" name="foo" autocomplete="organization">
В спецификации HTML5 есть огромная таблица, где перечислены все 53 возможных наименования поля автозаполнения, указано их назначение и типы инпутов, с которыми их можно использовать.
Это простейший вид автозаполнения, но оно становится мощнее и сложнее.
Доставка и биллинг
Значением атрибута autocomplete
является разделённый пробелами список токенов. К примеру, если вы хотите собрать данные для доставки товара, то перед значением атрибута нужно добавить токен shipping
:
<textarea name="shipping-address" autocomplete="shipping street-address"></textarea> <input type="text" name="shipping-city" autocomplete="shipping address-level2"> <input type="text" name="shipping-state" autocomplete="shipping address-level1"> <input type="text" name="shipping-country" autocomplete="shipping country-name"> <input type="text" name="shipping-postal-code" autocomplete="shipping postal-code">
Токен billing
работает точно так же, как shipping
.
Телефоны, электронная почта и ники в мессенджерах
Для номеров телефонов, адресов электронных почт и ников в мессенджерах используется другой вариант токена. Для таких случаев предусмотрен опциональный токен, обозначающий, что в поле нужно ввести номер домашнего (home
), рабочего (work
), мобильного (mobile
) телефона, факса (fax
) или пейджера (pager
).
Например:
<input type="tel" name="home-phone" autocomplete="home tel"> <input type="tel" name="work-phone" autocomplete="work tel"> <input type="email" name="home-email" autocomplete="home email"> <input type="url" name="chat" autocomplete="home impp">
Общие и уточняющие наименования полей автозаполнения
Для многих типов информации в спецификации определены общие (broad) и уточняющие (narrow) наименования полей автозаполнения. Скажем, в дополнение к единственному полю для ввода номера телефона tel
можно использовать:
tel-country-code
tel-national
tel-area-code
tel-local
tel-local-prefix
tel-local-suffix
tel-extension
Авторы спецификации поощряют нас как можно чаще применять общие наименования:
В целом авторам рекомендуется использовать общие наименования, а не уточняющие, поскольку последние навязывают западные стандарты. Например, в ряде стран принято сначала писать имя, а потом фамилию, в то время как во многих других странах принято писать наоборот — сначала фамилию, потом имя. Также немало стран, где используется одно лишь имя (мононим). Поэтому использование одного поля ввода является более гибким подходом.
Я согласен с этой рекомендацией. С практической точки зрения это означает, что важно уделять внимание таблице значений и выбирать правильное наименование для каждого поля.
Разделы (Sections)
Последним свойством новых токенов атрибута autocomplete
является возможность назначать групповым полям произвольные разделы. Он определяется с помощью токена, начинающегося с section-
<fieldset> <legend>Ship the blue gift to...</legend> <label> Address: <input name="bc" autocomplete="section-blue shipping street-address"> </label> <label> City: <input name="bc" autocomplete="section-blue shipping address-level2"> </label> <label> Postal Code: <input name="bp" autocomplete="section-blue shipping postal-code"> </label> </fieldset> <fieldset> <legend>Ship the red gift to...</legend> <label> Address: <input name="ra" autocomplete="section-red shipping street-address"> </label> <label> City: <input name="rc" autocomplete="section-red shipping address-level2"> </label> <label> Postal Code: <input name="rp" autocomplete="section-red shipping postal-code"> </label> </fieldset>
Все токены
Итак, теперь у нас есть гораздо более сложный набор токенов для атрибута autocomplete
. И здесь важен порядок следования токенов.
Во-первых, вы используете либо значения on
и off
, либо наименования полей автозаполнения — одновременно и то и другое нельзя.
При использовании токенов автозаполнения они должны следовать в таком порядке:
[section-](optional) [shipping|billing](optional) [home|work|mobile|fax|pager](optional) [autofill field name]
Помните, что токены [home|work|mobile|fax|pager]
применяются только для полей ввода номеров телефонов, адресов электронных почт и ников.
Самый длинный из возможных наборов токенов автозаполнения может выглядеть так:
<label for="foo">Mobile phone for delivery</label> <input type="text" name="foo" autocomplete="section-red shipping mobile tel">
Боюсь, что нет. Я лелею надежду, что в конце концов все браузеры будут поддерживать расширенный стандарт автозаполнения, но пока это не так. Я протестировал мобильные и настольные версии браузеров, чтобы выяснить текущую ситуацию с поддержкой атрибутов. Вот результаты:
Браузер | Версия | ОС | ID | Name | Autocomplete |
---|---|---|---|---|---|
Chrome | 50 | OS X 10.11.4 | Нет | Да | Да |
Opera | 35 | OS X 10.11.4 | Нет | Да | Да |
Firefox | 46 | OS X 10.![]() |
Да | Да | Нет |
Edge | 25 | Windows 10 | Нет | Да | Нет |
Safari | 9.1 | OS X 10.11.4 | Частично | Частично | Частично |
Safari | 9 | iOS 9.3.1 | Частично | Частично | Частично |
До сих пор только Chrome и Opera явным образом поддерживают новые возможности автозаполнения. В Safari, судя по всему, реализована частичная поддержка, но из-за отсутствия документации я не могу сказать, сделано ли это намеренно, или в случае с autocomplete
, name
и другими атрибутами просто осуществляется поиск с помощью регулярных выражений.
С момента появления в iOS 8 функции сканирования банковских карт веб-разработчики занимаются гаданием на кофейной гуще, стараясь определить, какую комбинацию признаков ищет Safari. Кто-то считает, что в атрибуте name нужно иметь определённые значения. Другие обнаружили, что используются значения в ID. Кажется, даже лейбл имеет значение:
Поле для имени владельца карты особенно хитрое. Мы долго игрались с разными ID и почти сдались. Нам не удалось вычислить ID, который заставил бы Card Scan заполнить реквизиты. После многочисленных разочарований мы наконец-то обнаружили, что всё дело в содержании соответствующего элемента label. Как только мы установили лейбл «Name on card», всё волшебным образом заработало.
Я провёл немало тестов и до сих пор не могу с уверенностью утверждать, что полностью разобрался в работе Safari. Тем не менее я всё же пришёл к нескольким основным заключениям:
Autocomplete поддерживается в полях ввода контактов и адреса
Safari распознаёт созданную мной форму, содержащую только атрибуты autocomplete. Как только я начинаю писать в первом поле, браузер предлагает заполнить форму моими контактными данными.
Всё работает, как и должно, но нужно сделать пару пояснений.
Во-первых, неясно, какая информация используется Safari для принятия решения об автозаполнении моих контактов из адресной книги Mac’a. Здесь указана моя должность, а название компании — нет.
Во-вторых, браузер не предлагает на выбор варианты для заполнения. В моих контактах указаны домашний и рабочий адреса, и Safari заполняет только домашний. Так что мне не повезёт, если я захочу заказать доставку в офис.
Автозаполнение платёжных форм работает совершенно ненадёжно
Поведение Safari в корне меняется, когда дело доходит до полей платёжных реквизитов. Атрибут autocomplete
игнорируется. Вместо него браузер использует какую-то волшебную эвристику. А поскольку я не маг из Apple, то мне было трудно распознать, что же на самом деле происходит:
Здесь показано, как я отредактировал названия двух полей. В обоих случаях были указаны autocomplete
, name
и id
, чтобы Safari было легче идентифицировать поля. Тем не менее он их не распознавал до тех пор, пока я не использовал в качестве лейблов
Name on Card
и Credit Card Number
. Как уже упоминалось, для активации автозаполнения Safari нужно больше одного поля. Затем я попробовал изменить лейбл на CCNumber, автозаполнение продолжало работать. А вот с подписью CC Number всё сломалось.
Список значений, по которым Safari выполняет поиск, нигде не опубликован. К счастью, Жак Карон смог извлечь этот список строковых значений из эмулятора iOS:
- card number
- cardnumber
- cardnum
- ccnum
- ccnumber
- cc num
- creditcardnumber
- credit card number
- newcreditcardnumber
- new credit card
- creditcardno
- credit card no
- card#
- card #
- cvc2
- cvv2
- ccv2
- security code
- card verification
- name on credit card
- name on card
- nameoncard
- cardholder
- card holder
- name des karteninhabers
- card type
- cardtype
- cc type
- cctype
- payment type
- expiration date
- expirationdate
- expdate
- month
- date m
- date mo
- year
- date y
- date yr
Согласно моему опыту, в обоих случаях:
<input type="text" name="nameoncard"> <input type="text" name="ccnumber">
и
<label for="foo">Name on Card</label> <input type="text" name="foo"> <label for="bar">Credit Card Number</label> <input type="text" name="bar">
срабатывает автозаполнение в Safari и функция сканирования банковской карты в iOS. Но если поместить те же значения в атрибут
autocomplete
, то работать не будет.
Учитывая всё вышесказанное — действительно ли можно создать форму, поддерживающую автозаполнение в разных браузерах? Я думаю, да.
По крайней мере, можно очень близко подойти к этой цели, выполнив четыре шага:
1. Добавьте атрибуты autocomplete
Это будущее автозаполнения. Если браузеры не распознают значения, то они их игнорируют. Это отличный пример прогрессивного улучшения.
2. Используйте для атрибутов name стандартные значения
При реализации автозаполнения в Firefox и Edge вам остаётся надеяться, что выбранные вами значения для атрибута name
совпадают с теми, которые используют другие разработчики на своих сайтах. Для этого можно проанализировать популярные сайты и посмотреть, какие там значения. Или можно взять те же значения, что и в атрибуте autocomplete, в надежде, что чем больше веб-разработчиков познакомятся со стандартами, тем чаще будут использовать для своих полей те же наименования.
К сожалению, невозможно гарантировать, что пользователи Firefox и Edge ранее посещали форму, использующую те же самые значения name
, что и в вашей форме.
3. Добавьте значения name и/или label в соответствии с используемым в Safari списком
С помощью извлечённого Жаком Кароном списка вы можете изменить значения атрибута name
или элемента label
, чтобы они соответствовали ожиданиям Safari.
4. Внесите автозаполнение в ваш план тестирования
Недавно я попросил у своих слушателей поднять руки, у кого в плане тестирования есть автозаполнение. Ни у кого не было. Я работаю в веб-разработке с 1996 года и до сих пор не встретил тех, у кого в плане тестирования было бы автозаполнение. Наверное, это какая-то слепая зона разработчиков и дизайнеров. Тем не менее крайне важно тестировать эту функциональность, чтобы удостовериться в её надёжной работе.
Вот пример формы, поддерживающей автозаполнение в Chrome, Safari, Opera, Firefox и Edge:
<form method="post"> <label for="name">Name</label> <input type="text" name="name" autocomplete="name"> <label for="jobtitle">Job Title</label> <input type="text" name="jobtitle" autocomplete="organization-title"> <label for="company">Organization</label> <input type="text" name="company" autocomplete="organization"> <label for="tel">Telephone Number</label> <input type="tel" name="tel" autocomplete="home tel"> <label for="email">Email</label> <input type="email" name="email" autocomplete="home email"> <h5>Shipping Address</h5> <label for="address">Street Address</label> <textarea name="address" rows="3" autocomplete="shipping street-address"></textarea> <label for="address-level2">City (Address Level 2)</label> <input type="text" name="city" autocomplete="shipping address-level2"> <label for="state">State/Province (Address Level 1)</label> <input type="text" name="state" autocomplete="shipping address-level1"> <label for="country-name">Country Name</label> <input type="text" name="country-name" autocomplete="shipping country-name"> <label for="postal-code">Postal Code</label> <input type="text" name="postal-code" autocomplete="shipping postal-code"> <h5>Do not use a real card</h5> <label for="nameoncard">Name on Card</label> <input type="text" name="nameoncard" autocomplete="cc-name"> <label for="ccnumber">Credit Card Number</label> <input type="text" name="ccnumber" autocomplete="cc-number" <label for="cc-exp-month">Expiration Month</label> <input type="number" name="cc-exp-month" autocomplete="cc-exp-month"> <label for="cc-exp-year">Expiration Year</label> <input type="number" name="cc-exp-year" autocomplete="cc-exp-year"> <label for="cvv2">CVV</label> <input type="text" name="cvv2" autocomplete="cc-csc"> <input type="submit" value="Submit" name="submit"> </form>
Чтобы увидеть её работу, вам нужно просмотреть её на CodePen через HTTPS, в противном случае браузер не заполнит реквизиты банковской карты. Я также сделал форму с 53 полями по спецификации autocomplete. Пока что ни один браузер не поддерживает все эти поля.
Разработчики браузеров активно работают над проблемой веб-платежей. Mozilla, Microsoft, Google и Facebook совместно создали Payment Request API. Apple участвует в Web Payments Working Group, где обсуждается и Payment Request API. Так что Apple номинально тоже примкнула к этому проекту.
Ходят слухи, что сервис Apple Pay будет доступен в мобильном вебе к сезону праздничного шоппинга, так что веб-платежи в этот раз могут получить новый импульс.
Возобновление интереса к упрощению процесса оплаты внушает мне надежду, что в ближайшее время улучшится поддержка autofill detail tokens. Эти токены сильно облегчают создание форм, работающих с автозаполнением.
И самое важное — поддержка автозаполнения сделает заполнение форм менее утомительным для наших пользователей, что поспособствует росту продаж в сегменте e-commerce.
UX и HTML5: Поможем пользователю заполнить вашу мобильную форму. 2/4
Это вторая часть в серии статей «UX и HTML5: Поможем пользователю заполнить вашу мобильную форму». Первую часть ищите по ссылке.
По возможности скажите «нет» дропдаунам на мобильных
Дропдауны, или раскрывающиеся списки (элемент выбора HTML) в вебе требуют множества табов и взаимодействий. Поэтому, как сказал Люк Вроблевски, в UI они должны использоваться как крайняя мера. Существует немало других UI компонентов, которые во многих случаях работают лучше раскрывающихся списков.
Такие элементы управления, как сегмент контролы и радио-кнопки представляют собой хорошую альтернативу раскрывающемуся списку, когда нужно показать от двух до четырех вариантов. Зачем прятать варианты в раскрывающийся список, когда можно сразу вывести их на экран? Не забывайте: подобно радио-кнопкам, сегмент контролы являются взаимоисключающими.
Пример сегмент контролов в библиотеке iOnic.
Список стран как раз хороший пример для использования компонента. Раскрывающийся список из более чем ста стран — кошмар взаимодействия на мобильном устройстве. Это ещё ничего, если вы ищете Афганистан (который находится в начале списка) или Зимбабве (в конце списка). А вот если вы ищете Люксембург, придётся поскроллить, чтобы добраться до середины списка: вы будете проскакивать слишком далеко — до буквы М, пытаться вернуться к Л, и так далее.
Длинные раскрывающиеся списки могут быть заменены предиктивными текстовыми полями ввода. Когда пользователь введёт букву Л, интерфейс предложит выбор из 9 стран. Напечатает ещё и Ю — вуаля! — вот и Люксембург. Четыре взаимодействия вместо двух VS. ни много ни мало шесть-семь скроллинг-взаимодействий с раскрывающимся списком.
Длинные раскрывающиеся списки станут кошмаром, когда вы начнете искать, например, Монако. Лучше сработают предиктивные поля ввода.
Вам нужно, чтобы пользователи выбрали дату? Забудьте о разбивке на раскрывающиеся списки для дня, месяца и года, хоть люди и привыкли к такому делению в бумажных формах. Замените многосоставные дропдауны для дня/месяца/года на date picker — эдакий календарь. Input type=date в HTML5 подходит для большинства случаев. Возможно, у вас есть особые нужды, и вы вообще создадите свой собственный элемент для выбора даты в JavaScript, особенно если ваша компания связана с бронированиями (отели, автомобили, самолёты).
Двойной элемент выбора даты, созданный в JavaScript, упрощает выбор даты прибытия и выезда — с минимумом взаимодействий.
В статье «Ещё раз о мобильных дропдаунах» Клаус Шэферс объясняет, как использование элемента выбора даты для дней прибытия и выезда ускоряет взаимодействие на 60%.
Элемент выбора даты с использованием HTML5 или JavaScript — вместо раскрывающегося списка; из статьи «Ещё раз о мобильных дропдаунах».
Давайте остановимся на бизнесе, связанном с бронированием. Предположим, пользователю нужно добавить несколько путешественников в свой маршрут. Вы можете **заменить раскрывающийся список *на *степпер** для настройки количества пассажиров. Степпер — это контрол, позволяющий пользователю увеличивать и уменьшать количество, просто нажимая кнопки + и —. Если нужно добавить шесть человек или меньше, он работает быстрее и более интуитивно. Ниже — пример степпера для выбора гостей в нативном Android-приложении Airbnb, и степпера для добавления пассажиров на вебсайте компании Kayak, оптимизированном для мобильных устройств.
Степпер для выбора гостей в нативном Android-приложении Airbnb, и степпер для добавления пассажиров на вебсайте Kayak, оптимизированном для мобильных устройств.
Последняя альтернатива дропдауну — подраздел со списком (list view) — компонент list view. Варианты представлены списком во вложенном компоненте (subview) — например, как радио-кнопки. Так работает большинство настроек Android.
В нашем приложении для мониторинга, когда пользователь кликает на «Уведомление первого типа», открывается список с вариантами.
Автозаполнение: действуем по-умному
Если вы хотите снизить цену взаимодействия в вашей форме, действуйте с умом. Не запрашивайте у пользователя то, что вы можете автоматически определить или угадать на основе остальной информации, которую пользователи уже вам оставили. Автозаполняйте (autocomplete) настолько, насколько возможно.
Места и адреса
Если пользователь ищет какую-то локацию, или ему нужно ввести адрес, вы можете предложить ему в помощь автозаполнение. Пока он печатает, API заполнит оставшиеся элементы адреса за них. К тому же это помогает снизить количество ошибок.
Вы можете использовать:
- Google Places API
- Algolia Places, который опирается на OpenStreetMap
В демоAlgolia Place показано, как, пока пользователь печатает, Algolia предлагает варианты и может автозаполнить (autocomplete) поле.
Во Франции и во многих других странах можно «отгадать» город по коду региона. Поэтому, если французский пользователь вводит код местности, вы можете автоматически заполнить или как минимум предложить город. Моя страна — Люксембург — маленькая (не смейтесь надо мной). Мой код региона напрямую связан с моей улицей. Поэтому, если я введу свой код региона, форма должна даже уметь предложить мне мою улицу.
Кредитные карты
Другая сфера, где автозаполнение легко применимо — банковские карты. Вам не нужно спрашивать у пользователя тип платёжной системы, потому что вы можете автоматически определить это на основе первых введенных цифр. Существует даже библиотека, которая может выполнить работу за вас.
Демо скрипта платежей, который определяет тип платёжной системы.
Использование автозаполнения HTML5
Атрибут автозаполнения HTML (autocomplete) умеет заполнять поля на основе ранее введенных пользователем данных. Этот атрибут может принимать значения on и off. Несколько умных людей уже начали работу над спецификацией, которая сделает его более мощным и расширит атрибут автозаполнения для полей форм. У WHATWG тоже есть интересный список.
Chrome и некоторые другие мобильные браузеры уже поддерживают кое-что из расширенных параметров для кредитных карт и имён. Это означает, что пользователи могут автоматически заполнять формы со своими именами и данными кредитных карт, которые они используют на других вебсайтах.
Автозаполнение помогает пользователям быстрее совершить чекаут (Источник: Google Developers)
Короче говоря, когда вам нужно выбирать между разными системами, посчитайте количество взаимодействий, которые понадобится совершить в каждой из них.
Последний шаг на нашем пути к лучшим мобильным формам — обработка ошибок. Мы можем попытаться снизить их количество, чтобы облегчить когнитивную нагрузку пользователей. Также мы можем помочь им оправиться от ошибок, потому что каким бы хорошим ни был дизайн вашей формы, ошибки всё равно случаются.
Избегаем ошибок при заполнении формы
«Лучше предотвращать, чем лечить», — любила повторять моя мама. Это справедливо и в отношении дизайна форм: предотвратите возможные ошибки, и UX ваших мобильных форм заметно улучшится.
Четко обозначьте ограничения формата
«Будьте консервативны в том, что вы делаете сами. Будьте либеральны по отношению к тому, что вы принимаете от других». Этот принцип сбалансированности можно применить и к полям форм. По возможности разрешите пользователям вводить данные в любом формате. Если вы считаете, что нужно ограничивать пользователей в том, что именно они могут ввести в поле, сначала спросите себя «зачем?». В сфере UX существует методика под названием «три вопроса «зачем»?». Если ответ звучит как «потому что база данных бла бла бла», пора что-то менять. К примеру, зачем вы запрещаете специальные символы вроде é, à и ö в поле ввода имени? Я написала статью, объясняющую, как формы бывают несправедливы ко мне, когда я пытаюсь ввести своё имя пользователя — “Stéphanie”. И я всё ещё не нашла достойную причину, почему это невозможно (помимо аргументов о базе данных).
Если у вас есть веские причины требовать определенный формат от пользователей, обозначьте это сразу. Можно использовать плейсхолдеры HTML5, чтобы подсказать пользователям, как именно должны выглядеть данные, но опять же, будьте с ними осторожны. Ещё можно использовать все варианты подписей к полям, которые мы рассматривали в предыдущей части этой серии статей. В конце концов, есть маска для поля ввода, которая поможет пользователю ввести данные в правильном формате.
Выделяем обязательные для заполнения поля (и необязательные тоже)
Не ждите, когда пользователь отправит вам наполовину заполненную форму — заранее расскажите ему об обязательных для заполнения полях. Если поле обязательно для заполнения, пользователи должны знать об этом. Выделение обязательных полей звездочкой (*) и сопровождение их поясняющими подписями уже стало стандартным паттерном для форм. Плюс в том, что это не занимает много места. Минус в том, что у такого обозначения нет семантической ценности, что может вызвать проблемы с доступностью, если код написан некачественно и вы полагаетесь на то, как люди привыкли взаимодействовать с формами.
Вместо этого вы можете четко обозначить разновидности полей фразами «обязательно для заполнения» и «необязательно». Как Институт Бэймарда, так и Люк Вроблевски с этим согласны. Это помогает избежать неоднозначности насчет длинных форм в мобильной версии — когда пролистываешь форму, переходишь к чему-то другому, а потом возвращаешься назад и не помнишь, были ли обязательные поля отмечены звездочкой или чем-либо еще.
Форма с отметками как для обязательных, так и необязательных для заполнения полей.
В конечном счете, решение о том, как выделять эти поля, будет зависеть от дизайна и длины поля, а также общего контекста. Лучший способ проверить, правильное ли решение вы приняли — протестировать форму.
Задумайтесь о дефолтных значениях
Будьте осторожнее с вариантами, которые выбираются в формах по умолчанию. Когда я отправляла резюме для своего прошлого места работы, нужно было заполнить форму с информацией. Семейное положение было необязательным для заполнения полем. И первым вариантом в дропдауне стояло «в разводе» — то есть это был вариант по умолчанию. Поэтому я могла не отвечать (поле-то необязательное) и уверить систему, что я разведена, либо исправить это и раскрыть свое настоящее семейное положение, даже если я этого не хотела бы. Будьте осторожнее и с половой принадлежностью. Опять же, оставьте вариант для людей, которые не хотят раскрывать её; уточните, зачем вам эта информация, а еще лучше попросите выбрать обращение или местоимение, или не спрашивайте об этом вообще, если это не так уж необходимо. Если вам интересна эта тема, я рекомендую почитать «Дизайн форм для гендерных различий и гендерной инклюзивности». И если гендер не обязателен для заполнения, не настраивайте автозаполнение первого варианта из списка, иначе люди не смогут отменить изначальное положение радио-кнопки и оставить за собой право не отвечать на вопрос.
Как лучше: оставить ответ по умолчанию и солгать, или ввести правдивую информацию, даже если я не хочу?
С другой стороны, дефолтные настройки, выбранные с умом, могут помочь пользователям избежать ошибок при заполнении формы. Вы ведь не герой сериала «Доктор Кто»? В таком случае у вас нет возможности забронировать номер в отеле в прошлом — и Booking.com понимает это. Когда вы открываете календарь на этом сайте, дата по умолчанию устанавливается на текущем дне и вы не можете выбрать уже прошедшую дату. А при выборе даты возвращения, система по умолчанию выбирает день, следующий за заездом.
Умные настройки по умолчанию Booking.com помогают пользователям избежать ошибок. Вы не можете выбрать уже прошедшую дату или дату перед вашим приездом в город.
Меньше боли с паролями
Я уже писала об аутентификации без использования паролей, но этот метод подходит не всегда. Рано или поздно пользователям придется создать пароль и вводить его в мобильной форме. И чаще всего UX просто отстойный. Вот несколько идей, которые помогут улучшить положение вещей и избежать ошибок.
- Создание аккаунта
Не буду вдаваться в подробности, какой именно пароль вы должны требовать и из какого количества символов он должен состоять — в интернете полно статей на эту тему — просто определитесь насчет своих критериев к паролям. Будьте проактивны, а не реактивны, когда пользователи создают аккаунт. Ради святого Ктулху, не заставляйте людей гадать. Ознакомьте пользователей со своими требованиями к паролям заранее.
Сегодня множество вебсайтов показывают свою оценку длины вашего пароля, сообщая в режиме реального времени, если чего-то не хватает. Это очень любопытный и прекрасный паттерн. KLM использует его в своей форме регистрации.
Для примера: форма регистрации KLM
Но и у такого дизайна всё ещё есть немало проблем:
- Они не сразу показывают пользователям критерии пароля.
Если пользователи хотят придумать пароль (например, используя генератор паролей), то они вынуждены сначала наугад ввести что-то в поле, чтобы увидеть критерии для создания пароля.
- Они ограничивают длину пароля до 12 символов, но никогда не сообщают пользователю, сколько именно символов осталось. Конечно, давайте добавим «подсчёт точек» к когнитивной нагрузке создания пароля, который должен соответствовать стóльким критериям. После 12 символов вы можете продолжать печатать и ничего не будет происходить.
- Что происходит, когда вы доходите до лимита в 12 символов, а пароль всё ещё не соответствует всем критериям? Со мной такое случалось. Ну, тогда вам нужно стереть весь пароль и начать заново.
- Наконец, вы обязаны напечатать пароль дважды. И как же пользователь должен запомнить и снова напечатать только что придуманный пароль под всеми этими критериями, да ещё и подсчитывая точки?
- Возвращаемся к 1 пункту и создаём пароль с помощью генератора.
Если бы KLM хотели сделать форму лучше, они могли бы предоставить пользователю опцию «показать/скрыть пароль». Сделав это, они уже могли бы и не требовать вводить пароль дважды. Пользователи могли бы визуально проверить, правильно ли они напечатали желаемый пароль.
TransferWise не решил мою первую проблему из списка, но я хотя бы могу посмотреть на пароль, когда его печатаю.
- Во время входа
В форме входа опция «показать/скрыть пароль» неимоверно улучшила бы UX.
Кнопка «показать/скрыть пароль» в форме.
У Amazon есть интересная история развития поля введения пароля в форме входа. Сначала у них была версия, в которой вы не могли видеть свой пароль. Следующая итерация позволяла пользователям сделать пароль видимым. Затем пароль становился видимым по умолчанию, и вы могли его скрыть. Так это выглядело в 2015 году.
Показ пароля на экране входа, Люк Вроблевски, 2015
Amazon протестировал последнюю версию и 60% людей заподозрили неладное. Поэтому они заменили невыбранный чекбокс «скрыть пароль» на выбранный «показать пароль». В этом случае пароль показывается мелким шрифтом под полем, когда пользователь печатает. Так это выглядело на момент написания этой статьи:
Функционал: как показывается и скрывается пароль на Amazon.
Как видите, всегда есть что улучшить.
Встроенная валидация
Если вы знакомы с основами юзабилити, вы можете знать гештальт-принцип близости. На мобильных устройствах лучше не выводить сводку ошибок наверх страницы вне контекстуальной информации, когда пользователь уже нажал кнопку «отправить».
Наоборот, сообщения об ошибках должны располагаться вблизи самих ошибок.
Пример встроенной валидации.
Валидация в режиме реального времени
А ещё не обязательно ждать, пока пользователи нажмут на кнопку «отправить». Вы можете оценивать правильность поля и давать фидбек, пока пользователь находится в процессе заполнения
Несколько советов:
- Как я уже говорила, поле для пароля выиграло бы от проверки в режиме реального времени и отображения фидбэка с каждым нажатием клавиши.
- В режиме реального времени можно проверять и логин во время создания аккаунта — чтобы убедиться, что имя не заняты. Twitter хорошо с этим справляется.
- Не настраивайте валидацию на каждый новый символ. Подождите, пока пользователь закончит печатать. (Используйте blur в JavaScript для веб-форм, либо просто подождите пару секунд, чтобы определить неактивность.)
Примечание: *Михаль Коньевич (Mihael Konjević) написал прекрасную статью «Inline валидация в формах: создаем опыт». Он объясняет концепцию «награждайте раньше, наказывайте позже».
«Если пользователь вводит допустимые данные в поле, запускайте проверку после ввода данных».
«Если пользователь печатает недопустимые данные в поле, запускайте проверку во время ввода данных».
Пример от Keechma на основе статьи.
Цвет имеет значение
Я утверждаю, что цвет имеет значение, не потому, что сейчас мои волосы покрашены одновременно в рыжий, розовый и фиолетовый цвет. Цвет действительно имеет значение в дизайне форм.
Существуют некоторые конвенции насчёт веба, которые не стоит нарушать. Люди, у которых нет проблем с восприятием цвета, знают, что красный цвет сигнализирует об ошибках, желтый используется для предупреждений, а зеленый почти всегда — для подтверждения или как сигнал об успешности процесса. Лучше придерживаться этой устоявшейся схемы. Между прочим, красный может вызывать у людей беспокойство. Пользователь может подумать, что он допустил какую-то серьезную ошибку. Оранжевый или желтый цвет в сообщении об ошибке вызовет меньше паники. Проблема оранжевого и желтого в том, что для них сложно подобрать оттенки, доступные для людей с нарушениями восприятия цвета.
Цвета имеют различные значения в разных странах и культурах. Будьте с этим аккуратнее.
Кстати о нарушениях восприятия цвета: цвет не должен быть единственным способом показать сообщение об ошибке. Это критерий доступности.
В примере ниже слева вы видите поле с ошибкой в оранжевом цвете, а исправленное поле меняет цвет на зеленый. Я использовала инструмент проверки на цветовую доступность, чтобы проверить скриншот посередине: там уже нельзя отличить серую дефолтную обводку от зеленой. Добавление нескольких иконок на последнем скриншоте делает сообщения об ошибке доступными для людей с нарушениями восприятия цвета.
Цвет не должен быть единственным способом сообщить об ошибке. Симулятор нарушений восприятия цвета посередине показывает, что обводка зеленого цвета не различима для людей с нарушениями цветовосприятия.
Исправляем ошибки: делаем сообщения об ошибках юзер-френдли
На данном этапе мы сделали всё, что могли, чтобы помочь пользователям заполнить наши формы без ошибок. Но порой, несмотря на все наши усилия, ошибки случаются. Пришло время понять, как помочь пользователям в их исправлении.
Прежде всего, запомните: не надо захватывать контроль системы. Если проблема не критична, пусть у пользователя будет возможность продолжить взаимодействие с оставшимся интерфейсом настолько, насколько это возможно. Избегайте таких сообщений об ошибках в JavaScript и модалов, которые блокируют пользователя где только можно. И если ваша форма нуждается в каком-то доступе, запрашивайте его в процессе использования. Если доступ заблокирован, не воспринимайте это как ошибку – потому что это не она. Будьте осторожны с текстом, который вы здесь используете.
Вы не робот, равно как и ваши пользователи
Роботы круты, это да. Но вы не робот, и ваши пользователи тоже. И всё же часто сообщения об ошибках пишутся жуть как коряво. Ловите несколько советов о том, как писать человеческие сообщения об ошибках:
- Никогда не выводите сухое сообщение об ошибке типа «Произошла ошибка 2393. Сервер не может завершить операцию». Вместо этого на человеческом языке объясните, что произошло и почему.
- Никогда не используйте тупиковое сообщение типа «Произошла ошибка». Вместо этого предложите пути её разрешения. Напишите текст с конкретными шагами по исправлению.
- Никогда не используйте туманное сообщение вроде «Сервер указанного сайта не может быть найден» с кнопкой «Попробовать снова». Вместо этого сделайте ваше сообщение об ошибке информативным и содержательным. Пожалуйста, не надо писать как робот.
- Не надо надеяться, что люди знают контекст сообщения. Ваши пользователи — не технически подкованные гики. Напишите на простом языке и без технического жаргона, как они могут исправить ошибку.
Примеры нечеловеческих сообщений об ошибках. Брр!
Осторожнее с языком, который вы используете в сообщениях
Что бы вы ни писали, не заставляйте людей чувствовать себя глупыми из-за того, что они допустили ошибку. По возможности откажитесь от негативных слов; они пугают людей и заставляют нервничать. Используйте вежливые, позитивные и утвердительные интонации.
И не вините пользователей в ошибках; вместо этого обвиняйте систему. Система не затаит обиду, обещаю. Сместите внимание пользователей на то, что система не может произвести действие, и объясните им, как найти решение проблемы.
Маленький трюк: прочитайте своё сообщение вслух. Это поможет вам услышать, звучит ли оно слишком жестко или слишком несерьезно, и так далее.
Помимо этого, вы можете покреативить с сообщениями об ошибках, встроить в них изображения и юмор, чтобы они звучали не так угрожающе. Впрочем, это будет зависеть от образа и тона вашего бренда. Чтобы научиться писать отличные сообщения об ошибках, я рекомендую почитать следующее:
- «Чеклист из шести пунктов для продакт-команд по созданию маленьких текстов без обращения к UX-копирайтерам»
- «Искусство создания сообщений об ошибке: как написать четкий и полезный текст для моментов, когда всё пошло не так»
Время отправлять форму
Итак, пользователь заполнил форму, ошибки исправлены и всё выглядит хорошо. Наконец, пришло время отправлять!
Правило первое: не скрывайте кнопку «отправить». Серьезно! Не знаю, какой умник до этого додумался, но я такое встречала в нескольких формах — кнопка «отправить» появляется только тогда, когда все требуемые поля заполнены без ошибок. Пользователь будет нервничать, гадая: то ли что-то заполнено неправильно, то ли кнопка формы ещё не прогрузилась, то ли вебсайт не в порядке, и мало ли, что ещё.
Если вы хотите, чтобы пользователи не могли нажать на кнопку «отправить», пока не заполнены все обязательные поля или выявлены ошибки, используйте HTML атрибут disabled в вводе данных submit. Когда форма будет проверена и готова для отправки, вам нужно будет снова активировать кнопку с помощью JavaScript.
Не нужно скрывать кнопку «отправить». Вместо этого сделайте её неактивной, пока пользователи не введут всю необходимую информацию.
Если у вас есть первичные и вторичные call to action’ы, используйте цвет, размер и различные стили, чтобы наглядно показать иерархию.
Пример первичной и вторичной кнопки call to action.
Если вы раздумываете, должна ли кнопка подтверждения идти перед или после кнопки отмены — знайте, я (и многие другие люди) тоже. Если вы разрабатываете нативное приложение, придерживайтесь гайдлайнов ОС. Стало особенно весело, когда Android поменял места кнопок в своей четвертой версии. В вебе это сложнее, потому что здесь не существует настоящих гайдлайнов. Независимо от ОС, есть несколько общих советов для кнопки «отправить» в оптимизации для мобильных устройств:
- В кнопках call to action используйте побуждающие к действию глаголы .
- Предоставьте визуальный фидбэк, когда пользователь нажимает кнопку.
- Если у вас две кнопки, сделайте так, чтобы первичное действие выделялось.
- Если вы работаете над формой для вспомогательного корпоративного проекта, у вас будут сложности с оптимизацией для мобильной версии. В любом другом проекте не используйте кнопку «перезагрузить». Пользователи могут перепутать её с кнопкой «отправить» и случайно потерять все свои данные.
Заключение
В этих двух частях я затронула множество маленьких способов прокачать вашу форму и помочь пользователям заполнить её. Некоторые общие гайдлайны и рекомендации для мобильных версий могут не работать в 100% случаев — в этом и подвох рекомендаций. Потому всегда тестируйте свои формы на реальных пользователях и реальных устройствах и адаптируйте гайдлайны под специфические нужды ваших пользователей и опыт.
Еще стоит иногда возвращаться к исходным точкам и автоматизированному функциональному тестированию – опять же, на реальных устройствах. Мобильного эмулятора Chrome будет недостаточно для тестирования форм, оптимизированных для тача. Я пишу об этом, потому что однажды я запустила e-commerce вебсайт с формой поиска, которая не работала в мобильной версии. Мы провели только автоматизированное тестирование с помощью эмулятора. Вот что произошло: форма поиска была спрятана под иконкой поиска, можно было нажать на кнопку, которая открывала окошко с поисковым полем. Это работало, когда мы сымитировали наведение курсора мыши как тач-событие (touch event). Мы протестировали нажатие на кнопку, и окошко открывалось. Никто из нас не попробовал запустить поиск. И поэтому никто (даже заказчик) не увидел, что поисковое поле пропадало, как только пользователь пытался с ним взаимодействовать. Что случилось? Когда фокус становился на элемент ввода, кнопка теряла состояние ховера, поэтому она закрывала контейнер с полем. Автоматизированное тестирование не смогло уловить этот момент, поскольку поле ввода не теряло фокус. Так мы и запустили этот сайт без функции поиска в мобильной версии.
Опыт так себе, мягко говоря.
В следующих частях нашей серии статей рассмотрим более продвинутые методы для мобильных версий. Узнаем, как можно использовать крутые штуки из HTML5 для форматирования полей и как использовать возможности мобильных устройств для поднятия UX на уровень выше.
Третью часть из серии статей вы найдёте по ссылке. Приятного чтения 🙂
HTML-атрибут: автозаполнение — HTML: язык гипертекстовой разметки
Атрибут HTML автозаполнения
позволяет веб-разработчикам указать, какое разрешение (если таковое имеется) должен предоставить пользовательский агент для предоставления автоматической помощи при заполнении значений полей формы, а также рекомендации для браузера, как к типу информации, ожидаемой в поле.
Доступно для
элементов, принимающих текстовое или числовое значение в качестве входных данных, элементов,
элемента и
элемента.
Источником предлагаемых значений обычно является браузер; обычно значения берутся из прошлых значений, введенных пользователем, но они также могут исходить из предварительно настроенных значений. Например, браузер может разрешить пользователю сохранять свое имя, адрес, номер телефона и адреса электронной почты для целей автозаполнения. Возможно, браузер предлагает возможность сохранять зашифрованную информацию о кредитной карте для автозаполнения после процедуры аутентификации.
Если элемент
,
или
не имеет атрибута autocomplete
, тогда браузеры используют атрибут autocomplete
владельца формы элемента, который является либо
элемент, потомком которого является элемент, или
, чей id
указан атрибутом формы
элемента.
Для получения дополнительной информации см. атрибут автозаполнения
в
.
Примечание: Чтобы обеспечить автозаполнение, пользовательские агенты могут потребовать
/
/
элементов для:
- Иметь
имя и 30004id
атрибут - Быть потомками элемента
- Форма с кнопкой отправки
- »
шт.
» -
Браузер не может автоматически вводить или выбирать значение для этого поля. Возможно, что документ или приложение предоставляет свою собственную функцию автозаполнения или что из соображений безопасности требуется, чтобы значение поля не вводилось автоматически.
Примечание: В большинстве современных браузеров установка
autocomplete
на «off
» не помешает диспетчеру паролей запрашивать у пользователя, хотят ли они сохранить информацию об имени пользователя и пароле, или автоматически заполнять эти значения в форма входа на сайт.См. атрибут автозаполнения и поля входа.
- «
на
» -
Браузер может автоматически завершать ввод. Никаких указаний относительно типа данных, ожидаемых в поле, не предоставляется, поэтому браузер может использовать свое собственное суждение.
- »
имя
» -
Поле ожидает, что значение будет полным именем человека. Обычно предпочтительнее использовать «
имя
», а не разбивать имя на его компоненты, потому что это позволяет избежать большого разнообразия человеческих имен и их структуры; однако вы можете использовать следующиеавтозаполнение
значений, если вам нужно разбить имя на составляющие:- «
почетный префикс
» -
Префикс или название, например, «миссис», «мистер», «мисс», «мисс», «доктор» или «мадемуазель».
- »
имя
» -
Данное (или «первое») имя.
- »
дополнительное имя
» -
Отчество.
- »
фамилия
» -
Фамилия (или «фамилия»).
- »
почтительный суффикс
» -
Суффикс, такой как «Jr.», «B.Sc.», «PhD.», «MBASW» или «IV».
- »
псевдоним
» -
Псевдоним или дескриптор.
- «
- «
электронная почта
» -
Адрес электронной почты.
- «
имя пользователя
» -
Имя пользователя или имя учетной записи.
- »
новый пароль
» -
Новый пароль. При создании новой учетной записи или изменении паролей это следует использовать для поля «Введите новый пароль» или «Подтвердите новый пароль», а не для общего поля «Введите текущий пароль», которое может присутствовать.
Это может использоваться браузером как для предотвращения случайного ввода существующего пароля, так и для помощи в создании безопасного пароля (см. также Предотвращение автозаполнения с помощью autocomplete=»new-password»).
- «
текущий пароль
» -
Текущий пароль пользователя.
- »
одноразовый код
» -
Одноразовый код, используемый для проверки личности пользователя.
- »
Название организации
» -
Должность или должность, которую человек имеет в организации, например «Старший технический писатель», «Президент» или «Помощник командира отряда».
- «
организация
» -
Название компании или организации, например «Acme Widget Company» или «Girl Scouts of America».
- «
адрес
» -
Адрес. Это может быть несколько строк текста, и он должен полностью идентифицировать местоположение адреса на втором административном уровне (обычно это город), но не должен включать название города, почтовый индекс или название страны.
- «
адрес-строка1
«, «адрес-строка2
«, «адрес-строка3
» -
Каждая отдельная строка почтового адреса. Они должны присутствовать только в том случае, если «
улица-адрес
» отсутствует. - »
адрес-уровень4
» -
Самый подробный административный уровень, в адресах которого есть четыре уровня.
- »
адрес-уровень 3
» -
Третий административный уровень, в адресах как минимум с тремя административными уровнями.
- »
адрес-уровень 2
» -
Второй административный уровень, в адресах их не менее двух. В странах с двумя административными уровнями это обычно будет город, поселок, деревня или другой населенный пункт, в котором расположен адрес.
- »
адрес-уровень 1
» -
Первый административный уровень в адресе.
Обычно это провинция, в которой находится адрес. В Соединенных Штатах это будет штат. В Швейцарии кантон. В Соединенном Королевстве почтовый город.
- «
страна
» -
Код страны или территории.
- »
название страны
» -
Название страны или территории.
- «
почтовый индекс
» -
Почтовый индекс (в США это почтовый индекс).
- »
имя копии
» -
Полное имя, напечатанное или связанное с платежным средством, таким как кредитная карта. Использование поля полного имени, как правило, предпочтительнее, чем разбиение имени на части.
- »
cc-имя
» -
Имя (имя), указанное на платежном инструменте, таком как кредитная карта.
- »
cc-дополнительное имя
» -
Отчество, указанное на платежном инструменте или кредитной карте.
- »
копия-фамилия
» -
Фамилия, указанная на кредитной карте.
- »
Номер копии
» -
Номер кредитной карты или другой номер, идентифицирующий способ оплаты, например номер счета.
- »
куб.см
» -
Дата истечения срока действия способа оплаты, обычно в формате «ММ/ГГ» или «ММ/ГГГГ».
- »
cc-exp-month
» -
Месяц, в котором истекает срок действия способа оплаты.
- »
cc-exp-год
» -
Год, в котором истекает срок действия способа оплаты.
- »
куб.см
» -
Защитный код платежного инструмента; на кредитных картах это трехзначный проверочный номер на обратной стороне карты.
- »
куб.см
» -
Тип платежного инструмента (например, «Visa» или «Master Card»).
- »
транзакция-валюта
» -
Валюта, в которой должна осуществляться транзакция.
- »
сумма транзакции
» -
Сумма, указанная в валюте, указанной в »
транзакция-валюта
«, транзакции для платежной формы. - »
язык
» -
Предпочтительный язык, указанный как действительный языковой тег BCP 47.
- »
дн
» -
Дата рождения как полная дата.
- »
дн-день
» -
День месяца даты рождения.
- »
день-месяц
» -
Месяц года даты рождения.
- »
день-год
» -
Год даты рождения.
- »
пол
» -
Гендерная идентичность (например, «Женщина», «Фаафафин», «Хиджра», «Мужчина», «Недвоичный») в виде текста произвольной формы без новой строки.
- «
тел
« -
Полный номер телефона, включая код страны. Если вам нужно разбить номер телефона на его компоненты, вы можете использовать эти значения для этих полей:
- »
тел-код страны
» -
Код страны, например «1» для США, Канады и других регионов Северной Америки и некоторых частей Карибского бассейна.
- «
тел-национальный
» -
Полный номер телефона без компонента кода страны, включая внутренний префикс страны. Для номера телефона «1-855-555-6502» значение этого поля будет «855-555-6502».
- «
тел-код города
» -
Код города с любым внутренним префиксом страны, если это необходимо.
- «
тел. местный
» -
Номер телефона без кода страны или города. Его можно разделить на две части: для телефонных номеров, у которых есть номер станции, а затем номер внутри станции.
Для номера телефона «555-6502» используйте «
tel-local-prefix
«для «555» и «tel-local-suffix
» для «6502».
- »
- »
добавочный телефон
» -
Дополнительный телефонный код в телефонном номере, например номер комнаты или люкса в отеле или добавочный номер офиса в компании.
- »
имп
» -
URL-адрес конечной точки протокола обмена мгновенными сообщениями, например «xmpp:username@example.net».
- «
адрес
» -
URL-адрес, например домашняя страница или адрес веб-сайта компании, в зависимости от контекста других полей в форме.
- »
фото
» -
URL-адрес изображения, представляющего человека, компанию или контактную информацию, указанную в других полях формы.
Более подробную информацию см. в стандарте WHATWG.
Примечание: Автозаполнение 9Атрибут 0004 также определяет, будет ли Firefox — в отличие от других браузеров — сохранять динамическое отключенное состояние и (если применимо) динамическую проверку элемента
автозаполнения значения
, элемента
или всего
при загрузке страницы. . Функция постоянства включена по умолчанию. Установка для атрибута
off
отключает эту функцию. Это работает, даже если атрибут автозаполнения обычно не применяется в силу его
типа
. См. ошибку Firefox 654072.
Четыре поля административного уровня (от address-level1
до address-level4
) описывают адрес с точки зрения повышения уровня точности в стране, в которой находится адрес. Каждая страна имеет свою собственную систему административных уровней и может располагать уровни в разном порядке при написании адресов.
адрес-уровень1
всегда представляет самую широкую административную единицу; это наименее конкретная часть адреса, кроме названия страны.
Гибкость макета формы
Учитывая, что разные страны записывают свой адрес по-разному, каждое поле находится в разных местах в адресе, и даже полностью разный набор и количество полей, может быть полезно, если, когда это возможно, ваш сайт возможность переключаться на макет, ожидаемый вашими пользователями при представлении формы ввода адреса, учитывая страну, в которой находится адрес.
Варианты
Способ использования каждого административного уровня зависит от страны. Ниже приведены некоторые примеры; это не претендует на то, чтобы быть исчерпывающим списком.
США
Типичный домашний адрес в США выглядит так:
432 Куда угодно ул. Примервиль CA 95555
В Соединенных Штатах наименее конкретной частью адреса является штат, в данном случае «CA» (официальное сокращение Почтовой службы США для «Калифорния»). Таким образом address-level1
— это состояние, или «CA» в данном случае.
Второй по значимости частью адреса является город или название поселка, поэтому address-level2
в этом примере адреса — это «Exampleville».
Адреса в США не используют уровни 3 и выше.
Соединенное Королевство
Формы ввода адреса в Великобритании должны содержать один уровень адреса и одну, две или три строки адреса, в зависимости от адреса. Полный адрес будет выглядеть так:
103 улица Фрогмарх Аппер-Ваппинг Винчелси ТН99 8ЗЗ
Уровни адресов:
-
address-level1
: Почтовый город — в данном случае «Winchelsea». -
address-line2
: Населенный пункт — в данном случае «Верхний Уоппинг». -
address-line1
: Данные дома/улицы — "улица Фрогмарх 103".
Почтовый индекс отдельный. Обратите внимание, что на самом деле вы можете использовать только почтовый индекс и адресную строку 1 9.0004 для успешной доставки почты в Великобритании, поэтому они должны быть единственными обязательными пунктами, но обычно люди склонны предоставлять более подробную информацию.
Китай
Китай может использовать до трех административных уровней: провинция, город и район.
6-значный почтовый индекс требуется не всегда, но при поставке он помещается отдельно с этикеткой для ясности. Например:
北京市东城区建国门北大街 8 号华润大厦 17 层 1708 单元 Номер: 100005
Япония
Адрес в Японии обычно пишется одной строкой , в порядке от наименее конкретной части к более конкретной (в порядке, обратном США ). В адресе есть два или три административных уровня. Дополнительную строку можно использовать для отображения названий зданий и номеров комнат. Почтовый индекс указывается отдельно. Например:
〒 381-0000 長野県長野市某町 123
"〒" и следующие семь цифр показывают почтовый индекс.
address-level1
используется для префектур или Токийского мегаполиса; В данном случае это «長野県» (префектура Нагано). address-level2
обычно используется для городов, округов, поселков и деревень; «長野市» (город Нагано) в данном случае. «某町 123» — это адресная строка 1
, которая состоит из имени области и номера участка.
Спецификация |
---|
Стандарт HTML # attr-fe-autocomplete |
загрузка таблиц браузера включена только в BCD. Включите JavaScript для просмотра данных.
-
<вход>
элемент - Элемент
- Элемент
- Элемент
- HTML-формы
- Все глобальные атрибуты
Обнаружили проблему с содержанием этой страницы?
- Отредактируйте страницу на GitHub.
- Сообщить о проблеме с содержимым.
- Посмотреть исходный код на GitHub.
Хотите принять участие?
Узнайте, как внести свой вклад.
Последний раз эта страница была изменена участниками MDN.
Атрибут автозаполнения ввода HTML
❮ Тег HTML
Пример
HTML-форма с включенным автозаполнением (и выключенным для одного поля ввода):
Попробуйте сами »
Определение и использование
Атрибут autocomplete
указывает, должно ли быть включено автозаполнение поля ввода.
Автозаполнение позволяет браузеру прогнозировать значение. Когда пользователь начинает вводить в поле, браузер должен отображать параметры для заполнения поле на основе ранее введенных значений.
Примечание: Атрибут автозаполнения работает с
следующие типы ввода: текст, поиск, URL-адрес, телефон, электронная почта, пароль, средства выбора даты, диапазон и цвет.
Поддержка браузера
Числа в таблице указывают первую версию браузера, полностью поддерживающую атрибут.
Атрибут | |||||
---|---|---|---|---|---|
автозаполнение | 17,0 | 6,0 | 2,0 | 5,1 | 10,0 |
Совет: В некоторых браузерах вам может потребоваться активировать функцию автозаполнения, чтобы это работало
(Посмотрите в разделе «Настройки» в меню браузера).
Синтаксис
Значения атрибутов
Значение | Описание |
---|---|
на | По умолчанию. Указывает, что автозаполнение включено (включено) |
от | Указывает, что автозаполнение отключено (отключено) |
❮ Тег HTML
НАБОР ЦВЕТА
Лучшие учебники
Учебное пособие по HTMLУчебное пособие по CSS
Учебное пособие по JavaScript
How To Tutorial
SQL Tutorial
Python Tutorial
W3.CSS Tutorial
Bootstrap Tutorial
PHP Tutorial
Java Tutorial
C++ Tutorial
jQuery Tutorial
Top References
HTML ReferenceCSS Reference
JavaScript Reference
SQL Reference
Python Reference
W3.CSS Reference
Bootstrap Reference
PHP Reference
HTML Colors
Java Reference
Angular Reference
jQuery Reference
Лучшие примеры
Примеры HTMLПримеры CSS
Примеры JavaScript
Примеры инструкций
Примеры SQL
Примеры Python
Примеры W3.
