Микроуровень пользовательского интерфейса

В уже упомянутой книге Р. Уаттса [13] указаны шесть режимов ведения диалога с пользователем:
1) выбор из меню;
2) вопрос-ответ;
3) ответы с указанием и заполнение бланков;
4) язык команд;
5) естественный язык;
6) запрос с позиционным выбором.
Каждый из режимов наиболее удобен при определенном сочетании условий, среди которых подготовленность пользователя, время освоения режима, его выразительные свойства, характер передаваемой информации, решаемая пользователем задача. Но наиболее важным условием, которое подчеркивается, в частности, в и с которым мы вполне согласны, является характер принятия инициативы в диалоге. В соответствии с этим условием все режимы диалога можно представить в виде следующей типологии.
Если инициативу принимает на себя система, ограничивая синтаксис ответа пользователя, то такой режим "вслед за" можно назвать ЗАПРОСНО-ОТВЕТНЫМ. Его вариантами являются выбор из меню, запрос с позиционным выбором, вопрос-ответ, заполнение бланков и ответы с указанием.
Если инициатива отдается пользователю и он более свободен в построении высказываний на некотором командном языке, то такой режим можно назвать ДИРЕКТИВНЫМ. Примерами директивного режима являются язык команд и диалог на естественном языке.
Естественно, что процесс работы с системой часто бывает неоднородным в том смысле, что задача пользователя может изменяться от начала к концу диалога. Это означает, что инициатива может и должна переходить "из рук в руки". Такой диалог проектируется из частей как запросно-ответного, так и директивного режимов и называется СМЕШАННЫМ.
Многие разработчики программного обеспечения не видят важности правильного выбора режима диалога, ограничиваясь созданием одного режима, чаще всего ВЫБОРА ИЗ МЕНЮ. Именно этот режим часто ассоциируется в их сознании с диалогом. Между тем, задача выбора режима диалога не так элементарна и прямо коррелирует с вероятным объемом тиражирования созданной программы.
В связи с чрезвычайной распространенностью меню важно, например, очертить область применения этого режима. Такой областью являются исключительно задачи так называемого навигационного типа: выбор и поиск требуемого режима или программы, определение требуемых параметров и содержания процесса, т.е. все те случаи, когда есть набор альтернативных объектов и надо осуществлять выбор одного или нескольких из них.
По уровню сложности встречаются МЕНЮ трех типов: ПРОСТОЕ, МНОГОУРОВНЕВОЕ и СЕТЕВОЕ.
ПРОСТОЕ МЕНЮ - это список пунктов, с каждым из которых связана определенная операция. Попытка использовать простое меню для организации выбора из более чем 5-9 объектов ведет сначала к психологическим сложностям (так как теряется его основное свойство - простота и наглядность), а затем и к переполнению экрана.
Поэтому в диалоговых системах часто используется МНОГОУРОВНЕВОЕ МЕНЮ с древовидной структурой. При этом вершинами "дерева" служат простые меню, а переход к его ветвям реализуется выбором одного из пунктов простого меню. Построение многоуровневых меню прямо связано с проблемой "прозрачности" системы для пользователя. Дело в том, что в многоуровневом меню можно просто "заблудиться". Поэтому наиболее совершенные системы содержат режим подсказки, в котором пользователю демонстрируется полная карта (ДЕНДРОГРАММА) меню и место пользователя на ней в данный момент. В главе 1 мы уже писали об этом подходе, различающем интерфейсы локального и глобального контекстов.
Еще одна проблема состоит в выборе уровня жесткости дендрограммы. Основной вопрос данной проблемы формулируется следующим образом: "Всегда ли, чтобы достичь определенного пункта меню, пользователь должен совершать одинаковую последовательность выборов? И если нет, то не может ли он с помощью какой-нибудь процедуры очутиться сразу в требуемой вершине?" Эта проблема нашла положительное решение посредством дополнительного режима директивного попадания в требуемую вершину многоуровневого меню.
Третий тип МЕНЮ - СЕТЕВОЕ - являет собой развитие многоуровневого меню, когда ветви дерева пересекаются и образуется дендрограмма, позволяющая делать циклический обход меню по разным маршрутам. Сетевая структура меню открывает перед разработчиками интерфейса и пользователями новые возможности. В частности, такое меню позволяет выйти за рамки чисто навигационных задач. С его помощью могут быть реализованы справочные и обучающие системы, построенные на принципах гипертекста. В этом случае каждое простое меню, представленное в виде фрагмента гипертекста, содержит ключевые слова, каждое из которых является выходом в другое простое меню. Это новый уровень предъявления справочного текста, на котором пользователь в зависимости от собственных потребностей и знаний может самостоятельно строить стратегию ознакомления со справочным или учебным материалом. Конечно, при этом возникают и новые проблемы. В частности, по сравнению с обычным постраничным строением справочного текста, пользователю сложнее строить его целостный образ. Однако, эта проблема также может быть решена на основе более развитой дендрограммы гипертекста. На ней должно демонстрироваться не только актуальное положение пользователя на карте меню, но и прочерченная в данном сеансе траектория перемещений. Быть может, необходима также и библиотека всех перемещений пользователя в каждом сеансе работы с системой. Кроме этого, нужна и суммарная карта, демонстрирующая все те вершины и ветви, с которыми пользователь уже ознакомился, и те, где ему еще не удалось побывать. В сетевом меню преодолевается его подчиненная, служебная функция, оно само становится ценным инструментальным средством, выполняющим самостоятельные задачи.
Тем более это касается ситуаций, возникающих в связи с параллельным проектированием. Ведь объединение инструментальных программных средств из разных этапов создания новых изделий объективно ведет к значительному увеличению числа разнообразных режимов, файлов, разделов информационно-поисковой системы. Дендрограмма меню может оказаться очень сложной, если не сказать запутанной - с петлями и тупиками. Очевидно, что она будет нуждаться в дополнении богатыми режимами подсказки и помощи. Просто отображения дендрограммы меню недостаточно. Всегда считалось, что уже сама по себе визуализация процесса может помочь его пониманию. Но вот на основании данных из [16] можно сказать, что схемное описание объекта значительной сложности также начинает не срабатывать, если задача пользователя состоит в том, чтобы определить проблемы, содержащиеся в схеме. Интерфейс сам должен отображать, хотя бы выделять цветом, те части схемы, в которых есть какое-либо отличие от стандартного протекания процесса. Нечто подобное происходит в современных системах упаковки информации на гибких дисках, когда отображается процесс перераспределения файлов, задержек в исполнении процесса, выявления дефектных участков диска. Более сложный вариант отображения такого же типа реализован в инструментальном средстве TeamWork/SIM компании Garde Technologies Inc. В целом данную процедуру можно отнести и к САПР. Одна из ее функций - отображение модели программных процессов на модель тех или иных аппаратных реализаций. Представление пользователю учитывает "состязание" аппаратных ресурсов, что позволяет выявлять, какие части проектируемого оборудования будут функционировать медленнее из-за неудачного выбора аппаратных средств. В дендрограмме меню может, например, демонстрироваться кратчайший путь к тому или иному пункту или те замедления в поиске, которыми грозит уже избранная пользователем стратегия поиска.
Очерченные проблемы режима выбора из меню во многом характерны для всех запросно-ответных диалогов. Новый пласт проблем открывается в тот момент, когда пользователь от задач навигационного типа переходит к выполнению расчетных задач, вводу числовых или каких-либо иных данных. Прежде всего это касается РЕЖИМА ОТВЕТОВ С УКАЗАНИЕМ и ЗАПОЛНЕНИЕМ БЛАНКОВ, а также ЗАПРОСОВ по ОБРАЗЦУ с ПОЗИЦИОННЫМ ВЫБОРОМ. Часто такого рода диалог используется в базах данных или тогда, когда информация может быть отображена в виде таблицы или электронного бланка. Конечно, такой диалог требует от пользователя больше знаний и умений, чем выбор из меню. И инициатива здесь в большей степени распределена между ним и компьютером. Помощь пользователю при работе с бланками и таблицами относится прежде всего к индикации места, куда должна быть введена информация, и мест, где отобразятся последствия от ее введения. В том случае, когда ввод должен быть осуществлен в несколько мест, отображению подлежит также нормативная последовательность введения информации. Размеры современных бланков и таблиц могут быть очень значительными, не входить целиком на экран дисплея. Поэтому важным является также манипулирование масштабом бланка, его сворачивание и растяжение, детализация, а также построение новых бланков. В настоящее время широкое распространение получили так называемые крупноформатные электронные таблицы (КЭТ). Самыми популярными считаются Excel 4.0 - пакет фирмы Microsoft [6] и пакет Lotus 1-2-3 фирмы Lotus Development [18]. Расчеты с помощью этих пакетов помимо числовых значений поддерживаются хорошими визуализациями результатов. Например, Lotus 1-2-3 позволяет получить шесть видов графических изображений результатов расчета: линии; столбцы, расположенные рядом друг с другом; столбцы друг на друге; двухкоординатные графики; круги с заштрихованными и съемными секторами.
При работе с самой КЭТ пакет Lotus 1-2-3 предоставляет ряд новых функций. Прежде всего это:
а) сокращение длины алгоритма ввода; там, где в прежних версиях требовалось несколько шагов, достаточно одного "нажатия" на виртуальной панели управления;
б) пользователю не только показывают место, в котором будет зафиксирован результат вычисления, но он сам может его выбрать с помощью процедуры autosum;
в) реализованы сжатие и растяжка КЭТ, что позволяет их рассматривать с разной степенью детализации;
г) могут быть объединены данные из разных КЭТ.
Отдельную своеобразную сферу диалоговых режимов представляют ЯЗЫК КОМАНД и ДИАЛОГ на ЕСТЕСТВЕННОМ ЯЗЫКЕ. Трудности в развитии этих режимов - по большей части психолингвистического свойства. Можно сказать, что два названных режима представляют собой своего рода полюса шкалы, при движении по которой в направлении естественного языка растет интеллектуальная составляющая пользовательского интерфейса. При этом растет также и доля программно-аппаратных ресурсов, уходящих на поддержку интерфейса. Что растет не очень значительно, так это - эффективность самого диалога. На полюсе диалога на естественном языке интерфейс превращается в своего рода игрушку, "пожирающую" массу ресурсов, но все же дающую пользователю ограниченные преимущества. Те же цели могут достигаться гораздо меньшими ресурсами. Поэтому в последнее время раздаются голоса, негативно оценивающие перспективы широкого распространения диалога на естественном языке. Перспективы же языка команд более многообещающи. На описанной шкале можно определить благоприятный отрезок, внутри которого может быть обеспечена как компактность, легкость и логичность языка команд, так и минимум интеллектуального инструментария, обеспечивающего употребление синонимов и других естественных для пользователя свойств языка диалога.
Может оказаться, что естественный диалог является очередной иллюзией хотя бы потому, что компьютер предполагает диалог гораздо более визуализированный, чем естественное общение. И у такого диалога масса дополнительных очень удобных свойств. Ведь показать можно намного больше, чем рассказать.