Эргономика пользовательского интерфейса

Эргономика пользовательского интерфейса
1.Критерии эргономичности интерфейса
Существует четыре основных (все остальные – производные) критерия эргономичности
(качества) любого интерфейса, а именно:
 Скорость работы пользователей
 Количество человеческих ошибок
 Скорость обучения
 Субъективная удовлетворенность пользователей
Подразумевается, что соответствие интерфейса задачам пользователя является
неотъемлемым свойством интерфейса.
2.Производительность
Существует две разных производительности - производительность компьютера и
производительность человека. Производительность компьютера – широко известное
техническое понятие и для ее увеличения существует множество методов. Увеличение
производительности компьютера ускоряет все процессы, повышает эффективность их
выполнения и уменьшает стоимость одной операции.
Увеличение производительности компьютера обычно приводит к увеличению
производительности человека, но есть и исключения. Во-первых, для этого нужно увеличить
производительность всего компьютера, а не только одной его части. За последние 20 лет
сложилась странная ситуация - в то время как мощность компьютеров увеличилась в несколько
тысяч раз, скорость работы пользователя в некоторых случаях даже замедлилась из-за
непомерно раздутых операционных систем и программ.
К счастью, существует много способов повысить производительность человека, не
затрагивая аппаратную часть компьютера. Производительность находится в прямой
зависимости от длительности выполнения работы пользователем. Длительность выполнения
работы пользователем состоит из
 Длительности восприятия исходной информации
 Длительности интеллектуальной работы
 Длительности физических действий пользователя
 Длительности реакции системы
Как правило, длительность реакции системы является наименее значимым фактором.
2.1.Длительность интеллектуальной работы
Взаимодействие пользователя с системой (не только компьютерной) состоит из семи
шагов:
1.
формирование цели действий;
2.
определение общей направленности действий;
3.
определение конкретных действий;
4.
выполнение действий;
5.
восприятие нового состояния системы;
6.
интерпретация состояния системы;
7.
оценка результата.
Из этого списка становится видно, что процесс размышления занимает почти все время, в
течение которого пользователь работает с компьютером, во всяком случае, шесть из семи
этапов полностью заняты умственной деятельностью. Соответственно, повышение скорости
этих размышлений приводит к существенному улучшению скорости работы. К сожалению,
существенно повысить скорость собственно мышления пользователей невозможно. Тем не
менее, можно уменьшить влияние факторов, усложняющих (и, соответственно, замедляющих)
процесс мышления.
Далее рассматриваются эти самые факторы и методики по уменьшению их влияния:
 Непосредственное манипулирование
 Потеря фокуса внимания (прерывание)
 Ограничение принятия решений
1
Закон Хика
Как правило, длительность реакции системы является наименее значимым фактором.

Непосредственное манипулирование
Можно выделить определенные этапы, через которые приходится проходить человеку,
выполняющему работу. Он должен знать:
1.
что он хочет получить на выходе;
2.
как минимум одну последовательность действий, приводящую к успешному
результату;
3.
где ему найти все объекты, участвующие в процедуре;
4.
как определять годность объектов к использованию;
5.
как управляться с объектами.
Существует способ ускорить выполнение этих этапов. Он называется непосредственным
манипулированием (direct manipulation). Смысл этого метода очень прост. Пользователь не
отдает команды системе, а манипулирует объектами. Это значительно более естественный для
человека способ.
Первым популярным применением этого метода была корзина для удаления файлов на
Macintosh (начиная с Windows 95, такая корзина стала стандартом и в Windows-мире, хотя
присутствовала она и раньше). Смысл действия заключается в том, что если перетащить в
корзину пиктограмму файла, этот файл будет фактически стерт. Чтобы лучше оценить
преимущества этого метода, сравним три варианта действий пользователя на примере этого
самого стирания:
Выбор команд из Использование Использование
Непосредственное
меню
горячих клавиш элемента
на манипулирование
панели
инструментов
Формирование
цели действий и
общего замысла
Определение
необходимых
действий
и
их
последовательности
Выбор файла
Поиск
меню, Поиск в памяти Поиск на экране Поиск корзины
ответственного за команды
соответствующей
стирание
стирания
пиктограммы
Поиск
элемента Поиск клавиши Нажатие
на Перенос файла в корзину
меню, вызывающее Delete
на пиктограмму
стирание файла
клавиатуре
Выбор
нужного Нажатие
элемента меню
клавиши Delete
Из таблицы сразу видно, что метод выбора команды из меню плох уже тем, что состоит из
большого количества атомов. С другой стороны, он имеет то достоинство, что пользователь,
вообще ничего не знающий о системе, только лишь благодаря сканированию меню может
узнать, что файлы вообще можно стирать (собственно говоря, эта обучающая функция
составляет главное достоинство меню как метода взаимодействия пользователя с системой). Но
поскольку это достоинство не имеет прямого отношения к скорости работы, можно смело
сказать, что метод выбора команд из меню не лучший вариант
Количество элементов второго метода, использующего горячую клавишу, также велико,
но у него есть определенные плюсы. При достаточной степени автоматизма нет ни
необходимости искать клавишу на клавиатуре, ни думать, какую клавишу нажать. Таким
2
образом, для опытных пользователей этот метод очень хорош, т.к. в этом случае он состоит из
одного и действия.
Третий способ, нажатие на кнопку в панели инструментов, состоит из не столь большого
количества элементов, так что формально он хорош. К сожалению, он не слишком универсален.
Количество элементов в любой панели инструментов ограничено, так что особенно с этим
способом не развернешься. Не говоря уже о том, что для многих действий невозможно
подобрать пиктограмму.
И, наконец, четвертый способ– непосредственное манипулирование. Помимо того, что он
сам по себе состоит из небольшого количества атомов, в определенных ситуациях он
оказывается еще короче. Дело в том, что когда расположение корзины (пусть даже и в общих
чертах) пользователю известно, процесс удаления файла начинает состоять из одного единого
действия, т.е. пользователь выбирает файл, высматривает корзину и перетаскивает туда файл
одним движением (основной признак единого действия).
Кстати, чтобы метод хорошо работал, корзина должна постоянно «плавать» над другими
окнами. Привязанность корзины к рабочему столу служит препятствием для полноценного
использования метода непосредственного манипулирования.
Несмотря на то, что пример с корзиной наиболее известен, назвать его единственным
нельзя. Например, одно и то же действие (перетаскивание) работает и при удалении, и при
перемещении файла. Более того, если перетащить файл в окно электронного письма, которое
пользователь в данный момент пишет, файл будет вставлен в письмо как вложение. Это значит,
что непосредственное манипулирование позволяет серьезно снизить как количество команд в
системе, так и длительность обучения.
Еще одно преимущество непосредственного манипулирования пересекается с методами
уменьшения количества ошибок пользователя. Предположим, что пользователь собрался
стереть важный системный файл, который стирать нельзя. Методы выбора команды в меню и в
панели инструментов, равно как и метод непосредственного манипулирования, здесь сработают
– элемент можно будет превентивно заблокировать. Если же пользователь попытается стереть
файл, нажав на Delete, система окажется неспособна как-то показать неправомочность его
действий (разве что писком или сообщением об ошибке , что в общем-то недопустимо). А
теперь предположим, что пользователь собрался стереть важный файл, который стирать не
рекомендуется. Ни один из методов, кроме непосредственного манипулирования (можно будет
поменять пиктограмму корзины на время, пока курсор, с зажатым в него файлом, будет
находиться над ней), здесь не сработает, т.е. этот метод отличается от остальных своей
гибкостью.
Потеря фокуса внимания (прерывание)
Абсолютное большинство офисных работников в своей деятельности постоянно
сталкиваются с прерываниями. Пришедшее электронное письмо, телефонный звонок,
рассказанный коллегой анекдот, курение – всё это примеры прерываний. Более того,
существует довольно много видов деятельности, для которых наличие прерываний является
неотъемлемым свойством, таковы, например, работа оператора службы поддержки или
деятельность менеджера, значительную часть дня решающего текущие вопросы.
Таким образом, прерывания оказывают значительное влияние на деятельность таких
пользователей, при этом это влияние следует считать негативным. Во-первых, восстановление
после прерываний занимает определенное время, которое отнимается от времени работы (не
говоря уже о том, что само прерывание чаще всего является потерей времени). Во-вторых,
прерывания грозят человеческими ошибками, вызванными тем, что человек в момент
прерывания забывает о том, что он делал. Нелишне также отметить, что переключения
внимания, вызванные прерываниями, как правило, вызывают значительное утомление и тем
самым снижают производительность труда работников.
Дело в том, что у человека есть только один фокус внимания, так что при любом
отвлечении (которое есть не что иное, как переключение на другую задачу) старый фокус
внимания теряется. Было бы еще ничего, если бы возвращение фокуса требовало только
изменения направления взгляда. Но при отвлечении новые стимулы заменяют содержимое
3
кратковременной памяти, так что для возвращения к работе от пользователя требуется заново
поместить в свою память нужную информацию.
Таким образом, снижение воздействия прерываний на деятельность работников способна
повысить эффективность этой деятельности. При этом специфика ситуации заключается в том,
что от самих прерываний, как правило, избавиться либо трудно, либо невозможно. В таких
условиях снизить их влияние можно, лишь облегчив возвращение работников к прерванному
действию.
Итак, для продолжения работы пользователь должен знать:
1.
на каком шаге он остановился;
2.
какие команды и параметры он уже дал системе;
3.
что именно он должен сделать на текущем шаге;
4.
куда было обращено его внимание на момент отвлечения.
Можно предложить следующие общие подходы, которые могут быть использованы
разработчиками интерфейсов при проектировании систем, ориентированных на частые
прерывания:
1.
Система должна быть снабжена возможностью "заморозить" свое текущее
состояние.
В таком состоянии система не должна реагировать ни на какие действия пользователя (нажатие
клавиш, передвижение мыши и т.п.). Причем выход из такого режима следует реализовать
таким образом, чтобы возможность непроизвольного выхода из него была полностью
исключена. Естественно, при нахождении системы в таком состоянии пользователю должны
предлагаться простые и внятные инструкции, объясняющие, как выйти из такого состояния
(аналог такого решения известен многим по играм, в которых в любой момент можно было
нажать кнопку "Pause", "отдышаться" и продолжить игру)
2.
Необходимо предусмотреть механизмы для объединения типовых составных
операций.
Так, например, последовательность разрозненных действий следует преобразовывать в
интерактивные, но объединенные общей логикой процедуры (Мастера или нечто подобное).
Это позволит пользователям четко понимать, на каком этапе выполнения действия он
находится в данный момент времени.
3.
Необходимо полноценно визуализировать рабочие объекты манипулирования.
При копировании текста через буфер обмена пользователи практически не имеют возможности
понять, что находится в буфере обмена (и находится ли там вообще что-либо), до тех пор, пока
не они вставляют содержимое буфера в документ. Если содержимое буфера обмена видно всё
время, этой проблемы бы не было, при этом нагрузка на память была бы минимальна.
4.
Необходимо показывать пользователям, какие фрагменты информации были
введены давно, а какие – недавно.
Если бы использовалась метафора "высыхающих чернил", количество проблем пользователей
(затрат времени, ошибок) было бы ощутимо меньше. Использование такой метафоры позволит
визуально отобразить отличие недавно внесенных изменений от изменений, внесенных давно.
Суть метафоры заключается в том, что цвет актуальных объектов манипулирования (например,
набранных слов) изменяется по мере прохождения определенного времени с момента
непосредственной работы с ними. Естественно, что при этом пользователям следует
предоставить возможность самостоятельно настраивать такие параметры как "скорость
засыхания" и дискретность изменения цвета.
Реализация предложенных рекомендаций поможет пользователям, работающим в
сложных условиях частых прерываний, значительно повысить производительность труда,
уменьшить количество ошибок, повысить субъективную удовлетворенность.
Ограничение принятия решений
Не заставляйте пользователя всего лишь сообщать о принятых решениях.
Многое из того, что часто принимают за принятие решений, на самом деле является
сообщением о решении. Большинство операций такого рода можно заменить машинами,
полностью удалив оператора из процесса.
4
В примере на рис. ** пользователю необходимо сообщить о принятии решения, которое
могла бы принять за него программа.
рис. **
Быстро и точно предоставляйте пользователю информацию, необходимую для
принятия решений.
Удостоверьтесь, что пользователю предоставлена вся необходимая информация для
принятия решения. Часто можно видеть, что программа задает пользователю вопрос, на
который он не может ответить, не обратившись за информацией куда-то еще. Такая программа
скорее всего никогда не тестировалась на пользователях; разработчики посчитали, что раз они
знают ответ, то и все остальные тоже знают его.
Избавляйтесь от ненужной информации.
Множество web-страниц сегодня изобилуют ссылками. Да еще и сами браузеры содержат
большое количество кнопок и меню. Что же остается неопытному пользователю? Скорее всего,
сделать неправильный выбор.
Опытные пользователи в конце концов научатся различать сигнал от шума, независимо от
того, насколько загроможденным будет интерфейс. Они будут работать медленнее, но не
остановятся. Однако в разовых программах такая ситуация может оказаться критической.
Визуально выделяйте наиболее вероятные варианты ответа.
Пользователи должны легко различать наиболее вероятный вариант ответа. Слишком
часто создатели программ предлагают нам неясные вопросы с двумя одинаково выглядящими
вариантами ответа, хотя одно из решений является неверным для большинства.
Не задавайте пользователю вопрос о какой-нибудь настройке, смысл которой неясен.
Чтобы ответить на этот вопрос и решить, нужна ему эта настройка или нет, пользователю
придется узнать все о ней. Спрячьте такую настройку в раздел “advanced”.
Закон Хика
Закон Хика позволяет количественно определить наблюдение, заключающееся в том, что
чем больше количество вариантов заданного типа вы предоставляете, тем больше
времени требуется на выбор.
Перед тем как переместить курсор к цели или совершить любое другое действие из набора
множества вариантов, пользователь должен выбрать этот объект или действие. В законе Хика
утверждается, что когда необходимо сделать выбор из n вариантов, время на выбор одного из
них будет пропорционально логарифму по основанию 2 от числа вариантов плюс 1, при
условии, что все варианты являются равновероятными. В этом виде закон Хика очень похож на
закон Фитса:
Если вероятность i-го варианта равна p(i), то вместо логарифмического коэффициента
используется
, что предоставление пользователю сразу нескольких вариантов одновременно обычно
является более эффективным, чем организация тех же вариантов в иерархические группы.
Выбор из одного меню, состоящего из 8 элементов, производится быстрее, чем из двух меню,
состоящих их 4 элементов каждое. Если все элементы могут быть выбраны с равной
5
вероятностью и если не учитывать время, необходимое для открытия второго меню (которое,
конечно, еще более увеличило бы время для интерфейса, состоящего из двух меню), то
сравнение времени для выбора одного элемента из восьми (a + b log 8) с удвоенным временем
для выбора одного элемента из четырех 2 (a + b log 4) покажет, что
a + 3b < 2 (a + 2b)
поскольку log 8 = 3, a log 4 = 2, а также поскольку а < 2а и 3b < 4b.
Это согласуется с данными, полученными в экспериментах со структурами меню.
2.2.Длительность физических действий пользователя
Любое физическое действие, совершаемое с помощью мускулатуры, может быть или
точным или быстрым. Вместе точность и быстрота встречаются исключительно редко,
поскольку для этого нужно выработать существенную степень автоматизма. Объясняется это
сугубо физиологическими факторами: при резком движении невозможно быстро остановиться,
соответственно, чем точнее должно быть движение, тем более плавным и замедленным оно
должно быть. Таким образом, чтобы физическое действие пользователя было быстрым, оно не
должно быть точным.
Пользователь, как правило, управляет компьютером двумя способами, а именно мышью и
клавиатурой. Клавиатура не требует особой точности движений – неважно, быстро нажали
клавишу или медленно, равно как сильно или слабо. Мышь, напротив, инерционна – есть
разница между медленным её перемещением и быстрым, сильным приложенным усилием и
слабым. Именно поэтому оптимизация использования мыши в системе может существенно
повысить общую скорость работы.
Мышь не является прецизионным инструментом. Проверить это очень легко – попробуйте
мышью нарисовать ровный круг. Соответственно, мышь не предназначена для очень точных, в
1 или 2 пикселя, манипуляций, например, в графических программах всегда есть возможность
перемещать объекты клавишами со стрелками. Именно поэтому любой маленький
интерфейсный элемент будет всегда вызывать проблемы у пользователей.
Ниже рассмотрены факторы влияющие на длительность физических действий
пользователя и методы уменьшиения этой длительностию.
 Закон Фитса
 Методы повышения доступности кнопки
 Уменьшение числа манипуляций
 Уменьшение необходимости ввода данных
 Память программы
