Давно хотел написать — про валидацию пользовательского ввода. Стоило бы наверное написать статью, но все как-то не до того…
Проблема: диалоги и валидация. Диалоги, или точнее, диалоговые окна, в настоящее время используются в интерфейсе большинства программ. С диалогами связана одна проблема, имеющая отношение к тому что называют ненашим словом «юзабилити».
Пользователь вводит несколько параметров и подтверждает выполнение команды нажатием кнопки (обычно — кнопки ОК). На вводимые значения накладываются ограничения. В простейшем случае одно из полей должно быть непустым, в других случаях правильность (валидность) значения определяется по сложной формуле или зависит от значений других полей. Процесс проверки введенных значений на правильность будем называть валидацией.
Валидация предполагает не только проверку, но и сообщение пользователю о результатах такой проверки. Обычно результат проверки представляется пользователю в виде стандартного окна-сообщения (message box) с кнопкой ОК. Такой подход хоть и является общепринятым, но имеет ряд недостатков.
Во-первых, сообщение обычно говорит только об одном поле и одном значении. А это значит, что пока вы дойдете до результата, вам придется несколько раз нажимать ОК и несколько раз получать сообщения о неправильном значении. Вы не видите всех полей, которые требуется заполнить или исправить — а значит, вам придется узнавать о таких полях, накапливая опыт работы с программой путем проб и ошибок.
Во-вторых, окно сообщения нужно каждый раз закрывать — это неудобно и отнимает время. После закрытия окна нужно найти поле, о котором говорилось в сообщении (даже если фокус переведен на это поле, вы должны найти его глазами), и исправить его так как было сказано — но сообщения вы уже не видите.
В-третьих, многие рядовые пользователи просто ненавидят сообщения об ошибках. Им не нравится, что машина указывает на ошибки человека.
Итак, существующий способ валидации по крайней мере неудобен.
Неудачное решение: ограничение ввода. Иногда данную проблему решают за счет более жестких ограничений при вводе. Например, если в поле вводится число, то все неподходящие символы вообще не вводятся. Для жестко форматированных значений (телефонные номера, почтовые индексы, номера счетов) используется MaskEditControl, который не позволит ввести текст никак иначе кроме как по заданной маске.
Такой подход мне не совсем не нравится — по той причине, что он по сути «замалчивает» проблему — вместо сообщения об ошибке пользователь теперь получает неприятный звук при нажатии «не той» клавиши. А это означает, что снижается само-описательность системы, и как следствие — возможность само-обучения для пользователя.
Единственное что я приемлю в качестве ограничения — ограничение по длине в текстовых полях: ввел текст максимальной длины — не можешь больше вводить. И то только потому что другие решения были бы еще хуже — например, сообщение «вы ввели на 17 символов больше чем допустимо в этом поле»…
Решение: ненавязчивая валидация. Работая над очередным приложением (под VB.NET, несколько лет назад), я пришел к мысли, что с валидацией нужно что-то менять. Основная идея заключалась в том, чтобы отказаться от окон сообщений. Но чем их заменить? Можно было бы снабдить каждый диалог строкой подсказки (status bar), но это изменит стандартный облик диалога и не решит всех проблем.
Другая мысль была в том, чтобы подсвечивать поля, содержащие неправильные значения — например, сменой фона контролов со стандартного на какой-либо другой. Оставалось решить как показывать сообщения. Рассмотрев несколько вариантов, в конце концов я остановился на тултипах (tooltips).
В общем, последние несколько лет я придерживаюсь такой идеологии валидации:
1. Пользователь может вводить в поля все что хочет.
2. Непосредственно при вводе (при изменении значения в поле) выполняется проверка валидности значения в поле. Валидация всего диалога описывается в одном единственном месте сразу для всех контролов диалога. Тем самым, всего в одном месте описываются как ограничения на отдельные поля, так и зависимости между ними.
3. Невалидные поля подсвечиваются светло-красным. Этот цвет — не константа, а вычисляется на основании цветов текущей цветовой схемы.
4. При наведении мыши на невалидное поле появляется тултип с очень коротким описанием проблемы и ограничений.
5. Запрещенные (disabled) и невидимые (hidden/invisible) поля не могут быть невалидными.
5. Нажатие кнопки ОК, в случае если не все поля валидны, выдает сообщение «Некоторые поля содержат некорректные значения».
6. Поле ввода даты — обычное текстовое поле, в которое можно вводить дату в нескольких форматах. Справа от поля находится квадратик с изображением календаря, при нажатии на него всплывает календарь с подсветкой выбранной и текущей дат.
До сих пор эта методика себя оправдывала. Использовались ее реализации под VB.NET/C#/VB6.
