07. МОДЕЛИ ИНТЕРФЕЙСА

СОДЕРЖАНИЕ
Окна как элементы графического интерфейса. Модели интерфейса. .................................................. 1
Модели построения интерфейса. ........................................................................................................... 1
Пиктограммы. .......................................................................................................................................... 1
Окна: виды и структура. ......................................................................................................................... 2
Использование подокон ......................................................................................................................... 2
Вторичные окна....................................................................................................................................... 3
Виды вторичных окон ............................................................................................................................ 4
Многодокументный интерфейс (MDI). ................................................................................................. 4
Рабочая область – контейнер. ................................................................................................................ 6
Рабочая книга .......................................................................................................................................... 6
Проект. ..................................................................................................................................................... 6
Объектно-ориентированный интерфейс ................................................................................................... 6
Основные характеристики ООПИ по документации IBM .................................................................. 8
Объекты и отношения между ними. ..................................................................................................... 8
Типы связей между объектами. ............................................................................................................. 8
Представление объектов. ....................................................................................................................... 9
Перспективы эволюции интерфейсовя – деятельностно-ориентированные интерфейсы ............. 11
ОКНА КАК ЭЛЕМЕНТЫ ГРАФИЧЕСКОГО ИНТЕРФЕЙСА.
МОДЕЛИ ИНТЕРФЕЙСА.
Модели построения интерфейса.
В соответствии с концепциями, положенными в основу графического интерфейса, объекты
приложения могут быть визуально представлены на Рабочем столе либо в виде пиктограмм, либо
в виде окон, отображающих содержимое объекта.
Однооконная модель приложения облегчает пользователям ассоциативную связь между
объектами и их визуальным представлением, существенно упрощает пользователю работу с
окнами.
Объекты некоторых типов (например, устройства) могут не требовать создания первичного
окна и использовать только вторичное окно для просмотра и редактирования их свойств. Иногда
объект может быть представлен в приложении лишь своей пиктограммой.
При выполнении некоторых заданий однооконная модель не обеспечивает достаточно
эффективного управления приложением или отдельными его объектами; такая ситуация может
иметь место в тех случаях, когда пользователю требуется работать одновременно с несколькими
различными форматами представления одних и тех же данных или с несколькими видами
взаимосвязанных данных в пределах одного окна. В таких случаях следует использовать другие
модели приложения: на основе многодокументного интерфейса (MDI) или Проекта.
Пиктограммы.
Все пиктограммы, используемые в приложении, следует разрабатывать как единый набор.
При этом должна обеспечиваться их согласованность и друг с другом, и с заданиями пользователя.
Каждая пиктограмма должна быть реализована в трех стандартных форматах:
- 16х16 пикселов (для 16 цветов);
- 32х32 пиксела (для 16 цветов);
- 48х48 пикселов (для 256 цветов).
Пиктограммы разрабатываются не только для исполнимого файла приложения, но и для всех
типов файлов данных, поддерживаемых вашим приложением. При этом пиктограммы для файлов
данных (или документов) должны отличаться от пиктограмм приложения, но иметь с ними общий
элемент. Пиктограммы должны отображать сущность хранимой информации. Все созданные
пиктограммы должны быть зарегистрированы в системном реестре, иначе система будет
автоматически использовать вместо них системные пиктограммы.
Окна: виды и структура.
Окна предоставляют доступ к различным видам информации и классифицируются согласно
своему предназначению.
Первичное окно. Взаимодействие с объектами реализуются средствами первичного окна, в
котором происходит первоначальный просмотр и редактирование данных. Типовая структура
первичного окна:
 рамка – определяет размеры окна;
 заголовок окна – идентифицирует информацию, представленную в окне, может содержать
кнопки управления первичным окном (Закрыть, Развернуть/Восстановить, Свернуть);
 полосы прокрутки – используются, если объем выводимой информации превышает текущий
размер окна;
 другие элементы интерфейса (меню, панель инструментов, строка состояния).
Внешний вид рамки окна определяется типом окна. Изменяемое окно имеет четкую границу,
которая обеспечивает управление размерами на основе прямого манипулирования. Если окно не
может изменять размеры, граница сливается с краем окна. Первичное окно содержит
уменьшенную копию пиктограммы объекта или приложения, к которому оно относится. Она
выводится в левом верхнем углу окна – в полосе заголовка и выбирается по следующим правилам:
 если окно относится к компоненту приложения, не создающему свои файлы данных, то
используется пиктограмма самого приложения;
 если приложение обеспечивает работу с документами (файлами) различных форматов, то