Закон Фитса
В 1954 году Поль Фитс (Paul Fitts) сформулировал правило, в наиболее практичной
формулировке ставшее известным как Закон Фитса: Время достижения цели обратно
пропорционально размеру цели и дистанции до цели. Рассмотрим его поподробнее.
Различные когнитивные законы, имеющие отношение к разработке интерфейсов, имеют
хорошее когнитивное обоснование, и их правильность была неоднократно проверена. Эти
законы часто дают дополнительные данные, на основе которых можно принимать те или иные
решения, связанные с разработкой интерфейсов. Закон Фитса позволяет определить
количественно тот факт, что чем дальше находится объект от текущей позиции курсора или чем
меньше размеры этого объекта, тем больше времени потребуется пользователю для
перемещения к нему курсора.
Представим, что вы перемещаете курсор к кнопке, изображенной на экране. Кнопка
является целью данного перемещения. Длина прямой линии, соединяющей начальную позицию
курсора и ближайшую точку целевого объекта, определяется в законе Фитса как дистанция. На
основе данных о размерах объекта и дистанции закон Фитса позволяет найти среднее время, за
которое пользователь сможет переместить курсор к кнопке.
6
В одномерном случае, при котором размер объекта вдоль линии перемещения курсора
обозначается как S, а дистанция от начальной позиции курсора до объекта - как D (рис **),
закон Фитса формулируется следующим образом:
рис **
(Константы а и b устанавливаются опытным путем по параметрам производительности
человека. Для приближенных вычислений можно использовать следующие значения: a = 50, b =
150)
Вычисляемое время отсчитывается от момента, когда курсор начинает движение по
прямой линии, до момента, когда пользователь щелкает мышью по целевому объекту.
Логарифм по основанию 2 является мерой трудности задачи в количестве бит информации,
которое требуется для описания (одномерного) пути перемещения курсора.
Для вычисления времени можно использовать любые единицы измерения дистанции, т.к.
D/S является отношением двух дистанций и поэтому не зависит от единицы измерения. Отсюда
следует, что хотя указательное устройство может переместиться на расстояние большее или
меньшее, чем то расстояние, на которое переместится на экране курсор, закон все равно
работает, при условии, что соотношение между движением мышки и курсора является
линейным. Закон Фитса может применяться только к тем типам перемещения, которые
совершаются при использовании большинства человеко-машинных интерфейсов, т.е. к таким
перемещениям, которые невелики относительно размеров человеческого тела и которые
являются непрерывными (совершаемыми одним движением).
Методы повышения доступности кнопки
Из всего вышесказанного можно сделать вывод, что лучший способ повысить доступность
кнопки заключается в том, чтобы делать её большой и располагать ближе к курсору.
У этого правила есть два не сразу заметных следствия. Чтобы «бесконечно» ускорить
нажатие кнопки, её, во-первых, можно сделать бесконечного размера и, во-вторых, дистанцию
до неё можно сделать нулевой.
Вариант 1. Кнопка бесконечного размера. При подведении курсора к краю экрана он
останавливается, даже если движение мыши продолжается. Это значит, что кнопка,
расположенная впритык к верхнему или нижнему краю экрана, имеет бесконечную высоту
(равно как кнопка у левого или правого края имеет бесконечную ширину). Таким образом,
скорость достижения такой кнопки зависит только от расстояния до неё (ну и точности выбора
начального направления движения).
Понятно, что кнопка, расположенная в углу экрана, имеет «еще более бесконечные»
размеры, если так вообще можно сказать (т.е. не важно даже, с какой точностью перемещали
мышь). Для достижения такой кнопки от пользователя требуется всего лишь дёрнуть мышь в
нужном направлении, не заботясь о её скорости и не делая попыток остановить её в нужном
месте. Это делает такие кнопки наиболее доступными для пользователя. Именно поэтому,
например, меню MacOS многократно эффективней меню Windows: если в MacOS меню всегда
расположено впритык к верхнему краю экрана, то в Windows меню отделено от края экрана
полосой заголовка окна программы (Title Bar).
Панель задач (Taskbar) в Windows вызывает удивление – оно расположено впритык к
краю экрана, но кнопки отделены от края экрана тремя пустыми пикселями. И скорость
работы снижается, и место теряется.
Вариант 2. Нулевая дистанция до кнопки. Рассмотрим контекстное меню, вызываемое
по нажатию правой кнопки мыши. Оно всегда открывается под курсором, соответственно
расстояние до любого его элемента всегда минимально. Именно поэтому контекстное меню
является чуть ли не самым быстрым и эффективным элементом.
7
Но не надо думать, что уменьшать расстояния до цели можно только с контекстными
меню. Есть еще диалоговые окна. Они тоже всегда контекстно-зависимы. По умолчанию они
открываются в центре экрана, но это легко можно изменить. Открывать их под курсором
гораздо лучше, именно потому, что дистанция до их кнопок сокращается, что хорошо не только
тем, что перемещать курсор нужно меньше, но также тем, что пользователю сразу становится
понятна связь между его действиями и появлением диалогового окна. Из всего вышесказанного
следует: открывайте новые диалоговые окна не в центре экрана, а в центре текущего действия
пользователя (если они не будут перекрывать важную информацию на экране, разумеется)
Если говорить о клавиатуре, она не требует особенной точности движений и, как таковая,
обеспечивает большую скорость работы. Тем не менее, и она не без проблем. Во-первых,
изначально она не предназначена для перемещения фокуса ввода по экрану, что приводит к
существенным трудностям (в том смысле, что самопроизвольно клавиатура не позволяет
перемещать фокус с достаточной эффективностью – для этого надо специально проектировать
экран). Если клавиатура не работает, приходится пользоваться мышью, но перемещение руки с
клавиатуры на мышь и потом обратно занимает почти секунду, что слишком много. Во-вторых,
работа с клавиатурой подразумевает использование горячих клавиш (именно потому, что
перемещение по экрану с клавиатурой затруднено). Но хотя горячие клавиши существенно
увеличивают скорость работы, плохо то, что их трудно запомнить. Таким образом, они
являются прерогативой опытных пользователей и для многих людей неприемлемы. Более того,
их популярность во многом основывается на субъективных критериях: воспринимаемая
пользователем скорость работы с клавиатуры выше, чем скорость работы с мышью (хотя
секундомер говорит обратное). Это значит, что на клавиатуру особо рассчитывать не стоит:
помимо набора текста большинство людей пользуются только клавишами пробела и возврата
каретки.
Уменьшение числа манипуляций
Программы часто демонстрируют такую же механическую сложность, как и реальные
механизмы, требуя, чтобы пользователь служил им, а не наоборот. Любой, кто хотя бы раз
обновлял системное программное обеспечение, знает, насколько сложной может быть эта
задача, хотя для этого пользователю не нужно принимать практически никаких решений.
Разделяйте все операции на “манипуляции с механизмом”, и более абстрактные,
сообщающие машине то, чего она знать не может.
После этого:
1.
Уменьшайте число манипуляций, насколько это возможно. Действительно ли
необходимо второе окно, или же задание можно выполнить с помощью одного? Действительно
ли здесь требуется нажатие на клавишу? Можно ли выполнить это задание за один шаг, а не за
два?
2.
Сделайте оставшиеся манипуляции подходящими к пользовательской модели
задачи. Избегайте требования от пользователя мысленного преобразования задачи в форму,
приемлемую для машины. Вместо этого предложите наиболее естественный способ
управления.
Уменьшение необходимости ввода данных
Следующие методы могут увеличить производительность ввода данных, уменьшая
количество необходимой для ввода информации:
1.
Автоматически заполняйте поля новой записи значениями предыдущей.
2.
Минимизируйте, либо полностью устраните необходимость ввода информации.
Можно ли получить информацию на основе логического вывода? Действительно ли данная
информация необходима для выполнения этой задачи?
3.
Исследуйте другие способы получения информации.
Память программы
Разрабатывая программу необходимо задумываться о том, как сделать так чтобы
программа задавала как можно меньше вопросов и как можно больше принимала решения
самостоятельно.
8
Все что нужно сделать для этого - это дать программе память подобно человеческой.
Проще говоря, если программа помнит последнее решение пользователя, следующее решение
она может сделать сама. Этот простой принцип является одним из самых эффективных
инструментов разработчика программ, но в то же время одним из самых малоизвестных.
Большинство программистов считает, что быстрее создать новое окно диалога, которое
спросит у пользователя некую информацию, которая не лежит на поверхности. Программисты
не видят в этом ничего плохого, потому что они не знают, что пользователям не нравится, когда
программа задает вопросы. Программа, которая задает меньшее количество вопросов, кажется
пользователям умнее. Вот схема диалога программы и пользователя которая сейчас
повсеместно распространена: Вы хотите сохранить этот файл? Вы хотите сохранить этот
файл сейчас? Вы действительно хотите сохранить этот файл? Вы уверены, что хотите
напечатать это? Вы уверены, что хотите печатать на этом принтере? Вы абсолютно
уверены, что хотите печатать? А если пользователь не знает ответа на заданный ему вопрос,
вдобавок к раздражению он еще и чувствует себя глупым. Возьмем например такой обычный
вопрос: Вы хотите профессиональную установку или установку для новичков? Другими
словами, вы хотите то, чего не сможете понять или вам будет не нужно, или же вы просто
лопух?
Вопросы доставляют пользователю беспокойство. Варианты выбора хороши, но
существует большая разница между свободой выбора и предложением альтернатив
программой. Вместо того, чтобы быть опрашиваемыми программой пользователи должны
направлять программы сами, как они направляют автомобиль в нужную им сторону.
Автомобиль предлагает пользователю бесконечное число вариантов выбора и не выдает ни
одного диалогового окна. Никто не любит, чтобы его допрашивали, как подозреваемого, но
точно так поступают многие программы.
У Алана Купера идея того, что программа может предсказать действия пользователя,
обозначается термином "связность задач" (task coherence). Когда человек работает с
программой, существует 80-процентная вероятность, что в следующий раз он сделает то же
самое, что и в предыдущий. Таким образом, можно со значительной долей уверенности
предсказать поведение пользователя, просто запомнив его последнее действие. Это позволит
значительно уменьшить число вопросов, которые программа задает пользователю.
Программа, эффективно использующая свою память, помнит все настройки пользователя
от одного запуска до другого. Например, она может запоминать положение окон на экране, так
что если пользователь открыл документ на весь экран, при следующем запуске программы он
будет открыт точно также. Если пользователь упорядочил окна по вертикали, они могут быть
упорядочены в следующий раз без его вмешательства.
Какие бы изменения в настройках программы пользователь не сделал, они должны
оставаться в силе до тех пор, пока он не изменит их сам. Программа не должна сбрасывать
их при каждом запуске. Если пользователь игнорирует или отключает какие-либо возможности
программы, она не должны предлагать их снова. Пользователь сам найдет их, когда они ему
понадобятся.
Программа с хорошей памятью дает пользователю немало преимуществ. Память
уменьшает бесполезные усилия, которые направлены на управление инструментом, а не
работой. Если ввод чисел в электронную таблицу - нормальная работа, то упорядочивание окон
- излишество. Если выбор имени файла - нормальная работа, то сохранение его на диск излишество. Большинство излишеств может быть устранено с помощью простого запоминания
того, что делал пользователь в последний раз. Это значительное достижение в проектировании
пользовательских интерфейсов.
Большинство программ позволяют пользователю устанавливать значения по умолчанию,
но это не дает для большинства пользователей такого же эффекта, как могла бы иметь память.
К примеру один пользователь использует Microsoft Word каждый день, поэтому он уже
тщательно отрегулирован в соответствии с его предпочтениями, но его коллега использует
Word от случая к случаю, и не намерен заниматься изучением его настроек. Каждый раз при
запуске программы ему приходится вручную устанавливать нужный шрифт. Если бы только
программа могла запомнить его предпочтения, необходимость в этом отпала бы.
9
Программа с лучшей памятью может уменьшить количество ошибок пользователя. Это
происходит потому, что пользователю приходится вводить меньшее количество информации.
Остальная ее часть будет введена автоматически из памяти программы.
Связность задач может предсказать, что именно будет делать пользователь в будущем со
значительной, но не абсолютной вероятностью. Если программа может надежно предсказать
действия пользователя в 80% случаев, это значит, что в 20% случаев она будет неправа, потому
что в каждом конкретном случае она не знает, в 20 она или в 80 процентах. Может показаться,
что это как раз тот случай, когда нужно спросить пользователя, но это не так. Вместо
предоставления выбора, программа должна продолжать делать то, что она считает наиболее
подходящим, вместе с тем давая пользователю возможность изменить или отменить это. Если
возможность отмены достаточно легка и понятна, пользователь не будет беспокоится о ней. В
крайнем случае, ему придется отменять решение программы только в 2-х случаях из 10, вместо
того, чтобы иметь дело с излишним диалоговым окном 8 раз из 10.
Как только программист начинает понимать всю силу принципа связности задач, в
процессе разработки программ происходят значительные изменения. Разработчики программ
начинают думать в совершенно новом направлении. Бездумный процесс создания еще одного
диалогового окна заменяется более продуманным и аккуратным, в котором разработчик
начинает задавать себе вопросы типа: сколько чего должна помнить программа? что именно
должно запоминаться? Должна ли программа запоминать больше, чем просто последний
вариант настройки?
Вопросы такого типа вскоре порождают другие, например, как информировать
пользователя о решении, которое приняла программа. Если программа сохраняет файл на диске
без обсуждения этого с пользователем, как он может узнать об этом? Когда разработчики
программ начинают задавать себе подобные вопросы, это значит, что они начинают создавать
программы для пользователей, а не для программистов.
2.3.Длительность реакции системы
Часто пользователи надолго прерывают свою работу. Помимо потери фокуса внимания, о
котором уже сказано, это плохо тем, что лишенная руководства система начинает простаивать.
Разумеется, мы ничего не можем сделать с этой ситуацией: странно было бы, если бы, как
только пользователь отходил в туалет, система, скажем, начинала бы форматировать жесткий
диск. Тем не менее, несомненно и другое: пользователь нередко отвлекается не потому, что
появляются внешние раздражители, а потому, что система не реагирует на внешний
раздражитель в лице пользователя. Попросту говоря, система делает что-либо длительное. Ни
один же человек в здравом уме не будет упорно смотреть в экран, зная, что система будет
готова к приему новых команд не ранее, чем через пять минут. Соответственно, человек
отвлекается.
Проиллюстрировать это очень удобно на процессе печати. Печать документа в сто
страниц даже на быстрых принтерах занимает существенное время, соответственно,
большинство людей, отправив такой документ в печать, начинают бездельничать, поскольку,
чтобы начать следующее действие в их трудовом процессе, им нужна распечатка, которой ещё
нет.
Проблема в том, что сразу после того, как человек отвлекается, системе зачастую, во что
бы то ни стало, начинает требоваться что-либо от человека. Человек же, уверенный в том, что
система работает, уходит в другую комнату. Таким образом, человек и система бездельничают.
При этом раздражение человека, вернувшегося с обеденного перерыва и вместо распечатанного
документа нашедшего диалоговое окно с вопросом «Вы уверены?», обычно оказывается
безмерным.
Это делает всегда верным следующее правило: если процесс предположительно будет
длительным, система должна убедиться, что она получила всю информацию от пользователя до
начала этого процесса.
Есть другое решение этой проблемы: система может считать, что если пользователь не
ответил на вопрос, скажем, в течение пяти минут, то его ответ положительный. Таким образом,
тот же самый сценарий решается подругому: пользователь отправляет документ на печать и
10
уходит, система спрашивает «Вы уверены?» и ждет пять минут, после истечения этого времени
она начинает печать. Этот метод вполне работоспособен, так что им стоит пользовать всегда,
когда невозможен первый метод (разумеется, за исключением случаев, когда ответ Да может
иметь катастрофические последствия).
Есть и другая причина отвлечения пользователя. Пользователь запускает какой-либо
процесс. Система показывает ему индикатор степени выполнения. Процент выполнения за
минуту едва доходит до четверти размера индикатора. Пользователь анализирует эти данные и
резонно решает, что у него есть три минуты, чтобы размяться. Однако, как только он отходит от
компьютера, процент выполнения с нечеловеческой скоростью начинает расти и за секунду
доходит до максимума. Процесс успешно заканчивается, а пользовать еще три минуты
бездельничает.
Происходят подобные случаи исключительно потому, что индикаторы степени
выполнения обычно рассматриваются программистами не как показатели процента выполнения
задачи, но как индикаторы того, что система вообще работает. Для них это очень удобно:
поскольку единый с точки зрения пользователя процесс часто состоит из многих
принципиально разных системных процессов, выполняющихся с разной скоростью, можно не
утруждаться, стараясь так сбалансировать рост индикатора, чтобы он всё время происходил с
одинаковой скоростью. Иногда это «неутруждение» принимает довольно комичные формы.
Так, индикатор выполнения может сначала расти, потом снижаться, потом опять расти.
Проблема в том, что пользователи рассматривают такие индикаторы именно как способ узнать,
когда процесс завершится. Так что врать пользователю тут нехорошо.
Фоновый режим выполнения задач
Выполняя все асинхронные операции в фоновом режиме, можно отделить задачи
пользователя от задач компьютера, позволяя пользователю работать без перерывов.
Сетевая печать была асинхронной операцией более 15 лет. Пользователи нажимали
кнопку “Печать” и шли заниматься своими делами, пока шел процесс. Над проблемой печати
стали работать в первую очередь, потому что
1.
Печать отнимает много времени
2.
Печать не требует вмешательства пользователя
3.
Общее время выполнения задачи предсказать нельзя
4.
Следующее задача пользователя обычно не связана с результатами печати
Если принтер подключен к высокоскоростной сети и в очереди печати нет заданий, все
происходит довольно быстро. Однако, если кто-то только что начал печатать 300-страничный
документ, то компьютер может оказаться “замороженным“ на длительный период времени.
Та же самая ситуация сложилась сейчас с Интернетом. Загрузка страниц занимает
длительное время, не требуя вмешательства пользователя в этот процесс, и предугадать, будет
ли она длиться 5 секунд или минуту, невозможно.
Всякая операция, которая подходит под вышеописанные критерии и может быть выделена
в отдельную задачу, должна быть выделена. Если нужно передать длинную форму после того,
как пользователь нажмет Submit, это нужно сделать в фоновом режиме, пока пользователь
переходит к следующей форме.
3.Человеческие ошибки
3.1.Типы ошибок
Наибольшее количество человеческих ошибок при пользовании ПО раскладывается на
четыре типа (сильно упрощенно, разумеется):
 Ошибки, вызванные недостаточным знанием предметной области.Теоретически,
