Переключение Отмены OK и Отмены хорошо для осуществления взаимодействия с пользователем?

Интересно, вы задумываетесь над опцией, существующей в Visual Basic, где вы можете устанавливать различные подсказки и опции ответа? ; и один из вариантов - разрешить переключение «Отмена» и «ОК» в зависимости от того, какое значение должно быть по умолчанию; так что пользователь может просто нажать Enter и большую часть времени получить правильное действие.

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

I am not really for OK/Cancel. It's overused and requires you to read the babbling in order to say what you are OKing or Canceling. Follow the idea of MacOSX UI: the button contains a simple, easy phrase that is meaningful by itself. Exampleç you change a file extension and a dialog pops up saying:

"Are you sure you want to change the extension from .py to .ps?"
If you perform the change, the document could be opened by a different application.

(Use .ps)   (Keep .py)

It is way more communicative than OK/Cancel, and your question becomes almost superfluous, that is, you just need to keep active the rightmost button, which seems to be the standard.

As it concerns the raw question you posed. Never do it. Ever. Not even at gunpoint. Consistency is an important requisite for GUIs. If you are not consistent you will ruin the user experience, and your users will most likely to see this as a bug than a feature (indeed it would be a BUG). Consistency is very important. To break it, you must have very good reason, and there must not be another different, standard way to achieve the same effect.

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

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

Решение этого, если Ваша цель состоит в том, чтобы обеспечить пользователей, понимающих:

• Опросите пользователя о содержании. Если Вы нажимаете ОК, Вы соглашаетесь на Опцию 1, или если Вы нажимаете ОК, Вы соглашаетесь на опцию 2. Если они выбирают корректный ответ, позволяют действие.
• Это будет раздражать пользователя, поэтому если можно отслеживать пользователей, только сделать это им однажды на сообщение.

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

Vista (и OSX IIRC) двинула идею использовать определенные глаголы для каждого вопроса (как "Отправление" / "Не отправляют", когда приложение хочет отказать и хочет отправить crashdump MS),

По-моему, мне нравится подход, используемый Outlook, когда приложение пытается послать электронное письмо через COM с таймером, прежде чем кнопкам позволят использоваться (также влияет на сочетания клавиш),

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

Я вижу другой хороший пример того, чтобы вынуждать пользователя "читать" перед щелчком: Firefox всегда grayed кнопка (иначе отключают), кнопка "OK". Поэтому пользователь должен ожидать приблизительно за 5 секунд до того, как он сможет продолжить делать что-либо. Я думаю, что это - максимальные усилия, которые я видел в том, чтобы вынуждать пользователя читать (и думать)

Другой пример, который я видел, находится на странице "License and Agreements" установщика. Некоторые из них потребовали, чтобы пользователь прокрутил вниз в конец страницы, прежде чем он сможет продолжить затем ступать.

Не передвигайте его - Вы только перепутаете больше, чем Вы поможете.

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

Не знайте, насколько лучше это будет, но это могло помочь.

Просто помните, как сказал человек: Вы не можете зафиксировать глупый.

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

Некоторые идеи как альтернативы движущимся кнопкам.

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

2. Имейте поле подтверждения после того, как они поражают хорошо объяснение, каков результат этого действия будет.

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

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

Я рекомендую сообщить пользователю, что это - критическая операция при помощи красного текста и объяснение, почему это - небезопасная операция.

Кроме того, а не две кнопки, имейте два переключателя и одну кнопку "Ok", с "не продолжают" переключатель, установленный как значение по умолчанию.

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

НЕ делайте этого, пожалуйста. Это не будет иметь никакого положительного эффекта: вы пытаетесь ИЗБЕЖАТЬ людей, нажимающих OK вместо Cancel, заставляя их потенциально нажимать Cancel вместо OK (хорошо, они могут повторить попытку). Но! с тем же успехом можно добиться того, чтобы люди нажимали ОК, когда они действительно хотят отменить, и это может стать настоящей катастрофой. Это просто не хорошо.

Почему бы не переформулировать пользовательский интерфейс, чтобы сделать ОК "безопасным выбором"?

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

В пользу механизма подтверждения говорит простота реализации. С точки зрения программиста, это самый простой способ переложить ответственность на пользователя: «Эй, я спросил тебя, действительно ли ты хочешь выстрелить себе в ногу, не так ли? Теперь некого винить, кроме себя ...» . "

С точки зрения пользователя:

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

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

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

• Дайте немедленную обратную связь для подтверждения, как только действие состоялось (ТАК подчеркивает недавно представленный ответ, gmail отображает подтверждение при отправке сообщения и т. д.).

• Разрешить отменить или исправить возможную ошибку (т. е. в случае SO удалить или отредактировать ответ, Windows позволяет восстановить файл из корзины и т. д.). Для некоторых необратимых действий все еще возможно предоставить возможность отмены, но только в течение ограниченного периода времени (например, разрешение отменить или изменить онлайн-заказ в течение первых 10 минут после его отправки, или позволить отозвать электронное письмо в течение первого Через 60 секунд после того, как сообщение было «отправлено», но фактически находилось в очереди в папке «Исходящие» и т. Д.) 1120260] Windows позволяет восстановить файл из корзины и т. Д.). Для некоторых необратимых действий все еще возможно предоставить возможность отмены, но только в течение ограниченного периода времени (например, разрешение отменить или изменить онлайн-заказ в течение первых 10 минут после его отправки, или позволить отозвать электронное письмо в течение первого Через 60 секунд после того, как сообщение было «отправлено», но фактически находилось в очереди в папке «Исходящие» и т. Д.) 1120260] Windows позволяет восстановить файл из корзины и т. Д.). Для некоторых необратимых действий все еще возможно предоставить возможность отмены, но только в течение ограниченного периода времени (например, разрешение отменить или изменить онлайн-заказ в течение первых 10 минут после его отправки, или позволить отозвать электронное письмо в течение первого Через 60 секунд после того, как сообщение было «отправлено», но фактически находилось в очереди в папке «Исходящие» и т. Д.) 1120260]

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

Довольно легкий сделать, также....

Что-то вроде этого:

Dim strStart As DateTime = Now
While Now < strStart.AddSeconds(5)
    MessageBox.Show("Something just happened", "Pay Attention", MessageBoxButtons.OK)
    If Now < strStart.AddSeconds(5) Then strStart = Now Else Exit While
End While

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

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

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

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

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

И затем флажок с "да, Я беру на себя ответственность за свои действия" и две кнопки:

• "ДА, я ХОЧУ УДАЛИТЬ IT" эта кнопка, должен только быть включен, если флажок проверяется.
• "ДЕРЬМО OH, ЭТО НЕ то, ЧТО я ИМЕЛ В ВИДУ ВО ВСЕЙ" этой кнопке, может всегда включаться.

Если они удаляют таблицу и сетки компании к останову, они уволены. Затем резервное копирование восстанавливается и общее счастливое как Larry [кто бы ни Larry] снова.

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

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

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

Например, вместо OK и Кнопок отмены, сделайте, чтобы они сказали, "Отправляют Счет" и "Возвращаются", или независимо от того, что является соответствующим в контексте Вашего диалогового окна.

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

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

Вот изображение в качестве примера:
_{(источник: apple.com)}

НЕТ. Если Вы будете мешать пользователю нажимать "OK" по ошибке и вынуждать их думать, то они будут все еще только думать тяжелее о том, как нажать "OK" - они не будут думать о фактической вещи, которую они пытаются выполнить. См. статью эксперта по удобству использования Aza Raskin: Никогда не используйте предупреждение, когда Вы будете иметь в виду Отмену. Кавычка:

Что относительно того, чтобы делать предупреждение невозможным проигнорировать? Если это - привыкание на человеческой стороне, которая вызывает проблему, почему бы не разработать интерфейс, таким образом, что мы не можем сформировать привычку. Тем путем мы будем всегда вынуждаться остановиться и думать прежде, чем ответить на вопрос, таким образом, мы будем всегда выбирать ответ, мы имеем в виду. Это решит проблему, правильно?

Этот тип взглядов не является новым: это - подход type-the-nth-word-of-this-sentence-to-continue. В игре Guild Wars, например, удаляя символ требует сначала нажатия на “удалить” кнопку и затем введения имени символа как подтверждение. К сожалению, это не всегда работает. В особенности:

1. Это заставляет нас концентрироваться на необычной задаче под рукой а не на том, хотим ли мы выбросить нашу работу. Таким образом невозможно игнорируемое предупреждение немного лучше, чем нормальное предупреждение: Мы заканчиваем тем, что теряли нашу работу так или иначе. Это (потеря нашей работы) является худшим возможным грехом программного обеспечения.
2. Это является удивительно раздражающим, и потому что это всегда требует нашего внимания, это обязательно отвлекает нас от нашей работы (который является вторым с конца грехом программного обеспечения).
3. Это всегда медленнее и более интенсивно работой, чем стандартное предупреждение. Таким образом это фиксирует третий худший грех — требующий большего количества работы от нас, чем необходимо.

[Если Вы хотите Микромягковатый, этот парнем.NET на MSDN говорит то же самое!]

NOOOOOOOOOOOO!

В одном из наших продуктов у нас есть пользовательская опция потребовать Ctrl+Click для связанных с безопасностью команд.

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

Но если OK/отмены не последователен, который мог бы отбросить или расстроить пользователя.

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

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

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