509_Merzljakova_E.JU._CHeloveko-mashinnoe_vzaimodejstvie_

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

1.Будут ли пользователи пытаться произвести тот или иной эффект, который даёт действие?

2.Видят ли пользователи элемент управления (кнопку, меню, переключатель

ит. д.) для осуществления действия?

3.Если пользователи нашли элемент управления, поймут ли они, что он производит тот эффект, который им нужен?

4.После того как действие сделано, будет ли понятен пользователям тот отклик, который они получают, чтобы перейти к следующему действию с уверенностью?

По результатам CWT-анализа необходимо исправить интерфейс. Большинство исправлений будут очевидны. Сложный случай возникает тогда, когда у пользователя вообще нет никаких причин думать, что действие должно быть сделано. Самое верное решение этой проблемы – исключить это действие; пусть система сама выполнит его. Если так не получается, то необходимо перестроить задачу так, чтобы пользователи получали бы логическое побуждение к выполнению "проблемного" действия.

CWT-анализ позволяет выявить много проблем с интерфейсом, но не даёт ответа на вопрос, насколько сложен интерфейс, т. е. сколько времени тратит пользователь на выполнение задачи.

1.3. Анализ GOMS

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

Аббревиатура GOMS означает Goals, Operations, Methods, Selections (цели,

операции, методы, правила выбора). Модель GOMS состоит из описания методов, необходимых для достижения заданных целей. Методы представляются последовательностями шагов, состоящих из операций, которые выполняет пользователь. Метод может быть назван подцелью, т. о. методы образуют иерархическую структуру. Если существует более одного метода для достижения цели, то включаются правила выбора, с помощью которых в зависимости от контекста выбирается один метод.

В терминологии данного вида анализа цель – это то, что мы раньше называли (репрезентативной) задачей, метод – это список действий пользователя, операции – элементарные действия пользователя.

21

Операции в GOMS – это элементарные действия, которые нельзя разложить на более мелкие. Причём учитываются как внешние действия, т. е. те, что приводят к видимым физическим эффектам, так и внутренние, связанные с мышлением пользователя. Например, действие (шаг метода) "нажать кнопку <button>" представляется в виде последовательности следующих операций:

визуально определить местонахождение кнопки (мыслительная операция);

навести на кнопку указатель мыши (внешняя операция);

щелкнуть кнопкой мыши (внешняя операция).

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

K – нажатие клавиши;

B – клик кнопкой мыши;

P – наведение указателя мыши;

R – ожидание ответной реакции компьютера;

H – перенос руки с клавиатуры на мышь или наоборот;

D – проведение с помощью мыши прямой линии (например, выделение или прокрутка текста);

M – мыслительная подготовка (к осуществлению одной из перечисленных операций).

Разные пользователи выполняют указанные операции за разное время. Однако напомним, что GOMS исследует работу опытного пользователя. Многочисленные исследования выявили средние значения времени операций, выполняемых опытными пользователями. Приведём их значения:

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

Время ожидания R зависит от характера действия, выполняемого компьютером. Речь идёт только о тех задержках, которые связаны с работой интерфейса (например, ожидание открытия нового интерфейсного объекта). При анализе GOMS, как правило, не учитывается время, расходуемое компьютером на выполнение целевой вычислительной функции (например, преобразование одного формата в другой). Такие вычислительные операции относятся уже к функциональному программному обеспечению; скорость их выполнения определяется быстродействием аппаратуры, объёмом обрабатываемых данных и эффективностью алгоритмов, но не связана со сложностью интерфейса. С другой сторо-

22

ны, очень быстрые реакции компьютера, кажущиеся для человека практически мгновенными (например, эхо-печать символа после нажатия клавиши), также не учитываются. Следует учитывать только ожидания, которые сбивают ритм выполнения других операций. Время таких ожиданий можно оценить при работе с реальной программой следующим образом: Если реакция компьютера достаточно быстрая, но, всё же, ощутима, то "стандартное" время R рекомендуется установить 0.25 с.

Время операции D также может быть разным в зависимости от величины перемещения и других сопутствующих деталей. Его рекомендуется приблизительно оценить при работе с реальным приложением. В качестве "стандартного" значения можно взять 2 с.

