Избавляемся от подтверждений

Три принципа проектирования дают нам возможность избавиться от диалоговых окон подтверждений. Лучше всего придерживаться про' стого правила: делайте, а не задавайте вопросы. Проектируя программ' ный продукт, придайте ему уверенности (разумеется, положив в осно' ву этой уверенности исследование пользовательской аудитории, опи' санное в главе 4). Пользователи с уважением отнесутся к немногослов' ности и уверенным действиям вашей программы.

Не расспрашивайте – действуйте.

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

Большинство ситуаций, которые кажутся нам несовместимыми с ко' мандой отмены, в действительности вполне допускают применение этой команды. Хороший пример – удаление файла или запись нового файла поверх существующего. Имеющийся файл можно переместить во временный каталог, где он будет храниться месяц или около того, пока не подвергнется физическому удалению. Корзина в Windows ис' пользует подобную стратегию, но файлы из нее не удаляются автома' тически через месяц, и пользователям приходится выносить мусор вручную.

Все действия должны быть обратимыми.

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

Помогайте пользователям избегать ошибок при помощи немодальной обратной связи.

Иногда возникают ситуации, в которых действительно невозможно использовать функцию отмены. Являются ли они законным основани' ем для выдачи окна подтверждения? Не обязательно. Более удачный подход – защищать пользователей, как мы защищаем водителей на автострадах – с помощью последовательной и понятной разметки. Часто есть возможность встраивать замечательные немодальные пре' дупреждения прямо в интерфейс. В качестве примера рассмотрим диа' логовое окно Adobe Photoshop (рис. 25.7), которое сообщает нам, что документ больше области печати. Почему программа дожидалась это' го момента, чтобы информировать нас о данном факте? Почему бы не показывать на экране границы области печати все время (пока пользо' ватель не скроет их)? Почему бы не выделять те части изображения, которые не могут быть напечатаны, когда пользователь наводит указа' тель мыши на кнопку Печать на панели инструментов? Прозрачная немодальная обратная связь (см. следующий раздел) является луч' шим способом решения подобных проблем.

Изображение выходит за границы

области печати и может быть обрезано

Продолжить Отмена

Рис. 25.7. Это диалоговое окно приносит мало пользы и появляется слишком поздно. Почему бы программе не обозначать границы области печати пунктирными линиями прямо в интерфейсе? Нет никаких причин терроризировать пользователей подобными окнами

Гораздо чаще действительно необратимых действий встречаются дей' ствия легкообратимые, но все же сопровождаемые диалогами подтвер' ждения. Подтверждение на рис. 25.6 – яркий пример ненужного окна такого типа. Нет ни одной причины просить подтверждения для пере' носа файла в Корзину: она для того и существует, чтобы можно было отменить операцию удаления файлов.