- •Эргономика
- •1. Производительность пользователя
- •1.2. Длительность интеллектуальной работы
- •1.2.1. Непосредственное манипулирование
- •1.2.2. Потеря фокуса внимания (прерывание)
- •1.2.3. Ограничение принятия решений
- •1.2.4. Закон Хика
- •1.3. Длительность физических действий пользователя
- •1.3.1. Закон Фитса
- •1.3.2. Методы повышения доступности кнопки
- •1.3.3. Уменьшение числа манипуляций
- •1.3.4. Уменьшение необходимости ввода данных
- •1.3.5. Память программы
- •1.4. Длительность реакции системы
- •1.4.1. Фоновый режим выполнения задач
- •Типы человеческих ошибок
- •3.1. Ошибки, вызванные недостаточным знанием предметной области.
- •3.2. Опечатки.
- •3.3. Не считывание показаний системы.
- •3.4. Моторные ошибки.
- •Методы предотвращения ошибок
- •4.3.Повышение разборчивости и заметности индикаторов
- •4.3.1. Качество/скорость восприятия элемента
- •Ошибочно выбранный визуальный сюжет элемента.
- •4.3.1.2. Нестандартно выбранный сюжет элемента или реализация сюжета.
- •4.3.1.3. Избыточная детализация сюжета.
- •4.3.2.Физическая реализация элемента
- •4.4. Блокировка потенциально опасных действий до получения подтверждения
- •4.4.1. Блокируйте системные файлы.
- •4.4.2. Не делайте опасные для пользователя кнопки кнопками по умолчанию.
- •4.5. Проверка действий пользователя перед их принятием
- •4.6. Самостоятельный выбор параметров
- •Обучение работе с системой
- •5.1. Почему пользователи учатся
- •5.2. Средства обучения
- •5.2.1. Понятность системы
- •5.2.1.1. Ментальная модель
- •5.2.1.2. Метафора
- •5.2.1.3. Идеома
- •5.2.1.4. Аффорданс
- •5.2.1.5. Стандарт
- •5.2.2. Обучающие материалы
- •5.2.2.1.Типы обучающих материалов
- •5.2.2.2. Среды передачи обучающих материалов
- •5.2.2.3. Спиральность
- •Субъективная удовлетворенность
- •5.1. Эстетика
- •5.2. Субъективное восприятие скорости работы
- •5.3. Приемы для уменьшения субъективного восприятия
- •5.4. Уменьшение вероятности стрессовых ситуаций
- •5.5. Пароли
- •5.6. Сообщение об ошибках
- •5.7. Как избежать сообщений об ошибках
- •5.7.2. Каким должно быть сообщение об ошибке
- •5.7.3. Пузырь как альтернатива сообщениям об ошибке
- •5.7.4. Сообщения о завершении операции
- •5.7.4.1. Необходимо предлагать пользователю обратную связь, не прерывая его.
- •5.7.4.2. Используйте само-срабатывающие диалоги.
- •6.1. Программа перегружена элементами управления
- •6.2. Терминология не адекватна знаниям пользователя о системе
- •6.3. От пользователя постоянно требуется дополнительная информация
- •6.4. Программа не готова к немедленной работе и требуют настройки
- •6.5. Программа имеет многодокументный интерфейс
- •6.6. Отсутствует единый стиль
- •6.7. Программа перегружена окнами сообщений
- •6.8. Интерфейс отражает внутреннюю структуру реализации и мышление программистов
- •6.9. Взаимное размещение объектов на экране не совпадает с их логической связью и/или с их важностью
- •6.10. Пиктограммы используются некорректно
- •Заголовки
- •Дизайн окна
- •Командные кнопки
- •Порядок табуляции фокуса ввода
- •Пиктограммы
- •Взаимодействие с пользователем
5.7.4. Сообщения о завершении операции
Сообщения о завершении операции сходны с сообщениями об ошибках. Они точно также могут вызывать раздражение пользователя, снижать его субъективное удовлетворение от системы и отвлекать от выполнения основной задачи. Тем не менее в отличии от сообщений об ошибках в сообщениях о завершении операции есть необходимость и полностью избавиться от них невозможно. Таким образом, нужно попытаться сделать их как можно менее навязчивыми и «вежливыми». Разрабатывая очередную программу, необходимо учитывать следующие принципы:
5.7.4.1. Необходимо предлагать пользователю обратную связь, не прерывая его.
Например,
представим, что был произведен поиск
по запросу пользователя и теперь должно
появится сообщение о результате.
Представим, что этот поиск необходим
для заполнения одного из полей на форме
пользователя, как, например, адрес
человека, кому он должны послать ее,
полученный из адресной книги. Вместо
того, чтобы трубить об успешном результате,
необходимо просто заполнить это поле.
Если требуется дальнейшая обратная
связь, необходимо сделать желтую иконку,
мигающую во время поиска. В случае
успешного результата необходимо сменить
цвет на зеленый, в случае неудачи - на
красный. Если форма достаточно большая,
пользователь может в это время находиться
в другом разделе, поэтому нужно поместить
где-нибудь индикатор состояния для всей
формы. Индикатор статуса в форме иконки
может обозначать следующее: "где-то
на этой форме поле помечено красным.
Нажмите, чтобы найти его". Когда
пользователь закончит заполнять форму
и увидит зеленый индикатор, он поймет,
что можно идти дальше.
Рис.
5.10-1 Пример самого бесцеремонного
прерывания пользователя.
Когда
пользователь находится в другом
приложении, поверх приложения выскакивает
не только окошко о завершении операции
форматирования, но и само окошко
форматирования. Почему не сообщить о
завершении операции путем мигания
кнопки в панели задач?
5.7.4.2. Используйте само-срабатывающие диалоги.
Например, диалоги печати спрашивают пользователя, сколько копий ему нужно, и т.д. Затем они сидят на экране в течении следующих трех дней в ожидании ответа. Пользователь ушел на обед, забыв, что должен появиться этот глупый диалог, и ждет что к его приходу 500-страничный документ будет напечатан. В программе ни к коем случае не должно возникать таких ситуаций. В данном случае программа должна догадаться, что если пользователь послал на печать, значит ему нужна как минимум одна копия. Поэтому, когда пройдет пара минут, необходимо начать печать. Даже если получится так, что пользователю нужны две копии, он всегда может отпечатать еще одну, или даже сделать копию на копировальном аппарате. В любом случае, время не будет потеряно. Если говорить о перспективах, то уже сейчас есть технологии отслеживающие направление взгляда. Эти технологии можно применять и в случае с сообщениями. Увидев что пользователь прочитал сообщение, в течении нескольких секунд система должна сама закрывать окно. Необходимо думать о сообщениях, как о советах ценного помощника. Делать их вежливыми, полезными и прерывающими пользователя, только если это необходимо.
Типичные интерфейсные ошибки отечественного ПО
Серьёзная эргономическая экспертиза программного продукта (usability testing) - дело нетривиальное и дорогое, проводится по специальным методикам и позволяет получить как качественные, так и количественные оценки эргономичности как программного продукта в целом, так и таких его важных компонент, как пользовательский интерфейс и пользовательская документация. Не имея такой возможности - проводить серьёзное исследование, я попытаюсь лишь предоставить примеры эргономических проблем, возникающих при производстве программных продуктов. Таким образом, предлагаемый обзор является довольно поверхностным, так как используется эвристический метод оценки пользовательского интерфейса и эргономичности программ. Итак, проблемы, как правило, бывают трёх типов:
Глобальные эргономические противоречия
Неадекватное применение интерфейсной парадигмы
Ошибки проектирования элементов пользовательского интерфейса (как целых форм, так и аспектов применения конкретных элементов управления).
Оказывается, что практически в любом мало-мальски сложном отечественном программном продукте эргономические проблемы всех трёх типов присутствуют в изобилии. Разберем их подробнее.
Программа перегружена элементами управления
Терминология не адекватна знаниям пользователя о системе
От пользователя постоянно требуется дополнительная информация
Программа не готова к немедленной работе и требуют настройки
Программа имеет многодокументный интерфейс
Отсутствует единый стиль
Программа перегружена окнами сообщений
Интерфейс отражает внутреннюю структуру реализации и мышление программистов
Взаимное размещение объектов на экране не совпадает с их логической связью и/или с их важностью
Пиктограммы используются некорректно
