Начало интерактивных вычислений и, следовательно, исследование человеко-машинного интерфейса принято отсчитывать с 1959 г., когда на конференции Юнеско по обработке информации Г.Стречи предложил режим разделения времени при решении задач на компьютерах.
По мере роста мощности компьютеров росли и затраты на диалоговую компоненту программного обеспечения. Вопрос эффективности использования машин обострился во время стремительного выхода на рынок рабочих станций, объединивших интерактивность с графикой. Термин эффективность с тех пор изменил свое значение - если раньше он отражал такие характеристики как процессорное время и объем занимаемой памяти, то теперь под ним понимают простоту разработки, легкость сопровождения и удобство работы с программой. Поэтому затраты на исследование и разработку пользовательского интерфейса являются оправданными. В настоящее время большие усилия прикладываются к разработке методов и созданию инструментальных средств в рамках систем, получивших название UIMS - User Interface Management System.
Основные концепции UIMS были выработаны на ряде семинаров:
· 1983 Workshop on "User Interface Management Systems",
Seeheim, FRG;
· 1986 ACM SIGGRAPH Workshoop on "Software Tools for User
Interface Management Systems", Seattle, USA;
· 1987 Glasgow University Workshop on "User Interface
Management Systems";
· 1990 ESPRIT/Eurographics International Workshop on "User
Interface Management Systems and Environments", Lisbon.
Традиционный графический подход к интерфейсу с пользователем связан с работами Сазерленда, Ньюмена и др. [120,], в котором взаимодействие базируется на использовании графического дисплея с регенерацией и светового пера. Дальнейшее развитие графического диалога связано с прогрессом в области систем интерактивной машинной графики, который привел к регламентации в виде международных стандартов.
GKS - первый международный графический стандарт. В нем впервые зафиксированы концепции "рабочих станций" и логических устройств ввода (ЛОКАТОР, ШТРИХ, ДАТЧИК, ВЫБОР, УКАЗКА и КЛАВИАТУРА). К сожалению GKS был задуман во время превосходства парадигмы векторного рисования. Отсюда слабость поддержки диалога: отсутствие возможности ввода новых устройств или видоизменения изображения устройства на экране даже из прикладной программы (пользователя графического пакета), что приводит к необходимости использования в основном символьного ввода при организации диалога. Реализация диалога в GKS прерогатива прикладной программы, возможности раздельного проектирования не предполагается.
Второе направление графики - растровая графика оказала чрезвычайно большое влияние на все последующее развитие интерактивных систем. Все основные черты интерфейса с пользователем на современных рабочих станциях суть производные от работ по Xerox Park:
· управление окнами;
· использование графических символов ("икон") для
представления объектов;
· стиль взаимодействия, называемый непосредственным манипулированием;
· популярность "мыши" как устройства позиционирования на экране;
· объектно-ориентированный стиль программирования.
С тех пор система классификации инструментария для создания и управления пользовательским интерфейсом рассматривается на трех уровнях:
· Системы управления окнами (WMS-Window Manager System);
· Специализированный инструментарий;
- обычный (MacIntosh, SunView ј),
- объектно-ориентированный (Smalltalk-80, Andrew,
InterView).
· Системы управления пользовательским интерфейсом.
В следующих разделах будут даны краткие характеристики, статус и функциональное описание каждого из этих уровней.
Многооконная технология обеспечивает пользователя доступом к большему объему информации, чем это возможно при работе с одним экраном. Окна дают доступ ко множеству источников информации. Пользователь может объединять информацию от нескольких источников, исследовать информацию на разных уровнях детализации. В мультипрограммном режиме есть возможность управлять несколькими параллельными задачами. Вход и выход каждой задачи отображается в разных окнах, позволяя пользователю сосредоточиться по необходимости на каждой задаче.
WMS операционная среда связанных с окнами ресурсов управления
осуществляет поддержку:
· перекрывающихся окон (прямоугольных областей экрана);
· различных устройств ввода (цифровых и аналоговых);
· курсоров;
· шрифтов.
Интерфейс со стороны оператора и прикладной программы содержит команды заведения/уничтожения окон, изменения их размеров и положения, поднятие наверх, сжатия окна до пиктограммы и восстановления. Содержит графическую библиотеку вывода (только основные примитивы) и обработчик событий. Тем самым есть некие механизмы для реализации пользовательского интерфейса.
Возможны реализации WMS двух типов: базовая система (Kernel System), работающая на одной машине, и сетевая (Network oriented), реализуемая на основе модели клиент-сервер (client-server model).
По Майеру [103], "Инструментарий создания пользовательского интерфейса есть библиотека технологических интерактивных средств, дающих возможность использовать физические устройства ввода (мышь, клавиатура, планшет...) для ввода значений (таких как команда, число, положение или имя) при наличии обратной связи, отображаемой на экране". Программист использует этот инструментарий для организации взаимодействия с человеком. Инструментарий содержит набор функций, реализующий компоненты интерфейса нижнего уровня такие как: меню, кнопки, зоны диалога, подокна, зоны прокрутки.
Возможные модели управления, по терминологии конференции 1982 г. в Сиэтле:
1. Внутренняя (прикладная программа вызывает подпрограмму при необходимости ввода/вывода). Все управление диалогом сосредотачивается в прикладной программе, которая должна создаваться с учетом этого факта.
2. Внешняя (интерфейсные процедуры обращаются к прикладной программе в случае наступления требуемого события).
3. Смешанная, включающая модули с управлением по той и другой модели.
Пути реализации:
· механизм обратного вызова (прикладная программа организована
как набор процедур вызываемых инструментарием);
· разделяемая память;
· передача сообщений;
· механизм обработки событий.
Дальнейшее развитие инструментария привело к появлению понятия Widget (заготовка) - объекта более сложного, чем перечисленный выше набор простых средств ввода в прикладную программу, хотя и включающих в себя эти средства. Такой инструментарий не стандартизован, различные фирмы (Apple, Sun etc.) предлагают существенно разный набор средств, как по номенклатуре, так и по функциональным возможностям. В качестве примера рассмотрим набор простых, составных и дополнительных заготовок, предоставляемых программным продуктом OSF/Motif.
Основные:
Область рисования | графическое пространство |
Разделитель | линии разделяющие области |
Метка | статический текст |
Шкала | слайдер для получения числа |
Зона прокрутки | управление прокруткой |
Три типа Кнопок | управляющие кнопки с различным статусом |
Каскадные Кнопки | кнопки для каскадных меню |
Необязательные поля | отображение перечислимых значений |
переменной | |
Текст | ввод и редактирование текста |
Команды | клавиатура с описанием |
Составные:
Доска объявлений | панель с произвольным размещением |
объектов | |
Экранная форма | форма размещения объектов с |
выравниванием | |
Список | список строк |
Вертикальное подокно | столбец с изменяемой высотой |
СтрокаСтолбец | объект с ограничениями по строкам и |
столбцам | |
Зона меню | область меню для выпадающего меню |
Кадр | контейнер для поддержки 3D обрамления |
Дополнительные:
Прокрутка текста | область прокрутки текста |
Прокрутка списка | область прокрутки списка |
Окно прокрутки | обобщенная область прокрутки |
Радио поле | набор радио кнопок |
Поле выбора | выбор из списка строк |
Поле выбора файла | специализированная область селектирования |
файлов | |
Основное окно | прикладное окно верхнего уровня |
Поле диалога | транзитное поле диалога |
Диалог в экранной | транзитное поле диалога для экранных |
форме | форм "выпадающее"/"выпрыгивающее" меню |
Сообщение/ | зона диалога для печати сообщений |
предупреждение |
Несмотря на явное облегчение создания интерфейса пользователя с помощью такого инструментария, сейчас ставится задача создания интегрированной среды разработки и управления диалогом. Основной целью таких систем является отделение процесса конструирования интерфейса от разработки прикладной программы.
В научной литературе пока нет согласованного взгляда на термин UIMS - точное его значение само является объектом исследования. Одна из версий принадлежит Майерсу: "Система проектирования интерфейса пользователя есть интегрированный набор средств, помогающих программисту в создании и управлении различными интерфейсами пользователя. Эти системы обычно называют системами управления пользовательским интерфейсом (UIMS - User Interface Management Systems), но предпочтительнее называть их системами проектирования (UIDS - User Interface Development Systems), поскольку UIMS ассоциируется только с частью системы, работающей во время исполнения программы (но не с частью, используемой во время разработки), или с системами, включающими явные компоненты управления диалогом. UIDS обеспечивает как разработку, так и реализацию интерфейса и, таким образом, покрывает более широкий класс программ".
Основной концепцией UIDS является идея строгого разделения интерфейса и прикладной программы. В идеале она должна поддерживать все стили диалога и упрощать построение сложных интерфейсов. UIDS должен обеспечивать язык определения интерфейса для представления требуемого диалога и генератор, которой автоматически создает необходимый код из исходного определения в этом языке. Эти функции во многом похожи на функции компилятора или интерпретатора для обычных языков программирования.
Можно выделить три объекта, для каждого из которых ставятся различные цели при разработки UIDS.
Наиболее часто используется модель, введенная на конференции в Seeheim, в соответствии с которой UIMS состоит из трех КОМПОНЕНТ:
· система представления, обеспечивающая низкоуровневый ввод
и вывод;
· система управления диалогом, обрабатывающая лексические
единицы, получаемые в системе представления, в соответствии с
синтаксисом диалога;
· модель интерфейса прикладной программы, представляющая
семантику диалога и управляющая функциональностью прикладной
программы.
Структурная схема компонент UIMS/UIDS представлена на рис. 0.4.26.
Конкретные реализации моделей основываются на различных СПОСОБАХ
СПЕЦИФИКАЦИИ интерфейса, среди которых можно выделить следующие типы:
· языковая;
· графическая;
· автогенерация по спецификации прикладной задачи;
· объектно-ориентированный подход.
Каждая из этих спецификаций имеет свои особенности. В языковой
используется спецязык для спецификации синтаксиса интерфейса. Такими
языками могут служить:
· сети меню;
· диаграммы состояний и переходов;
· контекстно-свободные грамматики;
· языки событий;
· декларативные языки;
· обычные языки программирования;
· объектно-ориентированные языки.
Этот подход приложим к широкому кругу прикладных задач. Его недостатком является то, что разработчик диалога должен обладать профессиональной программисткой подготовкой.
Графическая спецификация связана с определением интерфейса с
помощью размещения объектов на экране (визуальное программирование).
Она проста для использования не программистами, НО:
· трудна в реализации;
· поддерживает лишь ограниченные интерфейсы.
Здесь также существуют разные реализации:
· размещение на экране интерактивных средств (меню, кнопки и
т.п.) и их привязка к фрагментам, написанным разработчиком
интерфейса;
· сеть статичных страниц (кадров), содержащих тексты,
графики, интерактивные средства;
· спецификация по демонстрации.
В третьем подходе создают интерфейс автоматически по спецификации семантики прикладных задач. Этим, в сущности, предпринимается попытка преодолеть сложности использования других технологий, однако ввиду сложности адекватного описания интерфейса, трудно ожидать скорого появления систем, реализующих такой подход в полной мере.
Возможные реализации:
· создание интерфейса на основе списка процедур прикладной программы (Mike);
· создание интерфейса по типам параметров процедур (Control
Panel Interface);
· создание интерфейса на основе определения семантики
прикладной задачи, описываемой на специальном языке (IDL).
Четвертый подход связан с принципом, называемом 'Direct Manipulation' - DM, рассматриваемым в следующем разделе. Основное свойство этого подхода состоит в том, что пользователь взаимодействует с индивидуальными объектами, а не со всей системой как единым целым.
Во многих отношениях технология непосредственного манипулирования (DM - Direct Manipulation) рассматривается как новая генерация методов программирования в области проектирования интерфейса с пользователем, имеющих такое же значение как разработка языка четвертого поколения для разработки баз данных. Начало этому подходу положили исследования, проводимые в центре Palo Alto корпорацией Xerox.
Что же такое непосредственность? Можно выделить четыре аспекта этого понятия:
Семантическая непосредственность. Определяется через "расстояние" между пользовательскими намерениями и операциями предоставляемыми системой. Пользователю важно, что: (1) в любое время он может передать свои намерения системе и (2) он может их выразить простым и кратким способом.
Для достижения этих целей необходимо, чтобы система предоставляла соответствующую функциональность, наряду с концептуальными объектами и операциями на уровне абстракции, удовлетворяющей пользователя. Эта проблема хорошо известна из области языков программирования высокого уровня - конструкции языка должны соответствовать проблемной области. Другими словами, семантическая непосредственность заключается в предоставлении пользователю возможности определять собственные классы графических объектов, соответствующих его прикладной задаче, а не заставлять его использовать базовые графические примитивы системы.
Операционная непосредственность. На уровне диалога можно рассматривать временной аспект непосредственности. Диалоговая последовательность не обладает нужной непосредственностью, если пользователь хочет воспользоваться последовательностью действий, не предоставляемых системой. Например, выбор пиктограммы с помощью мыши и получение возможности тут же передвинуть ее по экрану является реализацией непосредственности в операционном смысле, поскольку действие не подразделяется на дополнительные команды ввода (не надо нажимать клавишу "двигать").
Но не просто определить последовательность действий в намерениях пользователя. Большинство DM систем пытаются сделать все видимые объекты доступными способами инициируемыми пользователем и поддержать развитие последовательности действий непосредственной обратной связью на каждом шаге.
Формальная непосредственность. Этот аспект относится к естественности восприятия системного вывода, простоте и эффективности ввода (клавиатура, кнопки, работа с мышью и т.п). Увеличению степени формальной непосредственности может способствовать использование представления в виде пиктограмм при выборе объектов и функций вместо символических имен команд, хорошо структурированный экран и понятное обозначение функциональных клавиш. Еще одним важным требованием является использование принципа "То что вы видите - то и получите" (WYSIWYG - What You See Is What You Get), благодаря которому на экране формируется именно то изображение, которое будет получено при распечатке.
Компоненты DM интерфейса. На верхнем уровне DM систем обычно находится одна из метафор графического представления (типа метафоры письменного стола, конкретный объект). Через этот верхний уровень пользователю доступны прикладные программы, работающие на окнах. В окнах, подокнах и компонентах экрана доступны различные средства выбора объектов, функций инициирования и управления. Типичными компонентами используемыми для манипуляций с объектами и управляющими функциями являются:
DM часто называют интерактивной технологией с отсутствием режимов. Это конечно не так, но верно, что пользователь получает доступ к множеству функциональностей работая в нормальном контексте, команды и режимы ввода, присущие командно-ориентированным редакторам в этой технологии по возможности не используются. Обычной синтаксической композицией взаимодействия в DM является "выбор объекта" за которым следует "активация функции". Переход в режим "объект выбран" отражается изменением яркости объекта, после активации функции возможен переход в новый режим (например ожидания ввода параметра) отображаемый изменением формы курсора.
Требования к конструированию DM интерфейсов:
· поддержка разных классов интерактивной технологии;
· возможность создания новых типов технологий;
· использования подходящего, простого в изучении языка
программирования для описания частей системы, которую трудно
специфицировать графически;
· предоставление разной интерактивной технологии одновременно;
· обеспечение семантической обратной связи, проверки семантики
и использования в семантике установок по умолчанию;
· гибкость компоненты представления;
· выражение синтаксиса в терминах индивидуальных объектов.
В заключении приведем в качестве примера описание системы UIMS XFaceMaker2 фирмы Non Standard Logics, созданной на базе OSF/Motif и X Window System.
Ситуация в области разработки систем построения и управления интерфейсом пользователя в наши дни напоминает ситуацию с графикой до выработки международных стандартов: нет единой терминологии, есть разные подходы к построению моделей (лингвистический, графический), которые часто пересекаются.
Анализ разработок в области UIMS позволяет представить соотношение между различными компонентами в виде слойной структуры, напоминающей структуру OSI [104]. При реализации конкретной прикладной задачи необходимый уровень UIMS и набор компонент может определяться из соображений требуемой эффективности и доступных ресурсов.
Открытые проблемы в разработки UIMS можно определить как:
· эргономика взаимодействия;
· управление диалогом;
· отделение интерфейса пользователя;
· сопровождение, мобильность и эффективность.
Пока не существует единственной стратегии конструирования UIMS. Нужны эксперименты и опыт. Сфера быстро развивающаяся, сулящая многочисленные выгоды. Появившиеся стандарты (пока де-факто), по крайней мере на нижних уровнях систем (X-Windows и, в какой-то степени OSF/Motif), и активность разработчиков многих фирм дают надежду что ситуация в ближайшее время может измениться к лучшему.
1. Электромагнитная волна (в религиозной терминологии релятивизма - "свет") имеет строго постоянную скорость 300 тыс.км/с, абсурдно не отсчитываемую ни от чего. Реально ЭМ-волны имеют разную скорость в веществе (например, ~200 тыс км/с в стекле и ~3 млн. км/с в поверхностных слоях металлов, разную скорость в эфире (см. статью "Температура эфира и красные смещения"), разную скорость для разных частот (см. статью "О скорости ЭМ-волн")
2. В релятивизме "свет" есть мифическое явление само по себе, а не физическая волна, являющаяся волнением определенной физической среды. Релятивистский "свет" - это волнение ничего в ничем. У него нет среды-носителя колебаний.
3. В релятивизме возможны манипуляции со временем (замедление), поэтому там нарушаются основополагающие для любой науки принцип причинности и принцип строгой логичности. В релятивизме при скорости света время останавливается (поэтому в нем абсурдно говорить о частоте фотона). В релятивизме возможны такие насилия над разумом, как утверждение о взаимном превышении возраста близнецов, движущихся с субсветовой скоростью, и прочие издевательства над логикой, присущие любой религии.
4. В гравитационном релятивизме (ОТО) вопреки наблюдаемым фактам утверждается об угловом отклонении ЭМ-волн в пустом пространстве под действием гравитации. Однако астрономам известно, что свет от затменных двойных звезд не подвержен такому отклонению, а те "подтверждающие теорию Эйнштейна факты", которые якобы наблюдались А. Эддингтоном в 1919 году в отношении Солнца, являются фальсификацией. Подробнее читайте в FAQ по эфирной физике.