используйте пиктограмму, соответствующую формату отображаемого в окне документа;
 если приложение использует многодокументный интерфейс, пометите пиктограмму
приложения в заголовке родительского окна, а в заголовке дочернего окна – пиктограмму
конкретного типа файла данных.
Поле заголовка содержит кнопки управления первичным окном. Для первичных окон в число
этих кнопок не включается кнопка для вызова контекстно-зависимой справочной информации.
Если наличие справки необходимо, то соответствующая кнопка включается в панель
инструментов.
Для кнопок управления первичным окном используются следующие правила:
 если команда не поддерживается окном – не отображайте соответствующую кнопку;
 кнопка закрытия окна всегда должна быть самой правой кнопкой. Оставляйте промежуток
между ней и другими кнопками;
 кнопка Свернуть должна предшествовать кнопке Развернуть;
 Кнопка восстановить всегда заменяет кнопку Развернуть или кнопку Свернуть после
выполнения соответствующей команды.
Использование подокон
Окно может разделяться на две и более относительно независимых областей, которые
называются подокнами. Разделение окна позволяет, например, просматривать одновременно две
части одного документа или отображать одну и ту же информацию в различной форме.
Если необходимо одновременно получить доступ к нескольким файлам при выполнении
одного задания, следует использовать технологию MDI.
Разбиение окна на подокна может быть установлено либо разработчиком приложения как
основная форма окна, либо пользователем, посредством задания соответствующего параметра.
Для того чтобы поддерживать разбиение окна, которое не определено заранее, включите в
состав создаваемой программы блок разделения. Блок разделения - специальный элемент
управления, который отображается в конце полосы прокрутки окна и обозначает регулируемую
границу между подокнами. Пользователь может изменять размеры подокон, перемещая блок
разделения в нужную позицию.
При использовании подокон каждое из них должно иметь собственные значения атрибутов.
При этом область выбора следует отображать только в активном подокне.
Когда основное окно закрывается пользователем, следует запоминать состояние подокон
(количество, расположение, отображаемая информация, состояние выбора) как часть информации
о состоянии этого окна. Это необходимо для восстановления окна.
Вторичные окна
Вторичные окна предназначены для приема от пользователя или отображения
дополнительной информации об объектах, представленных в первичном окне. Они позволяют
устанавливать дополнительные параметры обработки или обеспечивают доступ к более
специфическим деталям взаимодействия с объектами первичного окна.
Вторичные окна обладают некоторыми свойствами первичных окон, тем не менее
отличаются от первичных во многих аспектах поведения и использования.
Для вторичных окон не создаются кнопки на панели задач!
Стандартное вторичное окно содержит:
 полосу заголовка окна;
 поле, ограниченное рамкой.
Пользователь может перемещать его с помощью мыши.
Нежелательно изменять размеры вторичного окна, кроме окна палитры, поскольку любое
вторичное окно предназначено для отображения конкретной предопределенной информации.
В некоторых случаях может возникнуть необходимость последовательного уточнения или
дополнения отображаемой в окне информации; в таком окне может использоваться специальная
кнопка – Дополнить.
Вторичное окно не имеет кнопок управления Развернуть и Свернуть. Для закрытия окна
используется кнопка Закрыть.
Заголовок вторичного окна является его меткой и поясняет назначение окна; полоса
заголовка вторичного окна не содержит пиктограммы.
Разрешается включать во вторичные окна строку состояния, но не рекомендуется
дублировать в ней элементы, используемые в строке состояния первичного окна.
Вторичное окно может содержать в полосе заголовка окна кнопку вызова контекстной
помощи (Что это?). Эта кнопка позволяет пользователю получать контекстно-зависимую
справочную информацию о компонентах, отображенных в окне.
Вторичное окно может быть независимым или модальным.
Независимое вторичное окно позволяет пользователю взаимодействовать с другими
вторичными или первичными окнами, а также переключаться между первичными окнами.
Независимое вторичное окно целесообразно использовать в тех ситуациях, где пользователю
может потребоваться повторить действие, связанное с этим окном (например, при поиске слова в
тексте или при форматировании текста).
Модальное вторичное окно требует от пользователя завершить ввод данных в пределах
данного окна и закрыть его, прежде чем продолжить работу за пределами окна. Вторичное окно
может быть модальным по отношению к своему первичному окну или по отношению к системе. В
последнем случае пользователь должен выполнить требующиеся действия и закрыть окно прежде,
чем взаимодействовать с любыми другими объектами или окнами.
Модальные вторичные окна используются только в ситуациях определенного типа:
 когда для выполнения команды требуется ввести дополнительную информацию;
 когда необходимо приостановить работу пользователя, пока не будет выполнено некоторое
