Подтверждения

Примечание

Это руководство по проектированию было создано для Windows 7 и не обновлялось для более новых версий Windows. Большая часть руководства по-прежнему применяется в принципе, но презентация и примеры не отражают наше текущее руководство по проектированию.

Подтверждение — это модальное диалоговое окно, которое запрашивает, хочет ли пользователь продолжить действие.

Типичное подтверждение.

Подтверждения имеют следующие основные характеристики:

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

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

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

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

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

Примечание: Рекомендации по диалоговым окнам, сообщениям об ошибках, макету и предупреждениям представлены в отдельных статьях.

Это правильный пользовательский интерфейс?

Чтобы определиться, ответьте на вопросы:

• Пользователь задается вопросом, чтобы продолжить действие с двумя или более ответами? В противном случае сообщение не является подтверждением.
• Отображает ли пользовательский интерфейс ошибку или возникшую проблему? В этом случае используйте сообщение об ошибке .
• Требует ли продолжение действия от пользователя сделать выбор, который не имеет подходящего значения по умолчанию? В этом случае может быть уместным подтверждение.
• Существует ли альтернативная конструкция, которая устраняет необходимость в подтверждении? Необходимость подтверждения иногда указывает на недостатки конструкции. Часто существует более лучший вариант проектирования, который не нуждается в подтверждении.
• Выполняет ли пользователь рискованное действие? Если это так, подтверждение уместно, если действие имеет значительные последствия или не может быть легко отменено.
• Может ли пользователь отказаться от задачи? Если да, не подтверждать. Предположим, что пользователи понимают последствия не завершения задачи.
• Имеет ли действие последствия, о которых пользователи могут не знать? В этом случае может быть уместным подтверждение.
• Учитывая текущий контекст, могут ли пользователи выполнить действие по ошибке? В этом случае может быть уместным подтверждение.
• Часто ли пользователи выполняют это действие? Если да, рассмотрите альтернативный дизайн. Частые подтверждения раздражают и не имеют ценности, потому что пользователи учатся реагировать, не думая.
• Влияет ли действие на безопасность? В этом случае может потребоваться подтверждение, даже если предыдущие тесты указывают на обратное.

Принципы проектирования

Ненужные подтверждения раздражают

Первое когда-либо созданное подтверждение Windows, несомненно, выглядело следующим образом:

Исходное раздражающее подтверждение.

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

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

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

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

Рассмотрите альтернативные варианты проектирования

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

• Предотвращение ошибок. Проектировать задачи таким образом, чтобы значительные ошибки было трудно сделать случайно. Например, физически отделять разрушительные команды от других команд и требовать выполнения нескольких действий.
• Укажите отмену. Предоставление возможности отменить изменения действий. Например, удаление файла в Microsoft Windows обычно не требует подтверждения, так как удаленные файлы можно восстановить из корзины. Обратите внимание, что если действие очень легко выполнить, достаточно простого повторного выполнения действия пользователями.
• Отправка отзыва. Сделать нежелательные результаты очевидными. Самостоятельного отмены недостаточно, если пользователи не понимают, когда они совершают ошибку. Например, эффект прямого манипулирования (например, операции перетаскивания) всегда должен быть очевидным.
• Предположим вероятный результат, но сделайте его легко изменить. Если вы не уверены, что пользователи хотят, но есть вероятный, безопасный и безопасный выбор, предположим, что это выбор, четко укажите, что произошло, и сделайте его легко изменить с помощью контекстного меню. Например, Microsoft Word предполагает, что пользователи хотят правильно писать слова. Если он распознает слово с ошибкой и знает вероятную правильную орфографию, Word автоматически вносит исправление, но позволяет пользователям отменить изменения.
• Полностью исключите выбор. Если выбор не важен, пользователи просто не будут заботиться. Лучше упростить программу и исключить выбор.

Для подтверждения требуется обдумать

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

В этом примере причина подтверждения очевидна.

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

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

Неправильно:

В этом примере для правильного ответа требуется обдумать.

Если вы подаете это подтверждение сразу после того, как пользователь дал команду Удалить, скорее всего, пользователь ответит :"Конечно, я хочу удалить!". Пользователь нажимает кнопку Удалить, не задумываясь.

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

Лучше:

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

Если этот подход нецелесообразно, можно использовать кнопки да/нет фиксации.

Кроме того, лучше:

В этом примере при использовании кнопок фиксации да/нет пользователи должны по крайней мере прочитать инструкцию main.

Укажите всю информацию

Если вы собираетесь задать вопрос, необходимо предоставить достаточно информации, чтобы пользователи ответили на этот вопрос интеллектуально. Рассмотрим диалоговое окно Подтверждение замены файла из Windows XP:

