Глава 12. Проектирование хорошего поведения

Тактичные продукты знают,

когда можно отклониться от правил

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

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

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

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

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

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

Проектирование тактичных продуктов 303

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

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

Тактичные продукты берут на себя ответственность

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

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

304 Глава 12. Проектирование хорошего поведения

их. Тем временем программа самодовольно сообщает пользователю, что операция отменена. Программа лжет - и пользователь видит это.

Пользователю нет дела до проблем со связью между приложением и принтером. Его не волнует, что эта связь односторонняя. Зато он твердо знает, что передумал печатать документ до того, как первая страница появилась в выходном лотке, знает, что он щелкнул по кнопке Отмена и что после этого глупая программа продолжила печатать и вывела 15 страниц, хотя он заблаговременно приложил все усилия, чтобы прекратить печать. Причем программа ведь даже подтвердила команду отмены! Выбросив 15 испорченных страниц в мусорную корзину, пользователь недовольно рычит на глупую программу.

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

Проектирование интеллектуальных продуктов

Услужливые продукты и люди должны быть не только тактичными, но и умными. Благодаря писателям-фантастам и футурологам существует некоторая путаница относительно смысла понятия «интеллектуальный интерактивный продукт». Некоторые наивные наблюдатели полагают, что умные программы действительно способны вести себя как разумные существа.

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

Использование циклов простоя

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

Проектирование интеллектуальных продуктов 305

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

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

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

В нормальной ситуации типичный пользователь не может выполнить никакое действие быстрее, чем за несколько секунд. Типичному настольному компьютеру этого времени достаточно, чтобы выполнить, как минимум, миллиард инструкций. Почти наверняка эти внутренние рабочие циклы будут выполнены вхолостую. Процессор просто ждет. Аргумент против использования этого времени простоя всегда был один: «Мы не можем делать предположения; они могут оказаться ошибочными...» Современные компьютеры настолько мощны, что этот аргумент, сам по себе справедливый, часто не имеет отношения к делу. Проще говоря, не страшно, если программа сделает ошибочное предположение. У компьютера достаточно мощности, чтобы программа сделала несколько предположений и отбросила результаты ошибочных, когда пользователь совершит окончательный выбор.

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

306 Глава 12. Проектирование хорошего поведения

операционная система использует время простоя для индексирования жесткого диска.

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

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

Интеллектуальные продукты обладают памятью

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

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

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

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

Проектирование интеллектуальных продуктов 307

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

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

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

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

308 Глава 12. Проектирование хорошего поведения

Связность задач

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

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

Например, Салли использует Excel совершенно не так, как Кацуо, но вполне постоянна в своих привычках. Кацуо предпочитает шрифт Times размером 9 пунктов, а Салли - Helvetica 12 пунктов, причем Салли пользуется им регулярно. Программе не обязательно спрашивать Салли, какой шрифт использовать: каждый раз Helvetica 12 пунктов будет надежной отправной точкой.

Запоминание выбора и значений по умолчанию

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

принцип Следует запоминать все, что выбирает пользователь.

проектирования

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

Проектирование интеллектуальных продуктов 309

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

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

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

Запоминание шаблонов

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

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

Глава 12. Проектирование хорошего поведения

Какие действия запоминать?

Следует запоминать все, что делает пользователь. На жестких дисках полно свободного места - и память вашего приложения найдет этому месту достойное применение. Мы привыкли считать, что программы требуют неоправданно много места на диске, потому что большое приложение, как правило, занимает порядка 200 Мбайт. Это типично для программы, но нетипично для данных пользователя. Если текстовый редактор будет сохранять один килобайт информации о поведении пользователя после каждого запуска, это не так уж много. Скажем, вы запускаете текстовый процессор 10 раз в течение рабочего дня. В году примерно 200 рабочих дней, так что получается 2000 запусков программы в год. Потребление места на диске составит 2 Мбайта - и это расчет с запасом на целый год! Обои на рабочем столе занимают на диске немногим меньше места.

Расположение файлов

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

Выводы, сделанные программой

Программа должна запоминать не только очевидные факты, но и выводы, которые можно сделать на их основании. Например, если программа запоминает количество измененных байтов при каждом открытии файла, она будет в состоянии помочь пользователю, выполняя некоторые проверки на разумность действий. Предположим, для некоторого файла исторические значения счетчика измененных байтов составляют 126, 94, 43, 74, 81, 70, 110 и 92. Если пользователь в следующий раз изменит 100 байтов, то в этом не будет ничего необычного. Если же вдруг счетчик зашкалит за 5000, то программа должна заподозрить что-то неладное. Хотя есть вероятность, что пользователь нечаянно сделал то, о чем впоследствии пожалеет, она все-таки невелика, поэтому беспокоить его диалоговым окном подтверждения изменений не стоит. Тем не менее со стороны программы будет весьма разумно на всякий случай сохранить помеченную копию файла, в которой эти 5000 байтов еще не изменены. Скорее всего, программе не придется хранить эту копию после следующего обращения пользователя к данному файлу, поскольку пользователь с большой вероятностью заметит ошибку сразу и потребует откатить изменения немедленно.

Проектирование интеллектуальных продуктов 311

Межсеансная отмена

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

Ранее введенные данные

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

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

Манипуляции с файлом третьими приложениями

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

Реализация памяти в ваших приложениях

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

312 Глава 12. Проектирование хорошего поведения

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

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

Сокращение множества решений

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

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

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

Сокращение множества решений наводит нас на мысль, что информация о предпочтениях пользователя, которую должна запоминать про-

Проектирование интеллектуальных продуктов 313

грамма, неким образом группируется. Не бывает какого-то одного правильного варианта - они все правильные. Приложение должно находить более тонкие «зацепки», чтобы определить, какое решение из небольшого множества подходит в данном случае. Например, если вы применяете программу оформления чеков для оплаты своих счетов, приложение может быстро сообразить, что только два или три счета используются регулярно. Но как ей определить по чеку, к какому счету он относится? Если программа запомнит, какие получатели и суммы соответствуют тому или иному счету, ей будет легко принимать решение. Вы платите за квартиру каждый раз одну и ту же сумму! То же самое относится к выплате кредита за машину. Сумма, которую вы платите за электричество, может меняться, но она, вероятно, будет отличаться от предыдущей не более чем на 10-20%. Эти сведения могут быть использованы программой, чтобы понять, что происходит, и помочь пользователю.

Пороги предпочтений

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

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

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

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

Глава 12. Проектирование хорошего поведения

⇐ Предыдущая26272829303132333435Следующая ⇒

Поделиться:

Воспользуйтесь поиском по сайту: