Как должна вести себя валидация

Question

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

Пример. Представьте себе форму, в которой можно ввести число от 0 до 50. Пользователь вводит 40. Все хорошо. Но затем пользователь входит и меняет его на 59.

Очевидно, ИМХО приложение должно сообщить ему о своей ошибке как можно скорее. Но что делать со значениями? Я думаю, что должен быть путь назад к 40 как легкий путь к действительному состоянию, но я не уверен, когда и как его вернуть: на потерянном фокусе? Только на специальную клавишу / нажатие кнопки?

Что ты думаешь?

Изменить: Я полностью согласен с первыми двумя ответами: автоматическое изменение ввода - плохая идея. Тем не менее, я хотел бы сохранить доступным значение «последнее действительное» ... Может быть, чистая функция UnDo будет в фокусе?

Answer 1

Подход, который я использую для проверки полей, довольно прост:

Ты не должен сбрасывать пользовательский ввод

Если введенная пользователем запись недействительна, пометьте ее как таковую - но не изменяйте значение.

Причина, по которой вы стоите, проста - последовательность.

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

Теперь пользователь хочет ввести совершенно новый диапазон.

Если ваша система немедленно отбрасывает недействительные записи, вы заставляете своего пользователя вести себя иначе. Для ввода более раннего диапазона дат, дата начала должна быть введена первой; для ввода более позднего диапазона дат, конечная дата должна быть введена первой. Unfriendly.

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

Это также мотивация для динамического отображения проверки (при изменении значений), но не для ограничения перемещения пользователей между полями.

Answer 2

@ Беван Ты праведник.

Если вы хотите увидеть пример того, как это может раздражать, откройте Google Analytics

Это недружественное поведение - именно то, что делает Google Analytics, когда вы пытаетесь сравнить даты, и это сводит меня с ума сумасшествие .

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

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

Answer 3

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

Однако вы действительно хотите заблокировать там своего пользователя? Что если допустимый диапазон составляет 0-50 при выборе опции b, но становится 0-60 при выборе опции c? И пользователь решает сначала изменить ранжированное значение? Тогда пользователь будет очень разочарован тем, что потерял то, что он считает вполне допустимым значением ...

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

Предупредите, что значение недопустимо, и пусть ctrl-Z отменит то, что пользователь добавил туда, может быть более разумным по умолчанию.

Answer 4

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

Основные пункты на мой взгляд: - дать понять, какие допустимые диапазоны и форматы ДО ТОГО, как пользователь вводит данные в форму, с помощью примеров или других подобных индикаторов. - Обязательно укажите обязательные поля четко до подачи. - пользовательские элементы управления, которые ограничивают пользователя для ввода валидных данных - средства выбора даты, элементы управления вращением, только числовые элементы управления, максимальная длина, заданная для текстовых полей и т. д. - дать понять при сбое проверки, какие элементы в форме являются недействительными и почему они недействительны, а не просто глобальное сообщение «данные неверны», особенно если у вас длинная форма со многими полями, которые могут иметь вопросы проверки.