Глава 10. Оркестровка и состояние потока
л обно ноет, раздраженно ворчит, изводит пользователя, а затем просит прощения? В главе 12 мы обсудим, как сделать программный продукт более вежливым и деликатным.
Важно предоставлять пользователю выбор, но существует разница между возможностью сделать выбор на основании предложенной информации и необходимостью подвергаться обязательным допросам (касающимся формы, а не существа дела) со стороны программы. Пользователи предпочли бы управлять программой, как они управляют автомобилем. Автомобиль предлагает водителю богатый выбор действий, обходясь при этом без диалоговых окон. Вообразите себе ситуацию, представленную на рис. 10.7.
Прямое манипулирование рулем - не просто подходящая идиома связи с автомобилем. Она ставит вас в положение превосходства над автомобилем - и вы направляете его туда, куда нужно. Никакой пользователь не захочет, чтобы его допрашивали как одного из подозреваемых, -а ведь именно так нередко ведут себя наши программы.
ПРИНЦИП проектирования
Прячьте рычаги катапультирования.
В кабине каждого истребителя есть ярко окрашенный рычажок. Если за него потянуть, небольшой реактивный двигатель под сиденьем пилота сработает и вытолкнет пилота вместе с сиденьем из самолета, после чего раскроется парашют - и пилот благополучно спустится на землю. Рычажок катапульты можно использовать только один раз, а последствия его использования значительны и необратимы.
Катапульта в истребителе необходима, так же как средства настройки необходимы в сложных настольных приложениях. Превратности бизнеса и требования, предъявляемые к программным продуктам, заставляют адаптировать их к специфическим ситуациям - и мы должны обеспечить возможность такой адаптации. Фирмы, выкладывающие миллионы долларов за заказное программное обеспечение для бизнеса или за массовые лицензии на использование тысяч копий продукта,
Проектирование гармоничного взаимодействия
263
б удут недовольны, если программа окажется неспособной адаптироваться к их внутренним стандартам. Программа должна приспосабливаться, но эту процедуру следует рассматривать как однократное действие или в крайнем случае как действие, выполняемое редко и только квалифицированными сотрудниками фирмы. Иными словами, рычаг катапульты нужен, но используется он нечасто.
Программы должны иметь «катапульты», чтобы пользователи могли время от времени перемещать внутри интерфейса стабильные объекты (см. главу 11) или существенно (иногда необратимо) менять функциональность либо поведение приложения. Единственное, что никогда не должно случаться, - так это непреднамеренное катапультирование (рис. 10.8). При проектировании интерфейса следует убедиться, что пользователь не сможет нечаянно катапультироваться, когда ему требуется лишь слегка подкрутить настройки программы.
Рычаги «катапульты» бывают двух типов. Одни сильно изменяют внешний вид программы (расположение инструментов и рабочих областей), а другие выполняют какие-либо необратимые действия. Обе эти функции должны быть спрятаны от неопытных пользователей. Второй тип наиболее опасен. В первом случае пользователь может быть удивлен или напуган результатом, но он, по крайней мере, сможет вернуться к прежнему состоянию после некоторых усилий. Во втором случае и пользователю, и его коллегам придется смириться с последствиями.
Рис. 10.8. Рычаг катапульты способен вызвать катастрофические последствия. Еще минуту назад пилот удобно сидел в кресле самолета - и вот он уже кувыркается вверх тормашками в синем небе, а его самолет продолжает полет без него... Катапульта нужна для безопасности пилота, но конструкторы самолета делают все возможное для того, чтобы пилот не включил катапультирование по ошибке. Если разрешить ничего не подозревающему пользователю настраивать программу, меняя стабильные объекты интерфейса, это будет сравнимо со случайным включением катапульты. Прячьте рычаг катапульты!
264 Глава 10. Оркестровка и состояние потока
Е сли вы будете соблюдать принципы потока и оркестровки, ваша программа позволит пользователю увлеченно и максимально эффективно работать в течение долгого времени. Продуктивно работающий пользователь - это счастливый пользователь, а счастливые и эффективно работающие клиенты - цель любого производителя цифровых продуктов. В следующей главе мы продолжим обсуждение методов, позволяющих повысить продуктивность работы пользователей путем удаления ненужных барьеров, появляющихся вследствие проектирования по модели реализации.
Оптимизируйте скорость реакции; предупреждайте о за-
принцип держках.
проектирования
О брабатывая большой объем информации или общаясь с удаленными серверами, принтерами, сетями, приложение может замедлить свою работу или перестать реагировать на действия пользователя. Нет ничего более опасного для состояния потока пользователя, чем необходимость смотреть на экран, ожидая ответа компьютера. Крайне важно проектировать интерфейсы таким образом, чтобы они достаточно быстро реагировали на команды пользователя- ни один «гламурный» интерфейс на свете не способен впечатлить пользователя, когда он работает со скоростью улитки из-за интенсивной отрисовки экрана.
Здесь важно сотрудничать с разработчиками. Различного рода взаимодействие может, в зависимости от платформы и технологической среды, иметь достаточно высокую стоимость с точки зрения скорости реакции приложения. Вы должны не только выступать за интерфейс, обеспечивающий пользователя насыщенным взаимодействием с минимальными задержками, но и создавать решения, учитывающие выбор технической платформы в начале проекта, который нельзя изменить. Когда задержки неизбежны, важно четко сообщить об этом пользователю и дать ему возможность отменить операцию, вызывающую задержку, а в идеале - еще и возможность делать другую работу во время ожидания.
Если приложение выполняет потенциально «долгоиграющие» задачи, не забывайте время от времени проверять, что делает пользователь. Возможно, он барабанит по клавиатуре или бешено щелкает мышью, завывая при этом: «Да нет же, не хотел я перестраивать всю базу данных. Это же займет 4,3 миллиона лет!»
В ряде исследований, проведенных еще в конце 60-х годов, ученые выяснили, что восприятие пользователем времени реакции можно грубо разделить на несколько интервалов (Miller, 1968):
• До 0,1 секунды пользователи воспринимают отклик системы как моментальный. Они чувствуют, что напрямую манипулируют пользовательским интерфейсом и данными.
Проектирование гармоничного взаимодействия 265
Д
о
1 секунды пользователи чувствуют, что
система реагирует. Ве
роятно,
они замечают задержку, однако эта
задержка недостаточно
велика,
чтобы прервать мыслительные процессы.До 10 секунд пользователи замечают, что система работает медлен но, и отвлекаются, однако способны сохранять некоторое внимание к приложению. Здесь важно наличие индикатора хода работы.
После 10 секунд внимание пользователя полностью рассеивается. Он уходит за чашкой кофе или переключается на другое приложе ние. В идеале такие длительные процессы должны проводиться в фоновом режиме или без участия пользователя, позволяя ему за няться другой работой. В любом случае следует четко обозначать состояние и ход процесса, в том число оставшееся время. II просто обязателен механизм отмены.
В общем, создание успешного продукта требует но только предоставления полезных функций. Следует задуматься также об оркестроаке различных функциональных элементов, позволяющей пользователям достигать состояния потока при решении своих задач. Лучшие пользовательские интерфейсы но поражают пользователей своей красотой - скорее они почти нозаметны, поскольку с ними крайне легко работать.
1
1
Оптимизация налогообложения
Программным продуктам часто свойственны взаимодействия, вынуждающие пользователя выполнять дополнительную работу. Программисты, как правило, настолько сосредоточены на технологиях, лежащих в основе продукта, что не особенно вникают в действия, которые требуются от человека, работающего с этими технологиями, чтобы он мог достичь своих целей. В результате получается приложение, взимающее с пользователя налог — в виде умственного, а иногда и физического напряжения во время работы.
Когда нам нужно поехать на работу, мы открываем гараж, садимся в машину, запускаем двигатель, выезжаем из гаража задним ходом и закрываем дверь гаража, прежде чем начать движение в сторону работы. Все эти действия нацелены собственно на автомобиль, а не на наше продвижение к месту назначения. Если бы у нас был транспортер, как в фильме «Звездный путь» (Star Trek), мы бы просто ввели нужные координаты и сразу оказались в нужном месте, - никаких вам гаражей, двигателей и светофоров. Нет, мы не жалуемся на особенности езды на автомобиле - мы пытаемся подчеркнуть разницу между двумя видами действий, которые совершает человек для выполнения повседневных задач.
Любая крупная задача, например поездка на работу, распадается на ряд подзадач. Некоторые из них направлены непосредственно на достижение цели, например управление автомобилем на дороге. Налоговые задачи, с другой стороны, не приближают нас к цели, но все равно необходимы для ее достижения. Примеры налоговых задач: отпирание и запирание двери гаража, запуск двигателя, остановки у светофоров, долив масла, заправка и прохождение техосмотра. Налоги - это работа, удовлетворяющая потребности либо наших инструментов, либо внешних агентов, с которыми мы сталкиваемся, пытаясь достичь цели. Различия не всегда очевидны, так как мы привыкли
Налоги в графическом пользовательском интерфейсе 267
с читать налоги частью наших задач. Многие из нас ездят в автомобиле так часто, что им трудно отделять действия по отпиранию гаража от действий по вождению автомобиля. Однако манипуляции с гаражной дверью нужны автомобилю, а не нам, и они не продвигают нас к цели в той же степени, как манипуляции с педалью газа и рулевым колесом. Остановка на красный свет - выдвигаемое обществом требование, которое также не способствует достижению цели. (Впрочем, оно способствует достижению родственной цели - прибытию к месту назначения в целости и сохранности.)
Когда речь заходит о программных продуктах, разделение подзадач на непосредственно ведущие к цели и налоговое бремя достаточно очевидно. Как и в примере с автомобилем, некоторые налоговые задачи тривиальны, и решать их не составляет труда. С другой стороны, бывают задачи такие же неприятные, как замена спустившего колеса. На ум приходят такие примеры налогов, как установка приложения, настройка сетей, создание резервных копий файлов.
Проблема с налоговыми задачами заключается в том, что усилия, направленные на их решение, не способствуют достижению цели. Когда нам удается сократить налоги, мы делаем работу пользователя более эффективной и продуктивной, а также повышаем пригодность нашей программы к использованию, создавая более качественный опыт взаимодействия с ней. В качестве проектировщика взаимодействия вы должны внимательно следить за появлением налогов и предпринимать шаги по их искоренению с энтузиазмом врача, борющегося с инфекцией.
Существование налогов в пользовательских интерфейсах вызывает справедливое раздражение пользователей цифровых продуктов. Любому проектировщику и менеджеру продукта следует отлавливать налоги взаимодействия во всех проявлениях и удалять их из своих продуктов.
принцип
Сокращайте
налоговое
бремя
при
любой
возможности.
проектирования
Н
алоги
в
графическом
пользовательском
интерфейсе
Одна из главных претензий, предъявляемых к графическим интерфейсам опытными пользователями - особенно теми, кто привык к системам с командной строкой, - заключается в том, что осмысленное манипулирование окнами и меню требует дополнительных усилий. Командная строка позволяет просто набрать команду, которую компьютер немедленно выполнит. В оконных системах пользователям приходится открывать различные папки в поисках файла или программы, прежде чем они смогут открыть файл или запустить программу на исполнение.
268 Глава 11. Оптимизация налогообложения
П осле появления окна программы на экране приходится растягивать его до нужного размера и перетаскивать в подходящее место.
Все эти претензии имеют под собой основания. Подобные манипуляции с окнами фактически являются налогом. Они не приближают пользователя к намеченной цели, а являются накладными расходами - требованием, выдвигаемым программой прежде, чем она снизойдет до оказания помощи пользователю. Однако каждый знает, что графические интерфейсы проще в использовании, чем системы с командной строкой. Так где же правда?
Противоречие возникает из-за того, что реальные механизмы взаимодействия остаются скрытыми. В интерфейсе с командной строкой налоговое бремя пользователей еще тяжелее: прежде чем начать работать с системой, требуется выучить команды. Кроме того, пользователь не может изменить экран по своему вкусу. Налоги командной строки снижаются только после того, как пользователь потратит много времени и сил на ее освоение.
Зато для неопытного, случайного пользователя визуальная ясность графического интерфейса оказывается подспорьем в навигации и изучении возможностей. Пошаговый способ общения пользователя с графическим интерфейсом помогает тем, кто еще не знаком с функциональностью системы. Он помогает в работе и тем, кто должен решать несколько задач одновременно и запускать сразу несколько приложений.
Налоги и опытные пользователи
Любой пользователь, желающий разобраться в интерфейсе командной строки, может быть автоматически отнесен к категории экспертов. А любой пользователь, разобравшийся в одном интерфейсе командной строки, быстро разберется в любом другом интерфейсе, включая графический. Эти пользователи без труда постигнут любые тонкости обращения с программой. Они запускают программу, имея четкое представление о том, что и как требуется сделать. Такому пользователю только мешает помощь, которую интерфейс предлагает новичку.
Снижая бремя налогов, мы должны быть очень внимательны. Не следует снижать его лишь в угоду опытным пользователям. С другой стороны, нельзя перекладывать все налоги на плечи опытных пользователей, создавая удобства для новичков.
Трехколесный велосипед
Поддержка новичков и пользователей, работающих с продуктом время от времени, - это та область, где проектировщикам приложений сложно избежать создания излишнего налогового бремени. Легко найти оправдание той функциональности, которая облегчает жизнь новичкам, изучающим программу. К сожалению, эта функциональность быстро превращается в дополнительную нагрузку, когда пользователь
Налоги в графическом пользовательском интерфейсе 269
п ереходит из категории новичков в категорию вечных середняков, что мы обсуждали в главе 3. Функциональность, добавленная к программе ради обучения пользователей (скажем, пошаговые сценарии), должна легко отключаться. Дополнительные колеса для велосипеда помогают учиться начинающим, но мешают тому, кто уже научился кататься.
принцип
проектирования
Не приваривайте дополнительные колеса к велосипеду намертво.
«Наглые» налоги
Существуют действия, в которых не нуждается никто - ни новички, ни специалисты. Это и есть «наглые» налоги. Операции, связанные с настройкой аппаратной части, например указание программе, какой СОМ-порт она должна использовать, компьютер мог бы выполнить и самостоятельно. Подобные аспекты следует убирать из пользовательского интерфейса и заменять интеллектуальным поведением программы, скрытым от пользователя.
Визуальные налоги
Визуальный налог - это работа по расшифровке видимой информации, которую приходится выполнять пользователю. Поиск конкретного элемента в списке, выяснение того, откуда начинать чтение текста на экране или какие элементы являются активными, а какие служат просто украшениями, - все это визуальные налоги.
Проектировщики иногда сами загоняют себя в угол, слишком сильно полагаясь на визуальные метафоры. Речь идет о таких метафорах, как телефоны, копиры, степлеры и факсы на рабочих столах или картотечные шкафы с папками в ящиках. Эти визуальные метафоры позволяют быстро понять связь между элементами интерфейса программы и ее поведением, однако, когда пользователь поймет эти основы, работа с метафорами окажется «наглым» налогом (подробное обсуждение недостатков визуальных метафор проводится в главе 13). Кроме того, место на экране, отведенное под изображения, расходуется крайне нерационально, особенно в монопольных приложениях (типы приложений мы подробно обсуждали в главе 9). Чем дольше мы видим окно программы изо дня в день, тем больше мы негодуем по поводу огромного количества пикселов, расходуемых лишь на то, чтобы сообщить уже известные нам сведения. Небольшое изображение телефона, которое помогло нам набрать номер в первый день пользования, теперь превратилось в препятствие, затрудняющее быструю связь. Пользователям временных приложений часто требуются некоторые инструкции, чтобы эффективно использовать продукт. Расходование экранного пространства на эти цели во временном приложении, как правило, не имеет столь губительных последствий, как в монопольном.
270