Переключение OK-Cancel и Cancel-OK для обеспечения взаимодействия с пользователем?

Question

Это связано с вопросом OK-Cancel или Cancel-OK? .

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

Это действительно имеет смысл? Это хороший способ заставить пользователя «сначала подумать / прочитать, а затем нажать»? Существуют ли другие концепции, применимые к такой ситуации?

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

Answer 1

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

То, что вы могли бы сделать, это использовать глаголы или существительные вместо типичных надписей Windows OK / Cancel. Это мгновенно принесет вам пользу, не жертвуя предсказуемостью.

Answer 2

NOOOOOOOOOOOO!

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

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

Answer 3

NO. Если вам будет сложнее нажимать на кнопку ОК по ошибке и заставлять их думать, они будут все же только усерднее думать о том, как нажимать ОК - они не будут думать о том, что они пытаются выполнять. См. Статью эксперта по юзабилити Азы Раскина: Никогда не используйте предупреждение, когда вы имеете в виду Отменить . Цитата:

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

Этот тип мышления не нов: это тип-n-е-слово-это-предложение-продолжить. В игре Guild Wars, для Например, удаление символа требует сначала нажмите кнопку «Удалить» и затем введите имя персонажа как подтверждение. К сожалению это не всегда работает В частности:

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

[Если вам нужен Microsoftish, этот от парня .NET в MSDN говорит то же самое!]

Answer 4

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

Например, вместо кнопок «ОК» и «Отмена» попросите их сказать «Отправить счет» и «Вернуться», или что угодно в контексте вашего диалога.

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

Сайт Apple Human Interface Guideline - отличный справочник, который очень удобочитаем. Эта страница на этом сайте рассказывает о диалогах.

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

Answer 5

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

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

Answer 6

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

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

Примерно так:

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

Answer 7

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

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

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

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

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

И затем флажок «Да, я принимаю ответственность за свои действия» и две кнопки:

• «ДА, Я ХОЧУ УДАЛИТЬ ЭТО» эта кнопка должна быть включена, только если установлен флажок.
• «О, БЕЗОПАСНОСТЬ, ЭТО НЕ ТО, ЧТО Я ВСЕ ЭТО ЗНАЧИЛ», эта кнопка всегда может быть включена.

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

Answer 8

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

Answer 9

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

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

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

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

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

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

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

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

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

Answer 10

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