Сообщение об ошибках. Субъективная удовлетворенность
         

Как избежать сообщений об ошибках


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

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

Вот такое диалоговое окно вынуждены наблюдать пользователи, которые захотят перевести файл в PROMT’e. Банальное открытие файла разработчики превратили в увлекательную игру «Отгадай формат». Не понятно, почему программа сама не может определить, какой формат у открываемого файла. Тем более не понятно, зачем при открытии файла указывать «направление перевода», ведь это можно сделать опционально, уже непосредственно в программе. Самое интересное, что у этой истории есть продолжение.

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

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

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

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

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

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

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

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

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


Каким должно быть сообщение об ошибке


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

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

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

Итак, исходное сообщение об ошибке гласит: «Не удается сохранить файл «D:\Только для чтения.doc». Файл с этим именем уже существует и доступен только для чтения. Сохраните файл под другим именем или в другой папке». Каким образом его можно улучшить?

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



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

Таким образом, сообщение об ошибке должно стать не только сообщением – оно должно позволять разблокировать файлы, разблокировать которые возможно (т.е. записанные не на компакт-диске).

Также необходимо помнить следующие общие правила:

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



Пузырь как альтернатива сообщениям об ошибке


В Windows появился элемент управления, значительно лучше предназначенный для показа сообщений: пузырь (balloon).

Пример пузыря

Пузырь, по сравнению с диалоговым окном, имеет существенные достоинства.

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

К сожалению, пузыри имеют и недостатки:

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



Сообщение об ошибках


<<к предыдущей главе     к следующей главе >>

Как избежать сообщений об ошибках Каким должно быть сообщение об ошибке Пузырь как альтернатива сообщениям об ошибке Сообщения о завершении операции

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

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

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

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



Типичное сообщение об ошибке, вызванное нежеланием системы показать пользователю границы его действий. К тому же из сообщения не понятно в чем собственно ошибка, а междометьем «или» система расписывается в своей некомпетентности. Все усугубляется тем, что система не предоставляет ни одного варианта решения проблемы (еще бы! она ведь даже не знает точно, в чем она заключается). Даже опытный пользователь, впервые столкнувшись с этой проблемой, потратит на ее расшифровку несколько минут. Между прочим, это Office XP.

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

Пример подобного сообщения. Для кого неверное? И кто, собственно, виноват, система или пользователь?

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

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

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


Сообщения о завершении операции


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

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

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

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

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

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

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

<< предыдущая глава следующая глава >>
 Дизайн, информационное наполнение -
Александр Ширышев