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

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

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

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

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

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

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

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

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

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

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

Чтобы решить, рассмотрите следующие вопросы:

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

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

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

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

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

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

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

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

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

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

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

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

Создание подтверждений требует мысли

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

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

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

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

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

В этом примере правильный ответ требует мысли.

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

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

Лучше:

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

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

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

В этом примере с помощью кнопок фиксации "Да/нет" пользователи могут по крайней мере читать основную инструкцию.

Укажите все сведения

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Шаблоны использования

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

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

Руководящие принципы

Общая информация

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

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

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

Иконки

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

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

  Рисунок	Иконка
  Стандартные подтверждения	Нет значка.
  Подтверждения рискованных действий	Значок предупреждения.
  Непреднамеренные подтверждения последствий	Используйте значок предупреждения, если существует риск, значок компонента, если он доступен; в противном случае значок отсутствует.
  Разъяснения	Если подтверждение включает документ, используйте эскиз документа; в противном случае используйте значок компонента, если он доступен или нет.
  Подтверждения безопасности	Значок предупреждения.
  Подтверждение мотивов Ulterior	Нет значка.

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

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

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

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

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

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

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

правильно:

В этом примере с помощью кнопок фиксации "Да/нет" пользователи могут по крайней мере читать основную инструкцию.

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

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

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

правильно:

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

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

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

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

Допустимо:

Лучше:

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

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

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

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

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

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

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

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

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

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

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

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

пакетные операции

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

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

• Устранение или откладывание подтверждений в массовой операции.

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

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

Прогрессивное раскрытие информации

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

Рекомендации по маркировке см. в прогрессивного раскрытия.

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

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

Текст

Общая информация

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

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

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

Titles

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

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

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

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

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

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

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

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

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

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

• Используйте положительное выражение. Положительное выражение проще для пользователей.

правильно:

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

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

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

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

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

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

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

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

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

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

• Дополнительные инструкции для подтверждения основаны на его шаблоне проектирования:

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

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

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

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

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