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

Чаще всего эту проблему решают, предусматривая показ диалогового окна для подтверждения действия, и этим ограничиваются. Если выполняемое действие может привести к серьёзным последствиям, то пользователь прочтёт сообщение, выведенное в окне, и, если он стремился сделать именно то, что сделал, подтвердит это действие. Правильно?



Несмотря на популярность вышеописанного механизма, использование диалогового окна подтверждения действия — это, в 90% случаев, неправильно. Поговорим о том, почему это так.

Проблемы диалоговых окон подтверждения действий

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

• Эти механизмы прерывают работу пользователя. Идея, которая лежит в основе применения диалоговых окон для подтверждения действий, заключается в том, чтобы остановить работу пользователя. Это должно дать ему возможность подумать о последнем совершённом действии и понять — действительно ли он сделал именно то, что намеревался. Но проблема прерывания работы пользователя заключается в том, что это отвлекает его от того, что он пытался сделать. Появление диалогового окна принуждает пользователей перестать думать о том, что они делают. Они, вместо этого, пытаются понять новую информацию.
• Мы, по привычке, нажимаем на кнопку, подтверждающую выполнение действия. Человек формирует сотни привычек, которые помогают ему жить. Одна из таких привычек заключается в том, что когда мы видим диалоговое окно, предлагающее что-то подтвердить, мы очень быстро его закрываем, не особенно вглядываясь в его содержимое. Привычку быстрого закрытия диалоговых окон закрепляет ещё и то, что в современном интернете каждый владелец сайта считает своим долгом показать посетителю всплывающее окно с предложением зарегистрироваться. 
• Мы не читаем тексты, выводимые в диалоговых окнах, предназначенных для подтверждения действий. Даже если человек и прочитает текст в подобном окне, он не всегда даёт себе возможность остановиться и подумать о прочитанном. Если не происходит ничего экстраординарного, мы полагаем, что всё идёт как надо, и нажимаем на кнопку подтверждения действия просто из-за того, что она позволяет убрать маленькое окно, которое перекрывает то, чем мы сейчас занимаемся. Главная кнопка в любом подобном окне немедленно воспринимается как кнопка, которая позволяет пользователю продолжить заниматься тем, чем он занимался.

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

Сильные стороны механизмов отмены действий

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

• Эти средства создают, исходя из предположения о том, что пользователь уверен в том, что он делает. Главное преимущество средств отмены действий перед окнами подтверждения заключается в том, что система не пытается предсказать действия пользователя. Нечто вроде кнопки отмены просто решает свою задачу, не задавая пользователю вопросов о том, уверен ли он в выполняемом действии.
• Механизмы отмены действий не мешают работе пользователя. Избавление от окна подтверждения действия и замена его менее заметным элементом управления, служащим для отмены изменений, позволяет не прерывать работу пользователя и не отвлекать его от решаемых им задач. Кнопка для отмены изменений — это не совершенно новый интерфейс, появляющийся перед пользователем и требующий внимания к себе.
• Средства отмены действий помогают пользователям исследовать программы. Если у пользователя есть возможность отменять действия, это его поддерживает, говоря ему о том, что он не может что-либо непоправимо испортить. Мне часто доводилось слышать рассказы не особенно продвинутых пользователей ПК о том, что они не пытаются работать с неизвестными элементами интерфейсов приложений из-за того, что не хотят что-то испортить.
• Использование механизмов отмены действий позволяет пользователям самим видеть результаты своей работы, а не читать об этом. Иногда пользователи не уверены на 100% в том, что их действия приведут именно к тем результатам, к которым они стремятся. Наличие в приложении чего-то вроде кнопки отмены действия позволяет пользователю видеть результаты своих действий и результаты их отмены. Это помогает пользователю определиться с тем, внёс ли он в систему именно то изменение, которое хотел внести.

Эффективное использование механизмов отмены изменений

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

• Давайте пользователю обратную связь. Если пользователь не видит результатов того, что сделал, то возможность отменить это действие не так уж и важна. Поэтому давайте пользователю обратную связь. Позвольте ему увидеть результаты совершённого им действия. Например — если в OS X файл отправляют в корзину — это сопровождается звуковой и визуальной обратной связью.
• Сделайте элемент управления, позволяющий отменить действие, хорошо заметным. Если удалять что-либо в вашей программе — это обычное дело (скажем — при работе с некими списками), разместите элемент управления для отмены действия прямо рядом с удалённым элементом. Если отмена действия может понадобиться не особенно часто — то хорошим вариантом будет показ всплывающей подсказки в верхней или в нижней части экрана. Например, именно так сделано в Gmail. Там, в верхней части экрана, показывают жёлтый баннер, содержащий ссылку для отмены действия.

Предложение об отмене действия в Gmail

• Сделайте так, чтобы элементы можно было бы восстанавливать. Создайте в своей программе место, куда попадают удалённые элементы и не уничтожайте их безвозвратно. Местом хранения удалённых элементов может быть нечто вроде корзины, архива, папки «Исходящие сообщения». Подобная стратегия используется в Trello, где карточки не удаляются, а, вместо этого, архивируются. Если пользователь хочет восстановить карточку, он может перейти в архив и сделать это, вернув её туда, где она была.
• Откладывайте выполнение необратимых действий. Если действие, которое выполнил пользователь, нельзя отменить — откладывайте его выполнение. Например, в Gmail есть возможность откладывания отправки писем на 15 секунд.

Что если отменить действие невозможно?

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

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

• Постарайтесь, чтобы диалоговые окна появлялись бы только в особых случаях. Лучший способ повысить эффективность использования диалоговых окон — сделать так, чтобы они появлялись бы не особенно часто.

Вот что написано по этому поводу в книге «Алан Купер об интерфейсе. Основы проектирования взаимодействия», в разделе «Диалоговое окно, которое кричало: «Волк!» (Купер А., Рейман Р., Кронин Д. Алан Купер об интерфейсе. Основы проектирования взаимодействия. – Пер.с англ. – СПб.: Символ-Плюс, 2009. – 688 с., ил.):

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

Чтобы диалоговые окна подтверждения работали, они должны появляться в тех случаях, когда пользователь почти наверняка щёлкнет по кнопке Нет или Отмена, и они ни в коем случае не должны появляться тогда, когда пользователь скорее щелкнет по кнопке Да или ОК.

• Сделайте процесс подтверждения действия необычным. Нужно стремиться к тому, чтобы сделать процесс подтверждения действия отличающимся от всего того, что обычно приходится делать пользователю. Например, на Github можно найти прекрасную иллюстрацию этой рекомендации. Там пользователю предлагают ввести в окне подтверждения удаления репозитория имя этого репозитория.

Необычный способ подтверждения удаления репозитория

• Используйте понятные надписи на кнопках. Сделайте так, чтобы на кнопке подтверждения было бы чётко описано выполняемое по её нажатию действие. Не стоит писать на таких кнопках что-то вроде Да или Подтвердить. Более вероятно то, что пользователь щёлкнет по кнопке Подтвердить, чем по кнопке, на которой написано Удалить kittens.jpg.

Используете ли вы окна подтверждения действий в своих проектах?