Проектирование гармоничного взаимодействия

Не существует универсальных правил, определяющих гармоничное взаимодействие, как не существует универсальных правил определения гармоничных пауз в музыке, однако мы находим, что перечисленные ниже стратегии направляют проектирование взаимодействия в нужное русло:

1. Следуйте ментальным моделям пользователей.

2. Меньше – лучше.

3. Позволяйте пользователям управлять, не принуждайте их к диалогу.

4. Держите инструменты под рукой.

5. Обеспечивайте немодальную обратную связь.

6. Проектируйте наиболее вероятное, будьте готовы к возможному.

7. Предоставляйте информацию о контексте.

8. Организуйте непосредственное манипулирование и графический ввод.

9. Отображайте состояния объектов и статус приложения.

10. Избегайте ненужных сообщений.

11. Не используйте диалоговые окна, чтобы сообщить, что все нормаль' но.

12. Избегайте чистого листа.

13. Просите прощения, а не разрешения.

 

14. Отделяйте функции от их настройки.

15. Не задавайте вопросы – предоставляйте выбор.

16. Прячьте рычаги катапультирования.

17. Оптимизируйте скорость реакции; предупреждайте о задержках. Обсудим эти принципы более подробно.

 

Следуйте ментальным моделям пользователей.

 

 

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

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

 

Меньше – лучше.

 

 

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

 

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

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

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

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

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

Классическая книга Маллета (Mullet) и Сано (Sano) «Designing Visual Interfaces» (Mullet and Sano, 1995) содержит плодотворное обсужде'

 

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

Минималистичный подход к проектированию продуктов неизбежно связан с четким пониманием назначения: чего пытается достичь поль' зователь, применяя инструмент? Без понимания назначения интерак' тивные продукты – не более чем неорганизованное нагромождение функций, демонстрирующих работу технологий. Показательным при' мером того, как глубокое понимание назначения привело к созданию минималистичного пользовательского интерфейса, является поиско' вая система Google, где есть лишь текстовое поле, две кнопки («Поиск в Google», отображающая перечень результатов, и «Мне повезет!», вы' полняющая переход к первому сайту из результатов поиска), логотип компании Google и пара гиперссылок на вселенную функций Google (рис. 10.1). Другой хороший пример минималистичного пользователь' ского интерфейса – iPod Shuffle. Компания Apple, определив со всей тщательностью набор уместных возможностей, служащий конкрет' ным потребностям пользователей, создала превосходный по удобству продукт с одним переключателем, пятью кнопками – и без экрана! Не' вероятно простой текстовый редактор WriteRoom (Hog Bay Software) вообще не имеет пользовательского интерфейса – только область, в ко' торой можно набирать текст. Текст сохраняется автоматически, из' бавляя от необходимости иметь дело с файлами.

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

 

Рис. 10.1. Знаменитый поисковый интерфейс Google – классический пример минималистичного проектирования интерфейса, в котором каждый элемент на экране содержателен и понятен

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

 

Позволяйте пользователям управлять, не принуждайте их к диалогу.

 

 

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

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

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

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

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

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

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

 

Держите инструменты под рукой.

 

 

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

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

 

Обеспечивайте немодальную обратную связь.

 

 

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

 

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

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

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

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

a) б) в)

 

Рис. 10.3. Работая в редакторе Word 2003, вы можете узнать количество слов в документе, выполнив команду Статистика из меню Сервис. Команда открывает диалоговое окно. Чтобы вернуться к работе, вы должны нажать кнопку Закрыть. Такое поведение является полной противоположностью немодальной обратной связи, и оно выводит пользователя из состояния потока. В Word 2007 Microsoft значительным образом улучшила ситуацию: число слов в документе немодально отображается в левом нижнем углу окна рядом со счетчиком страниц (в), поскольку это родственные значения

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

 

Проектируйте наиболее вероятное, будьте готовы к воз- можному.

 

 

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

Программисты обычно считают, что возможность и вероятность – од' но и то же. Например, пользователь может завершить работу с про' граммой и сохранить свою работу, а может выбросить документ, над которым работал в течение шести часов. Любой поворот событий воз' можен. Вероятность того, что пользователь выбросит результаты сво' его труда, – не больше, чем одна тысячная. Тем не менее типичная программа содержит диалоговое окно с вопросом, не хочет ли пользо' ватель сохранить изменения (рис. 10.4).

 

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

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

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

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

 

Представляйте информацию с учетом контекста.

 

 

Способ представления информации приложением – это еще один путь для создания помех в сознании пользователя. Особые злоупотребления наблюдаются при представлении количественной, то есть цифровой ин' формации. Если приложение должно сообщить пользователю об объе' ме свободного пространства на диске, оно может поступить, как в свое время поступал Менеджер файлов в Windows 3.х, а именно – вывести точное количество свободных байтов (рис. 10.5).

 

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

К счастью, теперь Microsoft Windows использует для индикации свободного места на диске круговые диаграммы

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

