Текст книги "Человеко-компьютерное взаимодействие"

4.2. Скорость и производительность работы

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

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

Этому соответствуют два наиболее распространенных устройства управления компьютером – клавиатура и мышь. Клавиатура требует сравнительно точных движений. Мышь, напротив, инерционна – есть разница между медленным и быстрым ее перемещением, сильным и слабым приложенным усилием. Поэтому оптимизация использования мыши может существенно повысить общую скорость работы. Мышь не является точным инструментом. Соответственно, мышь не предназначена для очень точных, в 1, 2 или даже 5 пикселей, манипуляций; в графических программах всегда есть возможность перемещать объекты клавишами со стрелками. По этим причинам любой слишком маленький интерфейсный элемент будет вызывать проблемы у пользователей. Еще в 1954 г. Поль Фиттс (Paul Fitts) сформулировал правило, ставшее известным как закон Фиттса: время достижения цели прямо пропорционально дистанции до цели и обратно пропорционально размеру цели. Проще говоря, лучший способ повысить доступность виртуальной кнопки заключается в том, чтобы делать ее большой и располагать ближе к курсору.

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

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

Что касается клавиатуры, то, как сказано выше, она требует сравнительно более высокой точности по сравнению с мышью. Но перемещение руки с клавиатуры на мышь и потом обратно занимает почти секунду. Кроме того, работа с клавиатурой подразумевает использование «горячих» клавиш (именно потому, что перемещение по экрану с помощью клавиатуры затруднено). Но хотя «горячие» клавиши существенно увеличивают скорость работы, плохо то, что их трудно запомнить. Таким образом, они являются прерогативой опытных пользователей и для многих людей неприемлемы. Более того, их популярность во многом основывается на субъективных критериях: воспринимаемая пользователем скорость работы с клавиатурой выше, чем скорость работы с мышью (хотя секундомер показывает обратное).

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

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

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

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

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

• на каком шаге он остановился;

• какие команды и параметры он уже дал системе;

• что именно он должен сделать на текущем шаге;

• куда было обращено его внимание на момент отвлечения.

Рис. 4.1. Три варианта индикации степени заполнения экранной формы (2-й и 3-й варианты значительно лучше)

Предоставлять пользователю всю эту информацию лучше всего визуально. Разберем это на примере. Чтобы показать пользователю, на каком шаге он остановился, традиционно используют конструкцию типа «Страница N из М». К сожалению, эта конструкция работает не слишком эффективно, поскольку не визуальна. Однако существуют и визуальные способы. Например, когда читатель держит в руках книгу, он может понять, в какой ее части он находится, по толщине левой и правой частей разворота. Можно воспользоваться этой метафорой и на экране: варьировать толщину левых и правых полей окна (рис. 4.1).

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

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

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

• к сокращению длительности чтения, редактирования и поиска информации;

• уменьшению времени навигации и выбора команды;

• повышению общей продуктивности пользователя, заключающейся в объеме обработанных данных за определенный период времени;

• увеличению длительности устойчивой работы пользователя и др. Сокращение непроизводственных затрат и усилий пользователя -

важная составляющая качества программного обеспечения.

4.3. Человеческие ошибки

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

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

• плавное обучение пользователей в процессе работы;

• снижение требований к бдительности;

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

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

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

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

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

• толерантность (терпимость) системы к ошибкам пользователя и определенный стиль сообщений об ошибке.

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

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

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

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

Проверка всех действий пользователя перед их принятием. Данной проверкой можно также успешно защищать вводимую пользователем информацию, в особенности числовую. Дело в том, что большинство числовых данных имеет некий диапазон возможных значений, так что даже в ситуациях, когда невозможно проверить корректность данных, можно, по крайней мере, убедиться, что они попадают в нужный диапазон. В большинстве операционных систем есть специальный элемент управления, именуемый «крутилкой» (spinner). Фактически это обычное поле ввода, снабженное двумя кнопками для модификации его содержимого (в сторону уменьшения и увеличения). Интересен он тем, что пользователь может не использовать клавиатуру для ввода нужного значения, установив его мышью. Этот элемент имеет то существенное достоинство, что при использовании мыши значение в этом элементе всегда находится в нужном диапазоне и обладает нужным форматом. Отсюда рекомендация: всегда показывайте границы диапазона во всплывающей подсказке. Но что делать, если пользователь ввел некорректное число с клавиатуры? Лучше индицировать возможную ошибку заменой цвета фона этого элемента, скажем, на розовый. В тех же случаях, когда количество возможных значений невелико, лучше использовать другой элемент управления – ползунок (рис. 4.2).

Рис. 4.2. Ползунок

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

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

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

Рис. 4.3. Диалоговое окно печати в MS Word

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

• здравый смысл разработчика системы;

• предыдущие установленные параметры;

• наиболее часто устанавливаемые параметры.

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

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

1) исправляемые во время совершения действия, например пользователь перетаскивает файл в корзину и во время перетаскивания замечает, что он пытается стереть не тот файл;

2) которые исправить можно, но с трудом, например реальное стирание файла, при котором никаких его копий не остается;

3) исправляемые после выполнения действия, например после ошибочного уничтожения файла его копия переносится из корзины;

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

