Окна - Основы: Настройка контекста

В этом разделе содержится общая информация о структуре оконного пользовательского интерфейса. Она необходима для понимания остальных рекомендаций.

Оконный пользовательский интерфейс разделен на окна. Окна можно перемещать по экрану, устанавливать поверх друг друга и сворачивать в значки. В системе обычно есть одно основное окно и несколько дополнительных. Основное окно предназначено для обработки основного взаимодействия системы с пользователем и обычно содержит произвольное число объектов. Дополнительные окна используются для поддержки взаимодействий с основными окнами, предоставляя сведения об их объектах и операциях над этими объектами.

Основные окна

Основное окно часто содержит произвольное число объектов, с которыми взаимодействует пользователь. Обычно при взаимодействии с системой пользователь сначала выбирает один или несколько объектов (например, с помощью мыши), а затем - действие (например, из меню), которое выполняется над всеми выбранными объектами. Общие действия - это Вырезать, Скопировать, Вставить, Удалить и Показать свойства.

Основное окно обычно содержит строку меню, из которой пользователь может выбирать действия. Кроме того, действия можно выбирать из всплывающих меню (если щелкнуть правой кнопкой мыши на самом объекте), либо выполнять их непосредственно (перетаскивая объект на нужное место). Поскольку все объекты могут не поместиться в основное окно, то для перемещения по объектам пользователи могут использовать полосу прокрутки или изменить размер окна. Кроме того, основное окно может состоять из нескольких панелей, размер которых также можно изменить.

Составные объекты

Составной объект пользовательского интерфейса - это объект, который визуально состоит из других объектов. Например, фрагмент текста состоит из символов, а сложный объект рисования - из более простых объектов рисования.

Дополнительные окна

Дополнительные окна обеспечивают поддержку основных окон, предоставляя сведения (такие как свойства) об их объектах, а также действия над этими объектами. В основном окне обычно показано лишь несколько свойств объектов. Для просмотра свойств объекта достаточно открыть соответствующее дополнительное окно, в котором показаны все атрибуты этого объекта. Для изменения этих атрибутов пользователь может воспользоваться управляющими элементами, такими как переключатели или радиокнопки, шкалы, поля со списком и текстовые поля.

Обратите внимание, что грань между основными и дополнительными окнами достаточно тонкая и иногда вообще искусственная; уровень сложности и тех, и других может быть одинаков. Однако, между основным и дополнительным окнами есть два главных различия:

• Основные окна часто считаются более важными для приложения, поскольку требуется, чтобы они были максимально удобными для работы. Поэтому при разработке интерфейса основные усилия следует сконцентрировать на проектировании основных окон.
• Дополнительные окна обычно открываются при навигации по основным окнам, но не наоборот.

Помимо окон свойств, есть дополнительные окна других типов, такие как окна диалога, окна сообщений, палитры и всплывающие окна.

Многие приложения созданы на основе файлов. Пользователи могут запускать их с помощью действия Открыть над файловым объектом (например, дважды щелкнув на значке файла в папке). В основном окне будут показаны объекты, хранящиеся в этом файле. Над файлами можно выполнять общие действия Сохранить, Сохранить как, Открыть и Создать, которые можно выбрать в меню Файл в основном окне. В основном окне обычно могут быть показаны несколько файлов; это так называемый многодокументный интерфейс, или MDI, позволяющий переключаться между различными файлами.

Визуальные параметры

Применение визуальных параметров при визуализации содержащихся в окнах объектов и их атрибутов позволяет создавать удобные основные окно. Преимущества представления большего числа атрибутов, чем требуется для идентификации, состоят в следующем:

• Пользователь избавлен от необходимости дополнительной навигации по окнам, поскольку при этом уменьшается число окон, которые должны быть показаны (когда атрибут, который требуется посмотреть пользователю, представлен в основном окне).
• Пользователь может видеть одновременно разные аспекты (или разные объекты), что часто бывает полезно для сравнения и для запуска программы распознавания по шаблонам. Умелое использование визуальных параметров может побудить пользователей изменить отношение к своей работе.

К визуальным параметрам относятся следующие:

• Расположение
• Размер
• Форма
• Цвет

