Ненавязчивая валидация

Проблема: диалоги и валидация

Диалоги, или точнее, диалоговые окна (dialog boxes), в настоящее время используются в интерфейсе большинства программ. С диалогами связана одна проблема, имеющая отношение к тому что называют ненашим словом «юзабилити» (usability).

Пользователь вводит несколько параметров и подтверждает выполнение команды нажатием кнопки (обычно — кнопки ОК). На вводимые значения накладываются ограничения. В простейшем случае одно из полей должно быть непустым, в других случаях правильность (валидность) значения определяется по сложной формуле или зависит от значений других полей. Процесс проверки введенных значений на правильность будем называть валидацией.

Валидация предполагает не только проверку, но и сообщение пользователю о результатах такой проверки. Обычно результат проверки представляется пользователю в виде стандартного окна-сообщения (message box) с кнопкой ОК. Такой подход хоть и является общепринятым, но имеет ряд недостатков.

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

Во-вторых, окно сообщения нужно каждый раз закрывать — это неудобно и отнимает время. После закрытия окна нужно найти поле, о котором говорилось в сообщении (даже если фокус переведен на это поле, вы должны найти его глазами), и исправить его так как было сказано — но сообщения вы уже не видите.

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

Итак, существующий способ валидации, по крайней мере, неудобен.

Неудачное решение: ограничение ввода

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

Ограничение ввода удобно для программиста — выставляются нужные ограничения, и никакие проверки и сообщения больше не нужны. Но так ли это удобно для пользователя?

Такой подход мне (как пользователю, если хотите) совершенно не нравится. Мне нравится, когда приложение, в ненавязчивой форме, само дает мне понять, как с ним работать, но при этом не держит меня в жестких рамках. Кроме того, ограничение ввода, по сути, «замалчивает» причину проблемы — вместо сообщения об ошибке пользователь теперь получает неприятный звук при нажатии «не той» клавиши. А это означает, что снижается само-описательность системы, и как следствие — возможность само-обучения для пользователя.

Единственное что мне кажется приемлемым в качестве ограничения — это ограничение по длине в текстовых полях: ввел текст максимальной длины — не можешь больше вводить. И то, только потому, что другие решения были бы еще хуже — например, сообщение «вы ввели на 17 символов больше чем допустимо в этом поле»…

Решение: ненавязчивая валидация

Работая над очередным приложением (под VB.NET, несколько лет назад), я пришел к мысли, что с валидацией нужно что-то менять. Основная идея заключалась в том, чтобы отказаться от окон сообщений. Но чем их заменить? Можно было бы снабдить каждый диалог строкой подсказки (status bar), но это изменит стандартный облик диалога и не решит всех проблем.

Другая мысль была в том, чтобы подсвечивать поля, содержащие неправильные значения — например, сменой фона контролов со стандартного на какой-либо другой. Оставалось решить как показывать сообщения. Рассмотрев несколько вариантов, в конце концов я остановился на всплывающих подсказках (tooltips).

Практические рекомендации

В общем, последние несколько лет я придерживаюсь такой идеологии валидации:

1. Пользователь может вводить в поля все что хочет.
2. Непосредственно при вводе (при изменении значения в поле) выполняется проверка валидности значения. Валидация всего диалога описывается в одном единственном месте (в одном методе класса) сразу для всех контролов диалога. Тем самым, всего в одном месте описываются как ограничения на отдельные поля, так и зависимости между ними.
3. Невалидные поля подсвечиваются светло-красным. Этот цвет — не константа, а вычисляется на основании цветов текущей цветовой схемы.
4. При наведении мыши на невалидное поле появляется тултип с очень коротким описанием проблемы и ограничений. Например: «Неверная дата. Введите значение в формате ДД.ММ.ГГ или ДД.ММ.ГГГГ».
5. Запрещенные (disabled) и невидимые (hidden/invisible) поля не могут быть невалидными.
6. Нажатие кнопки ОК, в случае если не все поля валидны, выдает сообщение «Некоторые поля содержат некорректные значения».
7. Поле ввода даты — обычное текстовое поле, в которое можно вводить дату в нескольких форматах. Справа от поля находится квадратик с изображением календаря, при нажатии на него всплывает календарь с подсветкой выбранной и текущей дат.

До сих пор эта методика себя оправдывала. Использовались ее реализации под VB.NET, C# и VB6.

Что делать с кнопкой ОК?

Если мы всегда знаем, возможно ли сейчас завершение по ОК, то очевидно, мы можем запрещать кнопку ОК в том случае если продолжение невозможно. Собственно, сначала я так и думал. И запрещал эту кнопку, пока пользователь не заполнит все поля как надо. Но практика показала, что многие пользователи не могут (сразу либо без посторонней помощи) разобраться — почему кнопка не включается. Действительно, здесь нужно установить связь между кнопкой ОК и подсвеченными полями. Лучше сделать так: если кнопка разрешена — пользователь нажимает ее и видит поясняющее сообщение — после этого ему становится легче установить эту связь. Программа становится более само-описательной (self-described).

«Быстрая» и «медленная» валидация

По поводу п.2 (см. выше Практические рекомендации) возникают сомнения вида (а) что если пользователь еще не ввел значение целиком, а ему уже подсвечивают ошибку? (б) валидация может занимать значительное время, поэтому выполнение валидации после каждого нажатия клавиши — нецелесообразно.

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

Во-вторых, предлагается разделить валидацию на «быструю» и «медленную». Быстрая валидация — это проверки на соответствие диапазону, проверку на то что значение это дата, взаимозависимости полей и т.п. Медленная валидация — действия по проверке значений, выполняющие обращения к файлом, обращения к базе данных. Быструю валидацию выполняем по изменению значений в полях ввода, медленную валидацию — уже только при нажатии кнопки ОК и только после удачной проверки быстрой валидация.

Warning-валидация

В качестве развития идеи. Можно предположить, что нужна также валидация, которая подсвечивает неправильные значения, но тем не менее позволяет их сохранить.

В качестве примера — ввод таких значений как Идентификационный Номер Налогоплательщика (ИНН). Правильность такого значения легко проверяется валидацией. Но что если задача оператора — просто регистрировать платежки, а почему этот ИНН в документе оказался неверным — разбираться ему некогда или вне его компетенции? Убрать в таком случае валидацию вообще или заставить пользователя вводить верное значение?

Предлагается в подобных случаях использовать «warning-валидацию»: подсвечивать значение и выводить тултип, но считать валидацию успешной. Цвет подсветки warning-валидации должен заметно отличаться от цвета подсветки обычной валидации.

Никита Зимин,
ведущий разработчик компании «Деловые программы»

Вернуться к списку статей