Кнопка OK должна находиться перед кнопкой Отмена или после неё? Следовать указаниям операционных систем в этом случае более важно, нежели совершенствовать отдельно взятое диалоговое окно.
Есть масса вопросов в дизайне пользовательских интерфейсов, которые не имеют большого значения для ощущений пользователя. Классический пример: порядок кнопок в диалоговых окнах:
* OK/Отмена
* Отмена/OK
Оба варианта разумны, и люди могут спорить часами о своих предпочтениях:
* Если поставить OK первым, это будет соответствовать естественному порядку чтения во всех языках, где слова читаются слева направо. Многие другие сочетания кнопок также имеют естественную прогрессию (скажем, Да/Нет или Раньше/Дальше). Эти кнопки стоит всегда располагать таким образом, чтобы порядок чтения был логичным — в таком случае, OK/Отмена. Более того, если предположить, что пользователям кнопка OK нужна чаще, чем Отмена, лучше располагать эту опцию первой, чтобы те пользователи, которые в основном пользуются клавиатурой и, в частности, кнопкой Tab для навигации на сайтах, могли добраться до желаемой кнопки на один клик меньше.
* Если поставить OK последней, это улучшит навигацию, потому что диалоговое окно будет “заканчиваться” своим логическим завершением. Кроме того, как в случае с Раньше/Дальше, OK – именно тот выбор, который ведет пользователя дальше, тогда как Отмена возвращает его назад. Таким образом, OK должна располагаться там же, где и Дальше: справа.
В подобных случаях, зачастую неважно, что вы делаете: существуют серьезные аргументы в пользу каждого варианта, и ни один из них не вызовет катастрофы.
Диалоговые кнопки для оффлайн-приложений
Что же касается разработки приложений, нелогичное расположение кнопок может стоить пользователям нескольких минут, если они пропустят или неправильно используют элементы интерфейса. В этом вопросе стоит отталкиваться от расположения кнопок в соответствующих операционных системах.
К сожалению, Windows Vista User Experience Guidelines отличаются от Apple Human Interface Guidelines в отношении кнопок OK/Отмена:
* Windows ставит OK первым
* Apple ставит OK последним
Если вы разрабатываете оффлайн-приложение для одной из этих платформ, вопрос решается просто: Делайте то, что велит вам разработчик платформы.
Диалоговые кнопки для веб-приложений
Если вы разрабатываете веб-приложение, дилемма труднее, но и в этом случае стоит придерживаться порядка, установленного той ОС, которой пользуется большинство ваших посетителей. Логи вашего сервера покажут вам соотношение пользователей Windows по сравнению с Mac OS, Linux или FreeBSD на вашем вебсайте. Конечно, у Windows намного больше пользователей, поэтому логика в большинстве ситуаций такова:
* OK сначала, Отмена потом, как в этом скриншоте из Microsoft Office 2007:
Этот скриншот иллюстрирует еще два правила, касающиеся кнопок в диалоговых окнах:
* Лучше, чтобы название кнопки объясняло, что она делает, чем использовать слова общего характера (типа «OK»). Точное название служит «своевременной подсказкой», придавая пользователям больше уверенности в том, что они выбирают правильное действие.
* Сделайте самые часто нажимаемые кнопки выбором по умолчанию и подсветите их (за исключением тех случаев, когда это может быть опасно; в таких случаях пользователю лучше самому выбрать желаемую кнопку, чем нечаянно активировать нежелательную, случайным нажатием Enter).
Есть масса вопросов в дизайне пользовательских интерфейсов, которые не имеют большого значения для ощущений пользователя. Классический пример: порядок кнопок в диалоговых окнах:
* OK/Отмена
* Отмена/OK
Оба варианта разумны, и люди могут спорить часами о своих предпочтениях:
* Если поставить OK первым, это будет соответствовать естественному порядку чтения во всех языках, где слова читаются слева направо. Многие другие сочетания кнопок также имеют естественную прогрессию (скажем, Да/Нет или Раньше/Дальше). Эти кнопки стоит всегда располагать таким образом, чтобы порядок чтения был логичным — в таком случае, OK/Отмена. Более того, если предположить, что пользователям кнопка OK нужна чаще, чем Отмена, лучше располагать эту опцию первой, чтобы те пользователи, которые в основном пользуются клавиатурой и, в частности, кнопкой Tab для навигации на сайтах, могли добраться до желаемой кнопки на один клик меньше.
* Если поставить OK последней, это улучшит навигацию, потому что диалоговое окно будет “заканчиваться” своим логическим завершением. Кроме того, как в случае с Раньше/Дальше, OK – именно тот выбор, который ведет пользователя дальше, тогда как Отмена возвращает его назад. Таким образом, OK должна располагаться там же, где и Дальше: справа.
В подобных случаях, зачастую неважно, что вы делаете: существуют серьезные аргументы в пользу каждого варианта, и ни один из них не вызовет катастрофы.
Диалоговые кнопки для оффлайн-приложений
Что же касается разработки приложений, нелогичное расположение кнопок может стоить пользователям нескольких минут, если они пропустят или неправильно используют элементы интерфейса. В этом вопросе стоит отталкиваться от расположения кнопок в соответствующих операционных системах.
К сожалению, Windows Vista User Experience Guidelines отличаются от Apple Human Interface Guidelines в отношении кнопок OK/Отмена:
* Windows ставит OK первым
* Apple ставит OK последним
Если вы разрабатываете оффлайн-приложение для одной из этих платформ, вопрос решается просто: Делайте то, что велит вам разработчик платформы.
Диалоговые кнопки для веб-приложений
Если вы разрабатываете веб-приложение, дилемма труднее, но и в этом случае стоит придерживаться порядка, установленного той ОС, которой пользуется большинство ваших посетителей. Логи вашего сервера покажут вам соотношение пользователей Windows по сравнению с Mac OS, Linux или FreeBSD на вашем вебсайте. Конечно, у Windows намного больше пользователей, поэтому логика в большинстве ситуаций такова:
* OK сначала, Отмена потом, как в этом скриншоте из Microsoft Office 2007:
Этот скриншот иллюстрирует еще два правила, касающиеся кнопок в диалоговых окнах:
* Лучше, чтобы название кнопки объясняло, что она делает, чем использовать слова общего характера (типа «OK»). Точное название служит «своевременной подсказкой», придавая пользователям больше уверенности в том, что они выбирают правильное действие.
* Сделайте самые часто нажимаемые кнопки выбором по умолчанию и подсветите их (за исключением тех случаев, когда это может быть опасно; в таких случаях пользователю лучше самому выбрать желаемую кнопку, чем нечаянно активировать нежелательную, случайным нажатием Enter).