эти ошибки методологических проблем не вызывают, сравнительно легко исправляясь
обучением пользователей.
 Опечатки. «Опечатки» происходят в двух случаях: во-первых, когда не все внимание
уделяется выполнению текущего действия (этот тип ошибок характерен, прежде всего, для
опытных пользователей, не проверяющих каждый свой шаг) и, во-вторых, когда в мысленный
план выполняемого действия вклинивается фрагмент плана из другого действия (происходит
11
преимущественно в случаях, когда пользователь имеет обдуманное текущее действие и уже
обдумывает следующее действие).
 Не считывание показаний системы. Ошибки, которые одинаково охотно производят
как опытные, так и неопытные пользователи. Первые не считывают показаний системы потому,
что у них уже сложилось мнение о текущем состоянии, и они считают излишним его проверять,
вторые – потому что они либо забывают считывать показания, либо не знают, что это нужно
делать (и как это делать).
 Моторные ошибки. Фактически, количество этих ошибок пренебрежимо мало, к
сожалению, недостаточно мало, чтобы вовсе их не засчитывать. Сущностью этих ошибок
являются ситуации, когда пользователь знает, что он должен сделать, знает, как этого добиться,
но не может выполнить действие нормально из-за того, что физические действия, которые
нужно выполнить, выполнить трудно. Так, никто не может с первого раза (и со второго тоже)
нажать на экранную кнопку размером 1 на 1 пиксель. При увеличении размеров кнопки
вероятность ошибки снижается, но почти никогда не достигает нуля. Соответственно,
единственным средством избежать этих ошибок является снижение требований к точности
движений пользователя.
3.2.Методы предотвращения ошибок
Необходимо стремиться минимизировать количество ошибок, поскольку только это
позволяет сберечь время (т.е. повысить производительность) и сделать пользователей более
счастливыми за счет отсутствия дискомфорта.
Суммируя, при борьбе с ошибками нужно направлять усилия на:
 плавное обучение пользователей в процессе работы;
 снижение требований к бдительности;
 повышение разборчивости и заметности индикаторов.
Дополнительно к этим трём направлениям, есть и четвертое: снижение чувствительности
системы к ошибкам. Для этого есть три основных способа, а именно:
 блокировка потенциально опасных действий пользователя до получения подтверждения
правильности действия;
 проверка системой всех действий пользователя перед их принятием;
 самостоятельный выбор системой необходимых команд или параметров, при которых от
пользователя требуется только проверка.
Повышение разборчивости и заметности индикаторов
В интерактивном процессе используются 2 типа визуальных элементов, а именно кнопки
и индикаторы. Существенной отличий между ними нет, нужно только передать разницу между
ними (случаев, когда кнопка является также индикатором, следует, по возможности, избегать).
Существуют два основных критерия оценки эффективности интерактивного визуального
элемента, это:
 качество/скорость восприятия элемента;
 физическая реализация элемента.
Качество/скорость восприятия элемента
При прочих равных, элемент, назначение которого трудно воспринять, не может
квалифицироваться как удовлетворяющий требованиям интерактивности. Проблемы
восприятия проявляются тремя способами: либо восприятие назначения элемента занимает
избыточное время (более половины секунды), либо значение не воспринимается вообще, либо,
что хуже всего, значение воспринимается неправильно. Применительно к Web, можно
утверждать, что элемент, восприятие которого замедлено, не будет воспринят вообще, за
исключением тех случаев, когда у пользователя есть действительно сильная мотивация
(пользователи склонны пропускать все, что с первого взгляда не кажется им интересным или
нужным).
Причинами ухудшения восприятия элемента являются:
12
1.
Ошибочно выбранный визуальный сюжет элемента.
Некоторые понятия могут быть выражены простыми сюжетами (характерный пример —
изображение принтера = печать), некоторые же выражаются сюжетами сложными либо
многозначными (характерный пример — лупа = изменение масштаба либо поиск). В
большинстве случаев эта проблема имеет наименьший приоритет, так как рисование сложных
сюжетов вообще не практикуется. Некоторые понятия имеют однозначные визуальные
репрезентации только для какой-либо одной аудитории, так что если эта аудитория является
целевой, необходимо проверять качество восприятия символа на представителях именно этой
аудитории (понятность или непонятность сюжета для всех остальных в таких случаях не может
служить индикатором эффективности).
2.
Нестандартно выбранный сюжет элемента или реализация сюжета.
Пиктограмма дома в Web исторически обозначает переход на титульную страницу сайта.
Благодаря этому пользователю не нужно проявлять излишнюю мыслительную активность при
определении значении такого элемента (вообще говоря, человеческий мозг наиболее успешно
решает задачи, метод решения которых основан на проведении аналогии). Таким образом, чем
стандартнее сюжет, тем выше скорость его восприятия. Важна также стандартность реализации
выбранного сюжета, например, пиктограмма перехода на титульную страницу, выполненную
как изображение избушки на курьих ножках является скорее нестандартной и будет вызывать
замешательство, по крайней мере на первых порах. В таких условиях наилучшим методом
выбора сюжета является поиск репрезентации, привычной целевой аудитории. Источниками
стандартных сюжетов/реализаций являются (отсортированы по степени знакомства с ними
пользователей): операционная система, системы конкурентов, среда. Таким образом, сюжет,
взятый из операционной системы всегда оптимален (поскольку наиболее знаком).
3.
Избыточная детализация сюжета.
Объекты реального мира перегружены мелкими деталями. Перенос этих деталей в сюжет
символа неоправдан — в реальном мире эти детали нужны (придают объекту уникальность), а
на пиктограмме лишь отвлекают внимание и тем самым замедляют распознавание. Более того,
скорость восприятия чистых абстракций чаще всего выше скорости восприятия даже
максимально упрощенных символов, т.е. символ человеческого лица, нарисованный по
принципу "круг, две точки и две черточки" воспринимается быстрее и легче, нежели тот же
символ, нарисованный, например, в стилистике комиксов.
Физическая реализация элемента
Любой элемент, предназначенный для совершения каких либо действий над ним (кнопка,
переключатель и т.п.), согласно закону Фитса должен быть достаточно большим физически.
Между кнопками необходимо выдерживать пустое пространство, чтобы избежать
случайного нажатия посторонней кнопки. По той же причине лучше сигнализировать о
попадании курсора в область элемента видом этого элемента (с другой стороны, если при этом
меняется курсор, как он меняется, например, при подведении к гиперссылке, дополнительная
индикация не обязательна).
Выпуклость является единственным способом показа элементом своей "кнопочности", т.е.
того, что элемент можно нажать. Соответственно, в однократно используемых системах кнопки
делать выпуклыми необходимо, в часто же используемых — желательно.
Понятно, что все сюжеты/реализации визуальных элементов в системе должны быть
выдержаны стилистически. Помимо этого необходимо визуально разделять кнопки,
индикаторы и просто надписи.
В данном примере элементы никак не разграничены по функциям: кнопки Site Map и Help
выполнены не как остальные кнопки, но как надписи. В результате многие пользователи либо
будут безуспешно нажимать псевдокнопку Quotes, либо никогда не нажмут кнопки Site Map и
Help.
13
Блокировка потенциально опасных действий до получения подтверждения
Блокируйте системные файлы.
Команда удаления файла в любой операционной системе снабжена требованием
подтвердить удаление. Этот метод приносит пользу только начинающим пользователям,
которые проверяют каждый свой шаг. Для опытных пользователей это диалоговое окно с
требованием подтверждения не работает. Для них это что-то вроде ритуала: «после нажатия на
клавишу Delete выскочит окошко, в котором нужно нажать ОК». Естественно, что даже в
случае неверно выбранного файла это диалоговое окно не сможет предотвратить его удаления.
К тому же оно без пользы отвлекает пользователя и тратит его время. Новичков же окно
лишний раз пугает, уменьшая субъективное удовлетворения от системы.
Правильнее блокировать файлы, изменение или удаление которых может привести к
краху ОС или программы, к которой они относятся. В данном случае термин блокировка не
предусматривает появление диалогового окна. В данном случае удаление должно быть не
возможно в принципе. Все остальные файлы следует разрешать удалять без предупреждения
(без диалогового окна), при этом предусматривая удобный способ восстановления (корзина в ее
нынешнем виде – не самый удобный способ, но это уже другой вопрос).
Не делайте опасные для пользователя кнопки кнопками по умолчанию.
Фокуса ввода необходимо снимать с терминационных кнопок, чтобы пользователь не мог,
не разобравшись, нажать на Enter и тем самым начать потенциально опасное действие.
Действительно, если пользователям приходится прилагать какие-либо усилия, чтобы запустить
действие, есть надежда, что во время совершения этих усилий он заметит вкравшуюся ошибку.
Обычно проще всего в опасных случаях не делать главную кнопку кнопкой по умолчанию.
Важно только не делать кнопкой по умолчанию и кнопку Отмена (как часто случается). Если
это сделать, пользователи будут ошибочно закрывать окно, т.е. одна ошибка заменит другую.
Проверка действий пользователя перед их принятием
Существует два универсальных и работающих способа проверки команд. Во-первых, это
меню. В случаях, когда пользователь выбирает команду из списка, система может без труда
делать так, чтобы в этот список попадали только корректные команды. Во-вторых, если
действие запускается непосредственным манипулированием объектами, можно индицировать
возможные действия изменением поведения этих объектов. Например, если бы форматирование
диска запускалось не нажатием кнопки, а перенесением пиктограммы диска в область
форматирования, можно было бы показывать пользователю, как с выбранного диска исчезают
все файлы и папки. При этом не только снизилась бы вероятность ошибочного форматирования
диска, поскольку перенести объект в другую область труднее, чем просто нажать на кнопку, но
при этом исчезла бы необходимость предупреждать пользователя о грядущей потере данных с
помощью сообщения.
Проверкой всех действий пользователя перед их принятием можно также успешно
защищать вводимые пользователем данные, в особенности данные численные. Дело в том, что
большинство численных данных имеют некий диапазон возможных значений, так что даже в
ситуациях, когда невозможно проверить корректность данных, можно, по крайней мере,
убедиться, что они попадают в нужный диапазон.
Пример крутилок. Как не крути, а больше 360 градусов не накрутишь
14
В большинстве ОС есть специальный элемент управления, именуемый крутилкой
(spinner). Фактически это обычное поле ввода, снабженное двумя кнопками для модификации
его содержимого (в сторону уменьшения и увеличения). Интересен он тем, что пользователь
может не пользоваться клавиатурой для ввода нужного значения, взамен клавиатуры установив
нужное значение мышью. Этот элемент имеет то существенное достоинство, что при
использовании мыши значение в этом элементе всегда находится в нужном диапазоне и
обладает нужным форматом. Кстати, если говорить о границах диапазона, то их всегда надо
показывать во всплывающей подсказке.
Но что делать, если пользователь ввёл некорректное число с клавиатуры? Ответ прост.
Для этого надо индицировать возможную ошибку изменением цвета шрифта или фона на
красный.
Классический пример использования ползунка.
В тех же случаях, когда количество возможных значений невелико, лучше использовать
другой элемент управления – ползунок. Мало того, что он позволяет устанавливать только
определенные значения (с этим справился бы и выпадающий список или комплект
переключателей), но он позволяет пользователю видеть взаимосвязь возможных значений и при
этом использование этого элемента понятно даже новичку.
Самостоятельный выбор параметров
Чем меньше действий требуется совершить пользователю, тем меньше вероятность
ошибки (при этом пользователь, которого избавили от рутинной работы, уже радуется). Вопрос
состоит в том, как системе узнать, что именно нужно пользователю.
Проиллюстрировать сферу применения данного метода удобно на примере печати в MS
Word. Существует две команды меню Файл, а именно Печать и Параметры печати. Обе
команды вызывают одноименные диалоговые окна. Проблема заключается в том, что по закону
Хика обилие элементов управления замедляет восприятие этих окон и увеличивает вероятность
ошибки.
Для такой часто используемой функции как печать, ее диалоговое окно содержит
слишком много параметров
15
Чем меньше элементов управления, тем меньше вероятность ошибки. Система может
уменьшить число элементов, если она знает сама, какими именно параметрами она должна
руководствоваться.
Главной причиной появления этих диалоговых окон является печать нескольких копий.
Причем есть простая зависимость – «количество копий обратно пропорционально частоте
печати такого количества», т.е. сто копий печатают примерно в сто раз реже, чем печатают
одну копию. Стандартное диалоговое окно печати содержит также область выбора принтера из
числа установленных в системе. Большинство же пользователей имеет только один принтер.
Так зачем заставлять это большинство каждый раз вдумчиво воспринимать совершенно не
нужные им элементы интерфейса?
С другой стороны на панели инструментов есть кнопка, нажатие на которую вызывает
печать одного экземпляра с текущими настройками. Это, впрочем, тоже нехорошо. Во-первых,
кнопка называется Печать, каковое название конфликтует с такой же командой в меню
(называть кнопку Печать одного экземпляра с текущими настройками тоже не выход). Сама
же по себе идея иметь в программе две кнопки с одинаковыми названиями и разным действием
порочна. Во-вторых, нормальная программа должна иметь меню, содержащее полную
функциональность, и панель инструментов, представляющую собой выжимку из меню. А здесь
получается, что в панели инструментов есть команда, которую нельзя вызвать никаким иным
способом.
Каким образом можно улучшить вызов печати? В меню есть те же две команды – Печать и
Параметры печати. Выбор первой команды вызывает немедленную печать документа с
текущими настройками. Выбор второй вызывает диалог со всеми доступными параметрами
печати, т.е. в системе с одним принтером никогда не появится ненужная группа элементов.
Если же пользователь начинает проявлять буйную активность и печатать несколько копий
разом, включается другой механизм. В первый раз, когда пользователь меняет число копий в
окне настроек печати, программа запоминает его действие и при следующем выборе команды
Печать выводит диалоговое окно со всего двумя элементами управления – полем ввода, в
котором уже стоит число копий (которое было запомнено в предыдущий раз) и кнопкой ОК.
16
Поскольку программа не может быть уверена в правильности числа копий, цифру лучше всего
выводить нестандартным цветом, чтобы привлечь внимание пользователя.
И так до тех пор, пока пользователь два раза подряд не введет единицу в поле ввода (что
переводит его в разряд представителей большинства) или не введет новое число копий (каковое
и будет запомнено). Причём такая метода применяется абсолютно ко всем возможным
настройкам, а не только к числу копий. Таким образом, большинство пользователей становится
счастливо, а количество ошибок сокращается, что хорошо.
Суммируя, можно сказать, что система сама может узнать большинство из тех сведений,
которые она запрашивает у пользователя. Главными источниками этих сведений являются:
 здравый смысл разработчика системы;
 предыдущие установленные параметры;
 наиболее часто устанавливаемые параметры.