условие.
Избегайте использования системных модальных вторичных окон, если ваше приложение не
исполняется в качестве системной утилиты; но даже и в этом случае применяйте их только в
наиболее серьезных ситуациях, игнорирование которых может привести к фатальной системной
ошибке.
Вторичное окно следует отображать в той позиции, где оно появлялось в последний раз.
При первом открытии окна установите его в позиции, удобной для работы пользователя
(окно должно отображаться полностью!).
Удобно располагать вторичное окно таким образом, чтобы оно находилось в центре
первичного окна по горизонтали и ниже заголовка окна, меню и всех панелей инструментов.
Виды вторичных окон
1. Панель свойств – наиболее универсальное средство представления свойств объекта.
Представляет собой независимое вторичное окно, которое отображает доступные
пользователю свойства объекта, причем необязательно пользователю должно быть
предоставлено право изменять их. Панель свойств отображается на экране по команде
Свойства для конкретного (выбранного) объекта. Стандартные кнопки панели свойств –
ОК, Отменить, Применить.
2. Панель контроля параметров. Реализуется в виде модального вторичного окна, связанного с
тем объектом, свойства которого она отображает. Панель контроля параметров всегда
относится к выбранному в данный момент объекту. При изменении параметров свойства
применяются динамически – не требуется кнопок для подтверждения или отказа.
3. Диалоговые панели обеспечивают обмен информацией или ведение диалога между
пользователем и приложением. Используются для получения от пользователей
дополнительной информации, необходимой для выполнения команды или задания.
Название диалоговой панели должно отражать название команды.
4. Окно Палитра – является независимым вторичным окном, которое содержит набор
взаимосвязанных элементов управления. В виде такого окна может быть представлена
панель инструментов или ее часть. Каждое окно Палитра может иметь собственное
название, отображаемое в полосе заголовка, и собственный формат. Полоса заголовка
содержит только одну кнопку Закрыть.
5. Окно Сообщение – предназначено для вывода на экран сообщений пользователю; обычно
это информация о конкретной ситуации или условиях выполнения операций. Окна
сообщений содержат графический символ, который указывает на тип выводимого
сообщения, и собственно текст сообщения.
6. Всплывающие окна – используются для отображения дополнительной информации в тех
случаях, когда в основном окне она представлена в сокращенной форме; для вывода
контекстно-зависимой справочной информации. Всплывающая подсказка – разновидность
всплывающего окна – используется для пояснений к элементам управления панели
инструментов.
Многодокументный интерфейс (MDI).
В процессе работы с одним и тем же приложением пользователю может потребоваться иметь
на экране несколько открытых окон, содержащих информацию различных типов, либо
представляющих собой разное изображение одних и тех же данных. Для создания таких окон и
управления ими существует специальная технология – многодокументный интерфейс.
Техника MDI заключается в использовании одного первичного окна, называемого
родительским окном, которое может содержать набор взаимосвязанных с ним дочерних окон.
Каждое дочернее окно – это также первичное окно, единственным ограничением для которого
является то, что оно может появиться только в пределах родительского окна. Родительское окно
обеспечивает как визуальное, так и операционное пространство для своих дочерних окон.
Например, на дочернее окно обычно распространяется область действия меню родительского окна
и, возможно, других элементов его интерфейса (панели инструментов, строки состояния и т.д.). Их
вид может изменяться, если необходимо отразить команды и атрибуты активного дочернего окна.
Вторичные окна, такие как диалоговые панели, окна сообщений или панели свойств,
появляются на экране как результат тех или иных действий пользователя в родительском или
дочернем окне. Эти окна должны активизироваться и отображаться в соответствии с общими
соглашениями для вторичных окон, связанных с первичным окном, даже если они относятся к
дочернему окну.
Заголовок родительского окна обычно содержит пиктограмму и имя приложения или
объекта, который он представляет. Заголовок дочернего окна содержит пиктограмму,
представляющую тип документа или файла данных, и имя файла. Как для родительского окна, так
и для всех его дочерних окон должны поддерживаться всплывающие меню; перечень команд в
таком меню соответствует первичному окну.
Пользователь может активизировать MDI-приложение, либо непосредственно открыв его,
либо открыв документ того типа, который поддерживается этим приложением. Если MDIприложение активизировано посредством открытия документа, сначала открывается родительское
окно, а затем внутри его рабочей области – дочернее окно, отображающее выбранный документ.
Для того, чтобы упростить пользователю открытие других документов, связанных с этим
приложением, включите в его интерфейс диалоговую панель Открыть.
В том случае, когда пользователь непосредственно открывает документ за пределами
родительского окна приложения, то если родительское окно уже открыто, следует создать второй
экземпляр приложения (еще одно родительское окно), а не окно документа в существующем
родительском окне. Хотя открытие нового дочернего окна может быть более эффективным, его
появление может нарушить среду задания, уже установленную в этом родительском окне.
Поскольку дочерние окна являются разновидностью первичных окон, при их закрытии
следуют соглашениям, принятым для первичных окон. Когда пользователь закрывает дочернее
окно, любые несохраненные изменения должны быть обработаны в соответствии с общими
соглашениями для всех первичных окон.
Приложение не должно разрешать пользователю закрыть дочернее окно, если это не
позволит ему продолжить работу с приложением.
Когда пользователь закрывает родительское окно, закройте все его дочерние окна. Где
возможно, сохраняйте состояние дочернего окна (размер и положение внутри родительского окна)
и восстанавливайте это состояние, когда пользователь вновь открывает окно.
Технология MDI имеет свои ограничения:
 Хотя пользователь может запустить приложение, открыв документ, для того, чтобы