Эти параметры представлены ниже. Однако, при проектировании визуализации объектов будьте осторожны с экранной площадью. Постарайтесь, чтобы накладные расходы при эксплуатации экранной площади были как можно меньше, и решите, что хуже: использование нескольких визуальных параметров или расходование экранной площади. Возможно, для пользователя будет более полезен простой список имен, так как все, что фактически нужно пользователю - это видеть как можно больше объектов.

Обратите внимание, что применение визуальных параметров или расширение их необходимо для уникальной идентификации объектов. Эта тема будет обсуждаться ниже (в разделе "Идентификация").

Заметим также, что визуальные параметры могут использоваться в сочетании с временными параметрами, например, при перемещении объектов (с течением времени изменяется их расположение) или при изменении формы или цвета объектов (с течением времени изменяется их состояние); последний случай обсуждается ниже в разделе "Форма".

Расположение

Наиболее очевидные аспекты, которые могут представляться параметром "расположение", - это реальные расположения объектов. Примеры:

• Геоинформационная система (ГИС), отображающая карту, объекты на которой представляются на той же широте и долготе, что и в реальном мире.
• Программы автоматизированного проектирования (CAD), представляющие объекты и их конфигурацию точно в соответствии с их реальными координатами.
• Редакторы WYSIWYG ("что на экране, то и на принтере"), которые отображают объекты (символы) в окне в тех же позициях, в каких они будут появляться при распечатке на бумаге.

Иногда важно показать реальный размер (например, в программах CAD и редакторах WYSIWYG), а иногда - нет, например, когда размер объектов намного меньше расстояния между ними.

Например, представим систему заказа авиабилетов, в которой пользователь должен вводить пункты назначения. Один из возможных способов - изобразить карту, содержащую различные аэропорты (в этом случае аэропорт - это объект). Естественно, поскольку реальные размеры аэропортов не важны, и кроме того, слишком малы, чтобы их различить, то все аэропорты будут показаны как значки одинакового размера.

Этот пример также иллюстрирует тот факт, что реальные расположения могут использоваться даже в том случае, если они не важны, коль скоро они помогают пользователю идентифицировать объекты. Например, пользователь не обязательно знает расположение аэропорта. Однако, если он знаком с географией, то ему будет легче найти нужный аэропорт на карте, чем в списке.

Параметр Расположение можно использовать для представления "виртуальных" реальных расположений. Например, представьте себе систему "магазин на диване", в рамках которой пользователи могут приобретать товары в разных магазинах. Эту систему можно представить с помощью схемы (виртуальных) моллов, в которых расположены различные магазины В этом случае объект - это магазин). Эта схема не имеет ничего общего с реальным расположением магазинов; просто она эксплуатирует пространственную память пользователя: легче запомнить расположение на плане, чем элемент в списке или иерархии.

Альтернативное применение параметра расположения - показ связей между объектами: все объекты, имеющие одну и ту же позицию по вертикали, связываются одним способом, а все объекты, имеющие одну и ту же позицию по горизонтали, - другим. Примером могут служить электронные таблицы.

Аналогично, предположим, что одна из осей представляет диапазон значений некоторого атрибута. Например, в электронной системе заказа билетов и бронирования мест в гостиницах авиарейсы, на которые заказаны билеты, (где авиарейс - это объект) могут размещаться вдоль горизонтальной временной оси, чтобы было видно, как они соотносятся по времени, какова их продолжительность, и сколько времени пользователь будет оставаться в каждом пункте назначения. Все эти вещи пользователю знать необязательно, но при ненавязчивом представлении видеть их приятно.

Если весь диапазон значений не требуется представлять на большой области экрана, то расстояния между объектами можно сжать. В системе заказа билетов из предыдущего примера это могло бы означать, что все рейсы, на которые заказаны билеты, расположены вдоль горизонтальной оси без промежутков между ними, то есть первый рейс - с левого края, сразу справа от него второй и т.д. В этом случае пользователи не увидят, сколько времени они проведут в каждом пункте назначения, но смогут оценить продолжительность полетов.

Размер

Во многих случаях параметр "размер" должен представлять то же, что и расположение. Например, в системах автоматизированного проектирования (CAD) параметр "размер", естественно, должен представлять размер. Иногда, однако, можно выбрать, что именно должен представлять размер, например, аэропорты на карте, которая предназначается для выбора пунктов назначения.