Ошибок из четвертого пункта нужно всеми силами избегать, не считаясь с потерями, поскольку каждая такая ошибка обходится гораздо дороже, чем любая ошибка из пункта третьего. То же касается ошибок из второго пункта, поскольку они гораздо дороже, чем любые ошибки из первого пункта. С ошибками из четвертого пункта все ясно. Всякий раз, когда мы теряем возможность проверить валидность данных или самой системы, мы вступаем на скользкий путь. Примеров неисправляемых ошибок из-за ошибок в программном обеспечении множество – межпланетные зонды, улетающие не туда, коммерческие договоры, в которых обнаруживаются ошибки, ошибки обработки различных данных и т.д. Разумеется, такие ошибки, как правило, обнаруживаются, но проблема в том, что к моменту обнаружения их уже не исправить. Именно поэтому эти ошибки гораздо хуже тех, которые исправить трудно, но которые сразу видны. Ошибки первого типа (исправляемые «во время») гораздо лучше ошибок второго типа (исправляемых «после»). Объективное объяснение простое: ошибки, исправляемые после, снижают производительность работы. Всякий раз, когда пользователь обнаруживает, что он совершает ошибку, ему приходится возвращаться назад на несколько этапов. Более того, чтобы исправить совершенную ошибку, от пользователя требуется понять, что ошибка совершена, как ее исправить и как потратить время на исправление ошибки. В результате много времени уходит не на действие (т.е. на продуктивную работу), а на исправление ошибок.

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

Теперь пора рассказать, как избавиться от ошибок, исправляемых после. Понятно, что исправить что-либо «во время» можно только тогда, когда во время совершения действия видно, что происходит и как это действие повлияет на изменяемый объект. Следовательно, чтобы дать пользователям возможность исправлять на ходу, необходима обратная связь. К сожалению, это простое соображение имеет существенный недостаток: вводить в систему обратную связь получается не всегда. Дело в том, что ее не любят программисты. Мотивируется это тем, что обратная связь плохо влияет на производительность системы. На самом деле ее реализация просто сопряжена с дополнительной работой. Иногда, впрочем, соображения о производительности системы действительно правомочны. Так что даже если программисты правы, когда утверждают, что система «будет безбожно тормозить», полезно вспомнить, что производительность связки «человек-ПИ» всегда важнее производительности системы как таковой (правильнее сказать, что влияние этой связки на производительность системы значительно серьезнее, чем кажется многим программистам). Можно спроектировать обратную связь весьма скромно. Иногда так получается даже лучше. Например, с помощью ползунков на линейке в MS Word можно менять абзацные отступы, при этом обратная связь есть, но не полная: вместо перманентного переформатирования документа по экрану двигается полоска, показывающая, куда передвинется текст. Это лучше, чем «дрыганье» текста вслед за передвигаемой полоской, которое будет только раздражать.

Стиль сообщений об ошибках

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

• недостаточно гибка, чтобы приспособиться к его действиям;

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

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

Разберем это подробнее. Многие программы искренне «уверены», что пользователь царь и бог, и когда оказывается, что пользователь хочет невозможного (с их точки зрения), они начинают «чувствовать разочарование». Проявляют же они свое чувство сообщениями об ошибках. В действительности множество действий пользователя направлено не на то, чтобы сделать так, а не иначе, а на то, чтобы сделать примерно так, как хочется. Пользователю часто нет дела, можно ли добиться точного результата или нет. Показывать ему в таких случаях диалог об ошибке глупо, поскольку пользователю не нужно ничего знать. Ему нужен результат. Вот что бывает (рис. 4.4), если пользователь попытается ввести значение, которое ему нужно, но которое система не умеет обрабатывать. Тут возможны три решения. Во-первых, при проектировании системы можно более тщательно подходить к выбору ее функциональности. Во-вторых, можно просто игнорировать неправильность значения, округляя его до ближайшего возможного (индицируя, возможно, самостоятельность действий системы однократным миганием соответствующего поля ввода). В-третьих, вместо обычного поля ввода можно использовать «крутилку».

Рис. 4.4. Примеры диалога об ошибке

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

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

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

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

Рис. 4.6. Примерно так пользователи воспринимают любые сообщения об ошибках

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

1. В чем заключается проблема?

2. Как исправить эту проблему сейчас?

3. Как сделать так, чтобы проблема не повторилась?

При этом отвечать на эти вопросы нужно возможно более вежливым и понятным пользователям языком. В качестве примера идеального сообщения об ошибке удобно взять какое-либо существующее сообщение (из тех, которые точно нельзя просто изъять из системы) и попытаться это сообщение улучшить. Например, попытаемся улучшить уже упоминавшееся сообщение о невозможности перезаписать заблокированный файл. Итак, сообщение об ошибке гласило: «Не удается сохранить файл „В:Только для чтения.скю“. Файл с этим именем уже существует и доступен только для чтения. Сохраните файл под другим именем или в другой папке». Это довольно неплохое сообщение, во всяком случае, оно гораздо лучше, чем «Указано неверное число». Но и его можно улучшить.

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

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

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

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

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

Рис. 4.7. Улучшенное сообщение об ошибке

• диски, на которые ничего нельзя записать, не показываются в диалоговом окне сохранения файлов;