Общий алгоритм действий при проведении GOMS анализа:

цель разбивается на подцели;

для каждой подцели расписываются методы;

методы могут раскрываться далее через внутренние методы;

формируется конечная последовательность операций;

добавляются мыслительные подготовки M;

считается время в секундах.

Вся последовательность операций разбивается на семантические группы. Например, набор на клавиатуре слова "слон" выполняется четырьмя операциями нажатия на клавиши KKKK и рассматривается как отдельная семантическая единица. Перед ней нужно поставить операцию M. Действительно, перед тем как напечатать слово, человек должен сформировать его внутренний образ. Это и отражается добавлением операции M. Но после того как образ сформирован, слово печатается без дальнейших раздумий между отдельными буквами. Пример другой семантической единицы – открытие меню. Оно состоит из двух операций PB. Но прежде чем они могут быть выполнены, нужно решить, какой пункт меню вам нужен и найти, где он находится. Поэтому перед PB (но не между P и B) нужно поставить M. Если затем с помощью ещё одной пары операций PB в меню выбирается элемент, то M ставить не нужно, т. к. идея о том, что нужно выбрать из меню, уже сформировалась у человека ранее.

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

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

23

1.4. Золотые правила построения интерфейсов

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

1.4.1. Правила Нильсена Молиха (Nielsen Molich)

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

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

Минимизируйте загрузку памяти пользователя. Не заставляйте пользова-

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

Будьте последовательны. У пользователей должна быть возможность изучить действия в одной части системы и применить их снова, чтобы получить похожие результаты в других местах.

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

Обеспечьте хорошо обозначенные выходы. Если пользователь попадает в часть системы, которая его не интересует, у него всегда должна быть возможность быстро выйти оттуда, ничего не повредив.

Обеспечьте быстрые клавиши и ярлыки. Элементы быстрого доступа мо-

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

Хорошие сообщения об ошибках. Хорошее сообщение об ошибке помогает пользователю понять, в чём проблема и как это исправить.

Предотвращайте ошибки. Всегда, когда вы пишете сообщение об ошибке, вы должны спросить себя, можно ли избежать этой ошибки? Хороший пример построения интерфейса, предотвращающего ошибки – стандартная программа «Калькулятор», в которой при переключении в двоичный режим интерфейс

24

делает недоступными числовые кнопки, кроме 0 и 1, а также делает недоступными некоторые функции, имеющие смысл только для чисел с плавающей точкой. Этот простой приём позволяет минимизировать возможные ошибки пользователя.

Снабдите программу системой помощи. Справка должна быть макси-

мально подробной и рассчитана на абсолютно неопытного пользователя.

1.4.2. Принципы организации графического интерфейса

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

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

Принцип "видимость отражает полезность". Делайте часто используе-

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

Принцип интеллектуальной последовательности. Используйте похожие экраны для похожих функций. Это похоже на заимствование, но в этом случае вы заимствуете что-то из одной части дизайна и применяете это к другой части. Обоснование этого принципа очевидно: раз пользователи выучили расположение элементов управления на экране (например, где находится кнопка "Помощь"), они могут легко приложить это знание к другим экранам внутри той же системы. Этот подход позволяет вам сосредоточить усилия на разработке лишь нескольких привлекательных работоспособных экранов, а затем их слегка мо-

25

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

Принцип "цвет как приложение". Не полагайтесь на цвет как носитель информации, используйте его умеренно, чтобы лишь акцентировать информацию, передаваемую другими средствами. Хорошее правило для большинства интерфейсов – разрабатывать их в чёрно-белом варианте, убедиться, что они работоспособны, а затем добавить минимальный цвет для их окончательного облика. Цвет, безусловно, полезен, когда необходимо выделить предупреждение или информационное сообщение, но обязательно дайте дополнительные ключи для пользователей, не способных воспринимать изменения цвета.

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

2. Задание

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

анализ задач и пользователей;

Найти двух человек, которые могут быть заинтересованы в решении предложенной задачи и, возможно, использовали бы ваше приложение. Дайте их краткое описание (возраст, образование, профессия, навыки в выбранной сфере, навыки владения компьютером);