Специалист в области визуального представления данных Эдвард Таф' ти (Edward Tufte) говорит, что представление количественной инфор' мации должно отвечать на вопрос: «По сравнению с чем?» Знание того, что на диске свободно 231728 Кбайт, не столь полезно, как знание то' го, что это 22% от общего размера диска. Другой афоризм Тафти: «По' казывайте данные», а не просто сообщайте о них в текстовой или чис' ленной форме. Круговая диаграмма, показывающая занятое и свобод' ное место на диске разным цветом, гораздо понятнее сообщает о мас' штабе и пропорциях использования дискового пространства. Она объясняет нам, что в действительности означает число 231 728 Кбайт. Цифры должны оставаться на экране, но их статус должен быть сведен к меткам на диаграмме. Кроме того, их точность должна находиться в пределах разумного и быть одинаковой повсеместно. Смысл информа' ции должен быть представлен визуально, а цифры используются лишь для поддержки.

В Windows ХР и Windows Vista корпорация Microsoft одной рукой да' ет, а другой отбирает. Менеджер файлов (см. рис. 10.5) уже давно ка' нул в небытие, а на смену ему пришел Проводник (рис. 10.6). Эта заме' на привела к появлению диалогового окна со свойствами жесткого диска. Занятое пространство окрашено в синий цвет, а свободное – в лиловый. Такую круговую диаграмму легко воспринимать. Теперь вы моментально определяете, что – о счастье! – ваш жесткий диск Gran' Fromage почти пуст.

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

 

 

 

Рис. 10.6. В Windows XP и Windows Vista компания Microsoft заменила электрический стул смертельной инъекцией. Вместо длинных неразборчи- вых чисел внизу окна Менеджера файлов можно открыть диалоговое окно свойств в Проводнике. Хорошая новость: наконец нам наглядно дают понять, как чувствуют себя жесткие диски. Плохая новость: чтобы

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

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

 

Организуйте непосредственное манипулирование и графи- ческий ввод.

 

 

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

 

ние. Редкие продукты позволяют пользователю создать график и по команде преобразовать его в последовательность чисел. Исключение – современные текстовые процессоры: почти каждый процессор позво' ляет указывать позиции табуляции и отступы путем перетаскивания маркера на линейке. Пользователь как бы говорит: «Я хочу, чтобы аб' зац начинался здесь», – и позволяет программе вычислить, что отступ равен 1,347 дюйма от левого поля. К счастью, пользователь не обязан вводить число 1,347 вручную.

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

 

Отображайте состояния объектов и статус приложения.

 

 

Когда человек спит, он выглядит спящим. Когда он проснулся, он вы' глядит бодрствующим. Если человек занят делом, он и выглядит соот' ветственно: его взгляд сосредоточен на объекте работы, а поза являет' ся закрытой и демонстрирует занятость. Если человек, наоборот, ни' чем не занят, это тоже понятно по его виду: его поза открыта, а взгляд блуждает в поисках контакта. Люди не просто ожидают друг от друга подобной обратной связи; поддержание общественного порядка приво' дит к определенной зависимости от этой обратной связи.

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

Точно так же состояние объектов пользовательского интерфейса должно быть ясным для пользователей. Большинство приложений электронной почты умеют очевидным образом показывать, какие со' общения не были прочитаны, на какие был написан ответ, а какие пользователь уже переслал. Разовьем идею: правда, было бы здорово, если, глядя на события в календаре Microsoft Outlook или IBM Lotus Notes, можно было бы понять, сколь многие люди согласились участ' вовать и как много людей еще не ответили?

 

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

 

 

Избегайте ненужных сообщений.

 

 

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

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

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

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

 

Не используйте диалоговые окна, чтобы сообщить, что все нормально.

 

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

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

 

Избегайте чистого листа.

 

 

Гораздо проще не задумываться о том, чего хочет пользователь, а за' дать ему кучу вопросов и принять решение на основе его ответов. Сколько вы видели приложений, начинающих работу с большого диа' логового окна с обширным списком вопросов? Однако нормальные лю' ди (не эксперты) чувствуют себя неуютно, когда им приходится объяс' нять интерактивному продукту, чего они хотят. Они предпочли бы, чтобы программа сделала то, что, по ее мнению, следует сделать, а за' тем скорректировали бы результат. В большинстве случаев программа в состоянии сделать правильное предположение на основании преды' дущего опыта. Например, когда вы создаете новый документ в Micro' soft Word, то получаете пустой документ с конкретными отступами и прочими атрибутами, а не оказываетесь лицом к лицу с диалоговым окном, требующим указать все эти детали. Программа PowerPoint ве' дет себя менее адекватно – она просит пользователя выбрать стиль презентации для каждой новой презентации. Обе программы стали бы гораздо приятнее, если бы запоминали часто применяемые и недавно использованные стили или шаблоны и задействовали их по умолча' нию для новых документов.

 

Просите прощения, а не разрешения.

 

 

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

 

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

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

 

Отделяйте функции от их настройки.

 

 

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

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

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

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

 

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