Альтернатива, чтобы предупреждать/подтверждать/ошибка диалоговые окна?

Много окон предупреждений и все те, которые раздражают меня, в основном покрывают недостатки базовой программы.

Это обычно сводит к i.s.o. оказание надлежащей поддержки отмены, "Вы уверены?" окно предупреждений добавляется.

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

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

1. Удалите элемент, который может привести к ошибке. Вам действительно нужна дата рождения пользователя? Можно ли обойтись точно также чем-то еще, что не потребует проверки, такой как переключатели для “менее чем 18 лет”, и “18 или”?

2. Предотвратите ошибку. Лишите возможности вводить недопустимый вход во-первых. Например, используйте выпадающий список или “изобразите” поле, отказавшись от любых недопустимых символов (например, буквы для номера телефона).

3. Примите вход и возможно исправьте его автоматически и повторение результата назад пользователю. Сделайте что-то из входа. Если пользовательские типы 4 - 14#008 для даты, автоматически корректируйте его, чтобы быть 14 апреля 2008. Если формат не соответствует номеру версии, проверьте, является ли это Номер выпуска и поиск соответствующий Номер версии. Если это не соответствует, Ваша идея допустимого адреса, ну, в общем, просто предполагают, что это (возможно, это для иностранного государства). Действительно имеет значение, если дата рождения пользователя исказила?

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

5. Предоставьте текст предупреждения и текст ошибки в главном окне или самой веб-странице; текст должен быть очевидным, не будучи дезориентирующим, немодальным, и исчезнуть автоматически, когда ошибка исправлена. Когда нераспознанная дата будет вводиться, подчеркните это в красном и помещенном тексте около нее, говоря “нераспознанную дату”, возможно, включая ссылку Справки для получения дополнительной информации.

6. Модальное окно сообщения.

Что относительно этого: Поля Монолога и Прозрачные сообщения Aza Raskin.

Эта статья говорит о сообщениях для полей "монолога" и и альтернатива им.

Это довольно интересно.

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

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

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

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

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

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

Сообщение строки состояния и color/text/item-flashing изменяются для указания на проблемы, подобные примеру @Rob с ASP.NET. И многоуровневая система отмены/восстановления является лучшей.

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

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

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

Уведомление о неправильных данных, с другой стороны, является критической потребностью в приложении. Прежде всего, в моем уме, необходимо попытаться препятствовать тому, чтобы неправильные данные были введены каждый раз, когда по-человечески возможно. Существует разнообразие сторонних инструментариев управления для большинства платформ (ASP.NET.NET WinForms, WPF, Java Swing, JSP, и т.д.), который поможет с этим. (Хотя это не популярно вокруг этих частей, я на самом деле стал неравнодушным к Infragistics NetAdvantage.)

В зависимости от Вашего выбора платформ у Вас есть много возможностей уведомления UI. Некоторые были упомянуты: Используя строку состояния Вашего приложения, указывая на проблему о самом поле, и т.д.

Я - парень.NET, таким образом, очевидно, мой вход здесь будет приправлен средой.

Я - огромный поклонник, в сети, средств управления проверкой. Они предоставляют много уведомления без слишком навязчивого UI. Объединение простого Text свойство *, подробное ErrorMessage свойство и хорошо помещающий и визуально очевидный ValidationSummary, Я получаю всю проверку почти ни с одним из пользовательских кошмаров. Эти средства управления, для тех, которые не на.NET, выполняют множество проверок против вводимых данных и отображают их Text свойства везде, где управление находится на странице (обычно рядом с проверяемым управлением). ErrorMessage свойство входит в тот ValidationSummary, обычно располагаемый в верхней части страницы.

В среде WinForms я взял к использованию комбинации ящика входящих сообщений ErrorProvider управление и всплывающие окна стиля Outlook Infragistics. В моем новом приложении WinForms я использую два различных видов всплывающих окон: Каждый полуполупрозрачен, и появляется в нижнем правом углу. Это имеет зеленый значок галочки и существует для уведомления пользователя сообщений успеха. (Мои пользователи не доверяют компьютерам; если они не видят некоторое подтверждение, они думают, что машина съела их данные. Длинная история.) Эти поля исчезают за семь секунд, или пользователь может закрыть их вручную.

Второй вид всплывающего окна не имеет никакой полупрозрачности, красный X значков, и появляется в верхнем правом углу. Это - то, где я отображаю ошибки проверки. Кроме того, ErrorProvider управляйте отображает значок рядом с каждым полем, где проверка, неудавшаяся, и парение мыши по данному контролю, отображает свое определенное сообщение об ошибке. (Эти определенные сообщения находятся также во всплывающем окне.) Ошибочные всплывающие окна исчезают после пятнадцати секунд.

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

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