Как бы вы поступили с пользователями, которые не читают диалоговые окна?
В недавней статье об A rs Technica обсуждается недавнее исследование, проведенное факультетом психологии Университета штата Северная Каролина, которое показало, что пользователи имеют тенденцию делать все возможное, чтобы избавиться от диалогового окна, чтобы вернуться к своей задаче. Большинство из них нажимают кнопку "ОК" или "Да", сворачивают диалоговое окно или закрывают диалоговое окно независимо от отображаемого сообщения. Некоторые из отображаемых диалоговых окон были настоящими, а некоторые из них были поддельными (например, всплывающие окна, отображаемые на веб-страницах в виде предупреждения от вирусов). Время ответа будет означать, что эти пользователи на самом деле не читают эти диалоговые окна.
Итак, зная это, как это повлияет на ваш дизайн, и что бы вы попытались с этим сделать (если что-нибудь)?
22 ответа
Я стараюсь разрабатывать приложения так, чтобы они были устойчивыми к случайным ситуациям - с ошибками (непреднамеренные операции, такие как нажатие в неправильном месте) или с ошибками (когнитивные ошибки, такие как нажатие кнопки "ОК" или "Отмена" в диалоговом окне). Вот несколько способов сделать это:
- бесконечное (или, по крайней мере, многошаговое) отмена / повтор
- интегрировать документацию с интерфейсом с помощью динамических всплывающих подсказок и других контекстно-зависимых средств коммуникации (одна из статей, которая особенно актуальна, касается "Сюрприза, объяснения, вознаграждения" (прямая ссылка: SER) - использование типичных психологических реакций на неожиданное поведение для информирования пользователей)
- Включите состояние системы в указанную документацию (используйте данные текущего пользователя в качестве примеров и сделайте документацию конкретной, используя данные, которые они могут видеть прямо сейчас)
- Ожидайте ошибку пользователя. Если есть вероятность, что кто-то попытается записать в:\, когда диск не установлен, установите тайм-аут, чтобы система могла корректно выйти из строя, и запросите другое место. Сохраняйте данные в памяти, пока они не будут защищены на диске и т. Д.
Это сводится к двум основным вещам: (1) Защитить программу и (2) Держать пользователя как можно лучше информированным. Если интерфейс системы прост в использовании и ведет себя в соответствии с их ожиданиями, то они с большей вероятностью узнают, какую кнопку нажимать, когда появляется раздражающее диалоговое окно.
Я также очень и очень стараюсь избегать модальных действий, поэтому пользователи могут игнорировать большинство диалогов, которые мне приходится использовать, хотя бы на некоторое время (а когда им действительно нужно обратить на них внимание, у них достаточно информации, чтобы знать, что делать с Это).
Невозможно сделать систему полностью защищенной от ошибок, но я обнаружил, что описанные выше методы имеют большое значение в правильном направлении. (и они были включены в системы, используемые для разработки Surprise Explain Reward и других инструментов, которые были проверены обширными исследованиями пользователей.)
Во-первых, использование цвета и значков должно помочь пользователю визуально осознать серьезность проблемы: красный - для исключения, желтый - для предупреждения, белый - для информации.
Во-вторых, использование глаголов в диалоговых кнопках дает пользователям представление о том, что они говорят системе, даже если они не читают текст диалога.
И наконец, если вы заинтересованы в изучении совершенно другой парадигмы уведомлений, ознакомьтесь с информационной панелью или панелью уведомлений, реализованной в Firefox и Internet Explorer. Stackru использует механизм того же типа для уведомления пользователей, когда они получают новый значок.
Информационная панель не навязчива и находится в верхней части экрана, ожидая внимания пользователя. Я думаю, что это отличная метафора дизайна.
Вот несколько учебных пособий по реализации:
Вот руководство Microsoft по дизайну диалогов, оно также касается концепции информационной панели.
Сразу вспоминается книга Стива Круга " Не заставляй меня думать".
В дизайне диалоговых окон, сообщений о состоянии, возвращаемых пользователю, и т. Д. Хорошо использовать иконографию и цветовые подсказки относительно того, что на самом деле говорят слова.
Поэтому выделите сообщения об ошибках красным, предупреждения желтым и т. Д.
"Гуманный интерфейс" Джефа Раскина стоит того, чтобы его прочитать. Диалоговое окно - последнее средство и признак плохого дизайна. Большинство из них не нужны, и, как вы обнаружили, все игнорируются пользователями.
Почему есть диалоговое окно? Решите эту проблему - не просите пользователей подтвердить операцию, вместо этого упростите ее отмену. Не открывайте диалоговое окно с сообщением об ошибке - в любом случае сделайте восстановление, которое вы собираетесь сделать (или все, что возможно). Определенно не показывайте диалоговые окна, которые имеют только один результат (только "ОК" - это дьявол), представьте информацию в приложении ненавязчиво.
Пара предложений
- Используйте коробки только в случае крайней необходимости.
- Всегда устанавливайте опцию по умолчанию на наименее опасную опцию
Вспоминается эпизод .NET Rocks (я думаю, что эпизод 338 "Марк Миллер о науке хорошего пользовательского интерфейса") обсуждает эту самую тему. Я думаю, что ключевым моментом всего этого обсуждения является то, что это базовый дизайн пользовательского интерфейса, зашедший слишком далеко. Там, где модал когда-то был приемлемым средством общения, теперь мы обнаруживаем, что он стал ошибкой программирования. Пользователи понимают, что в 6 случаях из 10 информация недостаточно уместна для них. В результате они относятся ко всем модалам одинаково - усвоенная беспомощность. Если модал подходит и сообщает мне, что произошла ошибка приложения X, и все, что я могу нажать, это "ОК" - даже когда я не думаю, что это "ОК", я изучаю определенное поведение. Я связываю модалы с мыслью, что я, вероятно, не могу с ними ничего поделать, но если я нажму ОК / Да, то смогу вернуться к тому, что мне нужно.
Итак, почему это все еще используется? Возможно, разработчики пытались избежать того факта, что разработка приложений становится не просто базовым интерфейсом, а пользователям требуется гибкий дизайн пользовательского интерфейса - от старых резервов трудно отказаться...
Я думаю, что ключевой момент здесь состоит в том, чтобы понять, что хороший дизайн пользовательского интерфейса теперь указывает на то, что прерывания (даже для самого начинающего пользователя компьютера) являются раздражающими факторами, и мы должны стремиться к тому, чтобы пользовательский интерфейс был беспроблемным, а фокус приложения - пользователь, а не потребности приложения с помощью подсказок и сообщений об ошибках - не позволяйте пользователю попадать в ситуации, когда им все равно.
Часто разработчики используют модальные диалоговые окна просто потому, что их легко кодировать.
Однако немодальные уведомления часто более удобны для пользователя.
Одно предложение:
- Не используйте диалоговые окна. Особенно модальные, ОК / Отмена диалоговых окон.
Иногда это сложно... как вы справляетесь с открытием файла? Иногда это легко... вам действительно нужно предупредить пользователя, что он собирается перезаписать файл? Скорее всего, если я слепо нажимаю "ОК", я не буду обращать внимания на любые предупреждения.
Если вы должны использовать диалоговое окно, поместите описательные надписи на кнопки в диалоговом окне.
Например, вместо кнопок "ОК" и "Отмена" попросите их сказать "Отправить счет-фактуру" и "Вернуться" или что-то еще, что подходит в контексте вашего диалога.
Таким образом, текст находится прямо под их курсором, и у них есть хорошие шансы для понимания.
Mac OS X делает это большую часть времени. Вот пример изображения.
Редактировать:
Это лучшее изображение, и я нашел его на сайте Apple Human Interface Guideline, который является отличным справочником и очень удобочитаемым. Этот документ на этом сайте посвящен диалогам.
Неправильный вопрос "Как бы вы поступили с пользователями" начинается не с того конца.
Правильный вопрос: "Учитывая, что диалоги отвлекают пользователей от поставленной задачи, какие существуют лучшие альтернативы?".
Работая над достижением цели или выполнением задачи, мы можем выделить три ситуации:
(1) Приложение приходит к выводу, что не предпринимается никаких действий, которые позволят пользователю достичь цели. Всплывающее сообщение, с одной кнопкой, чтобы отклонить его. Тебе все равно, понимает ли это читатель, потому что результат все равно не имеет значения.
(2) Вы можете предпринять только одно действие, или альтернативы не имеют отношения к пользователю. Не беспокойте его вообще.
(3) Есть два или более способов достижения цели. Позвольте пользователю выбирать между этим. Не формулируйте это как вопрос да / нет. (Vista предлагает это как обычный диалог, чтобы заменить окно сообщения.) Если это вообще возможно, не делайте этот выбор необратимым.
Исключением из этого правила является ситуация, когда пользователь может ожидать ответ "да / нет". Но на самом деле, если это так, то почему вопрос не является частью нормального рабочего процесса? Диалоговые окна находятся за пределами нормального рабочего процесса.
Если вы должны использовать диалог, наградите пользователя забавно сочувствующим или даже сатирическим и очень коротким пояснительным текстом. Если вы время от времени раздаете что-то веселое, скандальное, они все прочтут.
У пользователя опасно низкий здравый смысл. Пожалуйста, удалите этого пользователя и вставьте еще одного.
Много хороших советов выше. Я просто хочу добавить к книге рекомендации - книгу Джоэла Сплоски "Дизайн пользовательского интерфейса для программистов" стоит прочитать:
Я думаю, что вы, вероятно, захотите прочитать эту статью: "Влияние прерываний в стиле переговоров высокой интенсивности на отладку конечного пользователя", Т.Дж. Робертсон, Джозеф Лоуренс и Маргарет Бернетт, журнал по визуальным языкам и вычислениям 17(2), 187-202, апрель 2006 г.
Он задал похожий вопрос. В результате пользователь должен знать, что вы хотите его внимания, а затем бездельничать и ждать, пока пользователь ответит. Не перебивайте пользователя, хотя, это не то, что он или она хочет.
Модальное диалоговое окно [Lightbox] ( http://en.wikipedia.org/wiki/Lightbox_(JavaScript)) в некоторых случаях представляется эффективным методом (деривация web 2.0, но может применяться в других контекстах).
Еще один момент: если вы можете отказаться от диалогового окна для функции отмены (Gmail для одного отстаивал эту концепцию как стандартное поведение веб-приложения), это то, что нужно учитывать.
У меня мало терпения к пользователям, которые не читают, что заняло у меня много времени и усилий для разработки: 1) приложения 2) инструкции Кроме того, если вы не читаете и просто делаете "все, что нужно", вы самостоятельно. Я заявляю это заранее. Я делаю свои приложения максимально интуитивно понятными, и все же есть люди, которые будут звонить в службу поддержки по полной программе, как ребенок, выпадающий из класса, когда им этого не следует. У меня нет терпимости к этому. Прочитайте руководство, прочитайте диалоги - ответы на 99% проблем тут же.
Одна вещь, которую вы можете сделать, это отключить кнопку ОК на 3 секунды.
Firefox делает это при установке расширения.
Редактировать: Хорошо, некоторые люди находят это раздражающим. Я все еще думаю, что около 1 секунды будет в порядке. Это подавит инстинкт мгновенного нажатия кнопки "ОК", которым обладают люди (включая меня), и вынудит их принять двойную тактику. Конечно, даже это будет раздражать людей, если ваш диалог - это не то, что им действительно нужно читать.
Прежде всего, глупо должно причинять боль, но обычно это не так...
Следующая лучшая вещь включает в себя значок, который пытается передать серьезность проблемы. Некоторый процент тех, кто не читает, может изменить свою привычку, если значок диалога кажется зловещим. Какой-то процент не прочитает это независимо.
Я называю это проблемой "автопилот".
- Не используйте кнопки OK, Отмена в нижней части экрана. Посмотрите, как Vista пытается заставить пользователей принять реальное решение.
- Отключите кнопки на несколько секунд, отобразите "Время подумать" таймер / индикатор выполнения. Таким образом, пользователь не может нажать на автопилот. Пользователи склонны находить это очень раздражающим.
Помогает изменение формулировки и того, как работает диалог. Например, наличие кнопок OK/ Отмена позволяет пользователям игнорировать большую часть диалога. Если вы удалите обычные кнопки и замените их более текстовыми ссылками на команды, пользователи с большей вероятностью будут читать каждую кнопку, потому что опция "быстро уходить" недоступна.
Вы можете полностью избегать использования диалоговых окон! В некоторых программах есть минибуфер, который показывает ошибки и предупреждения. Наряду с этим, он также может спросить вас, где вы должны ввести то, что вы хотите сделать. Это довольно чистое и приятное решение, я предпочитаю его перед менубаром.
Но если вы действительно должны использовать диалоговые окна, попробуйте это:
- Только одно предложение в диалоге
- Максимум две или три кнопки
- Сделайте текст читаемым внутри диалога (больше, чёрно-белый)
- Скорее используйте один диалог, чем много маленьких многократно (совет: список)
Что я думаю о диалоговых окнах? В двух словах: они глупые и глупые вещи. Программы, которые их используют, встают у меня на пути и замедляют меня своими глупыми бессмысленными вопросами. Кроме того, часто программы, использующие диалоговые окна, довольно глупы.
Включите тест с несколькими вариантами ответов в конце диалогового окна, в котором пользователь должен выбрать ответ, который показывает, что он действительно прочитал и понял текст. Произвольно поменяйте порядок выбора, чтобы они не всегда могли щелкнуть один и тот же.
Не используйте подтверждение (Вы уверены? Да / Нет), но используйте Отменить.
Не выскакивайте предупреждения, которые будут блокировать, потому что пользователи будут пытаться возобновить работу как можно быстрее, игнорируя сообщение и просто щелкая его. Используйте что-то вроде информационной панели из Internet Explorer, которая не блокируется.