Показатели оценки качества и основы проектирования пользовательского интерфейса.

При проектировании ПИ необходимо определить:

1. Структуру диалога.

2. Возможный сценарий развития диалога.

3. Содержание управляющих сообщений и данных, которыми могут обмениваться пользователи и приложение (семантику сообщений).

4. Визуальные атрибуты отображаемой информации (синтаксис сообщений).

Выбор структуры диалога – это первый из этапов, который должен быть выполнен при проектировании ПИ.

Рассмотрим далее 4 варианта структуры диалога, каждая из которых имеет свои особенности и наиболее удобна для определенного класса задач.

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

Достоинства:

удобен для ввода управляющих сообщений;

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

по своим возможностям является самым быстрым и гибким (с точки зрения подготовленного пользователя).

Недостатки:

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

Диалог типа "вопрос-ответ". В каждой точке диалога система выводит в качестве подсказки один вопрос, на который пользователь дает один ответ. В зависимости от полученного ответа система должна решить, какой следующий вопрос задать.

Достоинства:

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

Недостатки:

не гарантирует минимального объема ввода по количеству нажатий клавиш;

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

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

список объектов, выбираемых прямым указанием, либо указанием номера (кода);

меню в виде блока данных;

меню в виде строки данных;

меню в виде пиктограмм.

Достоинства:

это наиболее удобная структура диалога для неподготовленных пользователей и представляет собой естественный механизм для работы с устройствами указания и выбора.

Недостатки:

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

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

Достоинства:

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

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

с такой структурой удобно работать пользователям любой квалификации.

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

Цели разработки сценария диалога:

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

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

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

Методы разработки сценария диалога:

неформальные

формальные.

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

Основной структурной единицей сценария является шаг диалога, соот-ветствующий одному акту взаимодействия пользователя с системой.

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

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

Время ответа системы определяется как интервал между событием и реакцией системы на него. Данная характеристика ПИ определяет задержку в работе пользователя при переходе к выполнению следующего шага задания.

В настоящее время выработаны следующие рекомендации по допустимому времени ответа интерактивной системы:

0,1…0,2 с – для подтверждения физических действий (нажатие клавиши на клавиатуре, работа с "мышью");

0,5…1,0 с – для ответа на простые команды (например, от момента ввода команды, выбора альтернативы из меню до появления нового изображения на экране);

1…2 с – при ведении связного диалога (когда пользователь воспринимает серию взаимосвязанных вопросов как одну порцию информации для формирования одного или нескольких ответов, задержка между следующими друг за другом вопросами не должна превышать указанную длительность);

2…4 с – для ответа на сложный запрос, состоящий в заполнении некоторой формы (если задержка не влияет на другую работу пользователя, связанную с первой, могут быть приемлемы задержки до 10 с);

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

Если пользователь не получает ответ в течении 20 и более сек, то приложение должно сообщить пользователю, что задержка ответа не является следствием выхода системы из строя.

В процессе разработки сценария диалога важно обеспечить гибкость (адаптивность) интерфейса.

Различают следующие виды адаптации:

1. Фиксированная адаптация. Здесь пользователь явно выбирает уровень диалоговой поддержки. В простейших случаях реализуется правило двух уровней: подробного (для начинающих пользователей), краткого (для подготовленных пользователей), а в других – правило N уровней.

2. Полная адаптация. Диалоговая система стремится построить модель пользователя, которая по мере обучения последнего определяет стиль диалога в зависимости от этих изменений.

3. Косметическая адаптация призвана обеспечить гибкость диалога не только без учета поведения пользователя, но и без однозначного выбора им конкретного стиля диалога. Здесь находят применение методы:

использования умолчаний;

использование сокращений;

опережающего ввода ответов;

многоуровневой помощи;

многоязычности.

Выбор визуальных атрибутов отображаемой информации предполагает выполнение следующих действий:

определение состава информации, которая должна появится на экране;

выбор формата представления этой информации;

определение взаимного расположения данных (или объектов) на экране;

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

разработка макета размещения данных на экране;

оценка эффективности размещения информации.

Общие принципы расположения информации на экране должны обеспечивать для пользователя:

возможность просмотра экрана в логической последовательности;

простоту выбора нужной информации;

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

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

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

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

Заключение

Для эффективного функционирования ИС необходимо иметь эффектив-ный пользовательский интерфейс, обладающий рядом свойств (естествен-ность, согласованность, дружественность, обратимость, простота, гибкость, эстетичность) и удовлетворяющий предъявляемым критериям качества.

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

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