В этих случаях параметр "размер" должен представлять то, что больше всего воспринимается как реальный размер объекта. Для файла, например, размер объекта должен представлять объем дисковой памяти, занятой этим файлом. Для счета в банке размер объекта должен представлять остаток на счете. Для большинства размеров предпочтительней не линейная, а логарифмическая шкала, так как при использовании последней требуется гораздо меньшая область экрана.

Размер на самом деле настолько умозрительное понятие, что вы можете счесть необходимым показать его, даже когда он не имеет отношения к делу. В конце концов, в реальном мире различные предметы (объекты) из-за своего размера занимают разную часть нашего поля зрения. И это не раздражает, а только помогает нам различать их. Аналогично, использование разных размеров в пользовательском интерфейсе поможет пользователям отличить один объект от другого.

Размер обычно следует использовать для представления только одного атрибута, даже если величину одного атрибута можно отложить по горизонтали, в второго - по вертикали (однако, это не слишком наглядно, и пользователь может запутаться).

Один из размеров (или по горизонтали, или по вертикали) должен быть пропорционален атрибуту (или логарифму его значения), который должен иллюстрироваться параметром "размер", а второй размер должен быть фиксирован (или зависеть, например, от длины имени). Если и горизонтальный, и вертикальный размер пропорционален одному и тому же атрибуту, то это дает небольшой выигрыш: слишком бросается в глаза и занимает больше места на экране.

Форма

Формы в графическом пользовательском интерфейсе обычно изображаются значками; форму лучше всего использовать для представления типа, поскольку различие во внешнем виде более наглядно, чем различие в типе. В реальности различные объекты предметов одного и того же типа обычно похожи, а объекты разных типов выглядят по-разному. Например, различные объекты "стул" выглядят похоже (у всех есть четыре ножки, сиденье и спинка), а "автомобиль" выглядит совершенно по-другому.

Каковы же критерии, по которым различные объекты можно отнести к разным типам? Очевидно, что различные классы определенно должны рассматриваться как разные типы. Кроме того, некоторые атрибуты подобны типам. Для этих атрибутов должен существовать ограниченный набор возможных значений, а их значение обычно определяет, что можно делать с объектом (в терминах действий и возможных значений других атрибутов). Точно так же и в реальном мире: наиболее важное различие между стулом и автомобилем состоит в том, как они используются: стул - для отдыха, а автомобиль - для передвижения.

Однако, при анализе атрибутов, которые должны рассматриваться в качестве разных типов, необходимо помнить, что наиболее важная вещь заключается в том, какой атрибут пользователь с наибольшей вероятностью будет воспринимать как тип.

Если у вас нет нескольких классов или какого-то атрибута, "похожего" на тип, то можно использовать значки для представления разных значений какого-то другого атрибута с ограниченным набором значений, но только если этот атрибут представляет интерес для пользователя.

Кроме указания на тип, значки часто применяются для отображения различных состояний объекта. При выборе объекта он обычно выделяется одним из двух способов: или его цвет изменяется на черный, или вокруг него появляется рамка. Другое возможное состояние - когда для этого объекта открыто окно свойств. Как правило, в конкретных приложениях могут существовать и другие состояния, например, была ли прочитана электронная почта. Убедитесь, что представление состояния не помешает пользователю различать типы, и наоборот.

Цвет

В соответствии с визуальным восприятием, параметр "цвет" можно разделить на три компонента. Это собственно цвет (то есть красный, синий, коричневый и т.д.), насыщение и оттенки серого. Однако, для представления разных атрибутов не рекомендуется применять разные компоненты, так как это слишком сложно для восприятия.

Компонент "цвет" может использоваться для представления типа или атрибутов с ограниченным числом возможных значений. Однако для этой цели лучше использовать значок, поскольку значок спроектирован так, что пользователь понимает, какое тот представляет значение, тогда как такого однозначного соответствия между цветом и большинством типов значений нет. Цветом вместо значков рекомендуется пользоваться в том случае, если не нашлось подходящих значков. Кроме того, если значков типов очень много, то с помощью цвета их можно распределить по категориям (то есть некоторые значки с похожим значением могут быть красными, с другим значением - синими и т.д.).