Единственная проблема этого метода заключается в том, что для его использования к
проектированию системы нужно подходить значительно более творчески и тщательно, нежели
обычно практикуется.
4.Обучение работе с системой
Начиная с определенного объема функциональности системы, количество пользователей,
знающих всю функциональность, неуклонно снижается. Чем объемней система, тем больше
шансов на то, что среднестатистический пользователь знает о ней очень немного (относительно
общего объема функциональности). Например средний пользователь MS Word, скорее всего,
умеет пользоваться не более чем пятью процентами его возможностей.
Плохо это по многим причинам: во-первых, пользователи работают с системой не
слишком эффективно, поскольку вместо методов адекватных они используют методы
знакомые. Во-вторых, достаточно часто случается, что пользователи, не зная, что имеющийся
продукт делает то, что им нужно, ищут (и находят) продукт конкурента. В-третьих, при таком
положении вещей затруднительно продавать новые версии продукта: если пользователь не
умеет пользоваться и тем, что есть, убеждать его совершить покупку ради новой
функциональности придется на довольно шатком фундаменте.
4.1.Почему пользователи учатся
Люди делают что-либо только при наличии стимула, при этом тяжесть действия
пропорциональна силе стимула. Обучение есть действие: если обучаться легко, пользователям
будет достаточно слабого стимула, если тяжело, стимул придется увеличивать. Пользователь
обучится пользоваться программой или сайтом только в том случае, если он будет уверен, что
это сделает его жизнь легче и приятней.
Пользователь будет учиться какой-либо функции, только если он знает о её
существовании, поскольку, не обладая этим знанием, он не способен узнать, что за её
использование жизнь даст ему награду. Т.е. одного стимула недостаточно, если пользователь не
знает, за что этот стимул дается.
Таким образом, чтобы пользователь начал учиться, ему нужно рассказать о
функциональности системы, причем не только безучастно сообщать о наличии той или иной
функции, но и расхваливать преимущества, которые пользователь получит, этой функции
обучившись. А дальше пользователь сам будет учиться, если, конечно, стимул достаточен.
Без этого любая система не вызовет никакого желания учиться, даже если это обучение
принесло бы пользователю множество пользы. Простота же обучения системе есть всего лишь
метод уменьшить «необходимый и достаточный» стимул; при достаточно сильном стимуле
люди охотно учатся и без всякой простоты (другой разговор, что получение достаточно
весомого стимула часто более сложно для разработчика, чем облегчение обучения).
Разрабатывая систему и прорабатывая вопросы простоты обучения пользования этой
системой, рассчитывайте на средних пользователей, а не новичков или на
профессионалов: средних пользователей, как-никак, абсолютное большинство.
17
4.2.Средства обучения
Обычно считается, что в случае ПО есть два способа повысить эффективность обучения, а
именно бумажная документация и «оперативная справка». Это категорически неправильно. Вопервых, способов много, и самые главные способы в эту систему не попали. Во-вторых, одно из
понятий, входящих в эту таксономию, просто некорректно: оперативность справки зачастую
бывает отрицательной (т.е. поиск в ней занимает больше времени, чем поиск того же в
бумажной документации). Поэтому разумно привести более совершенный список средств
обучения:
 Общая «понятность» системы
 Обучающие материалы
4.3.Понятность системы
Термин «понятность», будучи крайне приятным и во многих случаях удобным, на самом
деле нехорош, поскольку очень уж размыт. Однако кое-что выделить можно, а именно:
 Ментальная модель
 Метафора
 Идеома
 Аффорданс
 Cтандарт
Ментальная модель
Зачастую, или, точнее, почти всегда, чтобы успешно пользоваться какой либо системой,
человеку необходимо однозначно понимать, как система работает. При этом необязательно
точно понимать сущность происходящих в системе процессов, более того, необязательно
правильно их понимать. Это понимание сущности системы называется ментальной моделью.
Разберем это на примере файловой системы. Каждый, кто обучал кого-нибудь
пользоваться компьютером, знает, как трудно объяснить пользу от записи файла после его
редактирования. Дело в том, что без понимания сущности происходящих в компьютере
процессов понять сущность записи невозможно. Допустим, пользователь создал новый
документ, что-то в нем сделал, после чего попытался выйти из программы. Программа
спрашивает его «Сохранить документ или нет?»; тут и начинается самое интересное. Вопервых, в этом вопросе главное значимое слово непонятно. Что такое сохранить? Где
сохранить? Куда сохранить? Если же вопрос ставится техническим языком, а именно «Записать
документ на диск?», то и здесь непонятно: на какой такой диск? Во-вторых, что важнее, даже
если пользователь понял вопрос, он все равно не может понять, зачем документ сохранять?
Как-никак документ уже имеется, сохранять его не надо.
Проблема усугубляется тем, что даже самый начинающий пользователь знает, что если он
нажмёт кнопку Ок, начнется какое-то действие. А поскольку пользователь не хочет, чтобы
действие, которого он не понимает, начиналось, он недрогнувшей рукою нажимает кнопку Нет,
после чего программа закрывается, а файл не сохраняется.
Иной аспект той же проблемы: как научить пользователя превентивно сохранять рабочий
файл время от времени, чтобы, когда компьютер зависнет, можно было встретить судьбу во
всеоружии? Сделать это практически невозможно, поскольку пользователь искренне уверен,
что если файл есть в компьютере, с ним уже ничего не сделается.
В результате, есть только два способа научить пользователя сохранять файлы. Сущность
первого способа состоит в объяснении пользователю, что если он не будет время от времени и
перед выходом из программы сохранять файл, у него будут проблемы. Этот способ обладает
определенным своеобразием: пользователь не поймет, зачем он это делает, он будет только
знать, что делать это надо. Таким образом пользователь будет совершать своеобразный ритуал.
Второй способ: пользователю можно объяснить, что в компьютере есть две подсистемы
памяти, одна постоянная, а другая временная; при выключении или при зависании компьютера
содержимое временной памяти теряется, так что если документ нужен будет и позже, его надо
перенести в постоянную память; перенос туда документа называется сохранением. Это и будет
18
являться для пользователя ментальной моделью памяти компьютера. Понимание ментальной
модели послужит стимулом для осознанных действий, а нашем случае - сохранения файла.
Изначально пользователь не имеет ментальной модели памяти компьютера. Проблема же
состоит в том, что компьютер не дает ему возможности самому построить модель, так что
единственным её источником может являться обучение. Это один из самых больших
недостатков дизайна современных компьютеров, во всяком случае, первый компьютер без
разделения памяти на постоянную и временную (Palm Pilot) разошелся тиражом в миллионы
экземпляров.
Пример с сохранением был выбран как чрезвычайно удобный пример построения
ментальной модели. Однако следует оговориться, что программа вообще не должна требовать
от пользователя сохранять файлы, а должна делать это сама автоматически.
Метафора
Как было сказано, чтобы научиться пользоваться системой, пользователю нужно
построить ментальную модель этой системы. Очень хочется избавить его и от этой работы.
Лучшим способом добиться этого является применение метафоры, которая позволяет
пользователю не создавать новую модель, а воспользоваться готовой моделью, которую он
ранее построил по другому поводу.
Самым простым примером метафоры в интерфейсе является устройство программ для
проигрывания звуков на компьютере. Исторически сложилось, что вся аудиотехника имеет
почти одинаковый набор кнопок, со стандартными обозначениями: несколько кнопок со
стрелками (назад/вперед), кнопка с треугольником (воспроизведение), кнопка с двумя
прямоугольниками (пауза) и т.д. Соответственно, при проектировании программы
аналогичного назначения разумно скопировать существующую систему маркировки кнопок.
Благодаря этому пользователям для использования программы ничему не приходится учиться.
Почти всегда метафору можно использовать в документации, не перенося её в интерфейс,
при этом с тем же успехом. Достаточно просто написать, что «система во многом напоминает
…» и нужный результат будет достигнут.
К сожалению, у метафор есть несколько существенных недостатков.
1.
Не для любой функциональности можно подобрать подходящую метафору,
причем заранее узнать, есть ли хорошая метафора или нет, невозможно, так что можно
потратить время на поиски и ничего не найти. Это, как минимум, неэффективно.
2.
Даже подходящая метафора может оказаться бесполезной, если её не знает
существенная часть аудитории или её тяжело однозначно передать интерфейсом.
3.
Почти всегда метафора будет сковывать функциональные возможности. Что
делать, если проектируемая система обладает большим количеством функций, чем копируемый
образец? Следование метафоре в таких условиях будет только вредить, поскольку
совпадающим функциям будет учиться легче, а несовпадающим – сложнее (они будут слишком
иначе устроены).
Пример удачной метафоры. Хотя успех метафоры обусловлен, прежде всего, отсутствием
необходимости расширять функциональность. Действительно, что еще требуется от
проигрывателя, кроме как проигрывать музыку?
19
Пример неудачной метафоры. Главный экран ОС Magic Cap. Будучи вся построена на
метафорах, ОС приобрела широчайшую известность среди журналистов компьютерных
изданий (они сразу всё понимали). С другой стороны, она не смогла добиться такой же любви
у пользователей: они её понимали, но отказывались с ней работать из-за её неэффективности.
4.
Совершенно необязательно, что сам по себе копируемый образец работает
идеально. Если его копировать, окажется, что система не сможет быть эффективней своего
прародителя. Например, Adobe PageMaker во многом копирует традиционные верстальные
гранки, наследуя их известность пользователям вместе с их ограничениями. Благодаря этому он
стал чрезвычайно популярен. Однако через некоторое время появился не копирующий гранки
QuarkXpress, и отвоевал большую часть пользователей лишь потому, что работал более
эффективно, не таская на себе груз старой идеи. Пользователи предпочитали потратить больше
времени на обучение, зато выиграть в скорости работы. Анекдотичность ситуации заключается
в том, что к настоящему времени гранки не используются вовсе, появилось поколение
пользователей, которое никогда их в глаза не видело. Результат: обучаясь PageMaker, они
должны дополнительно обучаться идее гранок, которая им вовсе не нужна.
Для таких физических объектов как принтеры или документы легко найти визуальную
метафору. Но для таких часто используемых в программах понятий как процессы, связи,
службы и преобразования это сделать трудно или даже невозможно. Очень сложно найти
хорошую визуальную метафору для покупки билета, смены каналов, приобретения товара,
нахождения ссылки, установки формата, вращения инструмента или смены разрешения экрана,
хотя именно такие операции мы чаще всего встречаем в программах.
Самая коварная проблема метафор возникает, если мы привязываем свой интерфейс к
артефактам механической эры. Легко понять, как работать с буфером обмена, потому что это
метафора, но придерживаясь метафоры, мы обнаружим, что его возможности очень слабы. Он
не может хранить больше, чем один объект, не помнит, что хранил ранее, не может определить,
откуда взялось изображение, он не может показать вам уменьшенные картинки того, что
содержит и не хранит свое содержимое от запуска до запуска системы. Все эти действия неметафоричны и им нужно учиться. Следование метафоре дает пользователю значительный
прирост производительности в первый раз, когда они используют буфер обмена, но это стоит
им многого после того как они откроют слабость этого механизма.
Еще один "выдающийся" пример - новый интерфейс для взаимодействия с компьютером
под названием MagicCap. Он основывается исключительно на метафоре в каждом своем
аспекте. Вы метафорически идете вниз по улице со зданиями, обозначающими приложения. Вы
входите в здание, чтобы запустить приложение и видите коридор с дверьми, обозначающими
функции. С одной стороны вы можете интуитивно понять основные функции программы, но с
другой стороны метафора ограничивает навигацию очень элементарным, линейным
маршрутом. Чтобы запустить другое приложение, вы должны вернуться на улицу. В
20
физическом мире это нормально, но в программе нет нужды заставлять пользователя делать все
старыми неуклюжими методами.
Таким образом, метафора, будучи лучшим средством для избавления пользователя от
обучения, не является средством хорошим. С другой стороны, метафоры иногда всё-таки
работают (взять те же музыкальные программы), так что определенную пользу от них получить
можно.
Анализируя опыт успешных случаев их применения, можно вывести следующие правила:
 опасно полностью копировать метафору, достаточно взять из неё самое лучшее;
 не обязательно брать метафору из реального мира, её смело можно придумать самому;
 эффективнее всего метафорически объяснять значение отдельных объектов: например,
