Как быть с недостающими данными?

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

 

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

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

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

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

Контрпродуктивность подхода, при котором идиотами считают всех

работников, чтобы защититься от тех немногих, кто ими является на

 

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

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

Ввод данных и сговорчивость

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

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

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

 

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

 

Аудит и редактирование

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

Сказанное не означает, что приложение может умыть руки со слова' ми: «Раз он отказывается от спасательного жилета, пусть тонет». Про' грамма должна вести себя так, словно пользователь всегда прав, но от' сюда не следует, что он действительно всегда прав. Люди постоянно ошибаются, и ваши пользователи не исключение. Программа может быть не виновата в ошибках пользователя, но она несет за них ответст' венность. Как же исправлять ошибки?

 

В ошибках может и не быть вашей вины, но вы несете за них ответственность.

 

 

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

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

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

Аудит и редактирование 423

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

 

 

Выполняйте проверку, а не редактирование.

 

 

Microsoft Word предоставляет нам блестящий пример проведения ауди' та, а также ужасающий обратный пример. Положительным примером служит то, как этот редактор выполняет проверку орфографии в ре' альном времени. По мере набора текста появляется красное волнистое подчеркивание, выделяющее слова с подозрительной орфографией (рис. 18.1). Щелчок правой кнопкой мыши по такому слову выводит на экран меню вариантов замены, но вы не обязаны что'либо выби' рать, и ваша работа не прерывается диалоговыми окнами и другим мо' дальным идиотизмом.

 

Рис. 18.1. В Microsoft Word функция автоматической проверки орфографии подчеркивает ошибочные слова, предоставляя тем самым немодальную обратную связь. Щелчок правой кнопкой мыши выводит на экран меню, позволяющее выбрать один из вариантов правильного написания

Зато функция Автозамена поначалу несколько раздражает. Когда вы вво' дите текст, она без уведомления изменяет слова, которые считает напи' санными неправильно. Эта функция оказывается очень полезной для исправления незначительных опечаток. К сожалению, исправления, сделанные программой, не отслеживаются, и пользователь не имеет ни малейшего представления, что из набранного было изменено. Было бы лучше, если бы редактор Word отмечал, что именно исправлено, – на тот случай, если он ошибся (что весьма вероятно при вводе техническо' го текста, насыщенного специальными терминами и сокращениями).

Гораздо больше пугает функция Автоформат, которая пытается интер' претировать звездочки и цифры в тексте как сигнал для автоматиче' ского форматирования нумерованных списков и других элементов текста. Когда функция Автоформат срабатывает правильно, кажется, будто произошло чудо, однако часто она делает не то, что нужно, в то время как отмена ее действий затруднена. Функция Автоформат пыта' ется быть умнее, чем следует. Мыслительные процессы нужно делеги' ровать человеку. К счастью, эта функция может быть отключена (хотя найти, где она отключается, не так'то легко). Кроме того, в последних версиях Word присутствует специальное контекстное меню, позволя' ющее корректировать настройки функции Автоформат.

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