Длительность интеллектуальной работы

Скорость выполнения работы

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

Длительность интеллектуальной работы

Взаимодействие пользователя с системой (не только компьютерной) состоит из семи шагов:

1 формирование цели действий

2 определение общей направленности действий

3 определение конкретных действий

4 выполнение действий

5 восприятие нового состояния системы

6 интерпретация состояния системы

7 оценка результата.

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

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

Непосредственное манипулирование

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

Подойти к чайнику и открыть крышку. Если воды в чайнике мало или нет вовсе, перенести чайник к раковине и наполнить его водой, после чего поставить его на плиту. Если воды в чайнике достаточно, сразу поставить его на плиту. Закрыть чайник крышкой. Найти спички. Открыть коробок, вытащить одну спичку, закрыть коробок, зажечь спичку. Спичкой зажечь под чайником газ, установив подачу газа на максимум. Потушить спичку и выкинуть её. Подождать, пока чайник не закипит, в это время найти достаточно чистый стакан и налить в него заварки. По желанию, найти сахарницу и добавить сахару в стакан. Выключить газ. Налить кипятка из чайника в стакан. Размешать жидкость мизинцем (время от времени вытаскивая его из жидкости и дуя на него, чтобы не обжечься). Употребить жидкость по назначению. Ах, да. Закрыть кран в раковине.

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

1 что он хочет получить на выходе (чай)

2 как минимум одну последовательность действий, приводящую к успешному результату (наполнить чайник, поставить его на плиту, дождаться закипания, налить кипяток в стакан с заваркой)

3 где ему найти все объекты, участвующие в процедуре

4 как определять годность объектов к использованию (есть ли вода в чайнике)

5 как управляться с объектами (как включить газ).

Список, как видим, довольно внушительный. И если с первым пунктом проблем обычно не возникает, то с остальными приходится повозиться. Плохая новость заключается в том, что остальных пунктов много, хорошая новость – в том, что решение всех этих проблем единое. Оно называется непосредственным манипулированием (direct manipulation). Смысл этого метода очень прост. Пользователь не отдает команды системе, а манипулирует объектами. Когда вы хотите зажечь газ в плите, вы ведь не командуете плите «Зажги газ!». Нет, вы манипулируете спичками и плитой так, чтобы получился огонь. Это значительно более естественный для человека способ (как-никак весь реальный мир устроен таким образом). Первым популярным применением этого метода была корзина для удаления файлов на Macintosh (начиная с Windows 95, такая корзина стала стандартом и в Windows мире, хотя присутствовала она и раньше). Чтобы не пересказывать уже известное, ограничусь констатацией того простого факта, что если перетащить в неё пиктограмму файла, этот файл будет фактически стерт. Чтобы лучше оценить прелесть этого метода, удобно сравнить три варианта действий пользователя на примере этого самого стирания:

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

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

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

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

Потеря фокуса внимания

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

Телефонный звонок, обеденный перерыв, анекдот, рассказанный коллегой. В течение работы происходит множество таких отвлечений. Помимо них пользователя отвлекает множество мелочей: листок бумаги на столе перекрывает другой, нужный; мимо кто-то проходит и нужно бросить на него беглый взгляд. Более того, даже посторонняя мысль также отвлекает от работы. Но это еще не главное: каждый раз, когда пользователь прерывает свою деятельность и начинает думать о том, что ему делать дальше, он отвлекается тоже. И эти раздумья отвлекают пользователя значительно чаще, чем всё остальное. Каждое такое отвлечение занимает определенное время. Хуже того, оно сбивает фокус внимания, т.е. обработку текущего действия. После каждого такого отвлечения пользователь должен либо вспоминать текущую задачу, либо заново её ставить перед собой (занимает это несколько секунд, что много). Дело в том, что у человека есть только один фокус внимания, так что при любом отвлечении (которое есть не что иное, как переключение на другую задачу) старый фокус внимания теряется. Было бы еще ничего, если бы возвращение фокуса требовало только изменения направления взгляда. Но при отвлечении новые стимулы заменяют содержимое кратковременной памяти, так что для возвращения к работе от пользователя требуется заново поместить в свою память нужную информацию.

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

Итак, для продолжения работы пользователь должен знать:

- на каком шаге он остановился

- какие команды и параметры он уже дал системе

- что именно он должен сделать на текущем шаге

- куда было обращено его внимание на момент отвлечения.

Предоставлять пользователю всю эту информацию лучше всего визуально. Разберем это на примере.

Чтобы показать пользователю, на каком шаге он остановился, традиционно используют конструкцию «Страница N из N». К сожалению, эта конструкция работает не слишком эффективно, поскольку не визуальна. Однако существуют и визуальные способы. Например, когда читатель держит в руках книгу, он может понять, в какой её части он находится, по толщине левой и правой части разворота. Можно воспользоваться этой метафорой и на экране: варьировать толщину левых и правых полей окна.

Рис. 1. Три варианта индикации степени заполнения экранной формы.
Второй и третий варианты значительно визуальнее.

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

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

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

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