Остановите сообщения об ошибках!
Когда пользователь видит на экране сообщение об ошибке, он чувствует себя так же, как если бы кто-нибудь громким голосом и в снисходительном тоне сказал ему: "Фатальная ошибка, приятель. Что за ерунду ты ввел". Пользователям это очень не нравится! Программы, работающие таким образом, имеют чрезвычайно плохой интерфейс. Однако, большинство программистов на это просто пожимают плечами, продолжая создавать окна сообщений об ошибках. Они просто не знают, как создавать надежные программы.
Первые компьютеры были маленькими, маломощными и дорогими. Операторами этих машин были ученые в белых халатах, которые понимали, что нужно процессору, и не обижались, увидев сообщение об ошибке. Они знали, насколько сложна работа компьютера. Они не имели ничего против появления сообщения типа "Abort, Retry, Fail?" или др. Вот так и зародилась традиция отношения программы к человеку, как к процессору. С самого начала развития компьютерной техники программисты уяснили, что самый верный способ взаимодействия программы с пользователем - это требование ввода и выражение недовольства, когда пользователь не смог достичь уровня совершенства процессора.
Я называю это отношение силиконовым ханжеством. Примеры силиконового ханжества встречаются везде, где программа требует от пользователя действовать так, как это нужно ей, вместо того чтобы адаптироваться к нуждам человека. Силиконовое ханжество - это цикл негативной обратной связи, в котором программа игнорирует пользователя, когда он делает то, что она хочет, и кричит на него при малейшем отклонении.
Силиконовое ханжество необходимо для взаимодействия внутри программы. Каждый хороший программист знает, что если модуль А передал ошибочные данные модулю В, модуль В должен сразу же отбросить эти данные, сгенерировав подходящее сообщение об ошибке. Отсутствие такого взаимодействия означает серьезную ошибку в проектировании модулей. Но люди - не модули программы. Не только программа не должна отклонять ввод с сообщением об ошибке, но и ее разработчик должен переосмыслить само понятие "ошибочных данных". Когда данные получены от человека, программа должна предположить, что они правильные, потому что человек важнее, чем программа. Вместо того чтобы отклонить ввод, программа должна его проанализировать и понять. Программа может предотвратить возможные проблемы, гарантируя невозможность введения ошибочных данных.
У людей есть эмоции и чувства - у компьютеров их нет. Когда один кусок кода отклоняет ввод другого, последний не хмурится и не страдает. Процессору все равно, даже если вы выключите компьютер.
С другой стороны, у людей эмоции есть, и они могут выйти из-под контроля. Когда вы предлагаете что-то коллеге по работе и он (она) говорит вам "Заткнись, это глупо!", вы страдаете, это задевает ваши чувства. Вы начинаете думать, что вас не так поняли. Вы смотритесь в зеркало - все ли у вас в порядке с зубами. Все эти действия - часть человеческой натуры.
Люди, однако, хорошо реагируют на позитивную обратную связь. Представьте себе, что всякий раз, когда программа смогла понять информацию, которую они ввели, она показывает некий индикатор успешного завершения процесса. Если программа не может найти смысл во введенной информации, она никак не реагирует, что указывает на ошибку. "Если не можешь сказать ничего хорошего, лучше молчи".
Взаимодействие человека с молотком - показательный пример взаимодействия между пользователем и инструментом. Когда я использую молоток неправильно, он не выдает мне сообщения об ошибке. Он не пытается скорректировать мои действия. Он не указывает на отсутствие у меня навыков плотника. Он просто плохо забивает гвозди. Молоток дает хорошие результаты при правильном использовании, плохие - при неправильном.
Одна из причин, почему программы так трудны в обучении, - это то, что они редко предлагают позитивную обратную связь. С позитивной обратной связью люди учатся лучше. Люди хотят эффективно использовать свои программы. Они не хотят, чтобы программа била их по рукам в случае ошибки. Человеку нужно вознаграждение или, по крайней мере, уведомление в случае успеха.
Сторонники негативной обратной связи могут привести множество примеров ее эффективности для руководства людьми. Эти примеры верны, но почти всегда негативная обратная связь нужна, чтобы удержать людей от того, что они хотят сделать, но не должны. Но когда дело касается того, что люди хотят сделать, лучше всего связь позитивная. Представьте себе лыжного инструктора, который кричит на вас, или официанта в ресторане, который громко объявляет, что ваша кредитная карточка недействительна.
Помните, что мы говорим о недостатках негативной обратной связи от компьютера. Негативная обратная связь от другого человека, хотя и неприятна, может быть оправдана в определенных обстоятельствах. Сержант по крайней мере обучает вас для того, чтобы вы выжили в бою, а строгий профессор готовит вас к превратностям реальной жизни. Но получить негативную обратную связь от программы - любой программы - равносильно оскорблению. Сержант и профессор по крайней мере люди, имеющие определенный жизненный опыт. А программа - это мусор, пустое место. Она меньше, чем ничто. Слышать от программы, что вы сделали ошибку - унизительно. Пользователям не нравится быть униженными.
Ничто из того, что происходит в компьютере, не может быть достаточной причиной для оправдания унижения человека. Ничто. Не имеет значения то, насколько важна для вас целостность базы данных, она не стоит того, чтобы оскорблять пользователя. Если целостность данных такая важная вещь для вас, вы должны позаботиться о методах ее поддержания без унижения пользователя.
Вот три основных способа избежать сообщений об ошибках:
1) Делайте ошибки невозможными;
2) Давайте позитивную обратную связь;
3) Проверяйте, не редактируйте.
Наилучший способ избежать сообщений об ошибках это сделать так, чтобы пользователь не смог их совершить. Вместо требования ввести данные с клавиатуры, предоставьте пользователю список возможных вариантов выбора. Вместо требования ввести код штата вручную, предоставьте пользователям возможность выбрать требуемое значение из списка доступных кодов штатов или даже с помощью карты.
Еще один прекрасный способ избежать сообщений об ошибках - это сделать программу достаточно умной для того, чтобы избежать вопросов к пользователю. Многие сообщения об ошибках говорят что-то вроде "Неверные данные. Пользователь должен ввести ХХХХ". Почему же программа не может, зная, что должен ввести пользователь, ввести ХХХХ сама? Вместо запроса у пользователя имени файла на диске, давая возможность выбрать несуществующий файл, программа может запомнить, с какими файлами велась работа последний раз, и предоставить их список.
Позитивная обратная связь - хороший способ вознаградить пользователя за правильное пользование программой. Наилучший способ позитивной обратной связи это звук. К несчастью, долгие годы окна с сообщениями об ошибках сопровождались громким и пронзительным гудком, и звук стал ассоциироваться с ошибкой. Этот звук - публичное клеймо ошибки пользователя. Он громко объявляет всем в пределах слышимости, что вы только что сделали нечто глупое. Все то же силиконовое ханжество создало неоспоримую веру в голове большинства разработчиков программ, что звук является плохим признаком, и никогда более не должен считаться частью дизайна интерфейса. На самом деле это не так.
В реальной жизни любой объект или система, за исключением компьютерных программ, используют звук для позитивной обратной связи. Закрывая дверь, мы определяем, что она защелкнулась, услышав щелчок, тишина означает, что дверь еще не закрыта. Когда мы говорим с кем-либо и они отвечают "Ага" или "Да-да", мы знаем, что наши слова до них доходят. Когда они молчат, значит мы говорим неубедительно. Когда мы поворачиваем ключ зажигания и ничего не слышим, значит у нас проблемы. Когда мы включаем ксерокс, а он молчит, вместо того чтобы громко гудеть, мы понимаем - значит что-то не так.
Наши программы должны давать нам постоянные небольшие звуковые подсказки, похожие на тихие щелчки кнопок клавиатуры. Наши программы были бы более дружественными и простыми в использовании, если бы они издавали едва заметные, но легкоузнаваемые звуки, когда действия пользователя верны. Программа может выдавать мягкий звук каждый раз, когда пользователь ввел верное значение. Если программа не понимает введенную информацию, она молчит. В этом случае пользователь может сразу скорректировать данные безо всякого смущения. Когда пользователь начинает перетаскивать иконку, программа может коротко щелкнуть, а во время движения объекта производить тихое шипение. Когда объект находится над областями, где его нельзя оставить, звук меняется на что-нибудь более неблагозвучное. Когда наконец пользователь отпустит кнопку мыши, он будет вознагражден тихим "Да!", если действие завершено успешно, и тишиной из динамиков, если действие не имеет смысла.
Некоторые люди часто оспаривают этот аргумент, говоря, что пользователи не любят звуковую обратную связь, что они обижены звуками, издаваемыми компьютером, и что им не нравится, когда компьютер гудит и пикает на них. На это я скажу, что поведение людей обусловлено следующими установками:
1) Компьютеры всегда производят звуки, когда программа выдает сообщение об ошибке;
2) Компьютерные звуки обычно громкие, монотонные и неприятные.
Если дать людям выбор между звуком и его отсутствием в качестве негативной обратной связи, они выберут первое. Если им дать выбор между отсутствием звука и неприятными звуками для позитивной обратной связи, они сделают выбор, основываясь на личных пристрастиях и вкусе. Если же дать людям выбор между отсутствием звука и мягким и приятным звуком для позитивной обратной связи, почти все выберут звук. Мы никогда не давали нашим пользователям шанса попробовать высококачественную звуковую положительную обратную связь в наших программах, так что неудивительно, почему люди ассоциируют звук с плохим интерфейсом.
Звуковая обратная связь должна быть очень тихой, не громче, чем звук нажатий клавиш на переносном компьютере. Программа должна производить звук каждый раз, когда пользователь работает с программой правильно или каждый раз, когда пользователь вводит информацию, которую программа понимает. Пользователи быстро начнут зависеть от этих звуков и станут работать более быстро и эффективно.
Без сомнения, все эти решения потребуют от программистов большей работы. Это нисколько меня не волнует. Я не хочу, чтобы программисты больше работали, но, выбирая из сложности работы программистов и сложности работы пользователей, я немедленно заставляю программистов работать. Работа программиста - удовлетворить пользователя, а не наоборот.
Еще один метод избежать сообщений об ошибках для программы, когда пользователь вводит неправильные данные, состоит в том, чтобы принять, что они неправильные, потому что программа, а не пользователь, плохо информирована.
Если, например, пользователь вводит счет-фактуру для несуществующего номера клиента, программа может принять эти данные и сделать себе специальную заметку, которая показывает, что пользователь должен исправить ее. Затем она будет наблюдать, чтобы удостовериться, что пользователь ввел необходимую информацию до конца отчетного периода. Так в действительности работают большинство людей. Они не вводят "неверных" номеров. Просто люди обычно вводят информацию в такой последовательности, которую программа принять не может.
Мы предполагаем, что запись о клиенте должна уже существовать перед выпиской счета-фактуры, но это не догма. Почему программа не может воспринимать счета-фактуры независимо от записей о клиентах и попросту считать, что недостающая информация будет введена позже? Если человек забывает ввести недостающую информацию до конца месяца, программа может переместить незаконченные документы на неопределенный счет. Программа не должна прерывать работу и останавливаться с сообщением об ошибке. В конце концов, все документы на неопределенном счете наверняка будут составлять лишь малую долю всего объема продаж и, таким образом, не будут являться значительным фактором для бизнеса. Зачем останавливать весь процесс, если обнаружена некоторая непоследовательность? Зачем сажать самолет из-за того, что в баре не хватает одной маленькой бутылки вина?
Но если вы настаиваете, я признаю единственную ситуацию, когда сообщение об ошибке допустимо: когда ваш принтер горит.
Алан Купер (перевод Андрея Седельникова)
Первые компьютеры были маленькими, маломощными и дорогими. Операторами этих машин были ученые в белых халатах, которые понимали, что нужно процессору, и не обижались, увидев сообщение об ошибке. Они знали, насколько сложна работа компьютера. Они не имели ничего против появления сообщения типа "Abort, Retry, Fail?" или др. Вот так и зародилась традиция отношения программы к человеку, как к процессору. С самого начала развития компьютерной техники программисты уяснили, что самый верный способ взаимодействия программы с пользователем - это требование ввода и выражение недовольства, когда пользователь не смог достичь уровня совершенства процессора.
Я называю это отношение силиконовым ханжеством. Примеры силиконового ханжества встречаются везде, где программа требует от пользователя действовать так, как это нужно ей, вместо того чтобы адаптироваться к нуждам человека. Силиконовое ханжество - это цикл негативной обратной связи, в котором программа игнорирует пользователя, когда он делает то, что она хочет, и кричит на него при малейшем отклонении.
Силиконовое ханжество необходимо для взаимодействия внутри программы. Каждый хороший программист знает, что если модуль А передал ошибочные данные модулю В, модуль В должен сразу же отбросить эти данные, сгенерировав подходящее сообщение об ошибке. Отсутствие такого взаимодействия означает серьезную ошибку в проектировании модулей. Но люди - не модули программы. Не только программа не должна отклонять ввод с сообщением об ошибке, но и ее разработчик должен переосмыслить само понятие "ошибочных данных". Когда данные получены от человека, программа должна предположить, что они правильные, потому что человек важнее, чем программа. Вместо того чтобы отклонить ввод, программа должна его проанализировать и понять. Программа может предотвратить возможные проблемы, гарантируя невозможность введения ошибочных данных.
У людей есть эмоции и чувства - у компьютеров их нет. Когда один кусок кода отклоняет ввод другого, последний не хмурится и не страдает. Процессору все равно, даже если вы выключите компьютер.
С другой стороны, у людей эмоции есть, и они могут выйти из-под контроля. Когда вы предлагаете что-то коллеге по работе и он (она) говорит вам "Заткнись, это глупо!", вы страдаете, это задевает ваши чувства. Вы начинаете думать, что вас не так поняли. Вы смотритесь в зеркало - все ли у вас в порядке с зубами. Все эти действия - часть человеческой натуры.
Люди, однако, хорошо реагируют на позитивную обратную связь. Представьте себе, что всякий раз, когда программа смогла понять информацию, которую они ввели, она показывает некий индикатор успешного завершения процесса. Если программа не может найти смысл во введенной информации, она никак не реагирует, что указывает на ошибку. "Если не можешь сказать ничего хорошего, лучше молчи".
Взаимодействие человека с молотком - показательный пример взаимодействия между пользователем и инструментом. Когда я использую молоток неправильно, он не выдает мне сообщения об ошибке. Он не пытается скорректировать мои действия. Он не указывает на отсутствие у меня навыков плотника. Он просто плохо забивает гвозди. Молоток дает хорошие результаты при правильном использовании, плохие - при неправильном.
Одна из причин, почему программы так трудны в обучении, - это то, что они редко предлагают позитивную обратную связь. С позитивной обратной связью люди учатся лучше. Люди хотят эффективно использовать свои программы. Они не хотят, чтобы программа била их по рукам в случае ошибки. Человеку нужно вознаграждение или, по крайней мере, уведомление в случае успеха.
Сторонники негативной обратной связи могут привести множество примеров ее эффективности для руководства людьми. Эти примеры верны, но почти всегда негативная обратная связь нужна, чтобы удержать людей от того, что они хотят сделать, но не должны. Но когда дело касается того, что люди хотят сделать, лучше всего связь позитивная. Представьте себе лыжного инструктора, который кричит на вас, или официанта в ресторане, который громко объявляет, что ваша кредитная карточка недействительна.
Помните, что мы говорим о недостатках негативной обратной связи от компьютера. Негативная обратная связь от другого человека, хотя и неприятна, может быть оправдана в определенных обстоятельствах. Сержант по крайней мере обучает вас для того, чтобы вы выжили в бою, а строгий профессор готовит вас к превратностям реальной жизни. Но получить негативную обратную связь от программы - любой программы - равносильно оскорблению. Сержант и профессор по крайней мере люди, имеющие определенный жизненный опыт. А программа - это мусор, пустое место. Она меньше, чем ничто. Слышать от программы, что вы сделали ошибку - унизительно. Пользователям не нравится быть униженными.
Ничто из того, что происходит в компьютере, не может быть достаточной причиной для оправдания унижения человека. Ничто. Не имеет значения то, насколько важна для вас целостность базы данных, она не стоит того, чтобы оскорблять пользователя. Если целостность данных такая важная вещь для вас, вы должны позаботиться о методах ее поддержания без унижения пользователя.
Вот три основных способа избежать сообщений об ошибках:
1) Делайте ошибки невозможными;
2) Давайте позитивную обратную связь;
3) Проверяйте, не редактируйте.
Наилучший способ избежать сообщений об ошибках это сделать так, чтобы пользователь не смог их совершить. Вместо требования ввести данные с клавиатуры, предоставьте пользователю список возможных вариантов выбора. Вместо требования ввести код штата вручную, предоставьте пользователям возможность выбрать требуемое значение из списка доступных кодов штатов или даже с помощью карты.
Еще один прекрасный способ избежать сообщений об ошибках - это сделать программу достаточно умной для того, чтобы избежать вопросов к пользователю. Многие сообщения об ошибках говорят что-то вроде "Неверные данные. Пользователь должен ввести ХХХХ". Почему же программа не может, зная, что должен ввести пользователь, ввести ХХХХ сама? Вместо запроса у пользователя имени файла на диске, давая возможность выбрать несуществующий файл, программа может запомнить, с какими файлами велась работа последний раз, и предоставить их список.
Позитивная обратная связь - хороший способ вознаградить пользователя за правильное пользование программой. Наилучший способ позитивной обратной связи это звук. К несчастью, долгие годы окна с сообщениями об ошибках сопровождались громким и пронзительным гудком, и звук стал ассоциироваться с ошибкой. Этот звук - публичное клеймо ошибки пользователя. Он громко объявляет всем в пределах слышимости, что вы только что сделали нечто глупое. Все то же силиконовое ханжество создало неоспоримую веру в голове большинства разработчиков программ, что звук является плохим признаком, и никогда более не должен считаться частью дизайна интерфейса. На самом деле это не так.
В реальной жизни любой объект или система, за исключением компьютерных программ, используют звук для позитивной обратной связи. Закрывая дверь, мы определяем, что она защелкнулась, услышав щелчок, тишина означает, что дверь еще не закрыта. Когда мы говорим с кем-либо и они отвечают "Ага" или "Да-да", мы знаем, что наши слова до них доходят. Когда они молчат, значит мы говорим неубедительно. Когда мы поворачиваем ключ зажигания и ничего не слышим, значит у нас проблемы. Когда мы включаем ксерокс, а он молчит, вместо того чтобы громко гудеть, мы понимаем - значит что-то не так.
Наши программы должны давать нам постоянные небольшие звуковые подсказки, похожие на тихие щелчки кнопок клавиатуры. Наши программы были бы более дружественными и простыми в использовании, если бы они издавали едва заметные, но легкоузнаваемые звуки, когда действия пользователя верны. Программа может выдавать мягкий звук каждый раз, когда пользователь ввел верное значение. Если программа не понимает введенную информацию, она молчит. В этом случае пользователь может сразу скорректировать данные безо всякого смущения. Когда пользователь начинает перетаскивать иконку, программа может коротко щелкнуть, а во время движения объекта производить тихое шипение. Когда объект находится над областями, где его нельзя оставить, звук меняется на что-нибудь более неблагозвучное. Когда наконец пользователь отпустит кнопку мыши, он будет вознагражден тихим "Да!", если действие завершено успешно, и тишиной из динамиков, если действие не имеет смысла.
Некоторые люди часто оспаривают этот аргумент, говоря, что пользователи не любят звуковую обратную связь, что они обижены звуками, издаваемыми компьютером, и что им не нравится, когда компьютер гудит и пикает на них. На это я скажу, что поведение людей обусловлено следующими установками:
1) Компьютеры всегда производят звуки, когда программа выдает сообщение об ошибке;
2) Компьютерные звуки обычно громкие, монотонные и неприятные.
Если дать людям выбор между звуком и его отсутствием в качестве негативной обратной связи, они выберут первое. Если им дать выбор между отсутствием звука и неприятными звуками для позитивной обратной связи, они сделают выбор, основываясь на личных пристрастиях и вкусе. Если же дать людям выбор между отсутствием звука и мягким и приятным звуком для позитивной обратной связи, почти все выберут звук. Мы никогда не давали нашим пользователям шанса попробовать высококачественную звуковую положительную обратную связь в наших программах, так что неудивительно, почему люди ассоциируют звук с плохим интерфейсом.
Звуковая обратная связь должна быть очень тихой, не громче, чем звук нажатий клавиш на переносном компьютере. Программа должна производить звук каждый раз, когда пользователь работает с программой правильно или каждый раз, когда пользователь вводит информацию, которую программа понимает. Пользователи быстро начнут зависеть от этих звуков и станут работать более быстро и эффективно.
Без сомнения, все эти решения потребуют от программистов большей работы. Это нисколько меня не волнует. Я не хочу, чтобы программисты больше работали, но, выбирая из сложности работы программистов и сложности работы пользователей, я немедленно заставляю программистов работать. Работа программиста - удовлетворить пользователя, а не наоборот.
Еще один метод избежать сообщений об ошибках для программы, когда пользователь вводит неправильные данные, состоит в том, чтобы принять, что они неправильные, потому что программа, а не пользователь, плохо информирована.
Если, например, пользователь вводит счет-фактуру для несуществующего номера клиента, программа может принять эти данные и сделать себе специальную заметку, которая показывает, что пользователь должен исправить ее. Затем она будет наблюдать, чтобы удостовериться, что пользователь ввел необходимую информацию до конца отчетного периода. Так в действительности работают большинство людей. Они не вводят "неверных" номеров. Просто люди обычно вводят информацию в такой последовательности, которую программа принять не может.
Мы предполагаем, что запись о клиенте должна уже существовать перед выпиской счета-фактуры, но это не догма. Почему программа не может воспринимать счета-фактуры независимо от записей о клиентах и попросту считать, что недостающая информация будет введена позже? Если человек забывает ввести недостающую информацию до конца месяца, программа может переместить незаконченные документы на неопределенный счет. Программа не должна прерывать работу и останавливаться с сообщением об ошибке. В конце концов, все документы на неопределенном счете наверняка будут составлять лишь малую долю всего объема продаж и, таким образом, не будут являться значительным фактором для бизнеса. Зачем останавливать весь процесс, если обнаружена некоторая непоследовательность? Зачем сажать самолет из-за того, что в баре не хватает одной маленькой бутылки вина?
Но если вы настаиваете, я признаю единственную ситуацию, когда сообщение об ошибке допустимо: когда ваш принтер горит.
Алан Купер (перевод Андрея Седельникова)
Компьютерная газета. Статья была опубликована в номере 30 за 1999 год в рубрике разное :: страна советов