работать с несколькими документами одновременно требуется использовать интерфейс
приложения.
 Если открыто несколько файлов в пределах одного родительского окна, может быть
нарушена согласованность связи между дочерними окнами и отображаемыми в них
объектами (файлы не связаны между собой).
 Родительское окно в действительности не содержит объекты, представленные в дочерних
окнах. Это не позволяет обеспечить эффективную непрерывную работу пользователя (После
закрытия родительского окна созданная ранее рабочая среда не восстанавливается).
Перечисленные недостатки MDI могут быть преодолены за счет применения альтернативных
средств, таких как Рабочие области, Рабочие книги и Проекты. Хотя эти средства реализуют
однооконную модель интерфейса, тем не менее они обнаруживают целый ряд достоинств,
присущих технологии MDI.
Рабочая область – контейнер.
Основное отличие Рабочей области от MDI заключается в использовании концепции
объединения отображаемых объектов. Это означает, что объекты, отображаемые в Рабочей
области, могут соответствовать файлам, содержащимся в одном и том же контейнере. Внешне же
соответствующие им окна выглядят как дочерние окна, расположенные в пределах родительского
окна.
Таким образом, концепция использования Рабочей области подобна концепции
использования Рабочего стола, за исключением того, что она сама является объектом, который
может быть представлен в виде пиктограммы и отображен в виде открытого окна. Чтобы окно
объекта могло появиться в Рабочей области, сам объект должен входить в состав
соответствующего контейнера.
Для рабочей области должна быть предусмотрена команда Сохранить все – для сохранения
содержимого всех объектов области.
В настоящее время реализация механизма хранения объектов зависит от типа используемого
контейнера.
Рабочая книга
Рабочая книга – это еще один альтернативный вариант управления формой представления
отображаемых данных, в основе которого лежит метафора книги или записной книжки. В Рабочей
книге различные формы данных представляются как отдельные разделы в пределах одного
первичного окна.
В качестве средств навигации между разделами Рабочей книги могут использоваться
этикетки вкладок. Каждый раздел представляет данные, которые могли бы быть отдельным
документом. Рабочая книга лучше подходит для представления таких данных, которые могут быть
определенным образом упорядочены и этот порядок имеет существенное значение.
Для рабочей книги действительны те же соглашения, что и обеспечивающие связь между
родительскими и дочерними окнами.
Как и для Рабочей области, должна быть предусмотрена команда Сохранить все.
Проект.
Проект реализует еще один альтернативный способ управления окном, который
предусматривает возможность отображения в одном окне взаимосвязанных объектов,
представленных их пиктограммами. В этом смысле Проект подобен каталогу: для выбранного
объекта открывается окно, которое относится к тому же уровню, что и родительское окно. В
результате, каждое дочернее окно проекта может также иметь собственную кнопку входа на
панели задач.
В отличие от каталога, проект обеспечивает управление из родительского окна окнами
входящих в него объектов (если открыт документ, пользователь может закрыть окно каталога; при
закрытии проекта – закрываются все окна проекта).
Для различных окон проекта возможен различный набор элементов управления.
По аналогии с Рабочей областью и Рабочей книгой, Проект должен иметь команды для
создания новых объектов, для их пересылки в Проект и из него, а также для сохранения любых
изменений объектов, входящих в проект. Окно проекта должно содержать средства для работы с
самим проектом как с объектом (в т.ч. для изменения его свойств).
ОБЪЕКТНО-ОРИЕНТИРОВАННЫЙ ИНТЕРФЕЙС
Концепция интерфейса, управляемого данными.
Разработка, управляемая данными (DCD – Data-centered Design) означает, что
проектирование интерфейса поддерживает такую модель взаимодействия пользователя с
системой, при которой первичными являются обрабатываемые данные, а не требуемые для этого
программные средства. Другими словами, при таком подходе основное внимание пользователя
концентрируется на тех данных, с которыми он работает, а не на поиске и загрузке необходимого
приложения.
При использовании DCD-технологии основным программным объектом является документ,
который представляет собой некоторое абстрактное устройство хранения данных, используемых
для выполнения заданий пользователей и для их взаимодействия. Документ должен быть доступен
как различным приложениям, используемым для его обработки, так и всем взаимодействующим
пользователям.
Основная характеристика ООПИ состоит в том, что они стараются преодолеть существенный
недостаток ГПИ – ориентирование на приложения.
Работа с ООПИ основана на прямом манипулировании. У этого метода есть один недостаток –
пользователи не видят на экране никаких указаний на то, какие прямые действия они могут
совершить с тем или иным объектом. Действия и пункты, осуществляемые с помощью
клавиатуры, перечислены на панели меню и в контекстном меню. Следовательно, для работы с
ООПИ пользователи должны научиться пользоваться мышью и контекстным меню.
Самым распространенным стилем взаимодействия в ООПИ является последовательность
«объект-действие», большинство ГПИ использует стиль взаимодействия типа «действие-объект».
Переход к ООПИ вносит изменения в управляющие элементы. Панель меню ГПИ носит
название FEVH (File, Edit, View, Help) – проблемно ориентированная панель. Смысл такой панели
определяется моделью «приложение-данные». В ООПИ первый раздел меню File теряет свое
значение. Здесь появляется новая структура меню – WOSH (Window, Object, Selected objects,
Help).
Объекты представляют собой элементы, которыми можно манипулировать как целыми
частями, однако они могут состоять из нескольких других объектов, определенным образом
взаимодействующих между собой. На объектах, а не на приложениях фокусируют пользователи
свое внимание при работе с объектно-ориентированным интерфейсом.
Ч
то свидетельствует о разработке объекта, работающего на пользователя? Если вы не в
состоянии описать функцию объекта одним коротким предложением, то ваш объект и
пользователи будут работать «на разных частотах». Если потребители не смогут без подсказок
назвать все важные объекты через пару дней, значит ваш набор объектов неудачен.
Различия
между
проблемно-ориентированными
и
объектно-ориентированными
пользовательскими интерфейсами.
ПОПИ
Приложение состоит из иконки, первичного окна и
вторичных окон
Иконки представляют приложения или открытые
окна
Пользователи должны запустить приложение,
прежде чем приступить к работе с объектами
Обеспечивает
пользователя
функциями,
необходимыми для выполнения задач
Акцент делается на основную задачу, по
определению приложения
Взаимосвязанные задачи поддерживаются другими
приложениями
Жесткая структура определяется функцией
Тренинг сфокусирован на приложении и его
функциях
Пользователи следуют структуре приложения
Требуется много приложений – по одному на задачу
ООПИ
Продукт состоит из набора взаимодействующих
объектов или видов объектов
Иконки представляют объекты, которыми можно
манипулировать напрямую
Пользователи
открывают
объекты
в
их
представлении на Рабочем столе
Обеспечивает
пользователя
запасами,
необходимыми для выполнения задач
Акцент делается на входные и выходные данные для
объектов и задач
Взаимосвязанные
задачи
поддерживаются
использованием других объектов
Гибкая структура определяется объектом
Тренинг фокусируется на общих концепциях,
представлениях и функциях
Пользователи могут выполнять задачи по-своему
или совершенствовать процесс выполнения
Мало объектов – больше повторного использования
одних и тех же объектов во многих задачах
Основные характеристики ООПИ по документации IBM
1. Ориентация на объект.
2. Стандартные объекты и управление.
3. Множественный согласованный просмотр объектов.
4. Композиция объектов и контейнеры.
5. Объединение объектов.
6. Прямое манипулирование.
7. Динамические иконки, отражающие состояние объекта.
8. Мгновенная фиксация изменений.
9. Типы окон, ориентированные на задачу.
10. Пользовательское управление группами окон.
11. Все объекты активны.
Объекты и отношения между ними.
Рассмотренные выше особенности графических интерфейсов, а также положенная в основу
их реализации DCD-технология обуславливают необходимость применения для проектирования
GUI объектно-ориентированного подхода. Такой подход предполагает использование аналогий
между программными объектами и объектами реального мира. С точки зрения пользовательского
интерфейса, объектами являются не только файлы или пиктограммы, но и любое устройство для
хранения и обработки информации, включая ячейки, параграфы, символы и т.д., а также
документы, в которых они находятся.
Объекты, независимо от того, относятся ли они к реальному миру или имеют
компьютерное воплощение, обладают определенными характеристиками, которые помогают нам
понимать, что они собой представляют, и как они ведут себя в тех или иных ситуациях.
Следующие понятия описывают основные аспекты и характеристики объектов, имеющих
компьютерное воплощение.
Свойства объектов. Объекты имеют определенные характеристики или атрибуты,
называемые свойствами, которые определяют их представление или возможные состояния
(например, цвет, размер, дату модификации). Свойства не ограничены внешними или видимыми
признаками объекта. Они могут отражать их внутреннюю организацию или текущее состояние
объекта.
Операции над объектами. Все действия, которые могут быть выполнены с (или над)
объектом, считаются допустимыми операциями. Перемещение или копирование объекта являются
примерами операций. Пользователь может выполнять операции над объектами, используя те или
иные механизмы, предоставляемые интерфейсом (командное управление или прямое
манипулирование).
Связь (отношения) между объектами. Любой объект тем или иным образом
взаимодействует с другими объектами. Во многих случаях взаимоотношения между объектами
могут быть описаны как связь определенного типа.
Типы связей между объектами.
Наиболее общими типами отношений являются наборы (Collection), объединения
(Constraints), и композиции (Composites).
Набор представляет собой наиболее простой тип отношения, которое отражает наличие у
объектов некоторых общих свойств. Результаты запроса (поиска по образцу) или операции
множественного выбора объектов – примеры использования данного типа отношения. Важным
достоинством этого типа отношения является то, что он позволяет указывать операции, которые
должны относиться к определенному набору объектов.
Объединение отражает более тесное отношение между объектами, при котором изменение
объекта влияет на некоторый другой объект в наборе. Простейший пример такого отношения –
изменение формата соседней страницы при добавлении текста на предыдущей странице.
Композиция имеет место в том случае, когда агрегация нескольких объектов может
рассматриваться как новый объект со своим собственным множеством свойств и допустимых
операций. Столбец ячеек в таблице и параграф в тексте – это примеры композиций.
Еще один распространенный тип отношений между объектами – контейнер.
Контейнер является объектом, который содержит другие объекты (например, рисунок в
документе или документ в папке могут рассматриваться как часть содержимого соответствующего
контейнера). Свойства контейнера часто влияют на поведение его содержимого. Это влияние
может заключаться в расширении или подавлении некоторых свойств содержащихся в нем
объектов или в изменении перечня допустимых операций. Кроме того, контейнер управляет
доступом к своему содержимому, а также преобразованием типа (формата) включаемого в него
объекта. Это, в частности, может сказаться на результате пересылки объекта из одного контейнера
в другой.
Основные типы объектов интерфейса составляют фундаментальные классы всех объектов,
обеспечиваемых операционной системой. Существует три основных типа объектов: объектыданные, объекты-контейнеры и объекты-устройства.
Многие объекты обладают характеристиками, относящимися более чем к одному классу
(пример – папка Входящие: свойства контейнера и устройства). Поэтому необходимо хорошо
разбираться в классах объектов интерфейса и их поведении. Объекты должны оправдывать
ожидания пользователей в отношении выполняемых ими действий, то есть определять, какие
представления могут его отобразить и изменить. Объекты-контейнеры должны обеспечивать
представления, соответствующие другим контейнерам, объекты-устройства – предлагать
представления, присущие данному устройству и совместимые с другими.
Объекты-данные снабжают пользователей информацией. Они могут представлять любой
тип информации, например текст, электронные таблицы, изображения, музыку, записанную речь,
видео, анимацию или любую их комбинацию. Поскольку объекты-данные, как правило,
ориентированы на продукт, руководства по разработке не дают определения особых объектов
данных. Это задача проектировщиков программ.
Объекты-данные также могут быть составными объектами, содержать другие объекты. Такие
объекты должны обладать поведением, присущим объектам-контейнерам.
Объекты-контейнеры являются мощным инструментом в руках пользователей для
организации их работы. Они могут хранить и группировать любые объекты, в т.ч. и другие
контейнеры, представляя их содержимое различными способами, перемещая и копируя объекты с
и на контейнеры, а также выстраивая или сортируя содержимое в каком-либо порядке. К
типичным контейнерам относятся папки, корзины входящих и исходящих для почты. 3 основных
вида контейнеров: рабочее место (Рабочий стол), папки и рабочие области.
Объекты-устройства часто представляют устройства, существующие в реальном мире.
Главным назначением объектов-устройств является обеспечение пользователей способами
коммуникации и взаимодействия с объектами, связанными с их компьютерами.
Объект-устройство может обладать характеристиками других типов объектов. Например, принтер,
факс и корзина для мусора содержат объекты. Принтер имеет очередь вывода на печать,
связанную с ним, факс содержит задания и страницы, а корзина для мусора позволяет открывать
ее и знакомиться с содержимым. Тип характеристик объекта и поведения любого конкретного
объекта будет определять представления, свойственные данному объекту.
Представление объектов.
Определение объектов и представлений наиболее сложная часть процесса разработки
пользовательского интерфейса. Окна представления объектов позволяют рассматривать объект и
содержащуюся в нем информацию различными способами. При проектировании ООПИ
необходимо определить, каким образом пользователи хотели бы работать с объектами, и
обеспечить их соответствующими представлениями.
Существует четыре основных типа представления объектов: составные, содержание,
свойства и система помощи. Представления подаются через окна. Содержимое окна и способы
обработки этой информации частично определяются типом представления объекта. Пользователи
могут взаимодействовать с объектами, используя прямое манипулирование, а также
представления, отраженные в окнах.
Составные представления отражают информацию и объекты, содержащиеся в конкретном
продукте, показывая порядок и взаимоотношения с другими компонентами. Такие представления
часто являются первичными видами, связанными с объектами данных. Составные представления в
значительной степени ориентированы на продукт и задачи, стоящие перед пользователями.
Представление содержания отображает компоненты и содержимое объектов. Такой тип
является стандартным для объектов-контейнеров. Порядок представления содержания не
обязательно изменяет значения самого объекта при перестановке содержимого.
Любой объект, обладающий свойствами контейнера, может иметь представление
содержания. Объекты принтера имеют его в дополнение к представлению свойств принтера.
Объекты данных могут также иметь представления содержания, где перечисляются их
компоненты, но, поскольку важны отношения между компонентами объекта данных, их порядок
роли не играет.
Представления свойств позволяют просматривать и изменять информацию или свойства
объектов.
Перечисленными представлениями должны сопровождаться все типы объектов. В
проблемно-ориентированных программах опции и свойства, как правило, отражаются в
диалоговых окнах внутри приложения. В ООПИ пользователи должны уметь изменять все
характеристики объекта в виде свойств (цвета, шрифта, названий и т.д.).
Представления объектов должны быть динамическими и тесно взаимосвязанными. Если
пользователь вносит в объект изменения, влияющие на другие представления, то новшества
должны отражаться немедленно или как можно быстрее. Использование многочисленных
представлений позволяет сразу же увидеть результаты их изменений.
Представление системы помощи. Информация отражается в представлениях системы
помощи для поддержки работы пользователя с объектами. С точки зрения разработчика – помощь
является видом объекта, однако пользователи, как правило, получают вспомогательную
информацию через главное или всплывающее меню. Помощь может оказываться на уровне
объекта или конкретного элемента, например для поля ввода (контекстная подсказка).
Помощь пользователям должна оказываться в том виде, в котором она им необходима. Она
является представлением объекта и состоит из информации, принимающей любые формы.
Необходимо определить, какой тип помощи предпочитают пользователи.
Описание типа объекта (данных, контейнера или устройства) являются техническими
терминами, а пользователи должны видеть только названия объектов или классов, например
«документ», «папка» или «принтер». Составное представление также является техническим
термином, у которого должно быть пользовательское название, например WYSIWYG вид для
документа. Представления содержания подаются пользователям как название вида содержания
(иконки, древовидная схема, детали и т.п.). Представление свойств является и техническим, и
пользовательским термином. Изображается как окно Свойства.
Названия объектов и представлений чаще всего появляются в меню и названиях окон.
Каждое открытое окно содержит название объекта и представления на панели названия.
Пользователи должны видеть удобные в применении и имеющие смысл названия объектов
и представлений объектов. На решении именно этой задачи должны сосредоточиться
разработчики. Внимательно и осторожно выбирайте названия объектов и представлений.
Обязательно проводите тестирование на удобство применения с участием потребителей.
Первым шагом в объектно-ориентированном проектировании интерфейса должен быть
анализ целей пользователей и особенностей выполняемых ими заданий. При проведении такого
анализа следует определить основные компоненты или объекты, с которыми взаимодействует
пользователь, а также характерные особенности объектов каждого типа. Необходимо также
выявить перечень операций, выполняемых над объектами, их влияние на состояние и свойства
объектов.
После завершения анализа можно переходить к описанию возможных способов
взаимодействия пользователя с объектами различных типов. На этом шаге выбирается форма
визуального представления объектов. При этом следует иметь в виду, что визуальный образ
объекта в зависимости от ситуации может изменяться. Например, контейнер может быть
представлен и в виде пиктограммы, и в виде окна, отображающего содержимое этого контейнера.
Завершает процесс проектирования компоновка и размещение на экране визуальных
элементов интерфейса.
Перспективы
эволюции
интерфейсовя
ориентированные интерфейсы
–
деятельностно-
Объектные
интерфейсы
практически
всегда
гораздо
лучше
интерфейсов
имплементационных (собственно говоря, объектные интерфейсы – это следующая, после
имплементационных интерфейсов, ступень эволюции). Поспорить с этим невозможно, но
открытым остается вопрос – что лучше объектных интерфейсов? Какова следующая
эволюционная ступень?
Это, вероятно, деятельностно-ориентированные интерфейсы (ДоИ, обратите внимание, что
это наш, относительно условный термин). В отличии от объектных интерфейсов, в которых
пользователю предоставляются объекты и свобода манипулирования ими, в ДоИ «строительными
блоками» являются задачи пользователя. В качестве примера можно привести диалоговое окно
создания нового документа в MS Word: создать можно не просто обобщенный документ,
одинаково плохо решающий все задачи, но документ для текущей задачи пользователя (например,
письмо).
Перед тем, как перечислять преимущества этого вида интерфейсов, нужно определить, чем
несовершенны интерфейсы объектные. Недостатки их таковы:
1. Такие интерфейсы требуют от пользователя существенных когнитивных нагрузок и
способности к абстрактному мышлению: пользователю необходимо транслировать цель
своих действий в конкретный алгоритм использования объектов. Это требует
определенных усилий, так что при прочих равных от этой работы пользователей следует
освободить.
2. Объектные интерфейсы зачастую требуют от пользователя серьезных усилий по
отвлечению от собственной предметной области и привлечения внимания к вопросу
«компьютерной поддержки» своей деятельности: репрезентируемые объекты, будучи
универсальными, не полностью соответствуют предметной области конкретного
пользователя. Например, разные интерфейсы почтового клиента нужны пользователю,
который получает 5 писем в день и пользователю, который получает 70 писем, хотя в обоих
случаях объекты (письма) одни и те же.
3. Во многих случаях «объектность» интерфейса подталкивает его разработчика к
совершению некорректных действий: в поиске объектов деятельности разработчики чаще
всего ограничиваются правами доступа. Смена парадигмы может форсировать
разработчиков более тщательно подходить к проектированию функциональности и
интерфейса (хотя и новая парадигма, вероятно, тоже будет подталкивать разработчиков к
совершению некорректных действий).
Деятельностно-ориентированные интерфейсы этих недостатков, как правило, лишены,
благодаря чему они оказываются более эффективными, чем объектные интерфейсы.
Частным, вырожденным, примером деятельностно-ориентированного интерфейса являются
мастера (Wizards). Вместо того, чтобы показывать пользователю единое диалоговое окно со
сложной конфигурацией элементов управления, пользователю выдается сравнительно простая
последовательность экранов. В идеальном случае, когда каждый последующий экран зависит от
действий пользователя на предыдущем экране, мастер оказывается чрезвычайно эффективным. В
неидеальном случае, когда его экраны не связаны между собой, он всё равно оказывается более
эффективным (незначительное снижение скорости работы компенсируется низкими
когнитивными нагрузками пользователя и другими факторами).
Но мастера это только начало пути: деятельностно-ориентированного в них не так уж и
много. В будущем интерфейсы, идя по пути большей ориентированности на задачи и деятельность
пользователей, достигнут ещё большей эффективности, при этом:
1. Разделение между интерфейсами, предназначенными для профессионалов и
непрофессионалов, будет увеличиваться (как это уже произошло во всех других областях
техники).
2. Программы будут становиться все более и более специализированными: не просто
текстовый редактор, а текстовый редактор для сугубо определенной группы пользователей,
решающих определенные задачи.
3. Адаптивность интерфейсов будет увеличиваться: они будут все больше и больше
учитывать характерные особенности работы конкретных пользователей.
4. Количество технических подробностей (файлы, папки, порты и т.п.) в большинстве
интерфейсов будет резко сокращено, поскольку эти объекты не связаны напрямую с
деятельностью пользователей.