Диалоговое окно Подтверждение замены файла в Windows XP.

Предоставляет ли это подтверждение все сведения, которые могут потребоваться пользователям для ответа на вопрос? Прежде чем ответить, рассмотрим наиболее распространенные сценарии пользователей:

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

Пользователи могут реализовать сценарий 1, щелкнув Да, а сценарий 2 — нет. Они могут реализовать сценарий 3, сравнив даты файла и нажав соответствующую кнопку, но обратите внимание, сколько времени потребуется, чтобы определить новый файл, а затем определить соответствующую кнопку, особенно для того, что, вероятно, будет наиболее распространенным сценарием.

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

Подтверждение копирования файла из Windows Vista значительно улучшает обработку этих сценариев, предоставляя дополнительные сведения и добавляя возможность сохранения обоих файлов:

Подтверждение копирования файла Windows Vista.

Предоставление конкретных полезных сведений

Если вы собираетесь задать вопрос, убедитесь, что пользователи понимают вопрос и последствия альтернативных ответов. Рассмотрим следующее подтверждение безопасности windows Internet Обозреватель:

Расплывчатое подтверждение безопасности.

Это подтверждение задает вопрос, на который пользователи не могут интеллектуально ответить. Пользователь запросил, чтобы Windows Internet Обозреватель отображать страницу, и это сообщение неявно рекомендуется неявно с помощью текста и выделения Нет в качестве варианта по умолчанию.

Конкретная проблема безопасности, которая возникает на странице, недостаточно объяснена, поэтому риск продолжения неясен. Какая информация в подтверждении приведет к тому, что пользователь когда-либо нажмет кнопку "Нет"? Из-за расплывчатости сообщения подтверждение, скорее всего, не помешит пользователям продолжать работу, но заставит их чувствовать себя плохо.

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

Как определить, требуется ли подтверждение

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

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

Если вы делаете только три вещи...

1. Убедитесь, что подтверждение действительно необходимо. Там должны быть законные и четкие причины, чтобы не продолжать, и шанс, что иногда пользователи не будут.

2. Если причина подтверждения не очевидна, нажмите кнопки фиксации, которые побуждают пользователей подумать о своем ответе. Как правило, это делается путем выражения подтверждения как "да" или "нет" и предоставления полностью понятных ответов или "Да/Нет".

3. Рассмотрите все сценарии и предоставьте сведения, необходимые для интеллектуального ответа на вопрос.

Варианты использования

Подтверждения имеют несколько шаблонов использования:

Использование	Пример
Обычные подтверждения подтвердите, что пользователь хочет выполнить обычное действие с низким риском.	Эти подтверждения обычно фразы "Вы уверены...?" и часто не показывать это сообщение снова проверка поле, чтобы свести к минимуму их раздражение. Примеры стандартных подтверждений. Примечание: Этот шаблон обычно не требуется, и его следует избегать.
Подтверждения рискованных действий убедитесь, что пользователь хочет продолжить действие, которое имеет определенный риск и не может быть легко отменено.	Так как они имеют риск, эти подтверждения обычно имеют значок предупреждения. Примеры подтверждения рискованных действий.
Подтверждения непреднамеренных последствий подтвердите, что пользователь хочет продолжить действие, которое имеет непредвиденные или непредвиденные последствия.	Помимо вопроса, эти подтверждения указывают на непредвиденные последствия. Поскольку они имеют непредвиденные последствия, эти подтверждения обычно имеют значок предупреждения. примеры непреднамеренных подтверждений последствий. однако этот шаблон требует, чтобы последствия были действительно непреднамеренные. Неправильный: Последствия предназначены здесь, так что это обычное подтверждение.
уточнения; уточнить, как пользователь хочет выполнить действие, которое может иметь неоднозначные или непредвиденные последствия.	Операции перетаскивания могут привести к уточнению, если результат операции может быть неправильно интерпретирован. Примеры уточнений. Примечание: Этого шаблона следует избегать, так как лучше разрабатывать действия без неоднозначных последствий и предполагать наиболее вероятный желаемый результат.
Подтверждения безопасности подтвердите, что пользователь хочет продолжить действие с последствиями безопасности.	Примеры подтверждений безопасности.
Подтверждения скрытых мотивов укажите сведения о действии, но предоставьте их в качестве подтверждения.	Хотя эти диалоговые окна представлены в качестве подтверждений, их реальной целью является обучение пользователей или объявление функций. Пример подтверждения скрытых мотивов. Примечание: Этот шаблон не рекомендуется, так как обычно существует более лучшая, более прямая альтернатива. Например, анимации — это лучший способ показать связь между причиной и следствием.

Рекомендации

Общие сведения

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

