Пользователь сам выбирает уровень диалоговой поддержки. Простейший вариант такой адаптации основан на использовании правила двух уровней, согласно которому система обеспечивает два вида диалога:
§ подробный (для начинающего пользователя);
§ краткий (для подготовленного пользователя).
Правило двух уровней может быть расширено до правила N уровней диалога. Однако такой подход имеет несколько недостатков:
§ не учитывается тот факт, что навыки накапливаются постепенно;
§ пользователь может хорошо знать одну часть системы и совсем не знать другую;
§ пользователь сам определяет уровень своей подготовки, что снижает объективность оценки.
полная
При полной адаптации диалоговая система стремится построить модель пользователя, которая по мере обучения последнего и определяет стиль диалога в зависимости от этих изменений.
Основная проблема - распознавание характеристик пользователя (время, затрачиваемое пользователем на ответ, количество его обращений за помощью или характер ошибок и тип запрашиваемой помощи).
В настоящее время полная (автоматическая) адаптация практически ни в одной диалоговой системе не реализована.
косметическая.
Обеспечивает гибкость диалога без учета поведения пользователя, но и без однозначного выбора им конкретного стиля диалога.
Такая адаптация может быть достигнута за счет применения следующих методов:
§ использование умолчаний (распространенный способ — это нулевой ввод);
§ использование сокращений (ввод вместо имени команды ее любое допустимое сокращенное обозначение);
§ опережающий ввод символов (система, «узнав» по первым символам команду, «дописывает» ее сама);
§ опережающий ввод ответов (возможность на очередном шаге диалога вводить не один ответ, а цепочку последовательных ответов, упреждая возможные вопросы системы.);
§ многоуровневая помощь (сначала на экран выводится сообщение начального уровня, а затем пользователь может уточнить полученную информацию);
§ многоязычность (структура и семантика диалоговых сообщений не должны зависеть от того, на каком языке разработаны инструментальные средства).
В 1986 году было опубликовано «Руководство по разработке программного пользовательского интерфейса». Содержало 944 принципа, касающихся ввода и отображения данных, поддержки пользователя, защиты данных и т.д. Недостаток: не учитывались технологические возможности инструментальных средств, имевшихся в распоряжении разработчиков программного обеспечения.
Ситуация коренным образом изменилась в 1987 г., когда корпорация IBM объявила о намерении создать единую среду разработки приложений (Systems Application Architecture — SAA).
Данный проект предусматривает не только разработку единых принципов создания приложений, но и «материализацию» этих принципов на основе соответствующей технологической базы.
Целями проекта являлись:
§ Повышение производительности труда программистов и конечных пользователей.
§ Облегчение эксплуатации и сопровождения программного обеспечения.
§ Повышение эффективности распределенной обработки информации.
§ Увеличение отдачи инвестиций в разработку информационных систем.
Проект SAA содержит 4 компонента:
§ Соглашения по интерфейсу пользователя (Common User Access — CUA);
§ Соглашения по программному интерфейсу (Common Programming Interface — CPI);
§ Соглашения по разработке приложений (Common Applications — СА);
§ Соглашения по коммуникациям
В качестве технологической базы для реализации соглашений по пользовательскому интерфейсу было предложено конкретное инструментальное средство — Programming Toolkit для операционной системы OS/2. При его создании был учтен накопленный к тому времени опыт разработки интерфейсов, а также последние достижения в данной области, в первую очередь — появление графических интерфейсов.
Исследованиями и практической реализацией графических интерфейсов в то время уже занимались такие фирмы как Xerox, Apple, Digital Research и Microsoft. В результате их деятельности были определены основные концепции построения графических пользовательских интерфейсов:
- использование единой рабочей среды пользователя в виде так называемого Рабочего стола;
- объектно-ориентированный подход к описанию заданий пользователей;
- использование графических окон в качестве основной формы отображения
- применение средств неклавиатурного ввода, основанного на выборе и указании с помощью Манипулятора «мышь».
В силу различных причин фирма IBM при реализации проекта SAA наиболее тесно сотрудничала с фирмой Microsoft, в результате чего была создана графическая оболочка Microsoft Windows IBM Top View. И хотя впоследствии пути двух гигантов компьютерного бизнеса несколько разошлись, основные положения проекта SAA живы и успешно развиваются: корпорацией IBM — применительно к OS/2, а фирмой Microsoft — в рамках семейства ОС Windows.
В марте 1997 года фирма Microsoft выпустила пакет Visual Studio 97, в который вошли все созданные ею инструментальные средства разработки приложений, а также средства автоматизации сопровождения программных продуктов (Visual SourceSafe). Это событие можно рассматривать как очередной шаг в направлении практической реализации идей проекта SAA.
И хотя требования и спецификации, изложенные в CUA, пока так и не стали международным стандартом де-юре, ориентация огромного числа производителей ПО на интерфейс MS Windows позволяет считать их таковыми де-факто.
Справедливости ради следует отметить, что для UNIX-систем, в определенном смысле являющихся конкурентом Windows, существует аналогичный «почти стандарт», представленный архитектурой XWindow.
Итак, стремление к стандартизации пользовательского интерфейса налицо, и оно обусловлено не только коммерческими интересами ведущих производителей ПО. Стандартизованный интерфейс (именно стандартизованный, а не стандартный) должен отвечать двум основным требованиям:
• обладать перечисленными выше свойствами (естественности, согласованности и т.д.);
• быть узнаваемым (или предсказуемым, что в данном случае одно и то же). Второе требование, в свою очередь, предполагает, что интерфейс содержит только стандартные базовые элементы; каждый такой элемент должен иметь «узаконенное» название и определенный перечень свойств. Например, нельзя называть меню «списком» и при этом использовать его для вывода результатов расчетов.
На первый взгляд может показаться, что стандартизация интерфейса ведет к убогому однообразию внешнего облика программных продуктов. Но ведь и Моцарт, и автор «Мурки» пользовались одними и теми же семью нотами... А программисты, знакомые с алгоритмизацией, знают, что любой, сколь угодно сложный алгоритм содержит всего три-четыре базовые алгоритмические конструкции. Так что и при создании стандартизованного интерфейса результат будет зависеть в первую очередь от «композитора» — разработчика.
И в заключение раздела еще одно замечание. Несмотря на широкое распространение графического интерфейса, он не является единственно возможным или необходимым вариантом организации взаимодействия пользователя с приложением. Поэтому и в проектах документов по стандартизации интерфейса, и в данном курсе рассматривается целый ряд вопросов, относящихся к общей методике проектирования и реализации пользовательского интерфейса.
