 |
Оркестровка и состояние потока
|
|
|
|
Если мы хотим, чтобы пользователи наших продуктов работали более продуктивно, эффективно и увлеченно, мы должны убедиться, что пользователь пребывает в нужном настрое. В этой главе мы обсудим ментальную эргономику - способы сделать так, чтобы наши продукты оказывали поддержку человеческому интеллекту и способностям, и избежать разрушения того состояния продуктивной концентрации, в котором должны находиться пользователи.
Состояние потока и прозрачность
Люди, способные всецело сосредоточиться на некоторой деятельности, забывают о посторонних проблемах и отвлекающих факторах. Такое состояние называется потоком. Это понятие впервые предложил Ми-хай Чиксентмихайи (Mihaly Csikszentmihalyi) в своей книге «Flow: The Psychology of Optimal Experience» (Csikszentmihalyi, 1991).
Том Демарко (Тот DeMarco) и Тимоти Листер (Timothy Lister) в своей книге «Peopleware: Productive Projects and Teams»1 описывают поток как «состояние глубокого, почти медитативного погружения в работу». Поток нередко вызывает «мягкое чувство эйфории», так что человек, бывает, перестает замечать течение времени. Важно, что в состоянии потока человек может быть исключительно продуктивным, особенно если он занят созидательной работой, например конструированием, дизайном, разработкой или созданием литературных произведений. Итак, подчеркнем очевидное: чтобы сделать людей более продуктивными и счастливыми, нам надлежит проектировать интерактивные продукты, вызывающие и поддерживающие состояние потока, и при-
Т. Демарко, Т. Листер «Человеческий фактор: успешные проекты и команды». - Пер. с англ. - СПб: Символ-Плюс, 2005.
Глава 10. Оркестровка и состояние потока
кладывать все возможные усилия, чтобы избежать любого поведения, потенциально способного разрушить поток. Если программа то и дело выбивает пользователя из потока, ему трудно возвращаться в это продуктивное состояние.
|
|
|
Если бы пользователь мог достичь своих целей волшебным образом, без вашего продукта, он бы так и поступил. Аналогично этому, если бы он, пользуясь вашей программой, мог решать свои задачи без всякого интерфейса, он бы обязательно решал их именно так. Взаимодействие с программным продуктом не несет в себе эстетической составляющей (кроме, быть может, взаимодействия с игровыми, развлекательными и информационными программами вроде веб-броузеров). В большинстве случаев это сугубо утилитарная деятельность, которую следует свести к минимуму.
Каким бы замечательным ни был ваш интерфейс, чем его
принцип меньше, тем лучше.
Проектирования
Если вы будете прежде всего думать об интерфейсе как таковом, на первый план выйдут побочные эффекты инструментов и технологий, а не цели пользователя. Пользовательский интерфейс- это артефакт, не связанный напрямую с целями, стоящими перед пользователем. Когда вы в следующий раз будете ликовать по поводу замечательно спроектированного взаимодействия, вспомните, что, в конечном счете, лучшим пользовательским интерфейсом в большинстве случаев является полное отсутствие интерфейса.
Чтобы привести пользователя в состояние потока, вы должны сделать его взаимодействие с программным продуктом прозрачным. Когда романист пишет хорошо, писательское ремесло остается незамеченным, а читатель воспринимает только историю и ее персонажей с ясностью, которой техника письма но препятствует. Точно так же, когда продукт хорошо взаимодействует с человеком, механика взаимодействия исчезает, оставляя человека один на один с его целями без какой-либо посреднической функции программы. Плох тот писатель, читатели которого обращают внимание на текст, и плох тот проектировщик взаимодействия, что неуклюжее присутствие ощущается в созданных им программах.
|
|
|
| ПРИНЦИП проектирования |
Хорошо оркестрованные пользовательские интерфейсы прозрачны.
Для романиста не может быть «хорошего» предложения в отрыве от повествования. Не существует правил, благодаря которым предложение становится прозрачным. Все зависит от действий главного героя или от воздействия, которое желает оказать на читателя автор. Писатель понимает, что не следует использовать непонятные слова в осо-
Проектирование гармоничного взаимодействия 245
бенно тихом и чувственном абзаце, ибо они прозвучат как фальшивые ноты в струнном квартете.
То же верно и для программного обеспечения. Проектировщик взаимодействия должен учить себя слышать фальшивые ноты в оркестровке программного взаимодействия. Жизненно важно, чтобы все элементы интерфейса работали скоординированно для достижения единой цели. Когда общение приложения с человеком организовано хорошо, оно становится практически незаметным.
Словарь Webster определяет оркестровку как «гармоничную организацию» - а от интерактивных продуктов разумно ожидать именно такой организации. Гармоничная организация не следует жестким правилам. Невозможно создать указания вроде «Пять кнопок в диалоговом окне — это хорошо» и «Семь кнопок в диалоговом окне - это уже слишком много». Однако легко догадаться, что не стоит создавать диалоговое окно с 35 кнопками. Серьезное затруднение, которое вызывают рассуждения такого рода, состоит в том, что проблема рассматривается в искусственных условиях. Подобный анализ не принимает во внимание задачу, которую требуется решить, равно как и то, чем занят в данный момент человек и чего он пытается добиться.
Проектирование гармоничного взаимодействия
Не существует универсальных правил, определяющих гармоничное взаимодействие, как не существует универсальных правил определения гармоничных пауз в музыке, однако мы находим, что перечисленные ниже стратегии направляют проектирование взаимодействия в нужное русло:
1. Следуйте ментальным моделям пользователей.
2. Меньше - лучше.
3. Позволяйте пользователям управлять, не принуждайте их к диалогу.
|
|
|
4. Держите инструменты под рукой.
5. Обеспечивайте немодальную обратную связь.
6. Проектируйте наиболее вероятное, будьте готовы к возможному.
7. Предоставляйте информацию о контексте.
8. Организуйте непосредственное манипулирование и графический
ввод.
9. Отображайте состояния объектов и статус приложения.
10. Избегайте ненужных сообщений.
11. Не используйте диалоговые окна, чтобы сообщить, что все нормаль
но.
12. Избегайте чистого листа.
13. Просите прощения, а не разрешения.
Глава 10. Оркестровка и состояние потока
14. Отделяйте функции от их настройки.
15. Не задавайте вопросы - предоставляйте выбор.
16. Прячьте рычаги катапультирования.
17. Оптимизируйте скорость реакции; предупреждайте о задержках.
Обсудим эти принципы более подробно.
Принцип Следуйте ментальным моделям пользователей.
Проектирования
Понятие ментальных моделей было введено в главе 2. Разные пользователи имеют разные ментальные модели определенной деятельности или процесса, но эти модели редко представлены в терминах того, как на самом деле функционируют компьютеры. Каждый пользователь естественным образом формирует в уме образ того, как программа выполняет свою работу. Мозг пытается найти какую-нибудь причинно-следственную связь между событиями и объяснить поведение компьютера.
Например, в медицинской информационной системе медперсонал имеет ментальную модель базы данных о пациентах, основанную на медицинских картах, с которыми они сталкиваются в реальной жизни. Следовательно, имеет смысл реализовать поиск информации о пациенте по имени. Каждый врач наблюдает нескольких больных, так что имеет смысл дополнительно фильтровать пациентов в интерфейсе информационной системы так, чтобы врач мог выбирать пациента из списка, отсортированного по именам. С другой стороны, сотрудников больничной бухгалтерии в первую очередь интересуют неоплаченные счета пациентов. Изначально им все равно, как зовут больных, - важны сроки оплаты счетов (и, возможно, суммы). Значит, для бухгалтерии интерфейс информационной системы должен сортировать записи о пациентах по срокам задержки оплаты счетов и, возможно, по их суммам, а имена пациентов отходят на второй план.
|
|
|
принцип Меньше - лучше.
Проектирования
Во многих случаях действует правило «чем больше - тем лучше». В области проектирования взаимодействия справедливо обратное утверждение, и мы должны постоянно бороться за сокращение количества элементов интерфейса без сокращения возможностей продукта. Чтобы добиться этого, мы должны сделать много, пользуясь минимумом средств, и здесь особенно важна тщательная оркестровка. Мы должны координировать и контролировать функциональность программного продукта, не позволяя интерфейсу превращаться в нагромождение диалоговых окон, усыпанных нелогичными и редко используемыми элементами управления.
Проектирование гармоничного взаимодействия 247
Легко создать сложный, но не очень мощный интерфейс. Как правило, в подобных продуктах функциональность изолируется в отдельные «гетто», и пользователь может выполнить какую-то одну задачу, не имея доступа к средствам решения смежных задач. Когда в 1995 году вышло первое издание этой книги, проблема была повсеместной. Взять такую простую вещь, как диалоговое окно сохранения файла в Windows-приложении: в этом диалоговом окне не было возможности переименовать или удалить файлы, представленные пользователю. Пользователь был вынужден выполнять эти родственные сохранению файлов задачи обходными путями, что, в конечном счете, требовало от операционной системы дополнительных интерфейсов. К счастью, современные операционные системы лучше справляются с такими тонкостями. Поскольку теперь принято предлагать функциональность, соответствующую контексту пользователя, человеку реже приходится перебирать различные области интерфейса, чтобы решать простые распространенные задачи.
Впрочем, у нас впереди еще долгий путь. Мы часто сталкиваемся с программами для бизнеса, в которых каждая функция или возможность «живет» в отдельном диалоге или окне, словно разработчики не задумывались, каким образом людям необходимо сочетать функции для решения определенных задач. Пользователям часто приходится выполнять команду меню, чтобы получить фрагмент информации, затем копировать эту информацию в буфер обмена, после чего в другом окне выполнять еще одну команду - и все это лишь для того, чтобы вставить скопированную информацию в поле ввода. Это не просто неэлегантное и грубое решение - это подход, провоцирующий ошибки и неспособный поддерживать продуктивное разделение труда между человеком и машиной. Как правило, подобные продукты создаются неспециально - это получается в ходе многолетней разработки с принятием решений на ходу или вследствие разработки продукта несколькими изолированными командами, обитающими в отдельных резервациях внутри организации.
|
|
|
Популярная модель телефона Motorola - Razr - хорошо иллюстрирует эту проблему: промдизайн телефона заслуживает всяческих похвал за элегантность результата, а вот программное обеспечение взято от предыдущего поколения телефонов Motorola и, похоже, разрабатывалось несколькими нескоординированными командами. Так, интерфейс ввода текста в записной книжке телефона отличается от интерфейса ввода текста в календаре. По-видимому, каждая из команд разработчиков создала собственное решение, что и дало два различных интерфейса, решающих одну и ту же задачу; все это - пустая трата ресурсов при разработке, а также источник путаницы и затруднений для пользователей продукции Motorola.
Классическая книга Маллета (Mullet) и Сано (Sano) «Designing Visual Interfaces» (Mullet and Sano, 1995) содержит плодотворное обсужде-
248 Глава 10. Оркестровка и состояние потока
ние идеи элегантности, которую можно считать новым, простым, экономичным и изящным способом решать задачи проектирования. Поскольку обычно программное обеспечение интерактивных продуктов является невероятно сложным, все более ценными становятся элегантность и простота. Это необходимые свойства технологии, предназначенной служить человеку и его потребностям.
Минималистичный подход к проектированию продуктов неизбежно связан с четким пониманием назначения: чего пытается достичь пользователь, применяя инструмент? Без понимания назначения интерактивные продукты - не более чем неорганизованное нагромождение функций, демонстрирующих работу технологий. Показательным примером того, как глубокое понимание назначения привело к созданию минималистичного пользовательского интерфейса, является поисковая система Google, где есть лишь текстовое поле, две кнопки («Поиск eGoogle», отображающая перечень результатов, и «Мне повезет!», выполняющая переход к первому сайту из результатов поиска), логотип компании Google и пара гиперссылок на вселенную функций Google (рис. 10.1). Другой хороший пример минималистичного пользовательского интерфейса - iPod Shuffle. Компания Apple, определив со всей тщательностью набор уместных возможностей, служащий конкретным потребностям пользователей, создала превосходный по удобству продукт с одним переключателем, пятью кнопками - и без экрана! Невероятно простой текстовый редактор WriteRoom (Hog Bay Software) вообще не имеет пользовательского интерфейса - только область, в которой можно набирать текст. Текст сохраняется автоматически, избавляя от необходимости иметь дело с файлами.
| Рис. 10.1. Знаменитый поисковый интерфейс Google - классический пример минималистичного проектирования интерфейса, в котором каждый элемент на экране содержателен и понятен |
Важно помнить, что стремление к простоте может зайти слишком далеко - сокращение интерфейса есть поиск баланса, требующий хорошего понимания ментальных моделей пользователей. Упомянутый выше аппаратный интерфейс iPod - пример элегантного и сдержанного проектирования - тем не менее противоречит ожиданиям некоторых пользователей. Если вы жили в мире кассетных дек и проигрывателей для компакт-дисков, вероятно, использование переключателя
Проектирование гармоничного взаимодействия 249
Проигрывание/Пауза на устройстве iPod для выключения устройства, а кнопки Меню - для включения устройства покажется вам странным. Это классический случай того, как визуальная простота может приводить к высокому когнитивному сопротивлению. В данном случае идиомы достаточно просты, чтобы их можно было легко заучить, и последствия неправильных действий не очень страшны, так что на успех продукта в целом это не повлияло.
Позволяйте пользователям управлять, не принуждайте их
принцип к диалогу.
Проектирования
Многие разработчики, похоже, воображают, что идеальный интерфейс должен иметь форму диалога с пользователем. Однако пользователи в большинстве своем так не думают. Они предпочитают взаимодействовать с программой примерно так же, как с автомобилем: они открывают дверцу и садятся в машину, когда хотят куда-нибудь съездить; они давят на педаль газа, когда хотят, чтобы машина ехала, и на тормоз, чтобы она остановилась; они поворачивают руль, когда хотят повернуть.
Такое идеальное взаимодействие не является диалогом. Скорее, это использование средства передвижения. Когда плотник забивает гвозди, он не вступает в диалог с молотком, а просто стучит по гвоздю. Водитель командует автомобилем, когда хочет изменить его поведение. Водитель ждет от автомобиля и окружения прямого отклика, уместного в контексте: вид из окна, показания приборов, свист ветра и звук шин на дороге, боковые перегрузки и вибрация от неровностей дороги. Есть своя обратная связь и у плотника: он чувствует, как гвоздь уходит в доску, слышит стук молотка и чувствует его тяжесть.
Водитель явно не ожидает, что автомобиль вступит с ним в переговоры с помощью диалогового окна, а плотник тем более не оценит появление на молотке диалогового окна (вроде того, что изображено на рис. 10.2).
Одной из причин, по которым программный продукт нередко раздражает пользователей, является то, что он ведет себя не так, как автомо-
Рис. 10.2. Из того, что программисты привыкли к подобным сообщениям, вовсе не следует, что это справедливо в отношении представителей других профессий. Никто не хочет, чтобы компьютер его ругал. Если мы заставляем его сделать глупость, то мы вправе ожидать, что он эту глупость сделает. Конечно, наши инструменты должны защищать нас от непоправимых ошибок, но защищать и ругать - не одно и то же
250 Глава 10. Оркестровка и состояние потока
биль или молоток. Он часто имеет наглость вовлекать нас в диалог: сообщает нам о наших промахах и требует от нас ответа. С точки зрения пользователей, все должно быть наоборот: пользователь требует, а компьютер отвечает.
Непосредственное манипулирование позволяет нам указывать на то, что мы хотим. Если мы хотим передвинуть объект из точки А в точку В, мы щелкаем по нему и перетаскиваем мышью. Вообще говоря, лучшие интерфейсы, вызывающие у пользователя состояние потока, - это интерфейсы с большим количеством развитых идиом непосредственного манипулирования.
принцип Держите инструменты под рукой.
Проектирования
Большинство приложений сложны настолько, что одного режима непосредственного манипулирования недостаточно для реализации всех функциональных возможностей. Как следствие, приложение обычно предлагает пользователю набор разнообразных инструментов. Эти инструменты в действительности являются различными режимами поведения продукта. Предоставление инструментальных средств потенциально усложняет программу, и требуется затратить еще много сил, чтобы манипулирование инструментом стало действительно простым и не выводило пользователя из состояния потока. В первую очередь мы должны обеспечить полноту и доступность информации о текущем инструменте, а также быстроту и легкость переключения с одного инструмента на другой.
Инструменты должны быть под рукой - предпочтительно на палитре или на панели инструментов для начинающих и середняков, а также в виде клавиатурных сокращений - для специалистов. Тогда пользователь будет их видеть и сможет одним щелчком или нажатием клавиши выбрать любой из них. Если пользователь вынужден переключать внимание с основного занятия на поиски нужного инструмента, он утратит сосредоточенность. Это все равно что встать из-за стола и пойти в другой конец дома за карандашом. Кроме того, никогда не заставляйте пользователя вручную убирать инструменты.
принцип Обеспечивайте немодальную обратную связь.
Проектирования
Когда пользователь интерактивного продукта манипулирует инструментами и данными, как правило, желательно, чтобы программа сообщала ему об их состоянии и о результатах произведенных манипуляций. Эта информация должна быть легко читаемой и понятной, не заслоняющей элементы интерфейса и не препятствующей нормальной работе пользователя.
Проектирование гармоничного взаимодействия
Приложение имеет ряд способов представлять информацию или осуществлять обратную связь с пользователем. К сожалению, самым распространенным подходом является вывод диалогового окна. Эта техника модальна: программа переходит в специальный режим, требующий реакции пользователя, без которой она не может вернуться в нормальное состояние, а пользователь не может продолжать работу. Более удачным подходом является обеспечение вемодальной обратной связи.
Обратная связь немодальна, если информация для пользователя включена в основной интерфейс и не прерывает нормальную работу системы и ее взаимодействие с пользователем. Например, редактор Word сообщает вам номер текущей страницы и раздела, количество страниц в документе, позицию курсора и текущее время. Вся эта информация немодальна: вы просто смотрите на строку состояния внизу окна, и для получения информации вам не требуется выполнять сложные действия.
Однако при желании узнать количество слов в документе нужно вызвать диалоговое окно Статистика из меню Сервис (рис. Ю.З.а), в котором есть доступ к панели статистики (рис. 10.3,6), но даже на ней придется постоянно нажимать кнопку Пересчет для получения точной информации. Авторы журнальных статей, которым важно знать количество слов, предпочли бы получать эту информацию в немодальной форме. И хотя многим людям такая статистика не нужна, внизу экрана есть свободное пространство, способное вместить подобную информацию.
В кабине истребителя есть специальное устройство, которое выводит показания важнейших приборов прямо на лобовое стекло. Пилоту даже не приходится пользоваться периферийным зрением: он видит всю
|
|
а)
б)
в)
Рис. 10.3. Работая в редакторе Word 2003. вы можете узнать количество слов в документе, выполнив команду Статистика из меню Сервис. Команда открывает диалоговое окно. Чтобы вернуться к работе, вы должны нажать кнопку Закрыть. Такое поведение является полной противоположностью немодальной обратной связи, и оно выводит пользователя из состояния потока. В Word 2007 Microsoft значительным образом улучшила ситуацию: число слов в документе немодально отображается в левом нижнем углу окна рядом со счетчиком страниц (в), поскольку это родственные значения
252 Глава 10. Оркестровка и состояние потока
необходимую информацию, не отрывая взгляда от самолета противника. Приложение может использовать края экрана для отображения информации о том, что происходит в рабочей области. Многие графические приложения, такие как Adobe Photoshop, имеют на периферии окна линейки, миниатюры и другие элементы немодальной обратной связи. Типы обогащенной немодальной обратной связи подробно обсуждаются в главе 25.
Проектируйте наиболее вероятное, будьте готовы к
принцип можному.
Проектирования
Существует много случаев, когда взаимодействие с пользователем (обычно в форме диалоговых окон) проникает в интерфейс без особой необходимости. Часто это происходит, когда программа стоит перед выбором. Большинство программистов решают проблему выбора с позиций логики, и это отражается на создаваемом продукте. С точки зрения логики, если утверждение справедливо в 999 999 случаях из миллиона и ложно в одном случае, то оно ложно. Так работает булева логика. Однако для большинства людей оно будет безусловно истинным. Утверждение может быть ложным, но вероятность этого мала настолько, что ею можно пренебречь. Одним из самых продуктивных методов оркестровки пользовательских интерфейсов является разграничение возможного и вероятного.
Программисты обычно считают, что возможность и вероятность — одно и то же. Например, пользователь может завершить работу с программой и сохранить свою работу, а может выбросить документ, над которым работал в течение шести часов. Любой поворот событий возможен. Вероятность того, что пользователь выбросит результаты своего труда, - не больше, чем одна тысячная. Тем не менее типичная программа содержит диалоговое окно с вопросом, не хочет ли пользователь сохранить изменения (рис. 10.4).
Рис. 10.4. Это, бесспорно, самое ненужное диалоговое окно в мире графических пользовательских интерфейсов. Конечно же, мы хотим сохранить свою работу! Это нормальный ход событий. Отказ сохранить ее был бы таким экзотическим событием, что обрабатывать его нужно было бы в каком-нибудь редко используемом диалоговом окне. Одно это диалоговое окно заставляет пользователя узнать едва ли не больше бесполезных и сбивающих с толку фактов об оперативной памяти и жестком диске, чем любое другое взаимодействие с компьютером. От этого диалогового окна следует отказаться
Проектирование гармоничного взаимодействия 253
Диалоговое окно, изображенное на рис. 10.4, неуместно и бесполезно. Как часто вы отказываетесь от изменений, которые внесли в документ? Это диалоговое окно подобно сварливой жене, предупреждающей мужа, чтобы он не пролил суп на рубашку, всякий раз, как он обедает. Мы обсудим смысл отказа от этого окна в главе 17.
Умения программистов оценивают по их способности создавать программы, обрабатывающие множество возможных, но маловероятных условий, возникающих в сложных логических системах. Однако это не означает, что они должны переносить свое умение обрабатывать экзотические ситуации на пользовательский интерфейс. Навязчивое присутствие пограничных ситуаций выдает те интерфейсы, которые были спроектированы программистами. Диалоговые окна, элементы управления и настройки, используемые сто раз в день, расположены рядом с окнами, элементами и настройками, которые могут понадобиться раз в год или не нужны вообще.
Возможно, что с вашей машиной столкнется автобус, однако вероятно, что вы доберетесь до работы без приключений. Вы же не останетесь дома из страха перед автобусом? Так пусть возможные события не отвлекают вас от вероятных в тот момент, когда вы разрабатываете интерфейс.
принцип Представляйте информацию с учетом контекста.
проектирования
Способ представления информации приложением - это еще один путь для создания помех в сознании пользователя. Особые злоупотребления наблюдаются при представлении количественной, то есть цифровой информации. Если приложение должно сообщить пользователю об объеме свободного пространства на диске, оно может поступить, как в свое время поступал Менеджер файлов в Windows 3.x, а именно - вывести точное количество свободных байтов (рис. 10.5).
Puc, 10.5. Менеджер файлов в Windows 3.x гордо сообщал пользователю точное количество байтов, занятых файлами на диске. Помогает ли такая точность понять, что диск пора чистить? Конечно, нет. Более того, разве семизначное число является лучшим способом индикации состояния диска? Разве графическое представление соотношения свободного и занятого пространства (например, в виде круговой диаграммы) не было бы более осмысленным?, К счастью, теперь Microsoft Windows использует для индикации свободного места на диске круговые диаграммы
254 Глава 10. Оркестровка и состояние потока
В левом нижнем углу окна выведено количество свободных байтов на диске и общее количество байтов на диске. Эти числа трудно воспринимать и трудно интерпретировать. Когда диск содержит больше десятка миллиардов байтов, для нас уже неважно, сколько сотен байтов свободно. Тем не менее программа подсчитывает килобайты. Несмотря на такую точность, передача информации затруднена. В действительности пользователь хочет знать, заполнен ли диск до отказа - или можно добавить программу размером 20 Мбайт и еще останется достаточно места. Голые цифры, какими бы точными они ни являлись, мало помогают в этом вопросе.
Специалист в области визуального представления данных Эдвард Таф-ти (Edward Tufte) говорит, что представление количественной информации должно отвечать на вопрос: «По сравнению с чем?» Знание того, что на диске свободно 231 728 Кбайт, не столь полезно, как знание того, что это 22% от общего размера диска. Другой афоризм Тафти: «Показывайте данные», а не просто сообщайте о них в текстовой или численной форме. Круговая диаграмма, показывающая занятое и свободное место на диске разным цветом, гораздо понятнее сообщает о масштабе и пропорциях использования дискового пространства. Она объясняет нам, что в действительности означает число 231 728 Кбайт. Цифры должны оставаться на экране, но их статус должен быть сведен к меткам на диаграмме. Кроме того, их точность должна находиться в пределах разумного и быть одинаковой повсеместно. Смысл информации должен быть представлен визуально, а цифры используются лишь для поддержки.
В Windows XP и Windows Vista корпорация Microsoft одной рукой дает, а другой отбирает. Менеджер файлов (см. рис. 10.5) уже давно канул в небытие, а на смену ему пришел Проводник (рис. 10.6). Эта замена привела к появлению диалогового окна со свойствами жесткого диска. Занятое пространство окрашено в синий цвет, а свободное-в лиловый. Такую круговую диаграмму легко воспринимать. Теперь вы моментально определяете, что - о счастье! - ваш жесткий диск Gran-Fromage почти пуст.
К сожалению, эта круговая диаграмма не встроена в интерфейс Проводника. Пользователю приходится искать в меню пункт, позволяющий ее открыть. Чтобы узнать, насколько заполнен диск, вы должны вызвать модальное диалоговое окно, которое, хотя и сообщает нужную информацию, отрывает вас от основного занятия и уводит далеко от того места, где потребовалась эта информация. Проводник - программа, которая позволяет просматривать, копировать, перемещать и удалять файлы, но в нем вы не можете легко узнать, пора ли вам что-то удалить. Эта секторная диаграмма должна быть встроена в интерфейс Проводника. В Windows 2000 она отображается в левой части окна при выборе диска в Проводнике. В XP Microsoft сделала шаг назад -и диаграмма снова прописалась в диалоговом окне. Следует выводить
Проектирование гармоничного взаимодействия
|
Рис. 10.6. В Windows XP и Windows Vista компания Microsoft заменила электрический стул смертельной инъекцией. Вместо длинных неразборчивых чисел внизу окна Менеджера файлов можно открыть диалоговое окно свойств в Проводнике. Хорошая новость: наконец нам наглядно дают понять, как чувствуют себя жесткие диски. Плохая новость: чтобы это понять, необходимо прекратить текущую деятельность и открыть диалоговое окно - всего лишь для получения базовой информации, которая должна быть доступна всегда. В Windows 2000 эта диаграмма автоматически отображалась в левой части окна Проводника при выборе диска; решение Windows XP представляет собой шаг назад
круговую диаграмму наряду с численными данными все то время, пока открыто окно Проводника, если пользователь не предпочтет убрать диаграмму с экрана.
ПРИНЦИП проектирования
Организуйте непосредственное манипулирование и графический ввод.
Программные продукты редко представляют численную информацию в наглядном виде. Еще реже они позволяют вводить данные в графической форме. Многие программы дают возможность вводить числа, а затем - по команде - преобразуют эти числа в графическое представле-
256 Глава 10. Оркестровка и состояние потока
ние. Редкие продукты позволяют пользователю создать график и по
команде преобразовать его в последовательность чисел. Исключение -
современные текстовые процессоры: почти каждый процессор позво-
ляет указывать позиции табуляции и отступы путем перетаскивания
маркера на линейке. Пользователь как бы говорит: «Я хочу, чтобы абзац начинался здесь», - и позволяет программе вычислить, что отступ равен 1,347 дюйма от левого поля. К счастью, пользователь не обязан вводить число 1,347 вручную.
Этот принцип действует в самых разных ситуациях. Когда нужно упорядочить элементы какого-либо списка, пользователь, возможно, захочет расположить их в алфавитном порядке. Однако он может захотеть расположить их по своему вкусу, а не в соответствии с неким алгоритмом. У пользователя должна быть возможность перетаскивать элементы списка непосредственно, без вмешательства каких бы то ни было алгоритмов.
принцип
Проектирования
Отображайте состояния объектов и статус приложения.
Когда человек спит, он выглядит спящим. Когда он проснулся, он выглядит бодрствующим. Если человек занят делом, он и выглядит соответственно: его взгляд сосредоточен на объекте работы, а поза является закрытой и демонстрирует занятость. Если человек, наоборот, ничем не занят, это тоже понятно по его виду: его поза открыта, а взгляд блуждает в поисках контакта. Люди не просто ожидают друг от друга подобной обратной связи; поддержание общественного порядка приводит к определенной зависимости от этой обратной связи.
Наши приложения и устройства должны вести себя аналогично. Когда программа «спит», она должна выглядеть спящей. Приложение в активном состоянии и должно выглядеть активным, а приложение, выполняющее определенные действия, должно выглядеть соответственно. Когда компьютер занят важной работой, например выполняет сложные вычисления или подключается к базе данных, должно быть очевидно, что приложение не будет так шустро реагировать на наши запросы, как обычно. Когда компьютер отправляет факс, мы должны видеть анимацию сканируемого и отправляемого факса (или хотя бы немодальный индикатор хода операции).
Точно так же состояние объектов пользовательского интерфейса должно быть ясным для пользователей. Большинство приложений электронной почты умеют очевидным образом показывать, какие сообщения не были прочитаны, на какие был написан ответ, а какие пользователь уже переслал. Разовьем идею: правда, было бы здорово, если, глядя на события в календаре Microsoft Outlook или IBM Lotus Notes, можно было бы понять, сколь многие люди согласились участвовать и как много людей еще не ответили?
Проектирование гармоничного взаимодействия
Отображать состояние программы и объектов лучше всего с помощью обогащенной немодальной обратной связи, которая уже обсуждалась ранее в этой главе. Более подробное обсуждение и примеры немодальной обратной связи можно найти в главе 25.
принцип Избегайте ненужных сообщений.
Проектирования
Программистам необходимо точно знать, что происходит в программе. Для них это связано с возможностью детального контроля внутренних процессов. Зато пользователям нет никакого дела до мелких подробностей того, что творится внутри программы. Например, люди, не разбирающиеся в технике, могут быть встревожены сообщением, что база данных была модифицирована. Гораздо лучше, когда программа просто выполняет свою работу, сообщает об успешном завершении операций и не нагружает пользователя подробностями о том, как она добилась результата.
Многие приложения усердно держат пользователя в курсе всех подробностей своей работы, даже если он не имеет ни малейшего представления о том, что делать с этой информацией. Программы выводят диалоговые окна, сообщающие нам, что соединение установлено, записи отправлены, пользователи зарегистрированы в системе, транзакции записаны, данные переданы, - и уйму других бесполезных фактов. Для программистов эти сообщения - все равно что ровный гул мотора, журчание ручья или плеск волн о берег моря: они свидетельствуют о том, что все благополучно. По всей видимости, эти сообщения использовались при отладке программы. Однако для обычного человека они равносильны тревожным огням на горизонте, крикам в ночи или предметам, самостоятельно летающим по комнате.
Как было сказано ранее, приложение должно недвусмысленно сообщить пользователю, что выполняет некую работу, но подробная обратная связь должна быть организована более тонко. В частности, вывод сведений, перечисленных выше, в форме диалоговых окон прервет взаимодействие пользователя с программой, не предложив взамен никакой компенсации.
Важно не прерывать работу ради выдачи сообщения о том, что все протекает нормально. Когда происходит ожидаемое событие, не нужно сообщать о нем с помощью диалогового окна. Поберегите диалоговые окна для событий, выходящих за рамки нормального положения дел.
ПРИНЦИП проектирования
Не используйте диалоговые окна, чтобы сообщить, что все нормально.
|9 3ак, 1494
258 Глава 10. Оркестровка и состояние потока
По сходным причинам не следует прерывать работу, чтобы побеспокоить пользователя сообщением о несерьезных проблемах. Если программа не смогла создать соединение с сервером, не выводите ради этого диалоговое окно. Поместите в ок
|
|
|