Насыщение можно было бы использовать для атрибутов с диапазоном значений, однако, разное насыщение скорее всего, трудно будет уловить, а высокое насыщение будет слишком утомительно для глаз.

Оттенки серого - этого наиболее востребованный компонент параметра "цвет". Он может применяться как для представления атрибута с диапазоном значений, так и для представления менее важных (или дополнительных) атрибутов. Не рекомендуется использовать чисто белый (оттенки серого отсутствуют) или чисто черный (максимальное затенение) цвет; оптимальным будет варьировать оттенки от светло-серого до темно-серого. Во множестве систем, где пользователи создают свои объекты, полезно представлять объекты с учетом их возраста: например, в соответствии с временем, прошедшим с момента последнего изменения. При этом пользователям будет легче идентифицировать объект, с которым они собираются работать (чаще всего это объект с наименьшим значением атрибута "время с момента последнего изменения"). Поэтому если у вас нет атрибута с диапазоном значений, который действительно нужен для представления пользователю, рассмотрите вариант представления возраста.

Часто цвет применяется, чтобы сделать значки более эстетически привлекательными, и это также помогает пользователю различать их. При предоставлении многоцветных значков не следует использовать цвет для других целей.

Поскольку некоторые люди не различают цвета, кроме того, не все экраны поддерживают цвет, не следует применять цвета в качестве единственного средства для отображения критически важной информации. Кроме того, хорошо спланированное и ненавязчивое применение цвета делает пользовательский интерфейс более эстетически привлекательным.

Идентификация

Пользователь должен быть в состоянии уникально идентифицировать каждый объект. Иногда для идентификации достаточно только визуальных параметров, но как правило, - нет. Наиболее распространенный способ поддержки идентификации - это отображение имени внутри или около значка. Преимущество этого способа состоит в том, что в очень небольшой области экрана можно показать большое число разных имен.

Лучше всего, если имя может генерироваться из значения атрибута (которое обычно является текстовым). Можно также разрешить пользователям указывать имена при создании объектов, но это занимает определенное время и, следовательно, менее удобно.

Иногда можно создать значок такой формы, что имя помещается внутри него. При этом экономится экранная площадь и явно подчеркивается связь между значком и именем. Однако, в этом случае могут возникнуть следующие проблемы:

• Середина значка (там, где появляется имя) должна быть пустой.
• Имена имеют разную длину, то есть либо горизонтальный размер значка должен зависеть от длины имени, либо должны усекаться некоторые имена.
• Ширина значка должна быть намного больше его высоты, чтобы в него поместился весь текст приемлемой длины.

В результате имя часто приходится отображать под значком или справа от него. Достоинство этого способа состоит в том, что требуется меньше экранной площади, а недостаток - что ширина объекта (значок + имя) становится больше, чем его высота. Если для отображения имени вообще нет места (что вполне возможно, поскольку вы можете идентифицировать значок, не присваивая ему имени), то имя можно вывести во всплывающем окне, которое появляется при наведении указателя мыши на значок.

Для того чтобы показать атрибут с ограниченным выбором, можно использовать шрифт имени, если вы сможете найти соответствие между шрифтом и значениями атрибута; например, для того чтобы отличить объект или подчеркнуть его важность, можно было бы использовать полужирный шрифт или курсив. Однако, в большинстве случаев это неприемлемо, поскольку такая связь не очевидна.

Если вы выводите имя (или другой текст, который может редактироваться пользователем), то необходимо обеспечить поддержку редактирования непосредственно в основном окне. В качестве альтернативы пользователь мог бы запросить действие по переименованию, а затем ввести новое имя, или открыть окно свойств и изменить имя там. Редактирование имени в основном окне не только занимает меньше времени, но и отвечает принципу "где видишь, там и изменяешь".

Поддержка поиска и выбора

Если группа объектов, которые должны быть изменены, или над которыми должно быть выполнено действие, составлена так, что пользователь может выразить критерии выбора, идентифицируя их, то функция поиска основного окна может решить эту проблему, всегда выбирая все совпадения с критериями.

Существуют два метода управления поиском:

