Как вы будете обрабатывать пользователей, которые не читают диалоговые окна?

В недавней статье о Ars Technica обсуждается недавнее исследование, проведенное Отделом психологии Университета штата Северная Каролина, которое показало, что у пользователей есть тенденция делать все возможное, чтобы избавиться от диалогового окна, чтобы вернуться к своей задаче. Большинство из них нажимают кнопку "ОК" или "да", сводят к минимуму диалог или закрывают диалоговое окно независимо от отображаемого сообщения. Некоторые из отображаемых диалоговых окон были реальными, а некоторые из них были поддельными (например, всплывающие окна, отображаемые веб-страницами, представляющими собой антивирусное предупреждение). Время ответа указывает на то, что эти пользователи не читают эти диалоговые окна.

Итак, зная это, как это повлияет на ваш дизайн и что вы попытаетесь сделать с ним (если что-нибудь)?

Ответ 1

Я стараюсь, чтобы приложения были надежными перед лицом аварий - либо скольжения (непреднамеренные операции, например, щелчок в неправильном месте), либо ошибки (когнитивные ошибки, такие как щелчок Ok или Отмена в диалоговом окне). Некоторые способы сделать это:

бесконечный (или, по крайней мере, многошаговый) отменить/повторить
интегрировать документацию с интерфейсом, с помощью динамических всплывающих подсказок и других контекстно-зависимых средств связи (одна из наиболее актуальных статей - 'Сюрприз, Объяснение, Награда ' (прямая ссылка: SER) - используя типичные психологические ответы на непредвиденное поведение для информирования пользователей)
Включить состояние системы в указанную документацию (используйте текущие пользовательские данные в качестве примеров и сделайте документацию конкретным, используя данные, которые они могут видеть прямо сейчас).
Ожидайте ошибку пользователя. Если есть вероятность, что кто-то попытается записать в: \, когда на диске нет диска, тогда используйте тайм-аут, чтобы система могла терпеть неудачу изящно и запрашивать другое местоположение. Сохраняйте данные в памяти до тех пор, пока они не будут защищены на диске и т.д.

Это сводится к двум основным вещам: (1) Защищайте программу и (2) Держите пользователя как можно более информированным, как вы можете. Если системный интерфейс прост в использовании и ведет себя в соответствии с их ожиданиями, тогда они с большей вероятностью узнают, какую кнопку нажать, когда появляется раздражающий диалог.

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

Невозможно сделать систему полностью безупречной, но я обнаружил, что вышеупомянутые методы идут в правильном направлении. (и они были включены в системы, используемые для разработки Surprise Explain Reward и других инструментов, которые были проверены обширными исследованиями пользователей.)

Ответ 2

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

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

Наконец, если вы заинтересованы в изучении совершенно другой парадигмы уведомлений, ознакомьтесь с панелью информации или панель уведомлений, которая реализована в Firefox и Internet Explorer. StackOverflow использует один и тот же механизм для уведомления пользователей, когда они получили новый значок.

Информационная панель не является навязчивой и остается в верхней части экрана, ожидая внимания пользователя. Я думаю, что это отличная метафора дизайна.

Вот несколько учебников по внедрению:

Ниже приведено руководство Microsoft по созданию диалогового окна, оно также затрагивает концепцию информационной панели.

Ответ 3

Сразу же книга Стива Круга Do not Make Me Think приходит на ум.

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

Таким образом выделите сообщения об ошибках красным, предупреждения желтые и т.д.

Ответ 4

Человеческий интерфейс, Jef Raskin стоит прочитать. Диалоговое окно - последнее средство, и это признак плохого дизайна. Большинство из них не нужны, и, как вы обнаружили, все игнорируются пользователями.

Почему есть диалоговое окно? Решите эту проблему - не просите пользователей подтвердить операцию, вместо этого упростите ее отменить. Не открывайте диалоговое окно с объявлением об ошибке - сделайте любое восстановление, которое вы собираетесь делать (или все, что возможно). Определенно не показывайте диалоговые окна, которые имеют только один результат ( "ОК" только ящики - дьявол), ненавязчиво отображают информацию в приложении.

Ответ 5

Несколько предложений

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

Ответ 6

A . Обнаружен эпизод NET Rocks (я считаю, эпизод 338, "Марк Миллер о науке хорошего интерфейса" ) обсуждает эту тему. Я думаю, что ключевой момент для всего этого обсуждения состоит в том, что это основной дизайн пользовательского интерфейса, взятый слишком далеко. Когда модальность была когда-то приемлемым средством коммуникации, мы теперь обнаруживаем, что она стала программированием faux pas. Пользователи понимают, что в 6 раз из 10 информация не уместна, чтобы о них беспокоиться. В результате они трактуют все модальности одинаково - изучают беспомощность. Если появляется модальный способ и говорит мне, что произошла ошибка приложения X, и все, что я могу щелкнуть, это "ОК" - даже когда я не думаю, что это "ОК", я узнаю конкретное поведение. Я присоединяю модалов к идее, что я, вероятно, не могу много сделать о них, но если я нажму OK/Yes, тогда я смогу вернуться к тому, что мне нужно.

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

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

Ответ 7

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

Однако немодальные уведомления часто более удобны для пользователя.

Ответ 8

Одно предложение:

Не используйте диалоговые окна. Особенно модальные, ОК/Отменить диалоговые окна.

Иногда это сложно... как вы обрабатываете открытие файла? Иногда это легко... вам действительно нужно предупредить пользователя о том, что они собираются перезаписать файл? Скорее всего, если я слепо нажимаю "ОК", я не буду прислушиваться к каким-либо предупреждениям.

Ответ 9

