Люди ненавидят сообщения об ошибках

Люди обладают чувствами. Компьютеры – нет. Когда один программ' ный компонент отвергает данные, переданные другим компонентом, компоненту'отправителю все равно. Он не сердится, не обижается, не просит совета. А вот люди очень злятся, когда им без обиняков гово' рят, что они идиоты.

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

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

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

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

Рис. 25.1. Неважно, насколько вежливо сформулированы ваши сообщения об ошибках, – интерпретированы они будут вот так

И все−таки: чья это ошибка?

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

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

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

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

«плохие» данные – они просто вводят данные в том порядке, к которо' му программа не готова.

Если человек забудет разъяснить компьютеру все до мелочей, компью' тер может после некоторой разумной паузы более настойчиво потребо' вать необходимую информацию. В конце рабочего дня или недели про' грамма может визуально выделить неким образом все противоречивые транзакции. Ей вовсе не обязательно прерывать работу сообщением об ошибке. Ведь она запомнила транзакции – и их можно найти и испра' вить. Так работают системы ручной обработки информации. Почему компьютеризированная система не может поступить подобным обра' зом? Зачем останавливать весь рабочий процесс только потому, что че' го'то не хватает? Пока пользователь в курсе того, что некоторые счета нужно привести в порядок, проблем не будет. Хитрость в том, чтобы информировать его, не прерывая работу. Эту идею мы более подробно обсудим позже.

Если бы на месте программы был живой человек, который устроил бы забастовку посреди бухгалтерии потому, что мы передали ему не до конца заполненную форму, мы вышли бы из себя. Будь мы его началь' никами, мы тут же стали бы искать замену такому упрямому, мелочно' му и самодовольному клерку. «Возьми форму, – сказали бы вы ему, – и впиши, чего там не хватает». Авторам приходилось пользоваться справочными системами, которые требуют указать вместе с телефоном код города даже тогда, когда адрес человека уже введен. Не надо много ума, чтобы в такой ситуации сделать разумное предположение о коде города. Если пользователь вводит новое имя и указывает уже извест' ный программе город, она может выяснить код, посмотрев на записи о других 25 адресатах, живущих в этом городе. Конечно, если вы вве' дете город, которого еще нет в базе данных программы, это может по' ставить ее в тупик. Но так ли трудно обратиться к справочнику в Ин' тернете или хотя бы держать в памяти список тысячи крупнейших го' родов страны с их телефонными кодами?

Программисты, вероятно, заявят протест: «Программа может ошибить' ся. Она не знает наверняка. Есть города с несколькими кодами. Про' грамма не должна делать предположения без одобрения пользовате' ля!» Все не совсем так.

Если мы попросим помощника ввести контактный телефон клиента в программу'справочник и не сообщим ему код города, он выполнит по' ручение, полагая, что код выяснится до того, как потребность в нем ста' нет неотложной. А еще он может самостоятельно выяснить код в спра' вочнике. Предположим, что клиент живет в Лос'Анджелесе, и в спра' вочнике неоднозначная информация: код либо 213, либо 310. Если по' мощник ворвется к нам в кабинет с криками: «Прекратите работу! Код города клиента неоднозначен!», то мы испытаем острейшее желание уволить его и нанять сотрудника, у которого коэффициент умственно' го развития все'таки превышает комнатную температуру. Почему программный продукт должен ввести себя иначе, нежели нормальный работник? Человек в такой ситуации может просто вписать в поле ко' да города 213/310. Когда мы будем звонить клиенту, нам придется уточнить код, но пока что можно жить спокойно.

Снова слышны крики протеста: «Но поле кода города вмещает только три цифры! Оно не может принять запись „213/310“!» О да, это ужас' но. Вы хотите сказать, что дизайн пользовательского интерфейса, соз' данный на основе внутренней модели реализации (жестко ограничен' ного размера поля ввода), заставляет вас отвергать естественное чело' веческое поведение в пользу оскорбительной компьютерной логики, сопровождаемой унизительными сообщениями об ошибках? Проще говоря, источником сообщений об ошибках является неспособность приложений вести себя разумно, а отнюдь не промахи пользователей.