• В основном окне выбираются все объекты, к которым применимы критерии поиска. Если вы не можете гарантировать, что все найденные объекты будут показаны в основном окне одновременно (так как они могут находиться слишком далеко друг от друга), то список найденных объектов можно показать в окне поиска. После завершения поиска пользователь или задает дополнительные критерии поиска, либо выполняет на выбранными объектами нужное действие. Преимущество такого подхода заключается в том, что он позволяет пользователю выполнить определенную операцию над всеми объектами, удовлетворяющими критериям поиска.
• В окне поиска создается кнопка Найти, при нажатии которой должен выбираться следующий объект, удовлетворяющий критериям поиска, а содержимое основного окна прокручиваться так, чтобы этот объект стал видимым. После завершения поиска пользователь может выполнить операцию над выбранным объектом, а затем продолжить последовательный поиск объектов, соответствующих критериям поиска. Преимущество этого подхода в том, что пользователь видит найденный объект среди окружающих его объектов (в основном окне, а не в отдельном списке найденных объектов).

Во многих случаях можно скомбинировать эти два способа, например, включив кнопку Выбрать все в окно последовательного поиска или кнопку Показать следующий в окно параллельного поиска.

Сортировка

Примером сортировки может служить упорядочивание системой всех объектов по вертикали, в алфавитном порядке по имени или в соответствии со значением атрибута. Затем пользователь находит объекты, прокручивая окно. Это наиболее простая возможная поддержка просмотра, что касается как реализации, так и действия пользователя. Сортировка работает лучше всего, когда пользователь знает имя (или атрибут, в соответствии с которым выполняется сортировка) объекта, который ему нужен. Примером системы, реализованной таким образом, может служить телефонная книга. Как правило, в основном окне должна быть предусмотрена операция изменения порядка и/или критерия сортировки.

Наследование, управляемое пользователем

Примером наследования, управляемого пользователем, могут служить редакторы, работающие по принципу "что на экране, то и на принтере, в которых вы определяете, каков "стиль" каждого абзаца, а затем определяете, как должен макетироваться этот стиль (то есть каждый символ, принадлежащий этому стилю).

По сравнению с функцией поиска недостаток наследования, управляемого пользователем, состоит в том, что оно поддерживает только изменение атрибутов (и возможно, связей) для нескольких объектов, но не выполнение операций. Кроме того, наследование, управляемое пользователем, требует от пользователя выполнения дополнительных действий: явного определения групп (то есть доступных стилей) и управления ими. Это более сложная концепция.

Однако, если для каких-то объектов нельзя задать критерии поиска или если пользователю требуется внести связанные изменения в значения атрибута (например, увеличить на два), то решением этой проблемы может стать управляемое пользователем наследование.

Для того чтобы управляемое пользователем наследование было полезным, характер класса должен быть таким, чтобы объекты можно было распределить по группам (имеющим для пользователя определенный логический смысл), в которых большинство значений атрибутов одинаковы.

Преимущество управляемого пользователем наследования по сравнению с функцией поиска состоит в том, что оно поддерживает переопределение; например, можно изменять значение атрибута, но только в том случае, если оно не было явно определено в объекте. Кроме того, управляемое пользователем наследование позволяет пользователям создавать более общие (и, следовательно, мощные) определения значений атрибутов, например, наследовать шрифт из стиля, но увеличить его на два пиксела. Управляемое пользователем наследование особенно полезно в тех случаях, когда для групп трудно задать критерии поиска.

Класс, для которого будет поддерживаться управляемое пользователем наследование, может либо наследовать сам себя, либо вы можете создать новый класс, из которого должна наследоваться цель. Первый случай немного более предпочтителен, поскольку один и тот же объект может использоваться двояко: во-первых, из него может выполняться наследование, во-вторых, он может быть тем объектом, который предполагался изначально, например, счетом. Это приводит к тому, что пользователю (и системе) приходится управлять меньшим числом классов. С другой стороны, создание нового класса, от которого выполняется наследование, облегчает понимание, поскольку наследование четко отделено от обычного действия этого класса. В большинстве случаев создание нового класса будет наилучшим решением, особенно если пользователи не обладают большим опытом работы с компьютерами и объектно-ориентированными моделями. Лучше, чтобы новый класс, который вы создаете, наследовал сам себя для поддержки нескольких уровней наследования.