Если вы должны использовать диалог, поместите описательные надписи на кнопки в диалоговом окне.

Например, вместо кнопок "ОК" и "Отмена" попросите их сказать "Отправить счет" и "Назад" или что-то подходящее в контексте вашего диалога.

Таким образом, текст прямо под их курсором, и у них есть хороший шанс понять.

Mac OS X делает это большую часть времени. Вот пример изображения.

Edit:

Это лучшее изображение, и я нашел его на сайте Apple Human Guid Guideline, который является отличной ссылкой и очень читабельным, Этот документ на этом сайте посвящен диалоги.

Ответ 10

Неверный вопрос. "Как вы будете обращаться с пользователями" начинается с неправильного конца.

Правильный вопрос: "Учитывая, что диалоги отвлекают пользователей от поставленной задачи, какие существуют лучшие альтернативы?".

При работе над достижением цели или завершением задачи мы можем выделить три ситуации:

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

(2) Есть только одно действие, которое вы можете предпринять, или альтернативы не имеют отношения к пользователю. Не беспокоить его вообще.

(3) Существует два или более способов достижения цели. Позвольте пользователю выбирать между ними. Не формулируйте это как вопрос "да/нет". (Vista предлагает это как обычный диалог, чтобы заменить окно сообщения.) Если это вообще возможно, не делайте это необратимым выбором.

Исключением из этого правила является ситуация, когда пользователь будет ожидать вопроса "да/нет". Но на самом деле, если это так, то почему вопрос не является частью обычного рабочего процесса? Диалоговые окна находятся вне нормального рабочего процесса.

Ответ 11

Одна вещь, которую вы можете сделать, - отключить кнопку OK в течение 3 секунд.

Firefox делает это при установке расширения.

Изменить: Хорошо, некоторые люди находят это раздражающим. Я все еще думаю, что около 1 секунды все будет в порядке. Это должно было бы подавить мгновенный щелчок мышью, который люди (включая меня), и заставить двойное взятие. Конечно, даже это будет раздражать людей, если ваш диалог не является тем, что им действительно нужно читать.

Ответ 12

Думаю, вы, вероятно, захотите прочитать эту статью: "Влияние прерываний с высоким уровнем согласованности в процессе отладки конечных пользователей" , TJ Robertson, Joseph Lawrance и Margaret Burnett, Journal of Visual Языки и вычисления 17 (2), 187-202, апрель 2006 г.

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

Ответ 13

Диалоговое окно [Лайтбокс] (http://en.wikipedia.org/wiki/Lightbox_(JavaScript)) кажется эффективным методом в некоторых случаях (вывод Web 2.0, но может быть имплантирован в другие контексты).

Еще один момент: если вы можете отказаться от диалогового окна для функции Undo (Gmail для одного отстаивала эту концепцию как стандартное поведение webapp) что-то рассмотреть.

Ответ 14

Много хорошего совета выше. Я просто хочу добавить к книге рекомендации - Joel Splosky "Дизайн пользовательского интерфейса для программистов" стоит прочитать:

http://www.amazon.com/User-Interface-Design-Programmers-Spolsky/dp/1893115941/ref=pd_bbs_sr_4?ie=UTF8& s = книги & QID = 1222233643 & ср = 8-4

Ответ 15

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

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

Ответ 16

У меня мало терпения с пользователями, которые не читают то, что потратило мне много времени и усилий на разработку: 1) приложение 2) инструкции Помимо этого, если вы не читаете и просто делаете "все, что требуется" " ты сам по себе. Я заявляю, что впереди. Я разрабатываю свои приложения как можно более интуитивно понятными, и все же есть люди, которые будут делать телефонные звонки с телефона синими, как ребенок, размывающийся в классе, когда они не должны быть. У меня нет терпимости к этому. Прочтите руководство, прочитайте диалоги - ответы на 99% проблем находятся прямо там.

Ответ 17

Прежде всего, глупо было бы больно, но обычно это не так...

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

Ответ 18

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

Ответ 19

Изменение формулировки и то, как работает диалог, помогает. Например, если кнопки OK/Отмена имеют тенденцию позволять пользователям игнорировать большую часть диалога. Если вы удалите обычные кнопки и замените их ссылками на словарные команды, пользователи с большей вероятностью прочитают каждую кнопку, потому что опция "быстрый, уходящий" недоступен.

Ответ 20

Я называю это проблемой "автопилота".

Не используйте кнопки ОК, Отмена в нижней части экрана. Посмотрите, как Vista пытается заставить пользователей принять реальное решение.
Отключите кнопки в течение нескольких секунд, отобразите таймер времени/времени выполнения "Время думать". Таким образом, пользователь не может нажать автопилот. Пользователи склонны находить это очень раздражающим.

Ответ 21

Не используйте подтверждение (вы уверены? Да/Нет), но используйте Отменить.

Не всплывающие предупреждения, которые будут блокироваться, потому что пользователи будут пытаться работать как можно быстрее, не обращая внимания на сообщение и просто отбрасывая его. Используйте что-то вроде информационной панели Internet Explorer, которая не блокирует.

Ответ 22

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

Но если вы действительно должны использовать диалоговые окна, попробуйте следующее:

Одно предложение только для каждого диалога
Не более двух или трех кнопок
Сделайте текст читаемым внутри диалогового окна (больше, черно-белое)
Скорее используйте один диалог, чем много маленьких (tip: listbox)

Что я могу сказать о диалоговых окнах? В двух словах: они глупые и глупые вещи. Программы, которые используют их, идут мне навстречу и замедляют мои глупые бессмысленные вопросы. Кроме того, часто программы, использующие диалоговые окна, довольно тупые.