для графической программы слои можно представлять как положенные друг на друга листы
стекла (этот пример подходит и для предыдущего пункта);
 если метафора хоть как-то ограничивает систему, от неё необходимо немедленно
отказаться.
Суммируя, можно сказать, что применять метафорический подход к разработке можно, но
с большой осторожностью. Гораздо более перспективным является идеоматический подход.
Идеома
Метафорический подход основан на интуитивном понимании. Идиоматический подход
основан на знании о том, как решать ту или иную задачу - естественный для человека процесс.
Метафорическая парадигма - шаг вперед, потому что ее интуитивное понимание
происходит без всякого знания механизма работы программ. Однако силу и полезность
метафоры часто раздувают до невероятных размеров. Толковый словарь Вебстера определяет
интуицию как "способность достижения непосредственного знания без какой-либо очевидной
разумной мысли или логического вывода". Человек интуитивно понимает вещи мысленно
сравнивая их с тем, что уже знает. Вы интуитивно понимаете, как работает пиктограмма
мусорной корзины потому, что вы уже однажды предприняли попытку понять как работает
настоящая мусорная корзина, тем самым подготовив свой мозг для отождествления. Но вы не
можете интуитивно понять, как работает настоящая мусорная корзина. Все это приводит нас к
идиоматической парадигме, основанной на том факте, что человеческий мозг - необычайно
мощная обучающаяся машина, и что обучаться для нас - легко.
В деле запоминания идиом человеческий разум проявляет выдающиеся способности. Ему
не приходится сравнивать их с уже известными ситуациями или понимать, как они работают.
Он и не должен делать этого, потому что большинство идиом вообще не имеют
метафорического смысла. Большинство элементов управления в графическом интерфейсе
пользователя - идиомы. Кнопки, выпадающие списки и полосы прокрутки - это то, что мы
узнаем автоматически, а не догадываемся метафорически.
Всем хорошо знакомая мышь не является метафорой чего-либо. Люди обучаются работе с
ней идиоматически. В мыши нет ничего, что указывало бы на цель ее применения. Она также
не напоминает ничего из нашего опыта, так что обучение работе с ней не интуитивно. Однако
научиться работать мышью очень легко. Некто наверняка потратил секунды три, чтобы в
первый раз показать вам, как она работает, и вы сразу поняли. Нам не нужно знать, как
устроена мышь но тем не менее можем прекрасно ею пользоваться. Это и есть идиоматическое
обучение.
Ирония в том, что большинство знакомых нам элементов GUI, которые считаются
метафорическими на самом деле являются идиоматическими. Такие артефакты, как кнопки
закрытия окна, окна с изменяемыми размерами, бесконечно вложенные папки с файлами,
щелчки мышью и перетаскивание пиктограмм - не метафорические операции, потому что их
нет в реальном мире. Их сила лишь в простой идиоматической узнаваемости.
Аффорданс
Другой составляющей понятности является нечто, по-английски называемое affordance. В
современном значении этого термина аффордансом называется ситуация, при котором объект
показывает субъекту способ своего использования своими неотъемлемыми свойствами.
21
Например, надпись «На себя» на двери не является аффордансом, а облик двери, который
подсказывает человеку, что она открывается на себя, несет в себе аффорданс.
Польза аффорданса заключается в том, что он позволяет пользователям обходиться без
какого-либо предварительного обучения, благодаря этому аффорданс является самым
эффективным и надежным средством обеспечения понятности.
Проблема в том, что аффорданс на экране получить сложнее, нежели в предметах
реального мира, поскольку единственным способом его передачи оказывается визуал, а такие
способы, как тактильные свойства или приспособленность к человеческой анатомии (пистолет,
например, трудно держать неправильно) оказываются за бортом. Это ограничение приводит к
тому, что доступными оказываются всего несколько способов передачи аффорданса, из
которых самыми значительными являются четыре:
1.
маппинг, или повторение конфигурации объектов конфигурацией элементов
управления (этот способ работает хорошо в реальном мире, но не очень хорошо на экране,
поскольку предпочтительней непосредственное манипулирование);
2.
видимая принадлежность управляющих элементов объекту;
3.
визуальное совпадение аффордансов экранных объектов с такими же
аффордансами объектов реального мира (кнопка в реальном мире предлагает пользователю
нажать на неё, псевдотрехмерная кнопка предлагает нажать на неё по аналогии);
4.
изменение свойств объекта при подведении к нему курсора (бледный аналог
тактильного исследования).
Стандарт
Если что-либо нельзя сделать «самопроизвольно» понятным, всегда можно сделать это
везде одинаково, чтобы пользователи обучались только один раз. Например, кран с горячей
водой всегда маркируют красным цветом, а кран с холодной – синим. Частично это
соответствует свойствам человеческого восприятия (недаром красный цвет мы называем
тёплым, а синий – холодным), но в основном здесь работает привычка.
Стандарт хорошо работает, когда популярен, в противном случае не работает вовсе.
Популярен же он может быть двумя способами: во-первых, он может быть во всех системах, вовторых, он может быть популярен внутри отдельной системы. Например, стандарт интерфейса
MS Windows популярен почти во всех программах для Windows, именно поэтому его нужно
придерживаться.
С другой стороны, этот стандарт оставляет неопределенным очень многое, и это многое в
разных системах трактуется по-разному. Бесполезно пытаться найти общий знаменатель во всех
системах, гораздо эффективнее установить собственный стандарт, не противоречащий
стандарту ОС, но дополняющий его; после чего этого стандарта надо придерживаться.
Последовательность в реализации интерфейса есть первое условие качества результата
Конечно, разработка собственного стандарта дело довольно тяжелое. С другой стороны,
сказать, что она совсем уж невозможна, тоже нельзя. Во-первых, самое главное уже
стандартизовано. Во-вторых, стандарт может развиваться параллельно процессу разработки,
при этом поддержание стандарта не стоит почти ничего. Обширный же стандарт вполне
окупает вложенные в него усилия ускорением обучения пользователей, не говоря уже о
снижении стоимости разработки.
4.4.Обучающие материалы



Типы обучающих материалов
Среды передачи обучающих материалов
Спиральность
Типы обучающих материалов
Базовая справка объясняет пользователю сущность и назначение системы. Обычно
должна сработать только один раз, объясняя пользователю, зачем система нужна.
Пример базовой справки. Показывается при первом запуске программы. Далее показ
можно отключить
22
В последнее время появилась возможность интегрировать в справочную систему видео
при помощи либо Macromedia Flash, либо Shockwave. Нет сомнений, что реклама, поданная не
просто в виде текста с картинками, но в виде анимации, способна как повысить желание её
просмотреть, так и повысить субъективное удовлетворение пользователей от системы.
Фактически, всем содержимым этой анимации является показ сменяющих друг друга
скриншотов (разработкой которых, должен заниматься графический дизайнер). Также,
необходимо создать более-менее хороший сценарий (его лучше отдать профессиональному
писателю). Дизайнер интерфейса в этом случае должен только составить список функций,
которые нужно рекламировать.
Обзорная справка рекламирует пользователю функции системы. Нужна и ПО и сайтам, и
нужна тем более, чем более функциональна система. Поскольку у зрелых систем
функциональность обычно очень велика, невозможно добиться того, чтобы пользователи
запоминали её за один раз. В этом случае оптимальным вариантом является слежение за
действиями пользователя и показ коротких реклам типа «А вы знаете, что…» в случае заранее
определенных действий пользователей.
«Помощник» поиска в Windows XP
23
Справка предметной области отвечает на вопрос «Как сделать хорошо?». Поскольку от
пользователей зачастую нельзя рассчитывать знания предметной области, необходимо
снабжать их этим знанием на ходу. При этом действуют два правила: во-первых, пользователи
ненавидят признавать, что они чего-либо не знают, соответственно, подавать это знание надо
максимально «небрежным тоном»; во-вторых, наличие такого знания всегда повышает
субъективную оценку справочной системы в целом, т.е. приводит к тому, что пользователи
чаще обращаются к справочной системе и от этого эффективней учатся.
Это окошко появляется при каждой загрузке программы, постепенно и ненавязчиво
информируя пользователя о функциях программы
Справка предметной области также реализуется обычно в бумажной документации.
Однако, как минимум, часть её можно подавать пользователям в интерфейсе вместе с
выдержками из обзорной справки.
После того как была исправлена ошибка, у «помощника» зажегся индикатор,
указывающий на то, что у него есть совет для пользователя. При щелчке по индикатору
появилось следующее сообщение . Отличный пример ненавязчивой и полезной справки.
24
Справка предметной области является самой важной подсистемой справки. Грамотный и
опытный пользователь сможет воспользоваться системой, лишенной всех справочных систем,
более того, такой пользователь сможет даже научиться пользоваться такой системой. Но без
знания предметной области он никогда не сможет пользоваться системой правильно и
эффективно.
Процедурная справка отвечает на вопрос «Как это сделать?». В идеале она должна быть
максимально более доступна, поскольку если пользователь не найдет нужную информацию
быстро, он перестанет искать и так и не научится пользоваться функцией (возможно, никогда).
Пример процедурной справки с «помощником» из MS Office
Лучшим местом для процедурной справки является выделенная справочная система.
Необходимо стараться привязывать темы справки к интерфейсу: когда пользователям
непонятно, как выполнить нужное им действие, им не придется подолгу искать в справочной
системе нужную тему.
Контекстная справка отвечает на вопросы «Что это делает?» и «Зачем это нужно?». Как
правило, наибольший интерес в ПО представляет первый вопрос, поскольку уже по названию
элемента должно быть понятно его назначение (в противном случае его лучше вообще
выкинуть), а в интернете – второй (из-за невозможности предугадать, что именно будет на
следующей странице). Поскольку пользователи обращаются к контекстной справке во время
25
выполнения какого-либо действия, она ни в коем случае не должна прерывать это действие
(чтобы не ломать контекст действий), её облик должен быть максимально сдержанным, а объем
информации в ней – минимальным.
Для контекстной справки заслуженно используют всплывающие подсказки (ToolTip) и, в
последнее время, пузыри.
Пример всплывающей подсказки
Справка состояния отвечает на вопрос «Что происходит в настоящий момент?». Не
может быть вынесена из интерфейса.
Пример справки состояния. Информирует пользователя о действиях системы
Среды передачи обучающих материалов
Бумажная книга.На одном листе может быть сконденсировано очень много материала,
легко позволяет читателю получить большой объем материала за один сеанс, наилучшим
образом работает при последовательном чтении. Сравнительно плохой поиск нужных сведений.
Объем практически всегда лимитирован.
Справочная карта. Отдельная краткая бумажная документация, демонстрирующая
основные способы взаимодействия с системой. Будучи реализована на едином листе бумаги,
позволяет пользователю повесить её перед собой. Хороша как средство обучения продвинутым
способам взаимодействия с системой и устройству навигации в системе.
Структурированная электронная документация.Плохо предназначена для чтения
больших объемов материала, зато обеспечивает легкий поиск и не имеет лимита объема.
Занимает большой объем пространства экрана. Плохо подходит для показа крупных
изображений, зато в неё могут быть легко интегрированы видео и звук.
Фрагменты пространства интерфейса, показывающие справочную информацию.
Занимают пространство экрана, но пространство ограниченное. Отвлекая внимание, как
26
минимум один раз воспринимаются всеми пользователями. Как правило, неспособны
передавать большой объем информации.
Всплывающие подсказки. Хорошо справляются с ответом на вопросы «Что это такое» и
«Зачем это нужно», при условии, что объем ответов сравнительно невелик. Поскольку
вызываются пользователями вручную, в обычном режиме не занимают пространства экрана и
не отвлекают внимания пользователей. С другой стороны, очень легко вызывают отвыкание –
после первого же случая неудовлетворения пользователя подсказкой, пользователь перестает
вызывать и все остальные подсказки.
Спиральность
Поскольку пользователи обращаются к справочной системе при возникновении проблем,
можно смело сказать, что использование справочной системы всегда воспринимается
негативно. Таким образом, следует всемерно сокращать объем справочной системы, чтобы тем
самым сократить длительность неудовольствия. К сожалению, сокращение объема не приводит
к полному счастью, поскольку при малом объеме справочной системы возрастает риск того, что
пользователи не найдут в ней ответы на свои вопросы.
Есть, однако, исключительно эффективный метод решения этой проблемы: так
называемые спиральные тексты. Идея заключается в следующем. При возникновении вопроса
пользователь получает только чрезвычайно сжатый, но ограниченный ответ (1-3 предложения).
Если ответ достаточен, пользователь волен вернуться к выполнению текущей задачи, тем
самым длительность доступа к справочной системе (и неудовольствие) оказывается
минимальной. Если ответ не удовлетворяет пользователя, пользователь может запросить более
полный, но и более объемный ответ. Если и этот ответ недостаточен (что случается, разумеется,
весьма редко), пользователь может обратиться к ещё более подробному ответу. Таким образом,
при использовании этого метода, пользователи получают именно тот объем справочной
системы, который им нужен.
Спиральность текста считается нормой при разработке документаций. Есть веские
основания считать, что она необходима вообще в любой справочной системе. Рекомендуется
делать её во всех случаях.
5.Субъективная удовлетворенность
Субъективная удовлетворенность складывается из
приведены некоторые из них:
 Эстетика
 Субъективное восприятие скорости работы
 Приемы для уменьшения субъективного восприятия
 Уменьшение вероятности стрессовых ситуаций
 Пароли
 Сообщения об ошибках
многих
составляющих.
Ниже
5.1.Эстетика
Конструируемый предмет должен быть незаметен в процессе его использования. Странно
интересоваться, как выглядит стул, на котором сидишь. Когда человек читает книгу, он чаще
всего не замечает её верстку. В то же время предмет должен приятно ощущаться на
бессознательном уровне. Таким образом, во что бы то ни стало, необходимо добиваться
неощущаемости интерфейса. Для этого:
 Избегайте развязности в визуальном дизайне.
 Избегайте ярких цветов. Существует очень немного цветов, обладающих и яркостью, и
мягкостью (т.е. не бьющих по глазам). На экране их значительно меньше, поскольку в жизни
такие цвета обычно моделируются как собственно цветом, так и текстурой, с чем на экране есть
проблемы.
 Избегайте острых углов.
 Старайтесь сделать дизайн максимально более легким и воздушным.
 Старайтесь добиваться контраста не сменой насыщенности элементов, но
расположением пустот.
27
Красота понятие относительное. Необходимо стремитесь не столько к красоте
интерфейса, сколько к его элегантности. Во-первых, элегантный интерфейс не надоедает. Вовторых, он редко осознается потребителями, обеспечивая неощущаемость. В-третьих – он
приносит эстетическое удовольствие независимо от культурного уровня потребителя. Вчетвертых, в производстве он гораздо удобнее красоты, поскольку сравнительно легко ставится
на поток. Чтобы добиться элегантности, надо действовать следующим образом:
 Старайтесь
сделать
интерфейс
максимально
насыщенным
визуальными
закономерностями. Есть универсальное правило – чем больше закономерностей, тем больше
гармонии. Даже самые незначительные закономерности всё равно воспринимаются. Под
закономерностью понимается любое методически выдерживаемое соответствие свойств у
разных объектов, например, высота кнопок может быть равна удвоенному значению полей
диалогового
окна.
Пример закономерностей в диалоговом окне. Старайтесь минимизировать количество
констант (тем более, что двух констант обычно хватает на все). Разумеется, единожды
примененных закономерностей необходимо придерживаться во всей системе.
Всемерно старайтесь использовать модульные сетки, т.е. привязывайте все объекты к
линиям (лучше узлам) воображаемой сетки, которую выдерживайте во всем интерфейсе.
 Старайтесь привязывать все размеры и координаты (как минимум пропорции
диалоговых окон) к золотому сечению (0.618 х 0.382).

