- •153003, Г. Иваново, ул. Рабфаковская, 34
- •Цели и задачи курса
- •Основные понятия
- •История развития интерфейсов
- •Первое поколение
- •Второе поколение
- •Третье поколение
- •Недостатки wimp-интерфейсов
- •Четвертое поколение
- •Классификация интерфейсов
- •Разработка пользовательского интерфейса
- •Постановка задачи
- •Формализация контекста использования
- •Формализация объективных критериев успеха
- •Определение необходимой функциональности системы
- •Анализ целей
- •Анализ действий пользователей
- •Низкоуровневые и высокоуровневые функции
- •Формализация бизнес-ролей пользователей
- •Формализация функциональности
- •Формализация сценариев действий пользователей
- •Обзор интерфейса конкурирующих систем
- •Формализация привычек и ожиданий пользователей
- •Проектирование интерфейса
- •Проектирование структуры экранов системы
- •Выделение независимых блоков
- •Проектирование навигационной системы
- •Низкоуровневое проектирование
- •Метод наблюдения за пользователем
- •Мыслим вслух
- •Проверка качества восприятия
- •Измерение производительности
- •Карточная сортировка
- •Контрольные списки
- •Эргономика пользовательского интерфейса
- •Критерии эргономичности интерфейса
- •Производительность пользователя
- •Длительность интеллектуальной работы
- •Непосредственное манипулирование
- •Потеря фокуса внимания (прерывание)
- •Ограничение принятия решений
- •Длительность физических действий пользователя
- •Закон Фитса
- •Методы повышения доступности кнопки
- •Уменьшение числа манипуляций
- •Уменьшение необходимости ввода данных
- •Человеческие ошибки
- •Типы ошибок
- •Методы предотвращения ошибок
- •Повышение разборчивости и заметности индикаторов
- •Качество/скорость восприятия элемента
- •Физическая реализация элемента
- •Блокировка потенциально опасных действий до получения подтверждения
- •Автоматический выбор параметров
- •Обучение работе с системой Типы обучающих материалов
- •Среды передачи обучающих материалов
- •Понятность системы
- •Ментальная модель
- •Метафора
- •Аффорданс
- •Стандарт
- •Субъективная удовлетворенность пользователей
- •Эстетика
- •Субъективное восприятие скорости работы
- •Уменьшение вероятности стрессовых ситуаций
- •Сообщение об ошибках
- •Сообщения о завершении операции
- •Библиографический список
- •1.Цели и задачи курса 3
- •5.2.Проектирование интерфейса 19
Анализ действий пользователей
Достижение почти всех целей требует от пользователей совершения определенных действий. Разумеется, эти действия могут различаться при разных способах достижения.
В сложных интерактивных системах сами по себе выбранные стратегии действий влияют на требования к функциональности. Возвращаясь к примеру с тостером, можно указать, что помимо возможности поджаривать хлеб он должен включаться и выключаться, более того, он должен быть устроен таким образом, чтобы его можно было удобно мыть. С другой стороны, возможно, что тостер можно сделать так, чтобы он не требовал мойки, в этом случае функция «возможность мытья» становится лишней. Разумеется, взаимодействие человека с тостером очень просто, здесь можно дойти до всего чисто логическим анализом. В компьютерных же системах взаимодействие обычно сложнее, при этом логический анализ неприемлем. Единственным выходом является наблюдение за людьми, выполняющими свою задачу, пользуясь уже имеющимися инструментами, а именно системами конкурентов (если они есть) и предметами реального мира. Неплохим источником материала для анализа часто служит даже не наблюдение за людьми, а анализ результатов их работы – если оказывается, что результат работы практически не зависит от используемого инструмента, это значит, что нужна только та функциональность, которая оказала воздействие на результат (т.е. функции, которыми никто не воспользовался, не нужны).
Как уже было сказано, обычно есть несколько разных способов реализации одной и той же функции. Анализ действий пользователей как раз и позволяет определить, какой именно способ следует реализовывать.
Поскольку на этом этапе мы узнаём, какая именно функциональность нужна для каждого варианта, можно избрать верный путь по правилу: чем меньше действий требуется от пользователя, тем лучше. Не стоит забывать и про другое правило: чем меньше функций, тем легче их сделать.
Низкоуровневые и высокоуровневые функции
Существует два принципиально разных подхода к определению функциональности системы. При первом подходе система снабжается максимальным количеством функций, при этом результаты многих из них являются суммой результатов других функций. При втором подходе разработчик снабжает систему набором базовых условно-элементарных функций, из которых пользователь может «собрать» более сложные необходимые ему функции.
Оба подхода имеют как недостатки, так и достоинства. Подход, при котором количество функций ограничено, позволяет упрощать интерфейс, но при этом от пользователя требуется понимание, как из многих низкоуровневых функций «собирать» функции более сложные. Подход, при котором помимо низкоуровневых функций есть высокоуровневые, позволяет потенциально обеспечивать большую скорость работы (за счет отсутствия пауз между низкоуровневыми функциями), но зато от пользователя требуются знания о том, где эти высокоуровневые функции найти и как с ними работать, при этом они перегружают интерфейс. Кроме того, остается возможность компромисса: всегда можно включить в систему средства автоматизации, чтобы пользователи получали возможность создавать (и распространять) свои метафункции. Этот подход является оптимальным.