Лучшая практика юзабилити для приема номеров с длинными номерами

Question

Пользователь недавно спросил (ОК, жаловался), почему 19-значный номер счета на нашем веб-сайте был разбит на 4 отдельных текстовых поля длиной [5,5,5,4]. Не будучи оригинальным дизайнером, я не мог ответить на этот вопрос, но я всегда полагал, что это было сделано для того, чтобы сохранить качество данных и, возможно, обеспечить лучший пользовательский интерфейс.

Другие более общие примеры включают телефон с кодом города (10 последовательных цифр в сравнении с [3,3,4]) и, конечно, ПЛА (9 цифр в сравнении с [3,2,4])

Это заставило меня интересно существуют ли какие-либо известные стандарты по этой теме? Когда вы разделите свой ID #? В частности, в отношении удобства пользователей и минимизации ошибок ввода данных.

Answer 1

Я знаю, что в этом было какое-то исследование, которое я могу найти на данный момент в статье Википедии по адресу Short-term memory, в частности chunking. Также есть The Magical Number Seven, Plus or Minus Two.

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

Тем не менее, если вы можете сделать интерфейс более удобным для пользователя путем:

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

ИЛИ

• Замена его одним длинным полем, в котором есть некоторая форма «маски ввода» (не уверен, что это выполнимо в простом HTML, но это может быть осуществимо с использованием одной из инфраструктур пользовательского интерфейса), поэтому оно выглядит как "_____ - _____ - _____ - ____" и заканчивается "1235 - 54321 - 12345 - 1234"

Это почти наверняка сделает их счастливее!

Answer 2

Не знаю, о стандартах, но с личной точки зрения:

• Если есть несколько полей, убедитесь, что курсор перемещается к следующему полю один раз в поле полно.
• Если есть только одно поле, разрешите пробелы/тире/все, что будет использоваться в этом поле, потому что вы можете отфильтровать их. Это действительно раздражает, когда сайты/программы заставляют вас вводить даты в формате «dd/mm/yyyy», например, что означает, что день/месяц должен быть дополнен нулями. «23/8/2010» должно быть приемлемым.

Answer 3

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

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

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

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