5.2.Субъективное восприятие скорости работы
Субъективное ощущение времени зачастую сильно отличается от объективного.
Воспринимаемая продолжительность действий напрямую зависит от уровня активности
пользователя, так что субъективная длительность последовательности действий всегда ниже
такой же по времени паузы. Пользователи часто жалуются, что им “кажется”, что процесс
происходит медленнее, чем есть на самом деле.
Классический пример произошел в Нью-Йорке в 1930 году, когда пользователи нового
офисного здания постоянно жаловались на долгое время ожидания лифтов. Когда пригласили
инженеров для консультации, выяснилось, что нет никакой возможности ни ускорить лифты,
28
ни увеличить их число или вместимость. Тогда пригласили дизайнера, который смог решить
проблему.
Дизайнер понял, что настоящая проблема была не в том, что время ожидания лифтов было
слишком большим, а в том, что оно воспринималось таковым. Дизайнер решил проблему
восприятия размещением зеркал на стенах площадок для ожидания лифта. Теперь люди были
заняты рассматриванием себя и других в множестве отражений. Их мозг был полностью занят,
а время летело.
В одном из исследований этого феномена пользователей попросили выполнить одно и то
же задание с помощью клавиатуры и мыши. Работа с клавиатурой была напряженной и
требовала принятия множество мелких решений. Версия для мыши была гораздо легче и
принятия решений не требовала.
Все пользователи выполнили задание с помощью мыши примерно на 50% быстрее. Но что
интересно, все высказались, что они выполнили задание гораздо быстрее с помощью
клавиатуры.
Таким образом, нужно всегда принимать во внимание субъективные убеждения
пользователей о том, насколько быстрым или медленным является процесс. Не принимайте
решение на основе только своего собственного мнения. Тестируйте программу на
пользователях.
Основная стратегия уменьшения субъективного времени восприятия:
Пользователи должны быть постоянно заняты
Когда в процессе работы возникает неизбежная пауза, например, потому что программа
должна обратиться к серверу, убедитесь, что пользователь занят и развлечен. Идеальное
занятие – это занятие, имеющее отношение к текущей задаче. Перед тем, как обращаться к
серверу, дайте пользователю прочесть что-нибудь, что подготовит его для следующей задачи.
Пример сокращения субъективного времени восприятия Во время ожидания конца
инсталляции пользователю показывается ряд меняющихся экранов с картинками и текстом. В
данном случае выполняются две задачи: дается справка о новых возможностях продукта и
сокращается субъективное время восприятия.
Приемы для уменьшения субъективного восприятия
Все приводимые указания зависят от использования индикаторов. Следующие типы
индикаторов приведены в порядке от наиболее до наименее желаемого:
1.
Индикатор оставшегося времени. Поместите его либо в модальный диалог, либо в
строку статуса.
29
2.
Индикатор “Система жива”. Когда оставшееся время предугадать невозможно,
покажите анимированный объект, который даст пользователям понять, что система не зависла.
3.
Индикатор “Слышу и понимаю”. Когда ожидаемая задержка менее 2 секунд,
показывать оставшееся время бессмысленно, поэтому просто измените форму курсора на
“песочные часы”.
Для задержек от 0,1 секунды до 10 секунд:
1.
Подтвердите щелчок мыши или нажатие клавиши в течение 0,1 секунды.
2.
Измените форму курсора на “песочные часы” или другой анимированный
указатель для любой задержки более 0,5 секунды.
3.
Покажите, когда пользователь может продолжать.
Для задержек от 10 секунд до 1 минуты:
1.
Подтвердите щелчок мыши или нажатие клавиши в течение 0,1 секунды.
2.
Привлеките внимание пользователя
3.
Укажите время ожидания точно или приблизительно.
4.
Выведите индикатор
5.
Покажите, когда пользователь может продолжать.
Для задержек от минуты до целой ночи:
1.
Подтвердите щелчок мыши или нажатие клавиши в течение 0,1 секунды.
2.
Привлеките внимание пользователя. Индикатор, который трудно заметить, может
и не существовать.
3.
Сообщите пользователю, насколько долгим будет ожидание. Если не знаете –
предположите диапазон значений. Даже довольно широкого диапазона (от 3 до 15 минут)
пользователю может быть достаточно для принятия решения – переключиться на другую
задачу, или же пойти попить кофе.
4.
Выведите индикатор.
5.
Четко и ясно сообщите пользователю, когда он может продолжать. Это не значит,
что вы должны вывести сообщение шрифтом 96 размера. Это значит, что изменения на экране
должны быть значительными, для того чтобы их можно было визуально различить.
5.3.Уменьшение вероятности стрессовых ситуаций
Нет ничего более неприятного, чем психологическое напряжение, иначе говоря – стресс.
Почти всё время пользователь может что-либо испортить и знает это. Он может
отформатировать жесткий диск, может стереть или испортить нужный файл. Неудивительно,
что пользователь часто боится. А если не боится, то склонен недооценивать свои возможности
к разрушению, отчего снижается бдительность.
Единственным полноценным решением является возможность отмены пользователем
своих предыдущих действий, без ограничения количества уровней отмены и типа отменяемых
действий. Пользователь, знающий, что он не может совершить ошибку, испытывает радость и
умиротворение. К сожалению, создание таких систем, не будучи исключительно трудным
делом с точки зрения технологии требует смены парадигмы мышления программистов.
Зачастую более реалистичным решением является давно уже существующая практика
прятать опасные для пользователя места интерфейса. Формально, это хороший и правильный
способ. Проблема заключается в том, что при этом логично прятать все функции, изменяющие
данные, например банальная функция автоматической замены может мгновенно уничтожить
текст документа (достаточно заменить одну букву на любую другую и забыть отменить это
действие).
Другим фактором, существенно влияющим на субъективное удовлетворение
пользователей, является чувство контроля над системой. Существует значительная часть
пользователей, для которой использование компьютера не является действием привычным. Для
таких пользователей ощущение того, что они не способны контролировать работу компьютера,
30
является сильнейшим источником стресса. Для остальных пользователей отсутствие чувства
контроля не приносит стресса, но всё равно приводит к неудовольствию.
Таким образом, пользователей нужно всемерно снабжать ощущением, что ничего не
может произойти, пока этого не захочется самому пользователю. Функции, работающие в
автоматическом режиме, но время от времени просыпающиеся и требующие от пользователей
реакции, вызывают стресс. В любом случае, стоит всеми силами внушать пользователям мысль,
что только явно выраженное действие приводит к ответному действию системы.
5.4.Пароли
Пароли имеют три принципиальных проблемы:
1.
пользователи не любят их вводить
2.
пользователи либо забывают пароли, либо пароли не работают, т.е. ничего не
защищают, поскольку пользователи используют те пароли, которые они помнят и которые,
соответственно, непроблематично подобрать.
3.
в интернете часто происходит так, что пользователи, не желая вводить пароль (и
регистрироваться, к слову говоря) так никогда не попадают в главную часть сайта.
Каким же образом можно решить эти проблемы. Для этого есть несколько путей. Вопервых, от паролей можно отказаться вообще. Этот путь почти всегда предпочтителен,
проблема в том, что он вызывает существенное отторжение у сетевых администраторов. В
самом деле, зачем требовать от пользователя пароль, если подобрать этот пароль
злоумышленник сможет без труда? И обратно: поскольку единственным способом создания
действительно трудноподбираемых паролей является генератор случайных чисел, каковые
числа (символы, по необходимости) невозможно запомнить, пользователи либо будут
записывать их на бумажке (в этом случае пароли еще легче украсть), либо будут забывать, что
дорого стоит.
Этот метод хорош, когда дело касается защиты информации. Однако гораздо чаще,
особенно в интернете, важна не столько защита информации, сколько идентификация
пользователя (которая может сопрягаться с защитой, а может и не сопрягаться). В этом случае
от паролей отказаться невозможно, просто потому, что не существует другой, столь же
эффективной, технологии идентификации. При этом содержимое пароля как таковое не очень
важно, важно его отличие от паролей других пользователей (в этом случае само по себе имя
пользователя является паролем). Обычно в таких условиях при регистрации применяют
стандартную группу элементов «имя, пароль, подтверждение пароля», после чего, уже при
нормальной деятельности, пользователь получает возможность ввести пароль только в первый
раз.
В этом случае появляется следующий недостаток: пользователь, однократно введя пароль,
потом его забывает, поскольку из-за отсутствия повторения пароль никогда не попадает в
долговременную память. В результате, когда пользователь переходит на другой компьютер или
переустанавливает ОС, ему приходится регистрироваться снова, что нехорошо. Во-первых, эта
лишняя работа раздражает. Во-вторых, база пользователей при этом разбавляется дубликатами,
что всегда плохо сказывается на стоимости этой базы. В-третьих, что иногда самое главное,
зарегистрировавшийся во второй раз пользователь лишается возможности получить уже
использованное им ранее имя, что огорчительно: например, пользователь, забывший пароль от
почтовой службы, лишается как доступа к своему почтовому ящику, так и возможность
получить прежний почтовый адрес. Конечно, некоторые пользователи воспользуются тем или
иным способом узнать свой прежний пароль, но отнюдь не все.
Это значит, что помимо какого-либо механизма напоминания пользователям их
потерянных паролей, очень полезно не скрывать от пользователей их пароль, т.е. выводить его
в поле ввода не звездочками, а открытым текстом. Это решение хорошо ещё и тем, что
количество ошибочно набранных паролей здорово сократится (тяжело набирать на клавиатуре
невидимое).
Таким образом, эффективнее всего максимально здраво определить степень важности
защищаемой информации, после чего выбрать адекватную схему защиты, стараясь, чтобы она
31
была максимально лёгкой для пользователей. Как правило, их субъективное удовлетворение
важнее потенциального вреда от потери информации.
5.5.Сообщение об ошибках
Как избежать сообщений об ошибках
Каким должно быть сообщение об ошибке
Пузырь как альтернатива сообщениям об ошибке
Сообщения о завершении операции
Ни один пользователь не может долго и продуктивно работать с системой, которая его
огорчает и обижает. Тем не менее, такие «скандальные» системы являются нормой. Виной тому
сообщения об ошибках.
Большинство сообщений об ошибках в действительности не являются собственно
сообщениями об ошибках. На самом деле они показывают пользователю, что система, которой
он пользуется несовершенна, а именно:
 недостаточно гибка, чтобы приспособиться к его действиям. В действительности
множество действий пользователя направлены не на то, чтобы сделать так, а не иначе, а на то,
чтобы сделать примерно так, как хочется. Пользователю часто нет дела, можно добиться
точного результата или нет. Показывать ему в таких случаях диалог об ошибке глупо,
поскольку пользователю не нужно ничего знать. Ему нужен результат.




Вот что бывает , если пользователь попытается ввести значение, которое ему нужно, но
которое система не умеет обрабатывать. Тут возможно три альтернативных решения. Вопервых, при проектировании системы можно более тщательно подходить к выбору её
функциональности. Во-вторых, можно просто игнорировать неправильность значения,
округляя его до ближайшего возможного (в данном примере система так и делает, но зачем
же при этом выводить сообщение!?). В-третьих, вместо обычного поля ввода можно
использовать крутилку (spinner)
недостаточно умна, чтобы показать ему его возможные границы действия. Во многих
случаях пользователь совершает действия, которые воспринимаются программой как
неправильные, не потому, что он дурак, но потому, что система не показала ему границ
возможного действия. Все такие сообщения порочны, поскольку их можно было бы избежать,
просто блокировав возможность совершения некорректных действий или показав пользователю
их некорректность до совершения действия.

Типичное сообщение об ошибке, вызванное нежеланием системы показать пользователю
границы его действий. К тому же из сообщения не понятно в чем собственно ошибка, а
междометьем «или» система расписывается в своей некомпетентности. Все усугубляется
тем, что система не предоставляет ни одного варианта решения проблемы (еще бы! она ведь
даже не знает точно, в чем она заключается). Даже опытный пользователь, впервые
столкнувшись с этой проблемой, потратит на ее расшифровку несколько минут. Между
прочим, это Office XP.
32
Пример из того же Office XP, но уже на порядок лучше. Во-первых, сообщение не выглядит как
банальное сообщение об ошибке, а выглядит как диалоговое окно. Во-вторых, пользователю тут
же предоставляются варианты выхода из затруднительной ситуации (тут даже язык не
поворачивается называть эту ситуацию проблемой). Однако есть существенный недостаток,
который буквально перечеркивает все достоинства: совершенно непонятна разница между
первым и последним пунктом. Ошибка в данном случае может быть фатальной. Хуже всего, что
из-за несовершенства интерфейса в случае перезаписи файла не поможет даже корзина.
 самоуверенна и считает, что пользователь дурак, которым можно и нужно помыкать.
