Эргономика и юзабилити пользовательского интерфейса программного обеспечения (стр. 2 )

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

1.3.1. Закон Фитса 1.3.2. Методы повышения доступности кнопки 1.3.3. Уменьшение числа манипуляций 1.3.4. Уменьшение необходимости ввода данных 1.3.5. Память программы

1.3.1. Закон Фитса

В 1954 году Поль Фитс (Paul Fitts) сформулировал правило, в наиболее практичной формулировке ставшее известным как Закон Фитса: Время достижения цели обратно пропорционально размеру цели и дистанции до цели. Рассмотрим его поподробнее.

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

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

Схема 1.3.1-1.

В одномерном случае, при котором размер объекта вдоль линии перемещения курсора обозначается как S, а дистанция от начальной позиции курсора до объекта - как D, закон Фитса формулируется следующим образом:

(Константы а и b устанавливаются опытным путем по параметрам производительности человека. Для приближенных вычислений можно использовать следующие значения: a = 50, b = 150)

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

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

1.3.2. Методы повышения доступности кнопки

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

У этого правила есть два не сразу заметных следствия. Чтобы «бесконечно» ускорить нажатие кнопки, её, во-первых, можно сделать бесконечного размера и, во-вторых, дистанцию до неё можно сделать нулевой.

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

Понятно, что кнопка, расположенная в углу экрана, имеет «еще более бесконечные» размеры, если так вообще можно сказать (т. е. не важно даже, с какой точностью перемещали мышь). Для достижения такой кнопки от пользователя требуется всего лишь дёрнуть мышь в нужном направлении, не заботясь о её скорости и не делая попыток остановить её в нужном месте. Это делает такие кнопки наиболее доступными для пользователя. Именно поэтому, например, меню MacOS многократно эффективней меню Windows: если в MacOS меню всегда расположено впритык к верхнему краю экрана, то в Windows меню отделено от края экрана полосой заголовка окна программы (Title Bar).

Панель задач (Taskbar) в Windows вызывает удивление –расположена впритык к краю экрана, но кнопки отделены от края экрана тремя пустыми пикселями. И скорость работы снижается, и место теряется.

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

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

Если говорить о клавиатуре, она не требует особенной точности движений и, как таковая, обеспечивает большую скорость работы. Тем не менее, и она не без проблем. Во-первых, изначально она не предназначена для перемещения фокуса ввода по экрану, что приводит к существенным трудностям (в том смысле, что самопроизвольно клавиатура не позволяет перемещать фокус с достаточной эффективностью – для этого надо специально проектировать экран). Если клавиатура не работает, приходится пользоваться мышью, но перемещение руки с клавиатуры на мышь и потом обратно занимает почти секунду, что слишком много. Во-вторых, работа с клавиатурой подразумевает использование горячих клавиш (именно потому, что перемещение по экрану с клавиатурой затруднено). Но хотя горячие клавиши существенно увеличивают скорость работы, плохо то, что их трудно запомнить. Таким образом, они являются прерогативой опытных пользователей и для многих людей неприемлемы. Более того, их популярность во многом основывается на субъективных критериях: воспринимаемая пользователем скорость работы с клавиатуры выше, чем скорость работы с мышью (хотя секундомер говорит обратное). Это значит, что на клавиатуру особо рассчитывать не стоит: помимо набора текста большинство людей пользуются только клавишами пробела и возврата каретки.

1.3.3. Уменьшение числа манипуляций

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

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

После этого:

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

1.3.4. Уменьшение необходимости ввода данных

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

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

1.3.5. Память программы

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

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

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

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

У Алана Купера [6] идея того, что программа может предсказать действия пользователя, обозначается термином "связность задач" (task coherence). Когда человек работает с программой, существует 80-процентная вероятность, что в следующий раз он сделает то же самое, что и в предыдущий. Таким образом, можно со значительной долей уверенности предсказать поведение пользователя, просто запомнив его последнее действие. Это позволит значительно уменьшить число вопросов, которые программа задает пользователю.

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

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

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

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

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

Связность задач может предсказать, что именно будет делать пользователь в будущем со значительной, но не абсолютной вероятностью. Если программа может надежно предсказать действия пользователя в 80% случаев, это значит, что в 20% случаев она будет неправа, потому что в каждом конкретном случае она не знает, в 20 она или в 80 процентах. Может показаться, что это как раз тот случай, когда нужно спросить пользователя, но это не так. Вместо предоставления выбора, программа должна продолжать делать то, что она считает наиболее подходящим, вместе с тем давая пользователю возможность изменить или отменить это. Если возможность отмены достаточно легка и понятна, пользователь не будет беспокоится о ней. В крайнем случае, ему придется отменять решение программы только в 2-х случаях из 10, вместо того, чтобы иметь дело с излишним диалоговым окном 8 раз из 10.

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

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

1.4. Длительность реакции системы

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

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

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

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

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

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

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

1.4.1. Фоновый режим выполнения задач

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

Сетевая печать была асинхронной операцией более 15 лет. Пользователи нажимали кнопку “Печать” и шли заниматься своими делами, пока шел процесс. Над проблемой печати стали работать в первую очередь, потому что

Печать отнимает много времени Печать не требует вмешательства пользователя Общее время выполнения задачи предсказать нельзя Следующее задача пользователя обычно не связана с результатами печати

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

Та же самая ситуация сложилась сейчас с Интернетом. Загрузка страниц занимает длительное время, не требуя вмешательства пользователя в этот процесс, и предугадать, будет ли она длиться 5 секунд или минуту, невозможно.

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

3.  Типы человеческих ошибок

Наибольшее количество человеческих ошибок при пользовании ПО раскладывается на четыре типа (сильно упрощенно, разумеется):

3.1. Ошибки, вызванные недостаточным знанием предметной области.

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

3.2. Опечатки.

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

3.3. Не считывание показаний системы.

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

3.4. Моторные ошибки.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

4.3.1.1.  Ошибочно выбранный визуальный сюжет элемента.

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

4.3.1.2. Нестандартно выбранный сюжет элемента или реализация сюжета.

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

4.3.1.3. Избыточная детализация сюжета.

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

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

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

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

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

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

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

Рис. 4.3.2-1.

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

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

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

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

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

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

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

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

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

Рис 4.5-1. Пример крутилок.

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

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

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

Рис 4.5-2. Классический пример использования ползунка. (рис 4.5-2)

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

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

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

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

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

Рис. 4.6-1.

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

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

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