Для большинства систем пользователю обычно приходится изменять группу наследования для определенных объектов, поскольку он заранее точно не знает, какова должна быть структура этих групп наследования. Предусмотрите для этого специальную операцию.

Если вы решили, что в вашей системе должно поддерживаться управляемое пользователем наследование, то сначала проанализируйте, что именно (атрибуты, связи, класс) должно наследоваться, а затем обеспечьте наследование только для этих элементов. Результатом будет менее общий, но более легкий (как для пользователей, так и для разработчиков) способ управления функциональными возможностями. Смоделируйте элементы, которые должны наследоваться, в своем новом классе. Затем как в наследующем, так и в наследуемом классе будут моделироваться многие атрибуты. Помните, что управляемое пользователем наследование предназначено для экономии времени пользователя, а не вашего времени. Если класс наследует сам себя, это означает, что наследоваться может все.

Определите, нужно ли в действительности пользователю создавать новые объекты наследуемого класса, или система может раз и навсегда предоставить достаточное число объектов. Запрет на создание пользователем новых объектов сильно уменьшает гибкость наследования, но, с другой стороны, упрощает работу.

Определите также, как должны интерпретироваться изменения в числовых атрибутах наследующих объектов: относительно наследуемого значения или как фиксированные. Предположим, например, что объект наследует шрифт размером 12, а пользователь изменяет его до 14. Если изменение интерпретируется как относительное, то система запомнит размер шрифта объекта как наследуемое значение, к которому прибавляется число 2; то есть если наследуемый объект изменит размер шрифта, то наследующий объект также изменит размер шрифта. Если поддерживается относительная интерпретация, то это следует указать в атрибуте наследуемого объекта (так как рассматривается именно он, если требуется изучить наследование). Важно, что относительная интерпретация показывается пользователю (например, выводится "размер шрифта: 12+2=14", а не просто "размер шрифта: 14"). Рассмотрите различные сценарии, чтобы определить, какую интерпретацию поддерживать. Возможно, следует поддерживать обе.

Поскольку управляемое пользователем наследование предназначено только для пользователей с достаточным уровнем подготовки, то эту функцию его необходимо спроектировать так, чтобы она не влияла на обычную работу (например, когда пользователь не применяет наследование), иначе начинающий пользователь будет испытывать сильные затруднения.

Помните, что управляемое пользователем наследование конструируется для того, чтобы облегчить жизнь пользователя; оно не должно быть ни простым, ни сложным, в должно быть пригодным к использованию.

Иерархии просмотра

Иерархия просмотра позволяет пользователю (или, возможно, системе) группировать объекты, помещая их в основные окна или в составные объекты, имеющие иерархическую структуру. В этом случае пользователю при поиске придется просматривать только одну (или небольшое число) категорий. Это уменьшает число объектов, которые требуется показать в данный момент времени. Недостаток состоит в том, что заниматься распределением по категориям приходится пользователю. Примером такой иерархии могут служить файловые браузеры: каталоги или папки призваны помочь пользователю в поиске файлов.

Управление окнами

Обычно размерами окна и его расположением управляет исключительно пользователь. Однако, вы можете освободить его от выполнения действий по управлению окнами, позволив системе самой определять их размеры и расположение.

Чем больше размер основного окна, тем больше объектов в нем может быть показано, но при этом оно занимает больше места на экране. В основном окно обычно должно быть показано как можно больше объектов, но при этом оно не должно занимать лишней экранной площади.

• Сделайте основное окно достаточно большим, чтобы в нем могли быть показаны все объекты, но не больше экрана. Кроме того, объекты должны отображаться целиком; однако, в окне не должно быть областей, не содержащих никакой полезной информации (типа полей в настольных издательских продуктах). Даже если и есть место для таких пустых областей, они могут быть скрыты другими приложениями.
• Помните, что от сеанса к сеансу размер окна изменяется пользователем. Если число объектов увеличивается, то для того чтобы они были видны все, увеличивайте размер окна, если он уже не составляет полную высоту экрана, или если пользователь не выбрал размер, который меньше размера по умолчанию. Если число объектов уменьшается, уменьшайте размер окна, если пользователь не выбрал больший размер, чем размер по умолчанию. Это правило позволяет отслеживать намерения пользователя по изменению размеров окна.