Неправильно:

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

Значки

• В подтверждениях не используются значки заголовка окна.

• Значок области содержимого для подтверждения основан на его шаблоне проектирования:

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

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

Неправильно:

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

Кнопки фиксации

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

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

• В противном случае для подтверждения ответов используйте кнопки Да и Нет. Это заставляет пользователей дать подтверждение некоторые мысли, прежде чем отвечать. Никогда не используйте ОК и Отмену для подтверждения.

Правильно:

В этом примере при использовании кнопок фиксации да/нет пользователи должны по крайней мере прочитать инструкцию main.

Неправильно:

В этом примере использование ОК или Отмены вызывает путаницу.

• Чтобы закрыть программу или перезапустить Windows, используйте конкретные ответы на инструкцию main. Чтобы предотвратить недоразумение, не используйте для этой цели закрыть или да/нет.

Правильно:

Неправильно:

В неправильном примере для перезапуска Windows используется значение Да.

Ссылки на команды

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

Хорошо:

Лучше:

В лучшем примере ссылки на команды делают альтернативы понятными.

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

Дополнительные рекомендации и примеры см. в разделе Command Links.

Значения по умолчанию

• Ответ по умолчанию для подтверждения основан на его шаблоне разработки:

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

Больше не показывать это сообщение

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

Неправильно:

По-прежнему неправильно:

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

Дополнительные рекомендации см. в разделе Диалоговые окна.

Массовые операции

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

В этом примере есть параметр для массовых операций.

• Исключите или отложите подтверждение в массовой операции.

Неправильно:

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

Поэтапное представление информации

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

Рекомендации по маркировке см. в разделе Прогрессивное раскрытие информации.

контроль учетных записей

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

Текст

Общие сведения

• Удалите избыточный текст. Найдите избыточный текст в заголовках, main инструкциях, дополнительных инструкциях, областях содержимого, ссылках команд и кнопках фиксации. Как правило, оставьте полный текст в инструкциях и интерактивных элементах управления и удалите все избыточность из других мест.
• Не используйте в тексте слово "warning" или "warning". Если пользователи должны действовать с осторожностью, укажите это с помощью значка предупреждения.

Неправильно:

В этом примере термин "предупреждение" не требуется.

Заголовки

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

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

• Не используйте заголовок, чтобы объяснить, что делать в диалоговом окне, которое является целью инструкции main.
• Если это добавит ясность, начните название со слова Подтвердить.
• Для подтверждения рискованных действий можно добавить имя объекта для дополнительного выделения.

В этом примере диск для форматирования включается в заголовок .

• Используйте прописные буквы в стиле заголовка без прекращения знаков препинания.

Основные инструкции

• Инструкция main для подтверждения основана на схеме проектирования:

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

• Кратко используйте только одно полное предложение. Разделите инструкцию main до важной информации. Если вы должны объяснить что-нибудь больше, используйте дополнительные инструкции.

• Будьте конкретными, если в них участвуют объекты, присвойте им полные имена.

• Используйте положительную формулировку. Положительная формулировка проще понять пользователям.

Правильно:

Включить общий доступ к файлам и принтерам?

Неправильно:

Отключить общий доступ к файлам и принтерам?

Однако выражение должно соответствовать связанной команде, даже если команда выражена отрицательно; поэтому, например, используйте команду disable, чтобы подтвердить команду Disable.

• Хотя нет строгих правил для выражения, эти распространенные фразы подтверждения имеют указанный коннотацию:

  Фраза	Коннотацию
  Вы действительно хотите [выполнить действие]?	Подтверждение прямого результата запроса пользователя.
  Вы хотите [выполнить действие]?	Подтверждение побочных эффектов запроса пользователя.
  Вы хотите [выбрать результат]?	Требуется уточнение.
  [Выполнить действие]?	Без коннотации.

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

В этом примере параметр "постоянно" означает, что действие не может быть отменено.

• Используйте прописные буквы в стиле предложений.

Дополнительные инструкции

• Дополнительные инструкции по подтверждению основаны на схеме проектирования:

Метка	Значение
Шаблон	Дополнительные инструкции
Подтверждения непреднамеренных последствий	Задайте один вопрос, чтобы определить, хочет ли пользователь продолжить.
Все остальные	Объясните все неочевидные причины, по которым пользователь может не захотеть продолжить. К таким причинам относятся: Возможная потеря одного или нескольких из следующих компонентов: Ценный актив, например потеря данных или финансовые потери. Доступ к системе или целостность. Конфиденциальность или контроль над конфиденциальной информацией. Действия, которые являются необратимыми.

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

Документация

При обращении к подтверждениям:

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

Пример. В сообщении Копировать файл щелкните новый файл.