Назад в раздел UIDS/UIMS
Родоначальником систем интерактивного взаимодействия человека с машиной является Ульям
Ньюман (1968, Reaction Handler. A System for Interactive Graphical Programming). А впервые
название UIMS появилось в статье Д.Казика Tiger в 1982г.[5].
GKS - первый международный графический стандарт. В нем впервые зафиксированы концепции "рабочих станций" и логических устройств ввода (клавиатура, выбор, локатор, валюатор, указатель, ввод последовательности координат). К сожалению задуман во время превосходства парадигмы векторного рисования. Отсюда слабость поддержки диалога: отсутствие возможности ввода новых устройств или видоизменения изображения устройства на экране даже из прикладной программы (пользователя графического пакета), что приводит к необходимости использования в основном символьного ввода при организации диалога. Реализация диалога в GKS прерогатива прикладной программы, возможности раздельного проектирования не предполагается. Второе направление графики - растровая графика оказала чрезвычайно большое влияние на все последующее развитие интерактивных систем. Все основные черты интерфейса с пользователем на современных рабочих станциях суть производные от работ Xerox PARC: управление окнами
Многооконная технология обеспечивает пользователя доступом к большему объему информации, чем это возможно при работе с одним экраном. Окна дают доступ ко множеству источников информации. Пользователь может объединять информацию от нескольких источников, исследовать информацию на разных уровнях детализации. В мультипрограммном режиме есть
возможность управлять несколькими параллельными задачами. Вход и выход каждой задачи
отображается в разных окнах, позволяя пользователю сосредоточиться по необходимости на
каждой задаче.
Возможны реализации WMS двух типов: базовая система (Kernel System), работающая на одной машине, и сетевая (Network oriented), реализуемая на основе модели клиент-сервер.
По Майерсу [4] "Инструментарий создания пользовательского
интерфейса есть библиотека технологических интерактивных средств, дающих возможность
использовать физические устройства ввода (мышь, клавиатура, планшет . . .) для ввода значений
(таких как команда, число, положение или имя) при наличии обратной связи, отображаемой на
экране". Программист использует этот инструментарий для организации взаимодействия с
человеком. Инструментарий содержит набор функций, реализующий компоненты интерфейса
нижнего уровня такие как: меню, кнопки, зоны диалога, подокна, зоны прокрутки.
Инструментарий включает также графическую библиотеку вывода (только основные примитивы)
и обработчик событий. Тем самым есть некие механизмы и инструменты разработки, но пока нет
общей стратегии.
В научной литературе пока нет согласованного взгляда на термин UIMS - точное его значение
само является объектом исследования.
Множество требований, предъявляемых к UIMS, и критериев их оценки строится, исходя из
основной эталонной модели UIMS (см. рис.1). Эта модель представляет систему в виде двух
компонент: инструментария, используемого на стадии разработки диалога и части, относящейся ко
времени исполнения (run-time portion). UIMS обычно предоставляет способ управлять
последовательностью действий конечного пользователя. Структура диалога задается вне
прикладной программы. Это даёт возможность разработчику (дизайнеру) диалога
экспериментировать с диалоговой последовательностью без необходимости каждый раз заново
компилировать всю прикладную программу. Именно здесь принимается решения, как будет выглядеть конечный продукт. Это не строгое определение, но указание направления разработок. Приложение не должно накладывать жёстких ограничений ни на внешний вид интерфейса, ни на его идеологию; должно быть возможным реализовать в интерфейсе продукта любые идеи. Возможно ли экспериментирование с интерфейсом на ранних этапах? Автоматический дизайн. Подразумевается возможность автоматического создания дизайна пользовательского интерфейса исходя из его описания. Первый черновой вариант такого дизайна должен быть приемлем в качестве исходного варианта (ввода, входных данных) других компонент (компонент следующих уровней доводки) UIMS. Путь от описания (спецификации) через прототип к конечному варианту должен быть хорошо определён и автоматизирован. Возможно использование автоматического инструмента дизайна для изготовления различных вариантов и форм интерфейса из одного и того же описания - управление вариациями может осуществляться либо через непосредственное манипулирование, либо через системы меню, либо на командной основе (через командную строку). Выбор варианта из полученного множества - за дизайнером. Явная семантика. Семантика приложения может быть выражена в поведении (в терминах поведения) объектов и действий пользовательского интерфейса. Например, красный цвет ассоциируется с риском, а зелёный - с безопасностью. Такие ассоциативные связи могут быть выгодно использованы в интерфейсе. UIMS должна предоставлять возможность определять и по мере необходимости позже изменять подобные зависимости (отношения). Это подмножество критериев охватывает те из них, которые могут быть полезными для разработки пользовательского интерфейса. Требования. Желательно наличие инструментов, которые могли бы помочь дизайнеру интерфейса вникнуть в суть поставленной задачи, той которую призван решать (или помогать решать) конечный продукт. Эти инструменты могли бы помочь выработать модели данных и поведения пользователя при работе с ними. Содействие может оказываться при сборе информации (накапливании знаний) и управлении данными. Эти инструменты должны предоставлять средства для быстрого создания прототипа. Знания полученные на этапе выяснения требований должны использоваться для создания формального описания интерфейса. Это описание (спецификация) должно отражать требования. Повторное использование прототипа в конечной системе позволит сохранить (сэкономить) время и силы. Если требования изменятся, то частично изменится и спецификация, и поэтому возникает необходимость в средствах, которые позволили бы проследить путь от требований к спецификации, т.е. выяснить, как выходная спецификация зависит от каких- либо входных требований. Эти средства также можно использовать для проверки спецификации на предмет соответствия выдвигаемым требованиям. Техника взаимодействия. UIMS должна поддерживать широкий диапазон приложений и пользователей. UIMS должна также поддерживать широкий диапазон стилей взаимодействия: как низкоуровневые, типа командной строки, так и высокого уровня, как, например, графическое манипулирование с лексической или семантической обратной связью, непосредственное манипулирование графическими объектами. Далее мы будем использовать термин "графический ввод" для обозначения простого распознавания символов; "стандартное меню" - для меню, которое видно на экране всегда. Подгонка интерфейса. Предоставляет ли UIMS возможность настройки интерфейса конечным пользователем или разработчиком? Управление настройкой может быть лексического уровня, например, пользователь определяет, где и как расположены меню и другие интерактивные графические объекты на экране, использовать ли для привлечения внимания пользователя звуковой или световой сигнал. Управление может быть частью синтаксиса взаимодействия, т.е. структура диалога может изменяться пользователем, с тем чтобы изменять существующие команды, вводить новые, добавлять новые функциональные возможности в пользовательский интерфейс. Большинство компаний имеют "домашний стиль" взаимодействия, который они хотят распространить на все свои приложения. UIMS должна обладать достаточной гибкостью, чтобы иметь возможность воспринять (принять) внешний стиль. С другой стороны, компании, использующие одну и ту же UIMS, возможно, будут вынуждены создавать приложения в стиле, навязанном UIMS, а не в своём собственном - будет трудно придать индивидуальность продукту, если UIMS не предоставляет возможности подстройки под нужды конкретного класса продуктов. Дизайнер должен иметь возможность задать индивидуальный стиль взаимодействия и представления. Причём, должно быть возможно задать любой стиль только раз и затем использовать его в любых последующих разработках (пользовательских интерфейсах). UIMS должна отделять прикладную часть программы от части пользовательского интерфейса: каждый раздел должен писаться отдельно. Управление системой может осуществляться как из интерфейсной части (посредством UIMS), так и из прикладной части. Две модели. UIMS обычно состоит из двух основных модулей: препроцессора разработки и реализации пользовательского интерфейса и рабочей (run-time) среды, в которой и работает интерфейс пользователя. Разделение пользовательского интерфейса прикладной части. UIMS должна отделять прикладную часть программы от интерфейсной. Должно быть возможно работать над этими частями раздельно. Осуществляет ли управление UIMS или приложение? Управление системой может осуществлять либо UIMS - посредством управляющих действий со стороны интерфейсной части, либо прикладная часть. Приложение может запрашивать у пользователя ввод, либо же инициатива во взаимодействии принадлежит пользователю. Если управление принадлежит UIMS, то обычно она вызывает прикладные модули по мере необходимости в ответ на действия конечного пользователя. Такое управление можно назвать "внешним". Если управление всегда осуществляется из прикладной части, то такое управление можно назвать "внутренним". Третий вид управления - пользователь полностью управляет системой. Настоящая UIMS предоставляет средства для осуществления внешнего управления, в то время как инструментарий предоставляет средства только для создания системы с внутренним управлением. UIMS должна допускать возможность ввода множеством разных способов. Пользователь может использовать только одно устройство ввода, а UIMS сама должна решать - которое именно (мышь или клавиатура). Пользователь может взаимодействовать со множеством устройств ввода, UIMS должна учитывать возможность такой ситуации и правильно её обрабатывать. Используемый метод зависит от того, как UIMS логически представляет ввод, а не от того, как он реализован. Инструменты. Этот раздел охватывает инструменты для разработки интерфейса. Эти инструменты дают возможность интерактивного построения пользовательского интерфейса. Возможен и, вероятно, более предпочтителен вариант, в котором дизайнеру вообще не надо писать программный код самому - необходимый для компоновки в окончательную систему код будет порождён автоматически. В этом случае дизайнер может изменять интерфейс, не меняя никакого кода, и приложение можно сразу же собирать с этим новым интерфейсом. Правка на ходу (в приостановленном состоянии). Редактор интерфейса должен позволять приостанавливать работу интерфейса конечного пользователя, подправлять его параметры и спецификации, и запускать его работу дальше - с того момента, на котором его работа была ранее прервана. Повторно используемые компоненты. UIMS может предоставлять инструменты для повышения повторной используемости программных компонент - цели весьма желательной. Она может запоминать определения и доставать (из своего хранилища) компоненты, которые можно использовать повторно. Должна иметься возможность задания семантики программных модулей, с тем чтобы дизайнер мог найти модуль с соответствующими функциями. Компоненты, допускающие многократное использование, повышают продуктивность (производительность) работы дизайнера; предоставляют возможность стандартизации и гарантию того, что все составные части интерфейса полностью проверены. Препроцессор. Желательно, чтобы UIMS предоставляла возможность оттранслировать спецификацию диалога в программу на стандартном языке высокого уровня. Сложность программирования. Использование таких возможностей, как интерактивный дизайн диалога и пробная работа, избавляют разработчика диалогов от необходимости формального программирования. Единственно необходимым остаётся только программирование прикладной части системы. Ясен пень, если прикладная часть создаётся отдельно и другим человеком, то дизайнеру интерфейса вообще не надо писать никаких программ. Эффективно интерфейс можно было бы создать полностью средствами UIMS. Система может быть формально описана в терминах языка типа BNF или же конечных автоматов. Последняя модель, вероятно, более проста для понимания человека, не искушённого в программировании. Автоматическое создание заглушек. UIMS должна автоматически создавать программные "заглушки" для отсутствующих процедур обработки событий. Система при обращении к такой несуществующей процедуре может, например, просто выводить на экран сообщение, что вызвана конкретная процедура. Макроопределения. Макросы суть сокращённые записи кусков программного кода. Макроопределения раскрываются в полную свою форму препроцессором или непосредственно при исполнении программы. Макрос определяется в процедуре и хранится в библиотеке. Библиотеки макроопределений позволяют использовать их как строительные блоки для других приложений. Макросы могут использоваться в рекурсивной форме. Уровень детализации описания. Как много деталей должен задавать в описании дизайнер? Можно ли заставить UIMS сконструировать интерфейс, предоставив ей только список операций и ничего более? Уровень детализации должен быть регулируемым, чтобы можно было, задав изначально общее описание и получив продукт в некоем виде, далее его довести до желаемого состояния, используя более высокий уровень детализации. Система должна допускать любой уровень детализации и предоставлять дизайнеру полную свободу выбора уровня, на котором он будет вести работу. На всех уровнях детализации должны быть заданы разумные умолчания, которые можно по мере необходимости изменять. Этот раздел охватывает многообразие переменных и выражений доступных разработчику. Типы, определяемые пользователем. Прикладной программист или дизайнер диалога должны иметь возможность пользоваться средствами языка программирования, на котором пишется система (например, "C"), для создания различных структур данных, например, записей событий. Проверка допустимости значений. Проверка типа и допустимости значений облегчает обработку данных вводимых пользователем. Эту проверку может осуществлять либо UIMS, либо программный код дизайнера интерфейса. При обнаружении ошибки должно выводится сообщение о таковой или подсказка о необходимых свойствах ожидаемых данных. Выражения. Выражения могут быть как арифметическими, так и частью диалога. Вычисляются ли значения выражений во время работы UIMS или конечной системы? Производятся ли вычисления прикладной частью или внешними программами, написанными на другом языке? Следует учитывать возможность использования графических объектов в качестве именованных переменных в вычислимых выражениях. Умолчания. Если значение параметра пользователем не задано, система должна быть способна использовать значение по умолчанию, определённое разработчиком интерфейса. Этот раздел охватывает взаимодействие аппаратного и программного обеспечения системы на низком уровне. Затрагиваются вопросы программной эмуляции аппаратуры и использования мультимедиа. Переносимость. Раз UIMS перенесена на некоторую аппаратную платформу, то и пользовательский интерфейс, и конечное приложение должны на ней работать. Низкоуровневое управление. Иногда возникает необходимость управлять устройствами на низком уровне из контекста языков высокого уровня. В ОС UNIX разработчик должен был бы переделывать устройства в ядре, но это очень непросто сделать в UIMS. Возможно использование низкоуровневого управления, чтобы получить отклик, который соответствует используемой технике взаимодействия. UIMS должна быть достаточно мощной, чтобы было возможно описать полный спектр интерактивных методик, но качество взаимодействия будет зависеть от того, насколько низкого уровня управление графическими устройствами ввода-вывода может быть использовано в диалоговой системе. Поддержка UIMS такой деятельности может оказаться весьма полезной. Но необходимость в задании управления на таком уровне должна отсутствовать - дизайнер не должен об этом думать, если он того не хочет. Конкурирующие потоки ввода-вывода. UIMS сама должна управлять конкурирующими потоками ввода-вывода различных устройств, с тем чтобы избавить от этой сложной задачи и дизайнера интерфейса, и прикладного программиста. Большинство языков программирования последовательны по природе, поэтому именно UIMS должна управлять вводом одновременно с разных устройств. Оказывается ли взаимодействие с пользователем блокированным во время производства системой вычислений? Пользователь всегда должен иметь возможность прервать вычисления и снова начать взаимодействовать с системой. Редактирование ввода. Каждый диалоговый элемент (диалоговая единица, элементарный диалог), связанный с низкоуровневым вводом, должен предоставлять возможность отменить последний ввод. В диалоге на более высоком уровне должно быть возможно "удалить последний параметр", не вызывая этим никаких ошибок. Мультимедиа. UIMS должна предоставлять возможность использовать широкий спектр устройств ввода-вывода, включая средства мультимедиа и виртуальной реальности. Должно быть также возможно добавлять в систему новые средства ввода-вывода. Интерсено в этой связи было бы задать такой вопрос: "Насколько сложно добавить в систему ввод голосом?". Диалоговая последовательность. Допускает ли UIMS неограниченную свободу движения по диалогу? Диалог может быть "плоским" - так что большинство команд доступны во входной точке диалога. Как только выбор сделан, этот путь должен быть завершён прежде, чем пользователь вернётся ко входной точке. Диалог может быть:
X Window. Система X Window (или просто X), разработанная в MIT, заслужила неимоверно широкую популярность, особенно в сообществе UNIX. В X базовая оконная система предоставляет высокопроизводительную графику в иерархически организованное множество окон изменяемых размеров. Вместо конкретного пользовательского интерфейса X предоставляет набор примитивов, поддерживающих несколько стилей и придерживающихся некоторых идеологий. В отличие от большинства оконных систем базовая система в X определяется протоколом клиент-сервер: асинхронная потоковая (stream-based) межпроцессная связь замещает традиционный интерфейс, построенный на подпрограммных и системных ("ядерных") вызовах, предоставляя возможности использования распределённой графики. Использование X Windows в UIMS резко повышает её аппаратную и программную переносимость. Графика. Эта область связана с графическими возможностями UIMS. UIMS может оказаться способной использовать только свой собственный графический пакет, либо же она может быть достаточной гибкой, что её можно настроить на работу с любыми графическими стандартами. Это может быть очень важно, если приложение уже использует какой-либо графический стандарт, такой, например, как GKS, или требуется усовершенствовать систему и добавить в неё работу с PHIGS или PHIGS+. Важно знать, какую схему использует UIMS для задания точки на экране: система координат задаёт расстояния в пикселях или в физических единицах, и т.п. Перевод существующего приложения на новый стандарт или подстройка его под другой графический пакет может отнять много времени. Многопользовательский диалог. Это метод предоставления возможности многим пользователям одновременно работать в распределённой вычислительной среде. Это охватывает возможные связи (коммуникации, взаимодействия) UIMS с другими объектами (процессами, операционной системой, etc.) в компьютерной системе. Связь с операционной системы. Предоставляет ли UIMS возможность легко доступаться к средствам операционной среды, в которой происходит работа? Легкое общение с операционной системой не следует считать деятельностью, достойной поощрения, - использование особенностей операционной системы может ухудшить переносимость конечного продукта. UIMS должна ограждать и оберегать дизайнера от общения с системой на низком уровне. Однако, такая возможность всё же должна присутствовать (по крайней мере, это должна использовать сама UIMS), поскольку доступ к средствам операционной системы даст возможность, например, использовать межпроцессный обмен данными и ускорить работу с графикой. Должна существовать возможность увязывать вывод сообщений с определёнными аппаратными событиями, например, с выводом графического документа на печать. Удобство работой с системой очень сильно зависит от того, как много помощи оказывается и какого она рода, какие усилия должны быть приложены со стороны разработчика, для получения различных уровней систем информационного вспоможения: обычная система подсказок, встроенная система обучения, обеспечения хорошего стиля разработок. Обратная трассировка. Было бы весьма полезен инструмент, который позволял бы проследить процесс создания продукта в обратном направлении, получить из конечного продукта его формальное описание в терминах входного языка. Это некая разновидность декомпиляции. Производительность. Производительность системы - важный фактор, которым пренебрегать нельзя. Система может быть лёгкой в использовании, но оказаться слишком медленной, что сведёт всё удобство на нет. Протоколирование ввода и воспроизведение "записи". Должна предоставляться возможность вести и записывать протокол взаимодействия пользователя с системой, с учётом всех происходящих в системе событий, проверкой корректности и регистрацией ошибок ввода, пауз, запросов помощи и т.п. Этот протокол должно быть возможно использовать для ввода в UIMS вместо реального ввода с устройств, с тем чтобы можно было воспроизвести сеанс работы, проанализировать его и полученные в его ходе данные, выявить в системе ошибки, слабые места и т.п. Всё это должно помочь дизайнеру улучшить интерфейс. Автоматическая оценка качества и управлением им. UIMS должна предоставлять средства для проверки и оценки на всех стадиях разработки. Желательно наличие инструментов автоматической оценки качества интерфейса по различным критериям, таким как планировка экрана, последовательность, стилистичность, модель пользователя и использования устройств ввода. Эти инструменты могут предупредить о потенциальных проблемах. Если компания имеет свой стиль, предписывает при разработке интерфейсов руководствоваться какими-либо принципами, то такие инструменты могут проверить разработку на соответствие этим требованиям.
ной классификации - третья ("смешанная")), введённая на конференции в Seeheim (1983), в соответствии с которой UIMS состоит из трёх компонент:
 Рис.1. Уровни в системах разработки пользовательского интерфейса Конкретные реализации моделей основываются на различных способах спецификации интерфейса, среди которых можно выделить следующие типы:
Графическая спецификация связана с определением интерфейса с помощью размещения объектов на экране (визуальное программирование, программирование демонстраций, программирование по примерам). Она проста для использования не программистами, но:
Возможные реализации:
"Непосредственное манипулирование" (DM - Direct Manipulation) Во многих отношениях технология непосредственного манипулирования рассматривается как новая генерация методов программирования в области проектирования интерфейса с пользователем, имеющих такое же значение как разработка языка четвёртого поколения для разработки баз данных. Начало этому подходу положили исследования, проводимые в центре Palo Alto корпорацией Xerox (Xerox PARC). Что же такое непосредственность? Можно выделить четыре аспекта этого понятия: Семантическая непосредственность. Определяется через "расстояние" между пользовательскими намерениями и операциями предоставляемыми системой. Пользователю важно, что:
Операционная непосредственность. На уровне диалога можно рассматривать временной аспект непосредственности. Диалоговая последовательность не обладает нужной непосредственностью, если пользователь хочет воспользоваться последовательностью действий, не предоставляемых системой. Например, выбор пиктограммы с помощью мыши и получение возможности тут же передвинуть её по экрану является реализацией непосредственности в операционном смысле, поскольку действие не подразделяется на дополнительные команды ввода (не надо нажимать клавишу "двигать"). Но не просто определить последовательность действий в намерениях пользователя. Большинство DM систем пытаются сделать все видимые объекты доступными способами инициируемыми пользователем и поддержать развитие последовательности действий непосредственной обратной связью на каждом шаге. Формальная непосредственность. Этот аспект относится к естественности восприятия (немедленной, непосредственной понимаемости) системного вывода, простоте и эффективности обработки элементов ввода и устройств (клавиатура, кнопки, работа с мышью и т.п). Увеличению степени формальной непосредственности может способствовать использование представления в виде пиктограмм при выборе объектов и функций вместо символических имён команд, хорошо структурированный экран и понятное обозначение функциональных клавиш. Ещё одним важным требованием является использование принципа "Что вы видите - то и получите" (WYSIWYG - What You See Is What You Get), в соответствии с которым на экране формируется именно то изображение, которое будет получено при конечной выдаче. Компоненты DM интерфейса. На верхнем уровне DM систем обычно находится одна из метафор графического представления (типа метафоры письменного стола, конкретный объект). Через этот верхний уровень пользователю доступны прикладные программы, работающие на окнах. В окнах, подокнах и компонентах экрана доступны различные средства выбора объектов, функций инициирования и управления. Типичными компонентами используемыми для манипуляций с объектами и управляющими функциями являются:
DM часто называют интерактивной технологией с отсутствием режимов. Это конечно не так, но верно, что пользователь получает доступ к множеству функциональностей, работая в нормальном контексте, команды и режимы ввода, присущие командно-ориентированным редакторам в этой технологии по возможности не используются. Обычной синтаксической композицией взаимодействия в DM является "выбор объекта", за которым следует "активация функции". Переход в режим "объект выбран" отражается изменением яркости объекта, после активации функции возможен переход в новый режим (например ожидания ввода параметра), отображаемую изменением формы курсора.
В заключении приведём в качестве примера описание системы UIMS XFaceMaker3 фирмы Non
Standard Logics, созданной на базе OSF/Motif и X Window System.
Ситуация в области разработки систем построения и управления интерфейсом пользователя в
наши дни напоминает ситуацию с графикой до выработки международных стандартов: нет единой
терминологии, есть разные подходы к построению моделей (лингвистический, графический),
которые часто пересекаются.
Имеется несколько открытых проблем в разработке UIMS, которые можно определить как:
Появившиеся стандарты (пока де-факто), по крайней мере на нижних уровнях систем (X-Window и, в какой-то степени OSF/Motif), и активность разработчиков многих фирм дают надежду, что ситуация в ближайшее время может измениться к лучшему. Перспективы в области разработки человеко-машинных интерфейсов в настоящее время связаны, главным образом, с такими направлениями развития новых информационных технологий, как:
Исследованиями и разработками таких систем занимаются в ведущих центрах по изучению человеко-машинного интерфейса, в частности, в Xerox PARC. Фундаментальные концепции вездесущих систем были рассмотрены на конференции Еврографика'90 в приглашённом докладе У.Ньюмана (Rank Xerox EuroPARC). Под термином "вездесущие системы" в настоящее время понимаются такие системы, которые включают в себя огромное количество миниатюрных, но достаточно мощных вычислительных устройств, повсюду окружающих человека: прикреплённых к документам, встроенных в окружающую мебель и т.п. Интегрируя такие системы с цифровым звуком и видео, можно получить очень мощные средства, например, для персональной автобиографической памяти. Последние достижения в области вездесущих систем оказывают большое влияние на проектирование и разработку интерактивных систем. В таких системах большое количество информации проходит без человеческого вмешательства: основной результат проектирования может обеспечить пользователю адекватную концептуальную модель поведения системы, а не поддержку традиционного взаимодействия с использованием экрана.
|
| ||
|