Если вам часто приходится работать с приложением параллельно с другими приложениями, то можно дополнительно ограничить размер основного окна. В этом случае размер по умолчанию для полностью развернутого окна можно установить равным половине экрана (а не полному экрану).

Расположение по умолчанию основного окна сделайте таким, чтобы оно как можно меньше скрывалось другими приложениями. Если приходится скрывать некоторые окна, то выберите те, которые не используются в течение более длительного времени, и постарайтесь сделать видимым хотя бы маленький кусочек окна, чтобы пользователь мог легко его активировать.

Недостаток применения вышеперечисленных правил состоит в том, что у пользователя отбирается часть управляющих функций (система без спроса изменяет размер окна и не запоминает расположение окон по завершении сеанса). Следовательно, если вы применяете эти правила, необходимо предусмотреть управляющий элемент, с помощью которого пользователь может их отключить.

Размер и расположение дополнительных окон должны быть такими, что скрывать окно, из которого они вызваны, и, по возможности, другие дополнительные окна. Если они все-таки должны скрыть окно, из которого вызваны, постарайтесь сделать так, чтобы они не скрывали выбранные объекты. Скрытие важных объектов, например, выбранных, - это общий недостаток при работе с дополнительными окнами.

Для основных окон, отличных от главного основного окна, следует также применять правила настройки размера, изложенные в последнем абзаце.

Окна диалога, наоборот, должны располагаться так, чтобы скрывать активное окно. Поскольку эти окна обычно временные и маленькие, то пользователю, как правило, не требуется видеть активное окно, пока открыто окно диалога. Размещение окон диалога над активным окном гарантирует, что пользователь заметит их, и сокращает расстояние, на которое требуется переместить мышь, поскольку ее указатель, как правило, уже находится над активным окном.

Размер окон свойств определяется числом атрибутов. Если размер слишком большой (примерно 1/4 экрана), то рекомендуется использовать вкладки.

Информация сеанса

Конфигурации всех приложений должны сохраняться между сеансами (причем необходимо, чтобы пользователю не требовалось это указывать). Кроме того, должны сохраняться размер и расположение окон, выбранное представление и расположение полос прокрутки. После перезапуска приложения его вид должен в точности совпадать с тем, что видел пользователь, когда в предыдущий раз выходил из приложения. Это связано с тем, что при запуске сеанса первое, что обычно делают пользователи, - это переходят туда, где они были в момент завершения предыдущего сеанса работы.

Электронная справка

Электронная справка - очень важная часть системы. Хорошо спроектированная справка даже в состоянии заменить руководства пользователя для большинства систем. В рамках большинства проектов значительное время и усилия тратятся на составление и выпуск руководств, тогда как (и это известный факт!) большинство пользователей никогда ими не пользуются. Поэтому вместо этого направьте свои усилия на создание хорошей справочной системы.

Существует несколько возможных справочных инструментов:

• Справка-по-теме - это наиболее важное справочное средство. Оно позволяет пользователю ввести тему или найти существующую тему и получить справку по этим темам. Этот вид справки должен содержать обширный предметный указатель с большим числом синонимов. Помните: пользователь, которому нужна справка, может не знать правильный термин.
• Справка-по-объекту - это контекстная справка. Она содержит текст, объясняющий конкретную часть (объект) пользовательского интерфейса. Пользователь запрашивает контекстную справку, а затем выбирает часть пользовательского интерфейса, для которой требуется справка. Этот тип справки должен поддерживаться для всех частей пользовательского интерфейса, которые будут использоваться. Альтернативный способ - предоставление скрытой справки, представляющей собой сжатую форму контекстной справки, во всплывающем окне, которое появляется при наведении указателя мыши на элемент интерфейса. Преимущество показа скрытой справки во всплывающих окнах состоит в том, что она не влияет на обычную работу пользовательского интерфейса.
• Область сообщений - это область (обычно в главном окне), в которой система печатает "собственные" комментарии относительно действий пользователя. Если эта область определена, то она должна быть необязательной.
• Мастеры - это распространенный прием, которым можно пользоваться для предоставления пользователям инструкций по выполнению каких-либо задач. Мастер предоставляет пользователю помощь при пошаговом выполнении (нетривиальной) задачи. На страницах мастера выводится текст описания в сочетании с действиями (кнопками), с помощью которых пользователь может выполнить части задачи, объяснение которых содержится в тексте. Мастер может также задать вопросы и выполнить задачу автоматически, основываясь на ответах пользователя. Мастеры представляют собой превосходное средство для выполнения нетривиальных задач, а также задач, которые редко используются.