Нормой также являются случаи, когда система пытается выставить дело так, как будто
пользователь неправ, а система, наоборот, есть воплощение безошибочности и правоты. В
действительности не пользователь сделан для системы, но система для пользователя. Таким
образом, как-либо ущемлять пользователя неправильно.
Пример подобного сообщения. Для кого неверное? И кто, собственно, виноват, система или
пользователь?
Суммируя, можно сказать, что почти любое сообщение об ошибке есть признак того, что
система спроектирована плохо. Всегда можно сделать так, чтобы показывать сообщение было
бы не нужно. Более того. Любое сообщение об ошибке говорит пользователю, что он дурак.
Таким образом, почти все сообщения об ошибках должны быть удалены. Разумеется, речь
идет не о том, чтобы просто выкинуть куски кода из программы, а о том, что системы
изначально надо проектировать так, чтобы в них отсутствовала необходимость в таких
сообщениях. Невозможно полноценно работать с системой, которая по нескольку раз за день
тебя ругает.
Как избежать сообщений об ошибках
Делайте ошибки невозможными. Наилучший способ избежать сообщений об ошибках
это сделать так, чтобы пользователь не смог их совершить. Вместо требования ввести данные с
клавиатуры, предоставьте пользователю список возможных вариантов выбора.
Еще один прекрасный способ избежать сообщений об ошибках - это сделать программу
достаточно умной для того, чтобы избежать вопросов к пользователю. Многие сообщения об
33
ошибках говорят что-то вроде "Неверные данные. Пользователь должен ввести ХХХХ".
Почему же программа не может, зная, что должен ввести пользователь, ввести ХХХХ сама?
Вместо запроса у пользователя имени файла на диске, давая возможность выбрать
несуществующий файл, программа может запомнить, с какими файлами велась работа
последний раз, и предоставить их список.
Вот такое диалоговое окно вынуждены наблюдать пользователи, которые захотят
перевести файл в PROMT’e. Банальное открытие файла разработчики превратили в
увлекательную игру «Отгадай формат». Не понятно, почему программа сама не может
определить, какой формат у открываемого файла. Тем более не понятно, зачем при открытии
файла указывать «направление перевода», ведь это можно сделать опционально, уже
непосредственно в программе. Самое интересное, что у этой истории есть продолжение.
Такое сообщение появляется, если пользователь вводит неправильный формат. При чем
вне зависимости от ответа пользователя система не пытается выполнить никаких действий.
После этого диалогового окна у пользователя уже не остается никаких сомнений, что
программа над ним издевается.
Позитивная обратная связь - хороший способ вознаградить пользователя за правильное
пользование программой. Наилучший способ позитивной обратной связи это звук. К несчастью,
долгие годы окна с сообщениями об ошибках сопровождались громким и пронзительным
гудком, и звук стал ассоциироваться с ошибкой.
В реальной жизни любой объект или система, за исключением компьютерных программ,
используют звук для позитивной обратной связи. Закрывая дверь, мы определяем, что она
34
защелкнулась, услышав щелчок, тишина означает, что дверь еще не закрыта. Когда мы
поворачиваем ключ зажигания и ничего не слышим, значит у нас проблемы. Когда мы
включаем копир, а он молчит, вместо того, чтобы громко гудеть, мы понимаем, значит что-то
не так.
Программы должны давать нам постоянные небольшие звуковые подсказки, похожие на
тихие щелчки кнопок клавиатуры. Программы были бы более дружественными и простыми в
использовании, если бы они издавали едва заметные, но легко узнаваемые звуки, когда
действия пользователя верны. Программа должны выдавать мягкий звук каждый раз, когда
пользователь ввел верное значение. Если программа не понимает введенную информацию, она
должны молчать. В этом случае пользователь может сразу скорректировать данные безо
всякого смущения. Когда пользователь начинает перетаскивать иконку, программа может
коротко щелкнуть, а во время движения объекта производить тихое шипение. Когда объект
находится над областями, где его нельзя оставить, звук меняется на что-нибудь более
неблагозвучное. Когда наконец пользователь отпустит кнопку мыши, он будет вознагражден
тихим "Да!", если действие завершено успешно, и тишиной из динамиков, если действие не
имеет смысла.
Звуковая обратная связь должна быть очень тихой, не громче чем звук нажатий клавиш на
переносном компьютере. Программа должна производить звук каждый раз, когда пользователь
работает с программой правильно или каждый раз, когда пользователь вводит информацию,
которую программа понимает. Пользователи быстро начнут зависеть от этих звуков, и начнут
работать более быстро и эффективно.
Проверяйте – не редактируйте. Еще один метод избежать сообщений об ошибках для
программы, когда пользователь вводит неправильные данные, состоит в том, чтобы принять,
что они неправильные, потому что программа, а не пользователь, плохо информирована.
Если, например, пользователь вводит счет-фактуру для несуществующего номера клиента,
программа может принять эти данные, и сделать себе специальную заметку, которая
показывает, что пользователь должен исправить ее. Затем она будет наблюдать, чтобы
удостовериться, что пользователь ввел необходимую информацию до конца отчетного периода.
Так в действительности работают большинство людей. Они не вводят "неверных" номеров.
Просто люди обычно вводят информацию в такой последовательности, которую программа
принять не может.
Мы предполагаем, что запись о клиенте должна уже существовать перед выпиской счетафактуры, но это не догма. Почему программа не может воспринимать счета-фактуры
независимо от записей о клиентах, и попросту считать, что недостающая информация будет
введена позже? Если человек забывает ввести недостающую информацию до конца месяца,
программа может переместить незаконченные документы на неопределенный счет. Программа
не должна прерывать работу и останавливаться с сообщением об ошибке.
Каким должно быть сообщение об ошибке
Существуют ситуации, в которых сообщение об ошибке не избежать. Типичные примеры
подобных ситуаций: файл, находящийся на сетевом сервере более не доступен; попытка записи
на диск, доступный только для чтения; недостаток нужных для работы программы
компонентов, и т.д. Каким должно быть сообщение об ошибке в этом случае? Идеальное
сообщение об ошибке должно отвечать всего на три вопроса:
1.
В чем заключается проблема?
2.
Как исправить эту проблему сейчас?
3.
Как сделать так, чтобы проблема не повторилась?
При этом отвечать на эти вопросы нужно возможно более вежливым и понятным
пользователям языком. Например, разберем сообщение о невозможности перезаписать
заблокированный файл.
Итак, исходное сообщение об ошибке гласит: «Не удается сохранить файл «D:\Только для
чтения.doc». Файл с этим именем уже существует и доступен только для чтения. Сохраните
файл под другим именем или в другой папке». Каким образом его можно улучшить?
Сначала надо разобраться, в каких случаях оно появляется: оно может появляться, если
пользователь попытался сохранить файл на компакт-диске, или же пытается сохранить файл,
35
незадолго перед этим скопировав этот файл с компакт-диска. Случаи, когда файл заблокирован
сознательно, в жизни редки, так что их чаще всего можно не учитывать. Главный враг –
компакт-диск.
Тут возможно несколько непротиворечащих друг другу решений. Во-первых, просто
можно блокировать возможность что-либо записать на диске, запись на который невозможна.
Собственно говоря, запись и так блокируется, но сообщением об ошибке. А можно просто не
показывать диски, на которые нельзя записывать, в окне записи, что эффективнее, поскольку
делает ошибку невозможной. Во-вторых, можно показывать файлы, защищенные от записи,
иначе, чем файлы незащищенные. Это будет работать, но тоже неидеально. Что делать
пользователю, который всё-таки хочет перезаписать файл? Сейчас в такой ситуации приходится
записывать файл под новым именем, потом стирать старый, а новому давать имя старого. Это и
потери времени и ошибочно стертые файлы.
Таким образом, сообщение об ошибке должно стать не только сообщением – оно должно
позволять разблокировать файлы, разблокировать которые возможно (т.е. записанные не на
компакт-диске).
Также необходимо помнить следующие общие правила:
 Никогда не забывайте показывать текст сообщений об ошибке техническому писателю;
 Всемерно старайтесь делать текст сообщения возможно более коротким.
Пузырь как альтернатива сообщениям об ошибке
В Windows появился элемент управления, значительно лучше предназначенный для
показа сообщений: пузырь (balloon).
Пример пузыря
Пузырь, по сравнению с диалоговым окном, имеет существенные достоинства.
 он гораздо слабее сбивает фокус внимания, нежели окно;
 чтобы закрыть пузырь, пользователям не обязательно нажимать на какую-либо кнопку,
достаточно щелкнуть мышью в любом месте экрана;
 он не перекрывает значимую область системы;
 он показывает, в каком именно элементе управления была допущена ошибка.
К сожалению, пузыри имеют и недостатки:
 в них не может быть никаких элементов управления;
 пузырей пока нет в интернете.
36
Сообщения о завершении операции
Сообщения о завершении операции сходны с сообщениями об ошибках. Они точно также
могут вызывать раздражение пользователя, снижать его субъективное удовлетворение от
системы и отвлекать от выполнения основной задачи. Тем не менее в отличии от сообщений об
ошибках в сообщениях о завершении операции есть необходимость и полностью избавиться от
них невозможно. Таким образом, нужно попытаться сделать их как можно менее навязчивыми
и «вежливыми».
Разрабатывая очередную программу, необходимо учитывать следующие принципы:
1.
Необходимо предлагать пользователю обратную связь, не прерывая его.
Например, представим, что был произведен поиск по запросу пользователя и теперь должно
появится сообщение о результате. Представим, что этот поиск необходим для заполнения
одного из полей на форме пользователя, как, например, адрес человека, кому он должны
послать ее, полученный из адресной книги. Вместо того, чтобы трубить об успешном
результате, необходимо просто заполнить это поле. Если требуется дальнейшая обратная связь,
необходимо сделать желтую иконку, мигающую во время поиска. В случае успешного
результата необходимо сменить цвет на зеленый, в случае неудачи - на красный. Если форма
достаточно большая, пользователь может в это время находиться в другом разделе, поэтому
нужно поместить где-нибудь индикатор состояния для всей формы. Индикатор статуса в форме
иконки может обозначать следующее: "где-то на этой форме поле помечено красным. Нажмите,
чтобы найти его". Когда пользователь закончит заполнять форму и увидит зеленый индикатор,
он поймет, что можно идти дальше.
Пример самого бесцеремонного прерывания пользователя. Когда пользователь находится в
другом приложении, поверх приложения выскакивает не только окошко о завершении операции
форматирования, но и само окошко форматирования. Почему не сообщить о завершении
операции путем мигания кнопки в панели задач?
2.
Используйте само – срабатывающие диалоги. Например, диалоги печати
спрашивают пользователя, сколько копий ему нужно, и т.д. Затем они сидят на экране в
37
течении следующих трех дней в ожидании ответа. Пользователь ушел на обед, забыв, что
должен появиться этот глупый диалог, и ждет что к его приходу 500-страничный документ
будет напечатан. В программе ни к коем случае не должно возникать таких ситуаций. В данном
случае программа должна догадаться, что если пользователь послал на печать, значит ему
нужна как минимум одна копия. Поэтому, когда пройдет пара минут, необходимо начать
печать. Даже если получится так, что пользователю нужны две копии, он всегда может
отпечатать еще одну, или даже сделать копию на копировальном аппарате. В любом случае,
время не будет потеряно.
Если говорить о перспективах, то уже сейчас есть технологии отслеживающие
направление взгляда. Эти технологии можно применять и в случае с сообщениями. Увидев что
пользователь прочитал сообщение, в течении нескольких секунд система должна сама
закрывать окно.
Необходимо думать о сообщениях, как о советах ценного помощника. Делать их
вежливыми, полезными и прерывающими пользователя, только если это необходимо.
6.Типичные интерфейсные ошибки отечественного ПО
Серьёзная эргономическая экспертиза программного продукта (usability testing) - дело
нетривиальное и дорогое, проводится по специальным методикам и позволяет получить как
качественные, так и количественные оценки эргономичности как программного продукта в
целом, так и таких его важных компонент, как пользовательский интерфейс и пользовательская
документация.
Не имея такой возможности - проводить серьёзное исследование, я попытаюсь лишь
предоставить примеры эргономических проблем, возникающих при производстве программных
продуктов. Таким образом, предлагаемый обзор является довольно поверхностным, так как
используется эвристический метод оценки пользовательского интерфейса и эргономичности
программ.
Итак, проблемы, как правило, бывают трёх типов:
1.
Глобальные эргономические противоречия
2.
Неадекватное применение интерфейсной парадигмы
3.
Ошибки проектирования элементов пользовательского интерфейса (как целых
форм, так и аспектов применения конкретных элементов управления).
Оказывается, что практически в любом мало-мальски сложном отечественном
программном продукте эргономические проблемы всех трёх типов присутствуют в изобилии.
Разберем их подробнее.
1.
Программа перегружена элементами управления
2.
Терминология не адекватна знаниям пользователя о системе
3.
От пользователя постоянно требуется дополнительная информация
4.
Программа не готова к немедленной работе и требуют настройки
5.
Программа имеет многодокументный интерфейс
6.
Отсутствует единый стиль
7.
Программа перегружена окнами сообщений
8.
Интерфейс отражает внутреннюю структуру реализации и мышление
программистов
9.
Взаимное размещение объектов на экране не совпадает с их логической связью
и/или с их важностью
10.
Пиктограммы используются некорректно
Программа перегружена элементами управления
Эту проблему без преувеличения можно назвать наиболее типичной для российского
программного обеспечения. Суть проблемы заключается в том, что структура
пользовательского интерфейса приведена в соответствие с информационными потоками
(структурой объектов) внутри самой системы, а не в соответствие со структурой реальной
деятельности пользователей.
38
Как следствие, интерфейс "зашумлен" информацией, релевантной объекту, с которым
работает пользователь, но либо не нужной ему сейчас, либо не нужной ему вообще, поскольку
разным сотрудникам нужна разная информация
Так при оптимизации интерфейса большой системы был проведен анализ одного из
диалогов запроса данных. В общей сложности, в этом окне было 15 полей ввода и 6 чекбоксов.
Как показал анализ интервью пользователей, в работе постоянно нужны только два поля ввода
и два чекбокса, ещё одно поле ввода нужно изредка. Таким образом, экран содержал пятнадцать
ненужных элементов управления, при этом основные элементы даже не были расположены в
первых рядах, на них не позиционировался курсор, они никак не были выделены. Более того,
большинство пользователей не могло ответить на вопрос, что означают некоторые из
имеющихся полей.
Примера перегруженного интерфейса программа для агентств недвижимости Flat.
Разработчикам следовало бы разбить это окно как минимум на два. В первом разместить
параметры, которые в первую очередь влияют на выбор квартиры. Вторую сделать как окно с
дополнительными (второстепенными) параметрами, которые можно просмотреть в том
случае если жилье заинтересовало и необходимо сделать выбор между несколькими
вариантами.
Также примером перегруженного интерфейса можно назвать интерфейс 1С.Ни в одной
другой программе вы не найдете такого количества интерфейсных элементов как в 1С
Предприятие. Опрос пользователей этой программы выявил следующие факты:
1.
Считают программу сложной абсолютно все.
2.
Никто из опрошенных не получает никакого удовольствия от работы с этой
программой. Опять же из-за ее сложного интерфейса.
3.
Большая часть пользуется "необходимым минимуму" и даже не пытается
расширять свои знания, считая изучение программы без помощи посторонних практически
невозможным делом
4.
Многие считают что выполнили бы работу быстрее без программы.
Выводы
Проектируя систему, прежде всего, необходимо приводить структуру пользовательского
интерфейса в соответствие со структурой реальной деятельности пользователей.
Спроектированную систему необходимо тестировать, тогда будет точно ясно какая информация
первостепенна для пользователей, а какую можно скрыть. Если от большого количества
интерфейсных элементов никуда не уйти, необходимо группировать их, причем исходя их
логики пользователя, которые будут пользоваться этим ПП. Часто используемые элементы и
функции необходимо помещать на самые видные места, помещая на них фокус ввода или
каким-нибудь образом отделяя их от второстепенных функций.
Терминология не адекватна знаниям пользователя о системе
Так как программы пишут программисты, они часто забывают, что пользоваться ими
будут обычные люди, которые не знакомы с их терминологией. Большинство людей в
действительности толком не представляют себе что такое, например "база данных" или понятие
"записи". Файлы и манипуляции с ними тоже сложны для пользователей.
Такая терминология пугает пользователей, в результате чего снижается эффективность их
работы. Практически всегда в подобных случаях можно назвать вещи более понятными
именами. Программа должна говорить с пользователями на их языке.
Прежде всего, это касается ПО для интернета, антивирусных и мультимедиа программ.
Аудитория пользователей этих программ чрезвычайно широка, причем основную массу
составляют как раз неопытные пользователи.
Окно популярной почтовой программы Bat.Для того чтобы начать получать/отправлять
почту пользователю необходимо пройти через обязательную процедуру определения
параметров получения и отправки почты. Начинающие пользователи в массе свое прибегают
в этом случае к помощи более опытных знакомых ("спецов"). Хотя процедура не казалось бы
такой сложной, если бы не профессиональная терминология, использованная при обозначении
параметров. Прежде всего трудности возникают с серверами. Во-первых, большинство
39
пользователей вообще смутно представляют себе что такое сервер, не говоря уже о том что
они просто не знают что такое POP и SMTP. Все было бы проще, если бы поля ввода просто
обозначались бы как "Адрес". В купе с помощью размещенной на самих почтовых серверах, это
помогало бы пользователю заполнять эти поля "ритуально", без построения ментальной
модели. Во-вторых, параметр Connection (не говоря уже о том, что он почему-то написан поанглийски), можно убрать во вкладку "Дополнительные параметры", в которую должна быть
переименована вкладка "Аутентификация" (еще один не понятный термин). Туда же
необходимо поместить и значения портов. Как грамотно организовать вкладку
"Дополнительные параметры" это уже отдельный разговор. Тем более, можно
предположить, что уже в ней будут залезать, только "продвинутые" пользователи.
Выводы
Еще на начальной стадии проектирования системы необходимо составлять глоссарий
используемых в системе терминов. Этот глоссарий должен отдаваться на рассмотрение
потенциальным пользователям, которые должны указать, какие термины им непонятны и
должны быть исправлены. После тестирования глоссария, необходимо тестировать саму
систему на предмет понятности терминов в контексте программы.
От пользователя постоянно требуется дополнительная информация
Нормой в отечественных программах является создание ситуаций, в которых
пользователь должен ввести информацию, которую может ввести за него программа. Также
повсеместно распространена практика, когда пользователь должен вводить информацию
которую он уже когда-то вводил.
Зачастую вопросы, которые задает система, могут просто поставить пользователя в тупик
и надолго заморозить его работу, из-за того, что пользователь просто не обладает той
информацией, что запрашивает система, либо чтобы найти эту информацию нужно время
Это сообщение возникает при удалении справочника в программе АРМ Секретарь. Мало
того, что программа пугает пользователя непонятными для него терминами (база данных),
она еще и спрашивает у него самого, что ей с этим делать.
Подобное окно появляется в переводчике Promt при попытке открыть файл с целью
перевести его. В нем предлагается выбрать формат открываемого файла. Совершенно не
понятно, почему программ сама не может определить формат открываемого файла,
перекладывая эту задачу на пользователя, тем самым, провоцируя к созданию ошибочной
ситуации.
Такой тирадой сообщений засыпает пользователя программа 1С. Ни о какой
комфортной работе при таком количестве сообщений не может быть и речи.
Выводы
Прежде всего, необходимо так проектировать систему, чтобы она, основываясь на
информации, которая у нее уже есть, принимала решение сама. Если система не обладает 100%
достоверной информацией, она должна принимать решения, основываясь на самом
высоковероятном, либо сразу предоставлять пользователю выбор из наиболее вероятных
действий.
Программа не готова к немедленной работе и требуют настройки
Это проблема особенно характерно для бухгалтерских программ. Зачастую оказывается,
что покупка собственно софта и установка его на рабочие места - лишь малая часть всех затрат
по работам, связанным с автоматизацией бухгалтерского учёта, это всего лишь вершина
айсберга. Оказывается, в придачу к коробке с программой фирме ещё надо покупать
специально обученного программиста. Многие пользователи не подозревают об этом,
приобретая и устанавливая ПО.
Недостатки использования такого решения следующие:
 Фирма-разработчик перенесла часть своих затрат на приведение своего продукта в
