Проектирование пользовательского интерфейса
Проектирование пользовательского интерфейса – прежде всего разработка удобных и понятных в использовании средств общения с компьютером. То есть лингвистически и эргономически обоснованных средств представления информации, продуцируемой компьютером и перевод того, что хочет сообщить пользователь, к виду, адекватно воспринимаемому средствами автоматизации. Автоматизации той деятельности, которая является для пользователя профессиональной. В этом смысле проектировщик АС и программист являются теми специалистами, которые должны разработать адекватную среду общения. И заглавное здесь требование – перейти на точку профессионального зрения и профессиональных представлений пользователя. Совершенное не приемлема точка зрения на пользователя, как «объект, наследующий установки, навыки, знания и понимание проблем программистом».
Общие принципы проектирования пользовательского интерфейса
Параметры пользовательского интерфейса определяются одними из первых при проектировании системы. Простота, интуитивность, удобство и понятность интерфейса определяют для пользователя системы полноту и эффективность использования ее функциональности. В идеале необходим интерфейс, учитывающий характеристики конкретного пользователя – его опыт, квалификацию, индивидуальные качества. Например, малоопытный пользователь предпочитает вести диалог на ограниченном естественном языке.
Понятие «дружественности» - это не одномерная величина, а вектор, содержащий согласно международной классификации семь компонент:
соответствие задачам, решаемым пользователем;
легкость применения;
управляемость;
соответствие ожиданиям пользователя;
устойчивость к ошибкам;
адаптируемость/индивидуализируемость;
легкость изучения.
Пользовательский интерфейс базируется на информационной модели деятельности и отрабатывается на прототипе системы. Основным является требование естественности интерфейса и его соответствие модели деятельности пользователя системы. Пользовательский интерфейс должен удовлетворять следующим принципам:
1. Необходимо максимально учитывать терминологию предметной области пользователя, стереотипные действия пользователя в его профессиональной деятельности, стандартные схемы принятия решений.
2. При работе с новой системой должен максимально использоваться опыт работы со сходными системами. Сходные процедуры должны требовать идентичных действий пользователя на всех этапах работы. Например, назначение функциональных клавиш не должно меняться от задачи к задаче, от экрана к экрану, или от одного пункта меню к другому. Например, известно, что непостоянство в пространственном положении пунктов меню увеличивает время поиска на 73%. Также этот принцип называют принципом согласованности интерфейса, о чем речь пойдет далее.
3. При рассмотрении пользователем одновременно нескольких вариантов действий (информационных единиц деятельности) следует учитывать ограничения кратковременной памяти человека - 7±2 ИЕД. Число элементов, удерживаемых в кратковременной памяти, зависит от их сложности, последовательности предъявления (ассоциативные связи), интервала времени после предъявления, интенсивности других мыслительных процессов и задействованности других перцептивных каналов.
4. Структурирование диалога должно быть основано на потребности пользователя представлять его структурный вид, положение на схеме диалога и возможности навигации по дереву диалога. В рамках этой потребности реализуется необходимый уровень понимания системы пользователем, его необходимые решения и действия. Очень важно предлагать пользователю карту структуры диалога и его место в ней в данный момент.
5. Обратная связь о ходе диалога должна предусматривать сообщения пользователю о качестве его действий, состоянии системы и необходимых для достижения результатов шагов. Для этого используются подсказки и упрощение операций устранения ошибок. Для ряда пользователей сообщение об ошибках необходимо удерживать до конца ввода информации.
6. Необходимо оптимизировать информационную нагрузку на пользователя путем регуляции объема и темпа представляемых пользователю сообщений. Вредна как перегрузка пользовательских каналов, так и недогрузка. Для оптимизации нагрузки действия пользователя отрабатываются на прототипе (макете) системы. Элементы информации необходимо так организовать на экране дисплея, чтобы минимизировать число сканирующих движений глаза при осмотре экрана. Последовательность предъявлений информации и ее структуризация должны соответствовать модели деятельности пользователя.
7. Необходимо диалог адаптировать к особенностям модели деятельности пользователя. Для этого необходимо планировать несколько вариантов диалога – на выбор пользователя.
Принято различать два вида интерфейса: гибкий и адаптивный. Адаптивный автоматически определяет компетентность и информационные потребности пользователя и подстраивает под него тип диалога. Структура интерфейса должна быть выведена из естественных особенностей выполнения задачи пользователем.
При полной адаптации диалоговая система стремится построить модель пользователя, которая изменяется по мере работы пользователя с системой и определяет стиль диалога, адаптируя его в зависимости от этих изменений.
Гибкий диалог (косметическая адаптация) обеспечивает гибкость диалоговых стилей без учета поведения пользователя и без однозначного выбора им конкретного стиля диалога. Это достигается в первую очередь путем применения сокращенных команд (акселераторов).
14.3.1. Виды диалога
При проектировании пользовательского интерфейса применяют следующие виды диалога:
- 1. вопрос-ответный диалог, в котором пользователь отвечает на вопросы системы. Предназначен для неподготовленного пользователя и наиболее свободен от ошибок.
- 2. диалог, основанный на заполнении шаблонов
- 3. диалог, основанный на выборе из меню, где система предъявляет список альтернатив и пользователь выбирает одну из них
- 4. диалог, основанный на применении команд, при котором пользователь вводит команду с использованием мнемоники и аббревиатур. Используется для системных проектировщиков и программистов
- 5. диалог на основе вопросного языка (языка запросов) – пользователь задает вопросы БД системы
- 6. диалог на естественном языке
- 7. диалог, использующий командный язык, реализованный на базе функциональной клавиатуры
- 8. диалог с использованием интерактивной графики.
14.3.2. Проектирование дисплейных форматов
В ходе проектирования диалога особое внимание следует уделять проектированию дисплейных форматов. Предъявляемая пользователю информация должна быть понятной, логически связной, распределенной по группам в зависимости от содержания и функционального назначения.
Информация, на которую следует немедленно обратить внимание, должна всегда отображаться в видном месте, чтобы захватить внимание пользователя (например, последние новости и объявления, контактная информация);
Информация, которая необходима не очень часто (например, схема проезда) не должна отображаться, но должна быть доступна, когда потребуется. Например, иконка «Контакты» или соответствующая опция меню должна быть доступна на каждом экране;
Менее срочная или менее необходимая информация не должна все время находится перед пользователем, но должна быть доступна, когда понадобится;
Отчеты и ссылки должны быть сгруппированы;
Логическая последовательность сообщений должна соответствовать структуре деятельности пользователя, последовательности решаемых им подзадач и особенностям информационного поиска;
Необходимо группировать близкие по смыслу единицы информации;
Предъявляемую пользователю на экране информацию необходимо структурировать по кадрам;
На экране должна предъявляться только та информация, которая имеет отношение к выполняемым в данный момент действиям пользователя;
Форматы представления информации на экране должны быть максимально просты;
Следует избегать избыточного кодирования и неоправданных сокращений;
Не следует использовать краевые зоны экрана для предъявления значимой информации;
Специальные эффекты: мелькание, повышенная яркость, инверсия и т.п. – следует применять только в крайней необходимости;
Основная текстовая информация не должна полностью заполнять экран – на экране должна находиться информация, обрабатываемая в данный момент;
Для вывода вспомогательной информации должны быть выделены четко идентифицируемые зоны на экране – зона подсказок, зона комментариев, зона управляющих сообщений, зона сообщений об ошибках. Рекомендуется вопрос-ответные сообщения и подсказки помещать в верхней части экрана, выделяя явным образом отведенную для этого зону (например, отделить горизонтальной линией). Следует отделять друг от друга в зоне вспомогательной информации различные виды информации. Для подсказок можно применять инверсное изображение.
При создании текстовых диалогов и отображений необходимо руководствоваться следующим:
Текст в нижнем регистре читается приблизительно на 13% быстрее чем текст, который напечатан полностью в верхнем регистре;
Символы верхнего регистра наиболее эффективны для информации, которая должна привлечь внимание. Не используйте верхний регистр, если вы не хотите выделять какую-либо информацию;
Равномерно распределенный текст с выровненным правым полем легче читать, чем выровненный по левому краю текст;
Оптимальный интервал между строками равен или немного больше, чем высота символов;
Использование цвета при проектировании пользовательского интерфейса
При организации многооконного вывода следует:
минимизировать количество цветов, одновременно используемых на экране
цвет переднего плана и цвет фона должны сочетаться между собой и с цветом символов на экране
не рекомендуется использовать яркие цвета для границ окон и для заглавий
окна следует разделять между собой цветом фона
при кодировании окон следует разделять три функции цвета: выделение, задний план, нормальное чтение
Кроме того, следует учитывать при цветовом кодировании, что:
необходимо ограничить число цветов до 4 на экране и до 7 для приложения в целом; для неактивных элементов нужно использовать бледные цвета;
если цвет используется для кодировки информации, необходимо удостовериться, что пользователь правильно понимает код, например, актуальная информация выделяются красным цветом, а устаревшая – зеленым;
необходимо использовать цвета согласно представлениям пользователя, например, для картографа зеленый - лес, желтый - пустыня, синий - вода. Для химика, красный - горячий, синий – холодный ;
для отображения состояния: красный означает опасность/стоп, зеленый - нормально/продолжение работы, желтый - предостережение;
для привлечения внимания наиболее эффективны белый, желтый и красный цвета;
для упорядочения данных можно использовать спектр 7 цветов (радуга);
для разделения данных необходимо выбрать цвета из различных частей спектра (красный / зеленый, синий / желтый, любой цвет / белый);
для группировки данных, объединения и подобия нужно использовать цвета, которые являются соседями в спектре (оранжевые / желтые, синие / фиолетовые);
в окнах равного формата информацию в приоритетном окне следует помещать на фоне другого цвета – если число окон больше двух. В однородном текстовом поле можно выделять значимые элементы информации рамкой, цветом или инверсией. Следует избегать выделения информации миганием за исключением случаев краткого срочного сообщения
следует избегать появления управляющих окон в информационном поле. В этом случае рекомендуется разделить экран на зоны.
наложение окон должно быть организовано на окнах одного формата со сдвигом, так чтобы визуально свободной и доступной была верхняя часть окна с ключевой строкой. Следует избегать наложения окон разного формата и одновременного появления разнородных неупорядоченно расположенных на экране окон.
Учет ошибок пользователя
Очень важным является учет возможных ошибок пользователя, которые могут вызываться:
1. перегрузкой пользовательского канала – слишком много сообщений одновременно;
2. пользовательской скукой;
3. недостатком мотивации (отсутствие интереса);
4. неадекватными инструкциями для поведения в непредвиденных ситуациях.
При разработке процедур обнаружения и диагностики ошибок следует:
1. избегать зашифрованных сообщений об ошибках;
2. диагностика ошибок должна быть максимально ясной;
3. сообщения об ошибках должны быть заранее специфицированы и четко определены;
4. следует избегать повторного ввода после исправления ошибки верно введенных ранее данных;
5. следует предусмотреть вариантность в обеспечении пользователя нужной информацией для исправления ошибки;
5.1. опытным пользователям лишь указать на наличие ошибки;
5.2. массовому пользователю необходимо подробно объяснить характер ошибки и пути ее исправления.
Время ответа системы
При разработке пользовательского интерфейса большое значение имеет обоснованный выбор времени ответа системы на различные запросы пользователей. При этом:
- надо стремиться к постоянству времени реакции системы на однотипные запросы пользователей
- учитывать, что время реакции человека в среднем составляет 2 сек.
Некоторые характерные времена реакции системы:
- ввод с клавиатуры – не более 0.1 – 0.2 сек
- инициализация системы - не более 3 сек
- вставка символов - не более 2 сек
- выполнение простых запросов - не более 2 сек
- выполнение сложного запроса - не более 5 сек
- листание страницы - не более 1 сек
- выбор функции - не более 2 сек
Манипулирование простой графикой - не более 2 сек
Жизненный цикл разработки пользовательского интерфейса
Процесс разработки пользовательского интерфейса (ПИ) разбивается на этапы жизненного цикла:
Анализ трудовой деятельности пользователя, объединение бизнес-функций в роли.
Построение пользовательской модели данных, привязка объектов к ролям и формирование рабочих мест.
Формулировка требований к работе пользователя и выбор показателей оценки пользовательского интерфейса.
Разработка обобщенного сценария взаимодействия пользователя с программным модулем (функциональной модели) и его предварительная оценка пользователями и Заказчиком.
Корректировка и детализация сценария взаимодействия, выбор и дополнение стандарта (руководства) для построения прототипа.
Разработка макетов и прототипов ПИ и их оценка в деловой игре, выбор окончательного варианта.
Имплементация ПИ в коде, создание тестовой версии.
Разработка средств поддержки пользователя (пользовательские словари, подсказки, сообщения, помощь и пр.) и их встраивание в программный код.
Usability - тестирование тестовой версии ПИ по набору ранее определенных показателей.
Подготовка пользовательской документации и разработка программы обучения.
- И.П.Беляев. Проектирование асоиу. – Москва, 2009. – 103 стр.
- Некоторые определения
- Назначение автоматизированных систем
- 4.1. Автоматизированные системы управления
- Асу технологическими процессами
- Ас научными исследованиями
- Системы автоматизированного проектирования
- 4.5. Ас обработки информации
- Ас технологической подготовки производства
- Ас контроля испытаний
- Состав и структура автоматизированных систем
- 2. В процессе проектирования ас (ее частей) разрабатывают, в общем случае, следующие виды обеспечений:
- 2) Технические (элементы-устройства, компоненты и комплексы; связи-линии и каналы связи);
- 3) Организационные (элементы-коллективы людей и отдельные исполнители; связи - информационные, соподчинения, взаимодействия);
- Принципы создания автоматизированных систем
- 1. Ас создают в соответствии с техническим заданием, являющимся основным исходным документом, на основании которого проводят создание ас и приемку ее заказчиком.
- Основные положения по созданию и функционированию автоматизированных систем Требования к планированию и нормированию разработки
- Разделение полномочий при создании ас
- Особо важные моменты создания ас
- Изменения в организационной структуре, вызванные созданием ас
- Комплекс средств автоматизации
- 7.7. Подготовка персонала
- Использование сетей эвм
- Технология распределенных баз данных и по промежуточного уровня
- Стадии и этапы создания ас
- 8.1. Общие положения
- 8.2. Стадии и этапы создания ас
- Содержание работ по созданию ас
- 9.1. Предпроектные стадии
- Содержание работ по этапам проектирования ас
- Содержание документов, разрабатываемых на предпроектных стадиях
- Состав и порядок разработки технического задания на автоматизированную систему
- 1. Общие положения
- 2. Состав и содержание тз
- 3. Правила оформления
- 4. Порядок разработки, согласования и утверждения тз на ас
- 5. Форма титульного листа
- 11.6. Форма последнего листа тз на ас
- Создание автоматизированной системы
- Содержание документов, разрабатываемых при создании ас
- Требования к содержанию документов по общесистемным решениям
- 1. Ведомость эскизного (технического) проекта
- 2. Пояснительные записки к эскизному, техническому проектам
- 3. Общее описание системы
- 4. Схема организационной структуры
- 5. Схема функциональной структуры
- 6. Описание автоматизируемых функций
- 7. Описание постановки задачи (комплекса задач)
- 8. Программа и методика испытаний (компонентов, комплексов средств автоматизации, подсистем, систем)
- 9. Ведомость покупных изделий.
- 10. Локальная смета и локальный сметный расчет
- 11. Проектная оценка надежности системы
- 12. Ведомость держателей подлинников.
- 13. Ведомость эксплуатационных документов
- 14. Паспорт
- 15. Формуляр
- Разработка решений по видам обеспечения ас организационное обеспечение
- Требования к содержанию документов с решениями по организационному обеспечению
- 1. Описание организационной структуры
- 2. Технологическая инструкция
- 3. Описание технологического процесса обработки данных
- 4. Руководство пользователя
- 5. Методика (технология) автоматизированного проектирования
- Информационное обеспечение
- Требования к содержанию документов с решениями по информационному обеспечению
- 1. Перечень входных сигналов и данных
- 2. Перечень выходных сигналов (документов)
- 3. Описание информационного обеспечения системы
- 4. Ведомость машинных носителей информации
- 5. Описание организации информационной базы
- 6. Описание систем классификации и кодирования
- 7. Описание массива информации (файла базы данных)
- 8. Чертеж формы документа (видеокадра)
- Программное обеспечение требования к содержанию документов с решениями по программному обеспечению
- 1. Описание программного обеспечения
- Техническое обеспечение
- Требования к содержанию документов с решениями по техническому обеспечению
- 1. Схема автоматизации
- 2. Описание комплекса технических средств
- 3. План расположения
- 4. План расположения оборудования и проводок
- 10. Схема соединения внешних проводок.
- 15. Чертеж установки технических средств
- 16. Схема принципиальная
- 17. Спецификация оборудования
- 18. Ведомость потребности в материалах.
- 19. Инструкция по эксплуатации ктс
- 20. Ведомость оборудования и материалов
- Требования к содержанию документов с решениями по математическому обеспечению
- 1. Описание алгоритма (проектной процедуры)
- 13.6. Правовое обеспечения ас
- 13.7. Лингвистическое обеспечение
- 13.8. Эргономическое обеспечение
- Проектирование пользовательского интерфейса
- Эргономические цели и показатели качества программного продукта
- 1. Эффективность работы
- 2. Производительность работы
- 3. Удовлетворенность пользователя от работы
- Проектирование интерфейса. Элементы стандарта ibm
- 14.8.1. Согласованность интерфейса
- 14.8.2. Разработка интерфейса
- 14.8.2.1. Проектирование панелей
- 14.8.2.2. Принцип проектирования: объект-действие
- 14.8.2.3. Проектирование диалога
- 14.8.2.4. Окна
- 14.8.2.5. Краткое описание типов панелей
- 14.8.2.6. Краткое описание элементов панелей
- Ввод ас в действие
- 1. Общие положения
- 2. Предварительные испытания
- 2.1. Автономные испытания
- 2.2. Комплексные испытания
- 3. Опытная эксплуатация
- 4. Приемочные испытания
- Содержание организационно-распорядительных документов
- 1. Акт завершения работ
- 2. Акт приемки в опытную эксплуатацию
- 3. Акт приемки в промышленную эксплуатацию
- 4. Документ "Приказ о начале опытной эксплуатации ас (ее частей)"
- 5. Документ "Приказ о вводе в промышленную эксплуатацию ас (ее частей)"
- 6. Приказ о составе приемочной комиссии
- 7. Протокол испытаний
- 8. Протокол согласования