Методы предотвращения ошибок

         

Блокировка потенциально опасных действий до получения подтверждения


Блокируйте системные файлы.

Команда удаления файла в любой операционной системе снабжена требованием подтвердить удаление. Этот метод приносит пользу только начинающим пользователям, которые проверяют каждый свой шаг. Для опытных пользователей это диалоговое окно с требованием подтверждения не работает. Для них это что-то вроде ритуала: «после нажатия на клавишу Delete выскочит окошко, в котором нужно нажать ОК». Естественно, что даже в случае неверно выбранного файла это диалоговое окно не сможет предотвратить его удаления. К тому же оно без пользы отвлекает пользователя и тратит его время. Новичков же окно лишний раз пугает, уменьшая субъективное удовлетворения от системы.

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

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

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

наверх к оглавлению



Методы предотвращения ошибок


Необходимо стремиться минимизировать количество ошибок, поскольку только это позволяет сберечь время (т.е. повысить производительность) и сделать пользователей более счастливыми за счет отсутствия дискомфорта.

Суммируя, при борьбе с ошибками нужно направлять усилия на:

плавное обучение пользователей в процессе работы; снижение требований к бдительности; повышение разборчивости и заметности индикаторов.

Дополнительно к этим трём направлениям, есть и четвертое: снижение чувствительности системы к ошибкам. Для этого есть три основных способа, а именно:

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


Повышение разборчивости и заметности индикаторов


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

Существуют два основных критерия оценки эффективности интерактивного визуального элемента, это:

качество/скорость восприятия элемента; физическая реализация элемента.

Качество/скорость восприятия элемента



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

Причинами ухудшения восприятия элемента являются:

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


Пиктограмма дома в Web исторически обозначает переход на титульную страницу сайта. Благодаря этому пользователю не нужно проявлять излишнюю мыслительную активность при определении значении такого элемента (вообще говоря, человеческий мозг наиболее успешно решает задачи, метод решения которых основан на проведении аналогии). Таким образом, чем стандартнее сюжет, тем выше скорость его восприятия. Важна также стандартность реализации выбранного сюжета, например, пиктограмма перехода на титульную страницу, выполненную как изображение избушки на курьих ножках является скорее нестандартной и будет вызывать замешательство, по крайней мере на первых порах. В таких условиях наилучшим методом выбора сюжета является поиск репрезентации, привычной целевой аудитории. Источниками стандартных сюжетов/реализаций являются (отсортированы по степени знакомства с ними пользователей): операционная система, системы конкурентов, среда. Таким образом, сюжет, взятый из операционной системы всегда оптимален (поскольку наиболее знаком). Избыточная детализация сюжета.
Объекты реального мира перегружены мелкими деталями. Перенос этих деталей в сюжет символа неоправдан — в реальном мире эти детали нужны (придают объекту уникальность), а на пиктограмме лишь отвлекают внимание и тем самым замедляют распознавание. Более того, скорость восприятия чистых абстракций чаще всего выше скорости восприятия даже максимально упрощенных символов, т.е. символ человеческого лица, нарисованный по принципу "круг, две точки и две черточки" воспринимается быстрее и легче, нежели тот же символ, нарисованный, например, в стилистике комиксов.

Физическая реализация элемента

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

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

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

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

В данном примере элементы никак не разграничены по функциям: кнопки Site Map и Help выполнены не как остальные кнопки, но как надписи. В результате многие пользователи либо будут безуспешно нажимать псевдокнопку Quotes, либо никогда не нажмут кнопки Site Map и Help.

наверх     к оглавлению


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


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

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

Пример крутилок. Как не крути, а больше 360 градусов не накрутишь

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

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

Классический пример использования ползунка.

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

наверх     к оглавлению



Самостоятельный выбор параметров


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

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

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

Чем меньше элементов управления, тем меньше вероятность ошибки. Система может уменьшить число элементов, если она знает сама, какими именно параметрами она должна руководствоваться.

Главной причиной появления этих диалоговых окон является печать нескольких копий. Причем есть простая зависимость – «количество копий обратно пропорционально частоте печати такого количества», т.е. сто копий печатают примерно в сто раз реже, чем печатают одну копию. Стандартное диалоговое окно печати содержит также область выбора принтера из числа установленных в системе. Большинство же пользователей имеет только один принтер. Так зачем заставлять это большинство каждый раз вдумчиво воспринимать совершенно не нужные им элементы интерфейса?

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

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

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

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

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

здравый смысл разработчика системы; предыдущие установленные параметры; наиболее часто устанавливаемые параметры.

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

наверх     к оглавлению