Проверка в реальном времени, хороший или плохой UX
У меня есть форма регистрации, в которой я сделал проверку в РЕАЛЬНОМ ВРЕМЕНИ, когда пользователь начинает печатать, как вы видите на картинке.
Я не знаю, вредит ли это пользовательскому опыту или нет, а также я не нашел ресурса об этом виде проверки.
Ответы
Цитата с nngroup.com :
7. Не проверяйте поля до завершения ввода
...
Может раздражать появление сообщения об ошибке до того, как будет предоставлена возможность закончить ввод.
Проверка не должна начинаться до завершения ввода
Когда пользователь начинает вводить правильное значение, при наборе не должно появляться никаких ошибок. Ввод считается завершенным, когда
- фокус ввода теряется (навигация на другое поле) или
- форма представляется (например AutoSubmit при нажатии войти) или даже
- после отсутствия ввода в течение некоторого времени (например, через 3 секунды после последнего события ввода).
Отображение ошибок ввода сразу же во время набора текста очень отвлекает ("должно содержать не менее 3 символов" при начале набора) и редко помогает.
Ошибки валидации следует удалять на лету
Когда поле проверено и показывает некоторые ошибки, пользователь хочет, чтобы ошибка исчезла, как только отредактированное значение станет правильным, а не когда он покинет поле или отправит форму (которая, вероятно, будет отключена в любом случае, пока есть ошибки отображается).
Это может быть достигнуто путем удаления всех ошибок из поля, когда оно снова становится грязным (и повторной проверки позже при отправке или потере фокуса), или автоматической повторной проверки поля каждый раз, когда оно изменяется.
Вместо того, чтобы постоянно отображать красное сообщение проверки, когда пользователь не выполнил требования поля, хорошей альтернативой является (1) отображение подсказки, которая сообщает пользователю, что ожидается, и (2) отображение зеленого сообщения «требования выполнены», когда пользователь ввел допустимое значение. Вы можете стать зеленым, как только вход в норму.
Это зависит от типа поля ввода.
- Для поля электронной почты:
Вы не хотите быть слишком нервным. Дайте пользователю завершить ввод адреса электронной почты. Если поле ввода станет красным с текстом ошибки в момент, когда пользователь начинает печатать, это будет раздражать пользователя.
Правильный подход состоит в том, чтобы позволить пользователю закончить ввод, и когда пользователь смещает фокус с этого поля, проверять и показывать, хорошо ли оно выглядит, или выдавать текст исключения, если он есть.
- Для поля имени пользователя и пароля:
Поля имени пользователя и пароля должны быть проверены перед отправкой, потому что они предъявляют самые строгие требования к вводу. Так четко покажите пользователю, что принято, а что нет, в режиме реального времени, когда он начинает печатать.
Ссылка на статьи:
https://designmodo.com/ux-form-validation/
https://uxmovement.com/forms/why-users-make-more-errors-with-instant-inline-validation/
Проверка в реальном времени работает, если вы правильно обрабатываете неполные ответы.
Приведенный пример является плохим пользовательским интерфейсом, потому что "reara" - допустимый способ начать адрес электронной почты. Примером, когда проверка в реальном времени может отклонить неполный ответ, является «reara @@». В этом случае проверка в реальном времени может отклонить его, не дожидаясь завершения.
В общем, вам нужно показать сообщение об ошибке, когда нет дополнительных данных, которые могут сделать ответ действительным. Насколько сложно это обнаружить, зависит от случая к случаю. Если у вас есть словарь, это довольно просто. С регулярными выражениями дело обстоит хуже.
Конечно, полезно иметь хорошие сообщения об ошибках, которые подходят в контексте неполного ввода. Например, «адрес электронной почты должен содержать ровно один знак @».
Если вы не можете обрабатывать неполные ответы, например, потому что всегда можно ввести суффикс, чтобы сделать конкретное поле законным, вам следует дождаться полного ввода, как предлагается в других ответах.
Проверять вживую - это хорошо. Однако такая проверка должна различать два случая:
- ввод, который можно сделать действительным, добавив материал в конце, и
- вход , который может не быть действительным путем добавления материала в конце.
В последнем случае сообщение об ошибке должно появляться немедленно, а в первом случае необходимо дождаться завершения ввода.
Но как отличить одно от другого?
Это немного сложно с учетом текущих инструментов, но если вы пишете свой собственный механизм регулярных выражений (или какой-либо другой конечный автомат для проверки), вы можете добиться этого следующим образом:
- если движок достиг конца регулярного выражения (целевого состояния), было совпадение.
- если движок достиг конца строки , возможно, совпадение произойдет позже.
- если двигатель не сможет достичь ни того, ни другого, совпадения не будет.
Проблема в том, что большинство языков программирования не дают никаких указаний о достижении конца строки. Кроме того, несмотря на то, что это незначительное изменение любого существующего движка регулярных выражений, развертывание собственного, безусловно, выходит за рамки любого проекта дизайна пользовательского интерфейса.
Простой ответ, я думаю, было бы так, что если на странице входа в систему есть 3-4 поля, вполне нормально добавить проверку, когда пользователь нажимает кнопку отправки
Длинные формы, проверка проверки должна запускаться, когда ввод находится в любом другом поле, кроме указанного поля.
Это можно сделать в Javascript
Я написал статью о проблеме с живой валидацией :
Короче говоря: он либо предоставляет обратную связь слишком рано и часто до того, как у пользователя была возможность ввести свой ответ, ЛИБО предоставляет ее слишком поздно, когда пользователь заканчивает вводить свой ответ и сосредотачивается на следующем поле, отвечая на следующий вопрос.
Вместо этого сосредоточьтесь на:
- четкая и краткая этикетка, текст подсказки и сообщения об ошибках
- прощать мелкие ошибки
- позвольте пользователю отправить форму, когда он будет готов
Таким образом, пользователи будут очень редко видеть сообщение об ошибке, а если и увидят, то тогда, когда они ожидают увидеть его.