Архитектура встраиваемых систем. Работа с таймерами МК. Отчет по лабораторной работе. Алан Купер Психбольница в руках пациентов
 Скачать 7.24 Mb.
|
|
Глава 4. Танцующий медведь Даже если уцелевшие осознают, что именно интерактивный продукт заставляет их чувствовать себя глупо, они находятся в окружении апологетов и, как правило, не могут говорить об этом, не выставляя при этом себя нытиками. Ворчунов не любят, поэтому люди испытывают сильное социальное давление, вынуждающее их присоединиться к 93 поборникам, принести извинения, обвинить себя в плохой расторопности. Однако инстинкты уцелевших пользователей сильнее сознательных попыток компенсировать чувство неуверенности. Программы заставляют их чувствовать себя глупо, хотя так не должно быть. Если вы из таких людей, то, возможно, задаетесь вопросом: «Что он имеет в виду, говоря о некачественных программах? Ведь эти программы решают рабочие задачи?» В оставшейся части главы я опишу свое понимание качества. Если это проблема, то почему ее до сих пор не решили? Танцующие программы-медведи плохи тем, что большинство людей довольствуется неуклюжими танцами. Лишь увидев, как должен выглядеть настоящий танец, они начинаются подозревать, что за медвежьим шарканьем скрывается иной мир. Очень немногие из продуктов, основанных на программном обеспечении, демонстрируют настоящие танцы, и большинство людей даже не подозревает, что ситуацию можно улучшить, причем существенно. Большинство пользователей электронных таблиц и текстовых процессоров на современных компьютерах считают, что все проблемы, которые способен решить компьютер, уже были решены, и найденные решения как минимум адекватны. Такое представление далеко от истины. Бесконечное число задач, связанных с обработкой информации, еще не решено, а в большинстве случаев никто даже не рассматривал возможные решения. Жертва бытовой электроники Как потребители продуктов, основанных на программном обеспечении, мы настолько привыкли принимать как должное все, чем мы пользуемся, что не можем увидеть, что мы должны иметь. Инженеры создают продукты, выполняющие задачи, из которых состоит работа, однако без надлежащего проектирования этот набор задач не позволяет пользователю достичь своих целей. За двадцать лет у меня было множество видеомагнитофонов. Каждый имел функцию записи передач в указанное время, и ни один, включая модель за полторы тысячи долларов, не давал полной уверенности, что у меня все получится. Интерфейс этого продукта настолько неудобный, настолько сложный в интерпретации, настолько расплывчатый в терминологии и настройках, настолько переполнен скрытыми режимам и переключателями, что мне удавалось осуществить запись лишь в четырех случаях из десяти. Более чем в половине случаев я обнаруживаю, что записал три часа бразильского 94 футбола вместо передачи с канала Пи-Би-Эс. Проведя в борьбе долгие годы, я признал поражение и больше даже не пытаюсь записывать телепрограммы. Как и все остальные члены моей семьи. Как и все мои друзья. Мы - люди, уцелевшие после столкновения с танцующими программами-медведями. Пребывая в отчаянии, я отправляюсь в местный Электронный Рай с «визой» В кармане. «Тысяча! Нет, две! - Кричу я. - Награда продавцу за видеомагнитофон, который я смогу использовать для записи телепередач!» Люди в сияющих костюмах собираются вокруг меня и предлагают свой товар. От низкобюджетных вариантов до самых дорогих аппаратов и нет никакой разницы во взаимодействии. Конечно, в каждом большой набор возможностей, но способ управления устройством одинаков независимо от цены. Иначе говоря, продукт совершенствуют уже двадцать лет, а пользоваться им мне ничуть не легче. Это и есть танцующие программы-медведи в своем лучшем виде. Когда я говорю об этом продавцу, он, защищаясь, сообщает мне, что лучше все равно не бывает. Он показывает мне место в брошюре, где написано, что видеомагнитофон «прост в использовании». Билл Гейтс однажды заметил, с нетипичным для него цинизмом, как сделать программу дружелюбной к пользователю: изготовить печать и поставить на каждой коробке штамп «USER FRIENDLY» (Дружелюбна к пользователю). Компьютерная индустрия взяла его метод на вооружение. Кнопочное управление не очень справляется с такой непрерывной сущностью, как время, в отличие от вращающегося манипулятора. Будь у этого видеомагнитофона дисковый манипулятор, как у моего будильника за одиннадцать долларов, я смог бы устанавливать время и навсегда избавиться от мерцающих цифр «12:00». Второй такой манипулятор для указания времени записи следующей передачи и я бы уже с легкостью записывал то, что меня интересует. Реальность же такова, что устройства, обладая 95 возможностями для программирования записи десяти передач, столь неудобна, что не позволяет записать и одну из них. Мы окружены танцующими продуктами-медведями. Упаковочные коробки с ног до головы исписаны их функциями. У них достаточно возможностей, чтобы заполнить колонку таблицы журнального обозревателя словом «да». Но они не делают пользователей счастливыми и не приносят им радости эффективной работы. Большинство не способно справиться со всеми возможностями и функциями. Это удается лишь апологетам, с радостью меняющим собственные привычки, чтобы справиться с вызовом, который им бросает программное обеспечение. Они наслаждаются возможностью повозиться с программой. Они трудолюбиво изучают новые возможности, которыми никогда не воспользуются. Чем плохи почтовые клиенты Пока производители устраивают одну за другой решительные битвы на рынке программного обеспечения, пользователи дрожат по своим рабочим отсекам в страхе ступить на неисследованную территорию. Например, производители электронной почты добавляют в свои списки функции одну за другой, не замечая базовых потребностей участников электронного обмена информацией. Новых пользователей электронной почты завораживает новообретенная способность общаться напрямую, без сложностей и асинхронно с любым другим человеком. Однако решение задач не всегда позволяет пользователю достичь своих целей, и поэтому обмен электронной почтой все еще не вылез из пеленок. Проблема заключается в недопонимании реального применения электронной почты. Двадцать лет назад появление любого электронного письма становилось важным событием. Поскольку способ передачи подчеркивал важность сообщения, само сообщение ничего особенного собой не представляло. Более того, это был отдельный простой файл, состоящий из символов набора ASCII, не имеющих специальных свойств и связей. Сегодня каждый из нас получает смешанный поток важных и бесполезных писем. Любой пользователь электронной почты быстро выясняет, насколько это мощный и полезный транспорт, и начинает активно пользоваться этим средством, чтобы решать повседневные и деловые задачи. Многие пользователи электронной почты получают десятки и сотни сообщений ежедневно. Сообщения в большинстве случаев отправляются 96 либо в ответ на уже имеющиеся, либо с целью получения ответа. Сообщения таких последовательностей, или нити, передаются в обе стороны, связывая двух или более человек. На моем компьютере отношение связанных сообщений к одиночным составляет примерно 50:1. И при этом ни одна существующая программа для обмена электронными сообщениями не считает сообщения электронной почты фрагментами последовательностей 1 . Они ведут себя так, словно нити не существуют или являются незначительным свойством редких сообщений. Легко понять, что просмотр нитей вместо сообщений позволит пользователю отчетливо прослеживать связи и потоки информации в сообщениях и то, как они формируют связное общение. Если рассматривать проблему с точки зрения функций, мы увидим лишь потребность в ответах на сообщения и отправке сообщений. Работа с нитями электронных сообщений - не особо сложная задача с точки зрения программирования; все дело в том, что никто и никогда не создавал такие программы, а программисты с неохотой реализуют нововведения, исходящие от пользователей. Рассматривая программное обеспечение с точки зрения реализации, программисты видят, что сообщения передаются между пользователями и что пользователи могут складывать сообщения в папки, так что программисты проблем не наблюдают. Когда медведь уже начал двигаться, они объявляют это танцем и прекращают дальнейшую работу. Электронная почта - лишь один из примеров программного обеспечения, не позволяющего достичь простых и очевидных первоочередных целей. Нас так впечатляют танцующие медведи, что мы не видим неадекватности подобных продуктов. Вот еще несколько примеров. Чем плохи программы для планирования В офисе адвоката, в рекламном агентстве, в кабинете бухгалтера, в любом другом предприятии, связанном с консультированием, существует серьезная и не удовлетворяемая потребность в программе, управляющей распределением людей по проектам с учетом времени. Такова организация деятельности всех консультирующих компаний, и все же, как это ни поразительно, не существует программы, решающей эту 1 Некоторые программы дают пользователю возможность вручную создавать нити и управлять ими, однако лекарство оказывается хуже болезни. Этой возможностью непросто управлять, и нити общения по-прежнему считаются чем-то исключительным. 97 задачу. С точки зрения программиста управление проектом - это задача планирования плюс, возможно, дополнительные навороты вроде анализа методом критического пути, если начало одной задачи зависит от завершения предыдущей. Все доступные сегодня программы управления проектами основаны на этом академически чистом предположении 1 Проблема в том, что этот взгляд на управление проектами имеет очень слабое отношение к действительности. Ошибочно одно из фундаментальных предположений программ для управления проектами, а именно: людям необходимо помочь понять, как надо действовать в рамках проекта. Большинство людей довольно успешно справляются со своими проектами; ведь такова их работа, в конечном итоге. Увязывание нескольких проектов в единое расписание - вот в чем действительно требуется помощь. Ресурсы (обычно подразумеваются люди) одновременно задействованы в нескольких проектах. Они начинают и заканчивают проекты один за другим, иногда с некоторым наложением, так что большая часть проектов стоит в очереди, ожидая своей судьбы. Недостаточно распределить людей по проектам, необходимо иметь возможность назначить одного человека на работу в нескольких проектах. Чтобы приносить пользу, такие программы управления ресурсами должны интегрировать три измерения проблемы: время, проекты, ресурсы. Вместо этого мы получаем программы, работающие лишь в двух измерениях: времени и ресурсов, причем продавцы программ настаивают, что больше нам ничего не нужно. Хоть под каким названием - «трафик», «управление проектами и «распределение ресурсов», - этот жизненно необходимый сегмент рынка приложений попросту не существует. Более того, проекты постоянно изменяются с учетом плана. Любая полезная программа для управления проектами должна быть гибкой и уметь адаптироваться к изменениям. Система управления проектами, не содержащая надежных и действенных механизмов обратной связи, позволяющих людям, выполняющим работу, указывать системе на истинное положение вещей, не очень полезна в реальном управлении проектами. 1 В этом смысле я не лучше остальных программистов. В 1984 году я написал SuperProjects для Computer Associates, одну из первых программ управления проектами. Как и практически все другие программы, появившиеся позже, она полностью игнорировала вопросы взаимодействия нескольких проектов. 98 Чем плохи календари Практически каждый использует календарь для делового планирования. На рынке существует множество программ-календарей, и каждая из них игнорируют самый простой и очевидный способ применения календарной системы. Говоря просто, календарь должен отражать то, как люди используют время для управления своей жизнью. В целом, можно поделить наши заботы о времени на две категории: сроки и процессы. Срок это момент времени, до которого что-то должно быть готово, скажем, промежуточная версия продукта. Пример процесса - деловая поездка на один день. Скажем, в ходе моего двухдневного визита в Чикаго у меня назначено три встречи с различными клиентами. Все современные программы-календари игнорируют сроки и процессы, вместо этого пропагандируя встречи. Встреча - это отдельное событие, которое начинается в определенное время. Встречи - важная составляющая управления временем, но никоим образом не единственная. Речь не только об отсутствии других видов календарных записей, но и, во многих случаях, о неверном представлении собственно назначенных встреч. Отслеживать начало встречи гораздо важнее, чем ее конец, однако календари не различают эти два момента времени. За последние тридцать летя, был инициатором и участником тысяч встреч. Время начала этих встреч имеет огромное значение. Время же завершения в большинстве случаев не важно, указывать его не требуется и оно не известно заранее. Однако в каждой из опробованных мной программ-календарей встречи обладают временем завершения, которое требуется указать заранее столь же точно, аккуратно и старательно, как время начала. Это время завершения используется в точных вычислениях вашей доступности, которые в принципе не могут быть точными, а потому являются серьезным искажением действительности. К примеру, если вы, пользуясь типичной календарной программой, пригласите меня на встречу в три часа дня, программа отвергнет ваше приглашение, если у меня в 2:30 назначена встреча, которая продлится 35 минут. В реальной жизни я могу с легкостью сбежать с предыдущей встречи на пять минут раньше. Кроме того, ни одна из этих программ не учитывает время, которое мне необходимо, чтобы добраться до места встречи. Если мне нужно подъехать на другой конец города к двум часам дня, я должен выйти из дома в половине второго. На какое 99 время я должен назначить встречу, на 1:30 или на 2? Качественно спроектированная программа должна решить этот вопрос самостоятельно и помочь мне выйти вовремя. Есть и целый ряд других видов записей, связанных со временем, не учтенных в существующих календарях. В любой день у меня может быть десяток или более текущих проектов, однако в любой момент времени я работаю лишь над одним из них. Типичная календарная программа отказывается уживаться с этим моим нормальным поведением, не позволяя работать с календарем на уровне проектов. Я не могу обойти этого танцующего медведя. Массовая веб-истерия Любому владельцу компьютера и модема Всемирная паутина дала в руки удивительный ресурс. Среда Web - колоссальной силы инструмент, и он предлагает невероятные возможности. Удивительно, но самым важным достижением этой среды стала демонстрация того, насколько простым в применении может быть программное обеспечение. Многие бывшие апологеты находят Всемирную паутину столь простой в использовании, что требуют подобного свойства и от всех остальных программ. В частности, им нравится, что броузеры позволяют избегать раздражающего процесса установки. Руководители индустрии ПО, особенно поставщики корпоративных приложений, с легкостью готовы запрыгнуть в этот вагон. Они влюблены по уши в программы, работающие из броузера, поскольку могут распространять свои продукты, не мучая пользователей тошнотворным процессом установки. До эпохи Всемирной паутины все программные продукты требовали сложного процесса установки, тогда как продукты, работающие в рамках броузера, ничего такого не требуют. И большинству менеджеров индустрии программного обеспечения это кажется технологическим прорывом, превосходящим изобретение застежки-молнии. Но это же просто притворство. Нет причин, по которым процесс установки не может быть невидимым для любой программы, независимо от технических деталей ее реализации. Если бы компьютер требовал обязательной установки программного обеспечения, то требовал бы независимо от наличия броузера. Единственная причина по которой работающие вне броузеров программы требуют установки состоит в том, что nпрограммисты привыкли всегда так делать в прошлом. Их работа упрощалась, 100 если они переносили ряд вопросов в программу установки. В ранних броузерах не было функциональности, позволяющей задавать такие вопросы, так что программисты просто пожимали плечами и переставали эти вопросы задавать. Если нужны еще доказательства: программисты практически не замечали этого недостатка, тогда как для многих пользователей отсутствие ее сделало Всемирную паутину самой простой в использовании платформой. Если отвлечься от вопросов установки, браузеры слабы, как новорожденные котята - доисторические идиомы взаимодействия с человеком, архитектура, напоминающая плоскую шутку, гибкость не лучше, чем у сосулек. Любая программа, работающая внутри браузера, обязана принести в жертву невероятную производительность и возможности. Меня приводит в ярость желание некоторых руководителей вырезать своему приложению сердце, перенеся его на платформу Web, чтобы получить преимущества, связанные с отсутствием процесса установки, когда они могли бы получить то же самое, просто вежливо попросив своих разработчиков избавиться от этого процесса. Пользователи требуют программное обеспечение, работающее в браузерах, потому что не знают лучших альтернатив. А вот разработчики программного обеспечения подчиняются этой тенденции, исходя из совершенно неверных предположений. Среда Web по организации схожа с Советским Союзом, здесь центральные компьютеры указывают беспомощным настольным машинам, что делать. Программисты – особенно в корпоративных ИТ-подразделениях - владеют центральными компьютерами, так что, подобно советским комиссарам, желают получить преимущества такого перехода. Вместо того чтобы бесплатно получить преимущества программ, которые не надо устанавливать, пользователи расплачиваются потерей долговременного контроля над своей информационная инфраструктурой. Что не так с программным обеспечением? Большая часть первой моей книги посвящена подробному ответу на этот вопрос. Но я хотел бы занять еще несколько страниц, чтобы познакомить читателей с началами принципов проектирования взаимодействий, которые позволяют создавать более качественные программные продукты. 101 Программы забывают Каждый раз, работая с программой, вы узнаете что-то о ней, но сама программа не запоминает ничего. Наш коллега, медиа-продюсер Трой Дэниэлс практически живет в Adobe Photoshop, который не помнит ровным счетом ничего из того, что он когда-либо делал. Не помнит, где Трой хранит файлы своих изображений, не помнит, как он обычно работает с этими файлами. Управляющие элементы и команды, которые он использует постоянно, в интерфейсе программы выглядят так же, как и остальные управляющие элементы и команды, которые он не использует и вряд ли когда-нибудь начнет. Программы ленивы Прикладные программы, в большинстве своем, не сильно напрягаются для пользователей. Не в том смысле, что не делают работу, но в том смысле, что часто тратят гигантские усилия, чтобы ублажить пользователей, относясь к ним так, как если бы они были программистами. Это все равно, что подарить жене на день рождения электродрель. Если электродрели нравятся вам, это совсем не означает, что они нравятся и ей. Направив усилия программистов на создание того, что будет действительно нужно пользователю, мы сможем сделать пользователя гораздо более счастливым, не вынуждая разработчиков при этом трудиться больше. Программы скупы на информацию Подобно банкомату, скрывающему от меня количество денег на счете, большинство интерактивных продуктов скупы на информацию. Они склонны не только к сокрытию информации о происходящем, но и маскировке собственно происходящего. Типичный пользователь интерактивной системы не может определить ее состояние, пока она не выпалит сообщение, указывающее на окончательный сбой. Для примера можновзять мои новые радиочасы, описанные в главе 1 .Загадки века информации, которые морочат мне голову, скрывая свое состояние. Внешне всевыглядит так, будто система работает 102 замечательно, но это не так, и нет способа узнать правду. Если, работая с программой, вы заметите, что делаете заметки на полах страницы, оказавшейся поблизости, знайте, что стали жертвой программы, скупой на информацию. Любая программа могла бы с легкостью отображать намного больше полезной информации, но немногие программисты об этом задумываются. К примеру, когда моя программа электронной почты принимает новое сообщение, она отображает крохотную пиктограмму конверта. Этот маленький конверт может означать, что у меня одно новое сообщение, но может означать и тысячу новых сообщений. Программа не позволяет мне оценить глубину цифрового почтового ящика. Эта скупость препятствует оценке ситуации в целом. Программы не гибки Когда человек имеет возможность оценить ситуацию в целом, он часто адаптируется к этой ситуации, исходя из оценки. Программное обеспечение редко бывает настолько гибким. Когда клерк видит, что стопка бумаг для обработки достигла пятнадцати сантиметров в толщину, он понимает, что следует предпринять какие-то решительные меры, чтобы избежать завала: Программы в большинстве своем написаны так, что человек может видеть лишь бумагу наверху стопки, но не далее. Независимо от метафорической глубины папки входящих документов, компьютер ведет себя так, как если бы только одно сообщение требовало ответа. Обратное тоже верно. Если в реальных входящих только одна бумага, человек может воспользоваться паузой и помочь коллеге с более высокой стопкой. Компьютер на такое не способен. При компьютеризации ручного труда программисты (или аналитики) изучают существующее поведение пользователей, выполняющих ручную работу, и делают выводы относительно задач и функций. Далее задачи реализуются в компьютерной программе. Как правило, все аспекты работы, не связанные с задачами, попросту теряются в процессе. В традиционной системе с ручным трудом управляющий может вытащить заявление своего близкого родственника со дна стопки и ускорить обработку этого заявления. Как вариант, рассерженный позвонивший, который ведет себя грубо, может добиться того, что его заявление переложат в самый конец очереди. Такая системная гибкость - ключ к сохранению социального порядка. Компьютеризованной системе присуща холодная 103 рациональность, разрушающая структуры цивилизации. Люди-пользователи предпочитают системы, допускающие легкое жульничество. Им нужна возможность слегка покачнуть пинбол-автомат, чтобы сдвинуть игру с мертвой точки, не сильно, но достаточно ощутимо, чтобы получить положительное влияние на исход игры. Именно эта податливость делает системы ручного труда столь эффективными, пусть и более медленными, в сравнении с компьютеризованными. Программы возлагают вину на пользователей Если программа сталкивается с проблемой, она неизменно возлагает проблему на пользователя, да ко всему еще и обвиняет его в возникновении проблемы. Если с человеком что-то случается, он, как правило, сознательно пытается компенсировать последствия, к примеру, если за обедом у приятеля я разолью чей-то бокал вина, то воспользуюсь своей салфеткой, чтобы остановить распространение пятна, а затем налью пострадавшему новый бокал. Я проявлю заботу и внимательность, никто не обидится, и ни у кого не останется плохих впечатлений от этого происшествия. Когда интерактивный продукт сталкивается с небольшой проблемой, то часто впадет в бездействие, превращаясь в бесполезную инертную массу. Такой сбой часто приводит к многочисленным сопутствующим повреждениям. Скажем, программа установки задает пользователю ряд вопросов, прежде чем начать копирование программы на жесткий диск. В прежние времена, если дисковое пространство заканчивалось в процессе установки, это приводило к сбою программы установки. Современные программы не намного лучше. Если заканчивается место, они могут выдать сообщение об ошибке, но затем перестают работать, забывая обо всех настройках, которые вы столь тщательно сделали. Если, расчистив дисковое пространство, вы снова запустите установку, она в первую очередь задаст вам все уже заданные вопросы, поскольку не запоминает ответы. Программы не несут ответственности Диалоги подтверждения - один из наиболее распространенных примеров некачественного проектирования; они спрашивают, «уверены ли мы», что хотим выполнить то или иное действие. На заре компьютеризации рабочих мест программы выполняли необратимые действия в ту же секунду, когда пользователь вводил команду. Команда «erase аll» (стереть все) делала именно это, причем немедленно и необратимо. 104 Как только первый пользователь непреднамеренно стер все содержимое жесткого диска, он, несомненно, пожаловался программисту, и программист добавил адекватный, с его точки зрения, уровень защиты. Пользователь набирает команду «erase аll», и теперь, прежде чем компьютер ее выполнит, программа просит пользователя подтвердить команду на удаление. Все очень логично и совершенно неправильно. Диалог подтверждения - удобный выход для программиста, поскольку избавляет его от ответственности за содействие непреднамеренному удалению. Однако здесь имеется неправильное понимание источника проблемы. Удаление целиком лежит на совести пользователя, и он уже набрал команду. Теперь не время программе проявлять нерешительность. Она должна просто взять и выполнить возложенную на нее задачу. В действительности имеет место уход от другой ответственности - ответственности программы быть готовой отменить действия, пусть даже пользователь захотел их выполнить. Люди обычно принимают решения иными способами, нежели компьютеры, так что для человека нормально и типично передумать или захотеть отменить принятое ранее решение. В реальном мире за пределами компьютеров большинство действий можно отложить, изменить, обратить. Не существует причин, по которым такое поведение не может быть реализовано и в продуктах, основанных на программном обеспечении; просто создающие их программисты об этом не задумываются. Банкомат из главы 1 отказывается от ответственности при помощи подтверждений точно так же, как программы для настольных компьютеров. Когда я вставляю карту, банкомат требует подтвердить, что я вставил карту. Когда я запрашиваю наличные средства, он требует подтвердить, что я хочу снять деньги. Когда я набираю сумму, требует подтвердить, что я набрал сумму. Почему бы машине просто не довериться мне? Почему просто не выполнить транзакцию? Она может дать мне возможность прервать транзакцию в любой момент гораздо более простым способом. Будь у этого банкомата обычная большая красная кнопка ОТМЕНА, которую я мог бы нажать в любое время, банкомат мог бы предполагать, что я разумен, осознаю, чего хочу и что делаю, вместо того чтобы считать меня глупым, некомпетентным и не имеющим четкого представления о своих желаниях. Уверен, что некоторые из пользователей этого банкомата действительно глупы и 105 некомпетентны, однако никому - даже глупым и некомпетентным людям - не нравится, когда их считают глупыми и некомпетентными. Кроме того, подобное отношение к клиенту никогда не вызывает у него привязанности и положительных эмоций. Исправить эту проблему несложно. Программа должна поместить слова «Снятие со счета» вверху экрана и не стирать их на протяжении всей транзакции. Затем она должна отобразить на экране «$1.50» - стоимость операции - и также не стирать. Затем она должна добавить слова «Идет проверка» наряду с номером моего счета, балансом и ограничениями на изъятие средств и оставить всю эту информацию на виду. Таким образом, когда зайдет речь о сумме, я буду уже хорошо информированным потребителем, а не жертвой допроса. Я могу принять решение: указать сумму, обладая знанием об ограничениях, о средствах, о возможностях и о приличиях. Система, представляющая полезную информацию, подобная описанной только что, суть типичный пример того, как работают человеческие системы, потому что людям необходимо видеть картину в целом. С другой стороны, компьютеры нуждаются лишь в небольших фрагментах информации, чтобы переходить от одного этапа процесса к другому. И именно на этой основе моделируется взаимодействие: система предполагает, что пользователь, нажимающий на кнопки, пока его друзья нетерпеливо переминаются с ноги на ногу, - лишь еще один компьютер, а не теплокровный человек, способный чувствовать. * * * Многие новички в мире компьютеров воображают, что программное обеспечение ведет себя так, как ведет, потому что на то есть уважительная причина. Напротив, поведение программ часто есть результат прихотей или случайностей, которые бездумно повторяются из года в год. Добавив в процесс разработки продуктов, основанных на программном обеспечении, своевременное проектирование взаимодействия, мы сможем получить значительные преимущества. |