выбор репрезентативных задач;

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

26

заимствование;

Найдите в интернете подобные приложения (или их авторские описания), приведите ссылку на источник, описание программы, скриншоты, перечислите задачи. Выберите и напишите, что именно вы будете заимствовать из данных приложений;

черновое описание дизайна;

Опишите черновой вариант дизайна словами и графически (иллюстрации с пояснениями). Черновой вариант должен отражать все внешние элементы интерфейса и их назначение, для каждого окна приложения, в том числе и окна сообщений (об ошибках, подсказках и т. д.);

обдумывание дизайна;

Проведите CWT и GOMS анализы интерфейса на примере двух репрезентативных задач, а также подробный анализ интерфейса на соответствие Правилам Нильсена-Молиха и правилам организации графического интерфейса;

создание прототипа;

Разработайте прототип интерфейса с помощью средств Qt Creator;

тестирование дизайна с пользователями;

Первый этап тестирования проводится с преподавателем, выступающим в качестве пользователя. Второй этап проводится в пределах подгруппы: первый участник тестирует, второй за ним записывает;

итерирование;

Исправление интерфейса по результатам тестирования (2 итерации соответственно). Сформулировать требования практичности;

реализация;

Программирование приложения в среде Qt Creator с использованием библиотеки Qt;

отслеживание эксплуатации;

Необходимо провести презентацию программного продукта. В качестве слушателей и пользователей будут выступать студенты и преподаватель;

изменение дизайна.

Изменение в соответствии с пожеланиями, высказанными на этапе отслеживания эксплуатации.

3.Варианты заданий

1.Электронный журнал куратора:

база данных студентов: ФИО, дата рождения, группа, фотография, электронный адрес или ссылка на интернет-страницу, телефон родителей (не менее 10 студентов в группе), с возможностью добавления, удаления, редактирования;

разделение на группы (минимум 3);

поиск студентов по ФИО, по группе и ФИО;

27

назначение старосты, смена старосты;

план мероприятий по группам, добавление фотографий с мероприятий, учет посещения мероприятий студентами;

учет успеваемости студентов по нескольким предметам за один семестр, учитывая одну сессию;

добавление в список «внимание» неуспевающих студентов на текущий

день;

вывод отчета по успеваемости выбранных студентов на текущий день, вывод отчета о посещении проведенных мероприятий любого студента.

2. Планировщик задач для управляющего проектами:

база данных рабочих проектов: название, схема или картинка результата, дата начала, срок сдачи, бригады, список заданий, сроки выполнения заданий (минимум 5 проектов), с возможностью добавления и удаления проектов;

по каждому проекту должно работать несколько бригад (минимум 10 бригад на все проекты);

одна бригада может выполнять последовательно несколько заданий в одном проекте;

отображение прогресса заданий (параллельных и последовательных) на текущий день по каждому проекту;

функция внесения прогресса заданий;

функция корректировки сроков задания и соответственно проекта;

выделение прогресса заданий в случае нарушения сроков выполнения;

вывод отчета по выбранному проекту на текущий день календаря.

3. Книга рецептов русской кухни:

база данных рецептов: название, список продуктов, время приготовления, тип блюда, картинка, описание (не менее 25 рецептов);

разделение на категории по видам блюд (не менее трех) и по типам приготовления: плита, духовка, мультиварка, микроволновка;

расширенный поиск рецептов: по названию, по ингредиенту, по типу блюда и ингредиенту, по типу приготовления и названию, по времени приготовления;

добавление рецепта совместно с поиском информации в интернете;

загрузка собственной картинки рецепта, как на заглавное фото, так и на этапы;

карточка дня: составление меню на день;

визуальная шкала рейтинга рецептов. Возможность менять рейтинг любого блюда;

добавление рецепта в избранное, удаление, сохранение в файл.

4. Строительство дачного домика:

база данных строительных материалов: наименование, этап работы, средняя стоимость, фотография, характеристики (не менее 20 материалов), с возможностью добавления, удаления, редактирования;

выбор планировки домика из готовых вариантов (не менее 5);

28

пошаговый план строительства, соответствующий выбранной планировке (основные этапы, не менее 10), с возможностью изменения;

