П_К_Лекц_ї. Что такое интерфейс
 Скачать 1.02 Mb.
|
|
ИСПЫТАНИЕ ПРОГРАММНОГО ПРОДУКТА UCD-технология предполагает достаточно активное привлечение пользователя к процессу разработки. Совместное с потенциальным пользователем испытание создаваемого приложения обеспечивает получение весьма ценной дополнительной информации и является, как правило, залогом успешной последующей реализации продукта. Необходимо подчеркнуть, что испытание программного продукта принципиально отличается от его отладки. Первое и наиболее важное отличие обусловлено различными целями этих двух процессов: отладка имеет целью выявление дефектов (ошибок) программирования, в то время как в ходе испытаний вы оцениваете, насколько полно разработанное приложения (в частности, его интерфейс) отвечает потребностям и ожиданиям пользователя. Второе принципиальное отличие состоит в том, что отладку выполняет непосредственно его разработчик, а основным действующим лицом при проведении испытаний является потенциальный пользователь (заказчик). Благодаря этому в ходе испытаний могут быть выявлены не только технические погрешности, но и концептуальные проблемы в предлагаемом продукте. Кроме того, испытания могут проводиться для двух или более альтернативных вариантов реализации создаваемого приложения с целью выявления наиболее удачного именно с точки зрения пользователя и решаемых им задач. ПОВТОРНОЕ ВЫПОЛНЕНИЕ ЭТАПОВ РАЗРАБОТКИ Поскольку испытания часто обнаруживают те или иные слабости проекта, или, по крайней мере, обеспечивают получение дополнительной информации, которую вы захотите использовать, почти всегда оказывается необходимым возврат к одному из предыдущих этапов разработки (а иногда и в начальную точку) и проведение повторных испытаний. Так может продолжаться до тех пор, пока и разработчик, и потенциальные пользователи не будут полностью удовлетворены полученными результатами. ОЦЕНКА ПОТРЕБИТЕЛЬСКИХ СВОЙСТВ ПРИЛОЖЕНИЯ В ПРОЦЕССЕ РАЗРАБОТКИ Как было указано выше, основная цель испытаний — определить, насколько полно разработанное приложение (в первую очередь, его интерфейс) отвечает потребностям и ожиданиям пользователя. В связи с этим основным направлением испытаний приложения является оценка его «потребительских свойств» (Usability). Такая оценка должна проводиться, начиная с самых ранних этапов разработки. Основой для проведения оценки должны служить данные о том, как пользователи обычно выполняют ту работу, которую призвано автоматизировать создаваемое приложение. По мере того, как разработка продвигается, оценка потребительских свойств приложения должна постоянно уточняться. Чем чаще и корректнее будет проводиться оценка, тем выше будет качество разработки. Нет простого уравнения, позволяющего определить, каким образом вносимые изменения повлияют на первоначальный проект приложения. Однако важную роль в такой оценке могут сыграть следующие соображения: Каждая дополнительная характеристика потенциально влияет на поведение, сложность, устойчивость, эксплуатацию и издержки по сопровождению создаваемого ПО. После выхода в свет официальной версии продукта труднее устранить проблемы, оставшиеся нерешенными на стадии разработки, поскольку пользователи могут приспособиться, или даже «подчиниться» имеющимся недостаткам вашего ПО. Простота пользовательского интерфейса — это далеко не то же самое, что его упрощенчество. Чтобы сделать нечто простым в использовании, часто требуется приложить много сил и создать весьма сложное изделие с точки зрения его внутренней организации. Доработки программного кода с целью расширения функциональных возможностей ПО совсем не обязательно будут иметь пропорциональный положительный эффект с точки зрения интерфейса пользователя. Например, если основная задача пользователя состоит в выборе единственного объекта, то, предоставляя ему возможность одновременного выбора нескольких объектов, вы только усложняете ему работу. 2.2. ЭТАПЫ ПРОЕКТИРОВАНИЯ ПОЛЬЗОВАТЕЛЬСКОГО ИНТЕРФЕЙСА Проводившиеся в свое время исследования психологических аспектов общения человека с компьютером показали, что следует всячески стремиться к дегуманизации этого общения, то есть пользователь не должен воспринимать компьютер как полноценного собеседника. Тем не менее, обмен информацией между пользователем и компьютером (точнее, его программным обеспечением) по всем формальным признакам соответствует понятию «диалог» в общепринятом смысле. Основные правила, которые должны соблюдаться, чтобы диалог оказался конструктивным: во-первых, участники диалога должны понимать язык друг друга; во-вторых, они не должны говорить одновременно; в-третьих, очередное высказывание должно учитывать как общий контекст диалога, так и последнюю информацию, полученную от собеседника. При проектировании пользовательского интерфейса необходимо определить: структуру диалога; возможный сценарий развития диалога; содержание управляющих сообщений и данных, которыми могут обмениваться человек и приложение (семантику сообщений); визуальные атрибуты отображаемой информации (синтаксис сообщений). ВЫБОР СТРУКТУРЫ ДИАЛОГА Выбор структуры диалога — это первый из этапов, который должен быть выполнен при разработке интерфейса. Рассмотренные ниже четыре варианта структуры диалога являются разновидностями структуры типа «вопрос — ответ», тем не менее, каждая из них имеет свои особенности и наиболее удобна для определенного класса задач. ДИАЛОГ ТИПА «ВОПРОС - ОТВЕТ» Структура диалога типа «вопрос-ответ» (Q&A) основана на аналогии с обычным интервью. Система берет на себя роль интервьюера и получает информацию от пользователя в виде ответов на вопросы. Это наиболее известная структура диалога; все диалоги, управляемые компьютером, в той или иной степени состоят из вопросов, на которые пользователь отвечает. Однако в структуре Q&А этот процесс выражен явно. В каждой точке диалога система выводит в качестве подсказки один вопрос, на который пользователь дает один ответ. В зависимости от полученного ответа система может решить, какой следующий вопрос задавать. Структура Q&A предоставляет естественный механизм ввода, как управляющих сообщений (команд), так и данных. Никаких ограничений на диапазон или тип входных данных, которые могут обрабатываться, не накладывается. Существуют системы, ответы в которых даются на естественном языке, но чаще используются предложения из одного слова с ограниченной грамматикой. Диалог в виде вопросов и ответов в достаточной степени обеспечивает поддержку пользователя, так как даже краткий наводящий вопрос при разумном построении может быть самопоясняющим. Однако структура Q&А обладает одним существенным недостатком. Даже если ввод происходит достаточно быстро, для человека, который уже знает, какие вопросы задает система и какие ответы нужно на них давать, отвечать на всю серию вопросов довольно утомительно. Тем не менее, у нее имеются определенные достоинства. Эта структура может удовлетворить требования различных пользователей и типов данных. В частности, такая структура особенно уместна при реализации диалога с множеством «ответвлений», т.е. в тех случаях, когда на каждый вопрос предусматривается большое число ответов, каждый из которых влияет на то, какой вопрос будет задан следующим. По этой причине структура Q&A часто используется в экспертных системах. ДИАЛОГ НА ОСНОВЕ МЕНЮ Меню является, пожалуй, наиболее популярным вариантом организации запросов на ввод данных во время диалога, управляемого компьютером. Существует несколько основных форматов представления меню на экране: список объектов, выбираемых прямым указанием, либо указанием номера (или мнемонического кода); меню в виде блока данных; меню в виде строки данных; меню в виде пиктограмм. Меню в виде строки данных может появляться вверху или внизу экрана и часто остается в этой позиции на протяжении всего диалога. Таким образом, посредством меню удобно отображать возможные варианты данных для ввода, доступных в любое время работы с системой. Если в системе имеется достаточно большое разнообразие вариантов действий, организуется иерархическая структура из соответствующих меню. Дополнительные меню в виде блоков данных «всплывают» на экране в позиции, определяемой текущим положением указателя, либо «выпадают» непосредственно из строки меню верхнего уровня. Эти меню исчезают после выбора варианта. Меню в виде пиктограмм представляет собой множество объектов выбора, разбросанных по всему экрану; часто объекты выбора содержат графическое представление вариантов работы. Меню можно с равным успехом применять для ввода, как управляющих сообщений, так и данных. Структура типа меню является наиболее естественным механизмом для работы с устройствами указания и выбора: меню представляет собой изображение тех объектов, которые выбираются пользователем. Меню — это наиболее удобная структура диалога для неподготовленных пользователей; жесткая очередность открытия и иерархическая вложенность меню может вызывать раздражение профессионала, замедлять его работу. Традиционная структура меню недостаточно гибка и не в полной мере согласуется с методами адаптации диалога, такими, например, как опережающий ввод, с помощью которого можно ускорить темп работы подготовленного пользователя. ДИАЛОГ НА ОСНОВЕ ЭКРАННЫХ ФОРМ Как структура типа «вопрос — ответ», так и структура типа меню предполагают обработку на каждом шаге диалога единственного ответа. Диалог на основе экранных форм допускает обработку на одном шаге диалога нескольких ответов. На практике формы используются в основном там, где учет какой-либо деятельности требует ввода достаточно стандартного набора данных. Человек, заполняющий форму, может выбирать последовательность ответов, временно пропускать некоторый вопрос, возвращаться назад для коррекции предыдущего ответа и даже «порвать бланк» и начать заполнять новый. Он работает с формой до тех пор, пока не заполнит ее полностью и не передаст системе. Программная система может проверять каждый ответ непосредственно после ввода или выждать и вывести список ошибок только после заполнения формы целиком. В некоторых системах информация, вводимая пользователем, становится доступной только после нажатия клавиши «ввод» по окончании заполнения формы. Эту структуру уместно применять там, где источником данных служит существующая входная («бумажная») форма документа. Не обязательно, чтобы внешний вид этих форм совпадал (это даже может ухудшить восприятие данных на экране), но все вводимые элементы данных должны располагаться в том же относительном порядке и иметь такой же формат, что и в исходном документе. Структура диалога на основе экранной формы обеспечивает высокий уровень поддержки пользователя: для каждого вопроса формы могут быть предусмотрены сообщения об ошибках и справочная информация. Пользователю можно также оказать помощь, включив некоторые элементы формата ответа в вопрос пли в поле ответа. Эта структура позволяет повысить скорость ввода данных по сравнению со структурой типа «вопрос — ответ» и манипулировать более широким диапазоном входных данных, нежели меню; кроме того, с ней могут работать пользователи любой квалификации. Поскольку эта структура имеет последовательную, а не древовидную организацию, она в меньшей степени подходит для работы в режиме выбора вариантов. Еще одной областью применения экранных форм является задание параметров запросов в базах данных. Этот механизм иногда называют запросом по образцу (QuerybyExample). ДИАЛОГ НА ОСНОВЕ КОМАНДНОГО ЯЗЫКА Структура диалога на основе командного языка столь же распространена, что и структура типа меню. Она очень часто используется в операционных системах. Исторически это первая из реализованных структур диалога. При такой организации диалога программная система не выводит ничего, кроме постоянной подсказки (приглашения на ввод команды), которая означает готовность системы к работе. Каждую команду вводят с новой строки и обычно заканчивают нажатием клавиши «ввод». Ответственность за правильность задаваемых команд ложится на пользователя. Система информирует о невозможности выполнения неверной команды, не поясняя, как правило, причин. Подобно меню, диалог на базе команд удобен для ввода управляющих сообщений, однако он обеспечивает более широкие возможности выбора в любой точке диалога и не требует иерархической организации обслуживающих его программ. Программная система может поддерживать достаточно большое количество команд, но на практике следует ограничивать их число, чтобы не перегружать память пользователя. Структура на базе командного языка не отличается хорошей поддержкой пользователя и пригодна в основном для подготовленных специалистов. Перед использованием такой системы необходимо пройти курс обучения и в дальнейшем изучать особенности работы по документации, а не на практике. Более того, поскольку системе неизвестно, что намеревается делать пользователь, трудно предложить какую-либо реальную помощь в процессе работы, кроме выдачи справок достаточно общего характера. Структура на основе языка команд по своим возможностям самая быстрая и гибкая из всех структур диалога. Большинство пользовательских интерфейсов на базе «естественного» языка реализуется с помощью языков команд с очень большим набором ключевых слов. Подготовленный пользователь испытывает удовольствие от ощущения того, что он управляет системой, а не наоборот. Однако эта структура не обеспечивает пользователя поддержкой, поэтому даже подготовленные пользователи считают, что очень сложно использовать все заложенные в ней возможности. Изложенное можно представить в форме так называемой «таблицы выбора»:
* — использование этого типа диалога данной категорией пользователей требует наличия системы помощи; ** — использование средств системы возможно только в ограниченном объеме. Рис.. Вариант таблицы выбора Наряду с указанными в таблице, в нее могут быть включены и другие критерии выбора (наличие инструментальных средств разработки интерфейса, характер пользователя, ограничения по имеющимся ресурсам и т.д.). Выбор наиболее подходящей структуры диалога на основе таблицы выполняется следующим образом. Закрыть графы «Тип диалога». В графе «Выбор пользователя» пометить критерии, относящиеся к рассматриваемому применению. Для каждого типа диалога подсчитать число случаев, когда помечены соответствующие пункты и в графе «выбор пользователя», и в графе «тип диалога». Подсчитать число совпадений для каждого типа диалога. Основная ценность таблицы состоит в том, что ее можно использовать как исходный вариант выбора типа диалога, либо как средство окончательной проверки соответствия выбранного типа диалога рассматриваемым критериям. Если предполагается, что одни пункты более важны, чем другие, можно брать их с разными весовыми коэффициентами. Можно также указать, какие пункты должны рассматриваться как выполняемые безусловно; типы диалога, не соответствующие хотя бы одному из таких пунктов, должны немедленно отвергаться, сколько бы очков они ни набрали по остальным пунктам. 2.2.2. РАЗРАБОТКА СЦЕНАРИЯ ДИАЛОГА Развитие диалога во времени можно рассматривать как последовательность переходов системы из одного состояния в другое. Очевидно, что ни одно из этих состояний не должно быть «тупиковым», т.е. пользователь должен иметь возможность перейти из любого текущего состояния диалога в требуемое (за один или несколько шагов). Для этого в ходе разработки интерфейса необходимо определить все возможные состояния диалога и пути перехода из одного состояния в другое. Другими словами, необходимо разработать сценарий диалога. Целями разработки сценария диалога являются: выявление и устранение возможных тупиковых ситуаций в ходе развития диалога; выбор рациональных путей перехода из одного состояния диалога в другое (из текущего в требуемое); выявление неоднозначных ситуаций, требующих оказания дополнительной помощи пользователю. Сложность разработки сценария определяется в основном двумя факторами: функциональными возможностями создаваемого приложения (т.е. числом и сложностью реализуемых функций обработки информации) и степенью неопределенности возможных действий пользователя. В свою очередь, степень неопределенности действий пользователя зависит от выбранной структуры диалога. Наибольшей детерминированностью обладает диалог на основе меню, наименьшей — диалог типа «вопрос-ответ», управляемый пользователем. Из сказанного следует, что сценарий диалога можно упростить, снизив степень неопределенности действий пользователя. Возможными способами решения этой задачи являются: использование смешанной структуры диалога (применение меню с целью «ограничения свободы» пользователя там, где это возможно); применение входного контроля вводимой информации (команд и данных). Дополнительные возможности по снижению неопределенности действий пользователя предоставляет объектно-ориентированный подход к разработке интерфейса, при котором для каждого объекта заранее устанавливается перечень свойств и допустимых операций. Наиболее эффективен такой подход при создании графического интерфейса. Способ описания сценария диалога зависит от степени его сложности. Существующие методы описания сценариев можно разделить на две большие группы: неформальные и формальные методы. Главное достоинство формальных методов состоит в том, что они позволяют автоматизировать как проектирование диалога, так и его модификацию (адаптацию) в соответствии с характеристиками пользователя. В настоящее время наиболее широко используются формальные методы описания сценариев на основе сетей Петри и их расширений, а также на основе систем представления знаний (фреймовые модели и продукционные системы). Независимо от способа описания сценария его основной структурной единицей является шаг диалога, соответствующий одному акту взаимодействия пользователя с системой. Схематично шаг диалога можно представить так, как показано на рис.  Рис. Шаг диалога | ||||||||||||||||||||||||||||||||||