Как заставить пользователей обращать внимание на проблемы?

Не пытайтесь решить с программированием. Посмотрите, можно ли изменить процесс ввода данных.

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

• сделайте отзыв пользователя данными для очевидных опечаток или ошибок

• сделайте кого-то еще для рассмотрения данных на более позднем этапе, когда больше информации будет доступно

• сообщите этому пользователю и кому-либо еще смотрящему на данные на более позднем этапе о любых сделанных предположениях

• удостоверьтесь, что пользователь понимает последствия их действий

Какая-либо из этих целей может быть достигнута эффективнее по-другому?

Некоторые идеи (ни один из них автоматически не квалифицирует как серебряная пуля):

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

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

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

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

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

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

• Сделайте действия невозможными, таким образом, Вам действительно не нужны предупреждения

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

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

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

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

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

• Если местоположение будет абсолютно очень важно, то мы сделаем, оно потребовало на форме.

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

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

Мне вполне нравится метод Firefox при установке плагинов: кнопка ОК отключена и отображает обратный отсчет в течение 5 секунд. После этого использование может принять решение проигнорировать его.

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

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

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

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

Это - то, что мы запланировали. По существу создайте что-то выход Bugzilla для хранения этих errors/warnings/whatever. Но это также идет рука об руку с некоторыми из других ответов.

Вместо того, чтобы использовать простой MessageBox, отобразите предупреждения/ошибки в подобном Visual Studio ошибочном окне. Пока существуют проблемы, они будут отображены в этом окне.

Если данные сохраняются, сохраните все предупреждения/ошибки базе данных. Теперь любой видит то, что текущие проблемы - премия! Кроме того, те проблемы могут быть загружены из базы данных вместо того, чтобы обнаружить их в приложении все время, которое поможет много - некоторые проблемы не тривиальны для обнаружения.

Позвольте пользователям выполнять несколько действий, как:

• Подтвердите проблему, таким образом, она больше не отображается.
• Присвойте проблему другому пользователю
• Отметьте проблему как "не действительно проблема"
• Установите, "должен быть решен" датой
• (вероятно, другие, дизайн еще не был полностью продуман),

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

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

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

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

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

Править--
Теперь, когда я перечитал свое сообщение, я не забываю читать, это в "не Заставляет Меня Думать". Блестящая небольшая книга (немного десятков страниц) это полно хороших и легких для понимания вещей удобства использования. Несколько сфокусированный на удобстве использования онлайн, но defenatly applyable в офлайновых приложениях также.

Мой совет сводится к трем вещам.

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

Если Вы имеете форму с необходимыми данными, то наносите цветную маркировку на поле как красное или выделяете его со звездочкой, чтобы указать, что это требуется. Отключите кнопку "OK" или "Confirm", пока они не заполнят все обязательные поля.

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

Фундаментальная проблема состоит в том, что пользователям не нравится читать, они просто хотят быть оставленными в покое, чтобы сделать их работу :).

Лучший способ сражаться с этим следующий:

• Не открывайтесь окно, если не абсолютно необходимо
• Если Вы делаете, сделайте сообщение об ошибке или предупреждающее сообщение столь короткими и сжатыми, как Вы возможно можете

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

Качество Вашего предупреждения не будет препятствовать тому, чтобы пользователи отправили недопустимые данные. Если Вы позволите недопустимым данным быть отправленными, то это будет.

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

Повредите систему!

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

Столь серьезно раздражающий, как целый "Windows Error/warning Messages" добирается, я никогда не замечаю, пока программа не говорит мне, что я не могу сделать чего-то... затем я вынужден спросить меня "Почему Нет"

Время для поиска с помощью Google ответа... или прочитайте руководство

Я знаю, что не всегда выполнимо использовать этот подход, но если Вы можете... они слушать!

Используйте цвета и значки.

Зеленый - все в порядке (или подтверждение, что что-то произошло, как ожидалось)

Желтый - Предупреждение. Пользователь может захотеть или не захотеть разбираться в проблеме

Красный - Ошибка. Что-то, что требует вмешательства пользователя для решения.

Я бы также посоветовал (как и другие в этой ветке) использовать экономно.