внесение своих заметок в план строительства с возможностью отметки «сделано»;

внесение своих графических файлов в план на любом этапе;

предложение материалов для строительства по каждому этапу, возможность выбора материалов различных по стоимости и качеству (выбор не менее 2 по каждому материалу);

расчет количества и примерной стоимости всех расходных материалов в зависимости от полученного объема работ;

сохранение в файл полного плана по строительству.

5. Учет пациентов стоматологической клиники:

база данных карточек пациентов: ФИО, пол, дата рождения, адрес проживания, телефон, дата регистрации в клинике, данные обо всех приемах (не менее 30 пациентов), с возможностью добавления, удаления, редактирования;

поиск пациентов по ФИО, по лечащему врачу;

поиск пациентов, наблюдавшихся за определенный период времени;

функция внесения приема: дата, причина обращения, лечащий врач, время, кабинет;

вывод листа текущего приема: все данные о приеме, включая редактируемый результат приема и список назначений;

загрузка фотографий рентгеновских снимков в лист приема пациента;

вывод карточки отдельного пациента с полными данными обо всех прие-

мах;

вывод краткой истории посещений пациента с основными результатами всех приемов.

6. Руководство путешественника:

база данных поездок: название, страна, маршрут, фотография, минимальный список вещей в дорогу, длительность, транспорт, погодные условия, ссылка на сайт (не менее 15 готовых поездок), с возможностью добавления, удаления, редактирования;

поиск поездок по ключу (по всем полям базы данных);

формирование списка вещей в дорогу на основе минимального предложенного, разделение на категории в виде иерархического списка, с возможностью редактирования, добавления, удаления;

возможность отметок в списке вещей: положил/не положил/необходимо купить;

карточка путешественника с основной информацией и возможностью загрузки файлов электронного билета, копии паспорта, внесение заметок, ссылки на сайты;

сохранение в отдельном файле карточки путешественника;

внесение плана поездки с фотографиями;

сохранение в отдельном файле плана поездки.

29

7. Учет продуктов в заведении общественного питания:

база данных продуктов: наименование, количество единиц в упаковке, количество продукта в единице товара (граммы, литры), стоимость упаковки, поставщик (не менее трех), количество упаковок в наличии, дата и время приема, дата выхода срока годности, фотография отдельной единицы товара (не менее 30 наименований продуктов), с возможностью добавления, удаления, редактирования;

формирование общего меню заведения, с указанием требуемого количества продуктов на блюдо (не менее 10 блюд, на каждое – не менее трех продуктов);

возможность добавления фотографий блюда;

подсчет стоимости продуктов каждого блюда с расчетом на количество продукта из упаковки;

учет расхода продуктов при изготовлении блюд на каждый день, учитывая продукты с истекшим сроком годности;

функция прихода товаров;

карточка дня: визуальное отображение наличия продуктов с выделением статуса, отражающего остаток и срок годности; вывод блюд, для которых недостаточно продуктов, связь с поставщиком;

вывод отчета за указанный промежуток времени о расходе и остатке продуктов.

8. Организация свадеб:

база данных: название свадьбы, дата свадьбы, бюджет, данные о женихе и невесте, список мероприятий, список необходимых вещей, список привлеченных людей и организаций, планы мероприятий (не менее трех проведенных свадеб в готовом виде), с возможностью добавления, удаления, редактирования;

составление списка мероприятий с возможностью добавления организаций, фотографий, описания;

план свадьбы должен иметь вид страничного документа. На каждой странице/вкладке в принятом порядке подробно в картинках отображается текущий этап проведения свадьбы;

формирование списка вещей по каждому этапу (мероприятию);

вывод стоимости на каждом этапе, а также общей стоимости;

привязка плана к заданному бюджету свадьбы;

сохранение каждого этапа в отдельный документ;

вывод отчета о проведенной свадьбе с возможностью добавления фотографий.

9. Электронный ежедневник работающего студента:

база данных дел: учебные предметы, задания и сроки сдачи, рабочие задания и сроки сдачи, личные цели, посещаемые места (не менее 5 предметов, не менее 5 заданий по каждому предмету, не менее трех рабочих заданий, не менее

30