Потребность в контекстной справке и мастерах, вероятно, должна определяться во время опытной эксплуатации. Если пользователи не понимают, каковы различные части пользовательского интерфейса, это указывает на то, то требуется контекстная справка. Если пользователи испытывают трудности при выполнении определенной задачи, это указывает на то, что требуются мастеры.

Проблема многих справочных систем заключается в том, что они или написаны для новичков (то есть содержат огромный объем текста, объясняющего очевидные вещи), либо для специалистов (это справочные руководства, которые предполагают, что пользователь знает столько же, сколько и программист, создавший это приложение). Подготовка большинства пользователей многих систем выше среднего. Для них и пишите текст справки.

Функция отмены

Функция отмены (undo) очень полезна, хотя реализовать ее достаточно трудно. Она позволяет пользователям быстрее обучаться, поскольку они не должны будут бояться что-либо уничтожить. Кроме того, она снижает риск потери информации. Существует и другая возможность избежать потери информации: необходимо, чтобы пользователи подтверждали все действия, которые могут привести к потере информации. Этот, как правило, не лучший выход, так как пользователям приходится выполнять лишние действия, причем со временем они начинают бессознательно подтверждать все операции; таким образом, этот способ не подходит.

Достаточно амбициозный вариант - предоставить также функцию возврата (redo) и, возможно, несколько уровней отмены и возврата. Однако, как правило, для удобства отмены достаточно отмены первого уровня.

Агент макросов

При предоставлении макросов весьма полезно использовать агент, который будет непрерывно отслеживать действия пользователя в поисках повторяющихся последовательностей взаимодействий. При обнаружении такой последовательности агент создает для нее макрос (после того как запросит разрешение пользователя). Предположим, что пользователь вводит команду "Подчеркнуть" для двух абзацев текста, и оба раза после этой команды изменяет цвет текста на синий. Тогда агент должен запросить пользователя, следует ли создать макрос, который будет выполнять для выбранного абзаца текста как команду "Подчеркнуть", так и команду "Выбрать синий цвет". В случае положительного ответа агент должен создать такой макрос, а также кнопку (или пункт меню) для его выполнения.

Если пользователь выбирает объект во время записи, это обычно должно интерпретироваться как спецификация приращения, то есть: какой объект был выбран по отношению к предыдущему выбранному (как "выбрать следующий", "выбрать первый потомок" и и.д.).

Не ясно, следует ли изменение атрибутов объекта интерпретировать как спецификацию приращения (например, интерпретировать изменение значение атрибута с 12 до 14 как увеличение на 2, а не как установку нового значения, равного 14). Интерпретация изменения атрибута как параметра приращения обычно более мощная, поскольку для изменения значения атрибута фиксированным значением для нескольких объектов часто требуется выбрать несколько объектов и затем открыть для них окна атрибутов, в котором раз и навсегда задается новое значение атрибута (равное 14).

Динамическое выделение

Достаточно часто ассоциации между классами являются двунаправленными, то есть в реальном пользовательском интерфейсе ассоциация показана для обоих объектов. Если пользователь при выборе объекта A сможет увидеть, что A связан с объектом B, то ему, как правило, будет интересно и обратное (то есть при выборе объекта B он сможет увидеть, что B связан с A). Ассоциация обычно отображается в окнах свойств для объектов; связанный объект идентифицируется по имени.

В общем случае, визуализация ассоциаций между объектами в основном окне - довольно сложная задача. Использование стрелок или линий часто приводит к запутыванию диаграммы. Хороший способ визуализации ассоциаций - выделение всех связанных объектов при наведении указателя мыши на связанный объект. Например, если в редакторе документов сноски связаны с символами, то при наведении указателя на связанный символ сноски выделяются.