готовый вид на своих клиентов. Теперь они несут дополнительные, и часто значительные
затраты на начальную настройку и сопровождение с помощью дополнительных людских
ресурсов - "настройщиков".
40
 Вследствие практически полной настраиваемости внешнего вида программы, конечный
интерфейс для пользователя очень сильно зависит от тех самых "настройщиков", которые уж
точно не являются специалистами по интерфейсам. Таким образом, пользовательский
интерфейс, который должен быть спроектирован специалистами, "настраивается и
конфигурируется" пользователями или "настройщиками". В результате неадекватно
"настроенного" интерфейса страдают как сами пользователи, так и эффективность их работы.
Выводы
Вероятнее всего, решение этой проблемы лежит где-то в области разработки более
конкретных настроек. Например такую программу как 1С:Предприятие можно спроектировать
для специфических организаций ("Завод", "Школа", "Магазин", "Торговая фирма" и т.д), что
сведет настройки к минимуму. Что касается интерфейса, то здесь следует, по крайней мере,
постоянно работать над качеством в готовых настройках, дабы конечные "настройщики"
использовали его в качестве образца. Высшим пилотажем было бы задание типовых
интерфейсных стилей или шаблонов
Программа имеет многодокументный интерфейс
Практически все отечественные ПП, в которых обрабатываются какие-нибудь текстовые
или табличные данные, используют многодокументный (MDI) интерфейс: много документов одно окно, в то время как в мире уже признали его неэффективность и возвращаются к
однодокументному интерфейсу (SDI): один документ - одно окно.
Сам по себе этот стиль интерфейса может оказаться полезным только в исключительных
случаях, так как он по своей природе заставляет пользователя манипулировать окнами, вместо
того, чтобы позволять ему делать свое дело. Пользователю приходится ворочать массу
бессистемно открытых и неупорядоченных окон, что явно скажется на эффективности его
работы не в лучшую сторону. Такой бессистемный подход может запросто привести к
ситуации, когда очередное открытое окно будет просто "потеряно" или надолго оставлено без
внимания в мешанине открытых окон.
Выводы
Для программ, которые работают с разными типами документов решение этой проблемы разработка набора так называемых рабочих областей (workspaces), то есть экранов, в каждом из
которых сосредоточены необходимые функции для решения той или иной задачи пользователя
(простейший пример такого приложения - Outlook Express). Для этого необходим тщательный
анализ деятельности пользователей программы, включения всего комплекса эргономических
работ в процесс проектирования ПО.
Отсутствует единый стиль
Целостность - одно из важных свойств интерфейса. Целостность облегчает обучение
новых пользователей и повышает производительность опытных.
Например, регулярное расположение кнопок (и других элементов интерфейса)
оправдывает ожидания пользователя - ему не приходится тратить усилия на поиск и
распознавание кнопок. Кроме того, существуют правила оптимизации перемещений курсора
мыши, которым рекомендуется следовать при размещении элементов управления
пользовательского интерфейса.
Явный пример отсутствия целостности
Примеры управляющих кнопок, собранные со всей программы. Много говорить здесь не
надо - о какой целостности интерфейса может вообще идти речь?
Выводы
Необходимо соблюдать хотя бы элементарные требования к целостности: кнопки в
диалоговых окнах должны располагаться на одном и том же месте в одном и том же порядке,
подписи к полям должны быть сделаны одним шрифтом, одна и та же функция встречающаяся
в разных местах программы должна называться одинаково и т.д.
Программа перегружена окнами сообщений
Привычка при каждой неоднозначной ситуации выводить на экран диалоговое окно,
наверное, еще долго будет влиять на создание интерфейсов отечественного ПО. В некоторых
программах при закрытии окна документа пользователь может увидеть до 4-х сообщений, на
каждое из которых ему придется ответить.
41
В программе Зарплата 2000 встречается пример неудачного использования диалоговых
окон. Для расчета зарплаты запись о работнике нужно добавлять в расчетную ведомость.
Если же запись об этом работнике уже есть, программа выдает 2 (!) сообщение подряд. Мало
того что сообщение здесь излишне - программу можно реализовать так, что ситуация с
внесением работника повторно может никогда не произойти, так еще оно разбито на два. А
если у вас 100 сотрудников и пользователь нажмет кнопку Добавить всех (которая, кстати,
присутствует в этой программе)? В результате ему придется 200 раз нажимать на кнопку
Ok! Будете ли он делать это? Скорее всего просто закроет эту программу.
Пример бесполезного сообщения, которое появляется при некорректном открытия
файла. Система сама предоставляет пользователю выбрать формат и сама же удивляется,
если пользователь допускает ошибку. Тем более что вне зависимости от того, какую из
кнопок нажмет пользователь, программа не производит никаких действий.
Еще одно бесполезное сообщение. Вместо того чтобы предложить пользователю
варианты решения проблемы или самой догадаться о способе решения, система
ограничивается бесполезным, а зачастую просто раздражающим сообщением.
Выводы
Прежде всего, систему необходимо проектировать таким образом, чтобы в ней
отсутствовали такие ситуации, в которых пользователь может совершить какую-нибудь
ошибку. Например, для ввода данным можно использовать интерфейсные элементы с жестко
заданным диапазоном значений. Следующее что можно сделать это считать всю информацию,
которую пользователь вводит в программу, верной по определению. Все сообщения должны
быть протестированы на предмет их целесообразности. Большинство из сообщений о
завершении какой-либо операции или сообщении о изменении состояния могут быть
безболезненно убраны, остальные преобразованы в другие формы подачи сообщения: пузыри,
индикаторы, подсветка и т.д.
Интерфейс отражает внутреннюю структуру реализации и мышление
программистов
Зачастую разработчики, в особенности небольшие компании, в которых экономят на
таких специалистов как юзабилити-эксперт (а в российских фирмах на них экономят всегда),
совершенно не задумываются, что пользоваться программой будут люди не знакомые с ее
внутренней структурой. Как следствие с конвейера выходят программы совершенно неудобные
в использовании, в структуру которых необходимо долго вникать
Программирование - очень сильно ориентированный на функции процесс, поэтому
пользовательский интерфейс часто создается подобным образом. Например, некоторые
разработчики считают, что каждую функцию нужно помещать в отдельное диалоговое окно.
Для достижения множества целей пользователю необходима целая серия функций. Если в
программе используется одно окно для одной функции, экран быстро становится визуально
загроможденным.
Опуская тот момент, что меню здесь жутко загромождено во-первых разделителями, а
во-вторых - пунктами меню - разделителями (помеченными "======"), следует обратить
внимание на структуру программы. Она построена в соответствии со структурой
организации, а не в соответствии с порядком использования информации.
Такой элемент управления используется в основном в приложениях, работающих с
базами данных, и служит для перемещения по записям. Во-первых, этот элемент понятен
только программистам. Большинство пользователей не имеют никакого представления о базе
данных, таблице (в понимании таблицы с данными) и записях в таблице. Они не знают, что
можно "двигаться по записям", и что есть конец и начало записей. Это терминология
программиста. Во-вторых, такой элемент управления заставляет пользователя "блуждать в
темноте" - в большинстве программ, где он используется, на экране видна одновременно
только вся информация об одной "записи", и никакой информации, что стоит за ней, а что
перед ней. Более того, люди редко просматривают информацию в такой последовательности
вообще (а в данном случае порядок представления информации еще и задается положением
записей в таблице ). Чаще всего люди выбирают информацию из списка на экране по какомуто одному критерию (например, фамилия). Предоставление всей информации, которая есть
42
для ориентации бесполезно - пользователь только теряется. И, наконец, элемент навязывает
пользователю, что данные расположены как-то горизонтально, хотя физически у них нет
направления.
Выводы
Интерфейс программы необходимо разрабатывать еще на стадии проектирования всего
ПП. Важно смоделировать пользовательские роли и сценарии и затем по ним тестировать
спроектированный интерфейс. Это поможет избежать глобальных проблем структуры
программы.
Взаимное размещение объектов на экране не совпадает с их логической связью и/или
с их важностью
К сожалению, нормой является ситуация, при которой наиболее важные объекты (и,
соответственно, наиболее важные действия) либо заслоняются от пользователя менее важными,
либо находятся там, где пользователь не ожидает их найти. Например, типичный случай, когда
программа, выполняющая только одну функцию, при этом вызвать эту функцию можно только
из меню или с помощью пиктограммы на панели инструментов (при этом нужная пиктограмма
не снабжена подписью и теряется на фоне других пиктограмм панели). Если бы кнопка для
вызова этой функции была размещена ближе к центру окна программы, была сразу заметна и
снабжена однозначной подписью, простота вызова функции увеличилась бы на порядок
Программа должна активно помогать организовывать эффективную работу пользователя.
В большинстве случаев программа сама может вычислить объём работ и приоритетность
выполнения заданий пользователем, и предложить список работ пользователю в виде меню,
списка актуальных задач (task framework), требующих пользовательского труда.
Меню и панель инструментов переводчика PROMT. Упуская вопросы количества и
понятности пиктограмм, следует отметить, что кнопка основной функции программы перевода - никаким образом не доминирует над всем этим многообразием элементов
управления.
Меню и панель инструментов программы распознавания текста FineReader. Не говоря
уже о том, что количество пиктограмм на порядок меньше, а понятность их на порядок
выше, триада основных функций программы - отсканировать, распознать, проверить - сразу
бросается в глаза. Кнопки расположены именно там где пользователь и ожидает их найти. А
расположение и обозначение кнопок в виде неделимой последовательности действий,
сокращает время обучения практически до 0. Отличный интерфейс.
Еще один характерный пример. Цель этой программы одна - проигрывать видео. Так
почему же кнопка Play одного размера и цвета с, к примеру, настройками видео. Первое, что
видит пользователь открыв программу - полтора десятка невыразительных кнопок, а должен
видеть только две - открыть и проиграть.
Выводы
В дизайне интерфейсов, как и в любом дизайне, необходимо уделять внимание
"расстановке акцентов". Пользователь должен загружать программу и сразу понимать, что ему
нужно сделать в первую очередь. Существует множество способов достижения этой цели и как
правило хороший эффект достигается от применения всего комплекса мер по улучшения
понятности интерфейса. Это и группировка элементов методом карточной сортировки, и
умеренность в пиктограммах, и качество их прорисовки, и построение структуры программы в
соответствии с представлениями пользователя, и многое-многое другое.
Для правильного построения пользовательского интерфейса, отражающего адекватный
алгоритм деятельности пользователя, необходимы usability-исследования с привлечением
конечных пользователей и экспертов. Такие сложные работы обычно принято проводить
параллельно процессу проектирования ПО, начиная с ранних стадий проектирования.
Пиктограммы используются некорректно
Несколько непонятный заголовок этого раздела объясняется тем, что проблем у
пиктограмм много и проблемы совершенно противоположны друг другу. В одних случаях
применяются излишне детализованные пиктограммы, в других случаях сюжет настолько прост,
что может обозначать что угодно. В одних случаях пиктограмм слишком много, в других
слишком мало.
43
Вообще, если обобщить, то анализируя российское программное обеспечение (да и не
российское тоже) создается впечатление, что используют пиктограммы только с одной целью:
"чтоб красивее было". Тем не менее грамотное и самое главное умеренное использование
пиктограмм, продуманность из сюжета может положительно сказаться на таких критериях как:
высокая
скорость
обучения
пользователя,
субъективная
удовлетворенность
и
производительность.
Пример избыточной детализации пиктограмм. Например, зачем нужен зеленый значок на
папке с документами? Или к чему рисовать содержимое корзины, когда метафора самой
корзины и так легко узнаваема?
Пример пиктограмм выдержанных в единой стилистике. Во второй строчке
оригинальные пиктограммы программы, в первой строчке стандартные Windows
пиктограммы (открыть, сохранить, поместить в буфер и т.д.), адаптированные под
стилистику программы. Плюсы - хорошо для брэндинга, минусы - уменьшается скорость
распознавания - уж слишком пиктограммы похожи друг на друга.
Для запуска проверки на вирусы в Dr.WEB неудачно использована метафора светофора.
Красная она потому, что в данный момент пользователь не выбрал ни один элемент для
сканирования. Но как пользователь догадается, что нужно сделать, чтобы она стала
зеленой? Список доступных дисков для сканирования не подает никакого сигнала о том, что
эти диски можно выбрать. А красный цвет на кнопке "отпугивает" пользователя от ее
нажатия. Некорректное использование метафоры заключается в том, что здесь индикатор
совмещен с элементом управления (кнопкой). Тогда как в реальной жизни светофор сам
меняет свое состояние.
Пример не очень качественных и не очень понятных пиктограмм (пиктограммы не
подбирались, а взяты скопом из одной панели). Одинаковая форма, незначительные различия в
расцветке и полное отсутствие аналогии с предметами реального мира делают задачу
запоминания этих пиктограмм практически невозможным.
Выводы
Рекомендации тут банальны. Прежде всего, пиктограмм не должно быть очень много как
в панели инструментов, так и в меню. Второй момент, сюжет пиктограмм должен быть
простым, легко узнаваем и самое главное однозначно ассоциирован. Чтобы пиктограммы
хорошо смотрелись их лучше делать в одной стилистике, но при этом стараться чтобы они
отличались друг от друга (либо цветом, либо формой элементов, либо еще каким-нибудь
внешними характеристиками).
44