Основные принципы создания интерфейса

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

2. Непротиворечивость. Если в процессе работы с системой пользователем были использованы некоторые приемы работы с некоторой частью системы, то в другой части системы приемы работы должны быть идентичны. Также работа с системой через интерфейс должна соответствовать установленным, привычным нормам (например, использование клавиши Enter).

3. Неизбыточность. Это означает, что пользователь должен вводить только минимальную информацию для работы или управления системой. Например, пользователь не должен вводить незначимые цифры (00010 вместо 10). Аналогично, нельзя требовать от пользователя ввести информацию, которая была предварительно введена или которая может быть автоматически получена из системы. Желательно использовать значения по умолчанию где только возможно, чтобы минимизировать процесс ввода информации.

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

• в чем заключается проблема?

• как исправить эту проблему сейчас?

• как сделать так, чтобы проблема не повторилась?

При этом отвечать на эти вопросы нужно возможно более вежливым и понятным пользователям языком.

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

Качество интерфейса — эргономический аспект

Качество определяется в ГОСТ Р ИСО/МЭК 9126-93 как «объем признаков и характеристик продукции или услуги, который относится к их способности удовлетворять установленным или предполагаемым потребностям». При комплексной оценке показателей качества программного продукта качество пользовательского интерфейса вносит определяющий вклад в такую субхарактеристику качества, как практичность (usability).

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

Таблица 2. Пример мер практичности пользовательского интерфейса офисных приложений (ISO 9241-10-98)

Целевая функция	Меры эффективности	Меры продуктивности	Меры степени удовлетворенности
Полная практичность	Процент достигнутых целей; процент пользователей, успешно выполнивших задание; средняя точность завершенных заданий	Время выполнения задания; задания, выполненные в единицу времени; денежная оценка затрат на единицу задания	Оценочная шкала для степени удовлетворенности; степень загрузки по времени; частота жалоб

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

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

• эффективности (effectiveness) - влияния интерфейса на полноту и точность достижения пользователем целевых результатов;

• продуктивности (efficiency) или влияния интерфейса на производительность пользователя;

• степени (субъективной) удовлетворенности (satisfaction) конечного пользователя этим интерфейсом.

Эффективность является критерием функциональности интерфейса, а степень удовлетворенности и, косвенно, продуктивность — критерием эргономичности. Вводимые здесь меры соответствуют общей прагматической концепции оценки качества по соотношению «цели/затраты» (таблица 2).

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

Лекция № 7. Графический пользовательский интерфейс

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

Метафора № 1: слуга

До сих пор эта метафора интерфейса пользователя широкого распространения в "овеществлениях" (реальных компьютерных системах) не получила, несмотря на явно присутствующую в названии историческую подоплеку. Действительно, слуги существовали почти во все времена, отлично известно, каким должен быть хороший слуга - исполнительным, ненавязчивым, недорогим, всегда сопровождающим своего хозяина. В соответствии с этими историческими канонами сформировано и новое направление в пользовательском интерфейсе и компьютинге в целом – ubiquitous computing, активно развиваемое в исследовательском центре Xerox в Пало-Альто. Основная идея пользовательского интерфейса-"слуги" – полное отсутствие этого интерфейса, точнее, его абсолютная незаметность. Просто ваш будильник, зазвонив утром, оповещает вашу кофеварку о "побудке" хозяина, кофеварка спрашивает, хотите ли вы кофе, в это время на настенную графическую панель выводятся новости (с учетом ваших интересов и вкусов), устанавливается любимая вами температура воды в ванне и так далее. Естественно, что все это осуществляется с помощью разветвленной сети независимых контроллеров (сколько услуг - столько и слуг).

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

Метафора № 2: ускоритель

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

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

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

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

Метафора № 4: виртуальная реальность

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

Теоретико-множественная метафора

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

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

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

Теперь о сути метафоры с таким страшным математическим названием. На самом деле ничего сложного в этих математических терминах нет, и любой человек, даже абсолютно незнакомый с соответствующими разделами абстрактной алгебры в повседневной жизни, чуть ли не ежеминутно использует ее методы. Два множества (объектов-данных и инструментов) отлично знакомы и домохозяйкам, и автослесарям. Графическим представлением причинно-следственных связей или свойств, умно именуемых "графом", пользуются также практически все. На этом, собственно говоря, сложности заканчиваются (естественно, для пользователя). Как это может выглядеть? Да как угодно, например так: где в вертикальном узком поле А представлены классы объектов-данных или объекты-данные, в горизонтальном поле В - ассоциированные с выбранным (активированным) пользователем классом/объектом доступные инструменты, и в самом большом поле С располагается область, в которой пользователь может "собрать" в виде графа произвольный и абсолютно новый процесс обработки

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

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

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

К сожалению, метафоры отнюдь не безоблачны. У них есть несколько существенных недостатков.

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

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

В-третьих, почти всегда метафора будет сковывать функциональные возможности. Что делать, если проектируемая система обладает большим количеством функций, чем копируемый образец? Следование метафоре в таких условиях будет только вредить, поскольку совпадающим функциям будет учиться легче, а несовпадающим – сложнее (они будут слишком иначе устроены). Зачем тогда система, почему бы пользователю не воспользоваться её исходным образцом?

В-четвертых, совершенно необязательно, что сам по себе копируемый образец работает идеально. Если его копировать, окажется, что система не сможет быть эффективней своего прародителя. Например, Adobe PageMaker во многом копирует традиционные верстальные гранки, наследуя их известность пользователям вместе с их ограничениями. Благодаря этому он стал чрезвычайно популярен. Однако через некоторое время появился не копирующий гранки QuarkXpress, и отвоевал большую часть пользователей лишь потому, что работал более эффективно, не таская на себе груз старой идеи. Пользователи предпочитали потратить больше времени на обучение, зато выиграть в скорости работы. Анекдотичность ситуации заключается в том, что к настоящему времени гранки не используются вовсе, появилось поколение пользователей, которое никогда их в глаза не видело. Результат: обучаясь PageMaker, они должны дополнительно обучаться идее гранок, которая им вовсе не нужна.

В-пятых, почти всегда метафору можно использовать в документации, не перенося её в интерфейс, при этом с тем же успехом. Достаточно просто написать, что «система во многом напоминает …» и нужный результат будет достигнут.

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

Анализируя опыт успешных случаев их применения, можно вывести следующие правила:

• опасно полностью копировать метафору, достаточно взять из неё самое лучшее

• не обязательно брать метафору из реального мира, её смело можно придумать самому

• эффективнее всего метафорически объяснять значение отдельных объектов: например, для графической программы слои можно представлять как положенные друг на друга листы стекла (этот пример подходит и для предыдущего пункта)

• если метафора хоть как-то ограничивает систему, от неё необходимо немедленно отказаться.

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

Лекция № 8. Элементы графического пользовательского интерфейса

К основным элементам графического интерфейса относят: окна, меню, линейки инструментов, или инструментальные линейки, планки инструментов (tool bar), представляющие собой наборы пиктограмм, выбор которых инициирует какое-либо действие, линейки прокрутки (scroll bar), и элементы управления (controls): кнопки (buttons), в том числе кнопки команд (command buttons), кнопки настройки (options buttons), переключатели (radio buttons), наборы значений (value sets), выключатели (check box), списки (list box), текстовые зоны (text box), спиннеры (spinners) и др.

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

Командные кнопки (Push Buttons) – нажатие на такую кнопку запускает какое-либо явное действие (кнопки прямого действия). Изображаются в виде прямоугольника, в центре размещается короткое текстовое сообщение (слово), поясняющее, какое именно событие инициирует нажатие кнопки. Командная кнопка имеет три состояния: нормальное (кнопка доступна, но еще не активирована пользователем), нажатое (активированное) и недоступное (неактивное) (если недоступна функция, закрепленная за кнопкой, или если кнопка расположена в фоновом окне).

Чекбоксы (Checkboxes) и радиокнопки (Radio buttons) – кнопки отложенного действия, т.е. их нажатие не инициирует какое-либо немедленное действие, с их помощью пользователя вводят некоторые параметры, которые скажутся после, когда действие будет запущено другими элементами управления. Главное отличие состоит в том, что радиокнопки являются кнопками единственного выбора, а чекбоксы – множественного. В группе радиокнопок как минимум одна кнопка должна быть проставлена по умолчанию. Радиокнопки отображают наборы состояний, они никогда не инициируют действия. Причем эти наборы должны быть статичны (т.е. не зависеть от контекста). Всегда объединяются в группы (предпочтительно от двух до семи кнопок).

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

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

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

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

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

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

Комбобоксы. Комбобоксами (combo box), называются гибриды списка c полем ввода: пользователь может выбрать существующий элемент, либо ввести свой. Комбобоксы бывают двух видов: раскрывающиеся и расширенные.

Поля ввода (edit text fields). Вместе с командными кнопками, чекбоксами и радиокнопками, поля ввода являются основой любого интерфейса.

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

Крутилка (spinner, little arrow) – элемент управления, который позволяет пользователю уменьшать или увеличивать значение некоторой величины. Крутилки также могут содержать поле ввода, не такое универсальное, как обычное, не позволяющее вводить текстовые данные, но зато обладающее двумя полезными возможностями.

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

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

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

• Статические меню, т.е. меню, постоянно присутствующие на экране. Характерным примером такого типа меню является панель инструментов.

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

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

Вторая классификация также делит меню на два типа:

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

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

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

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

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

• главные окна программы

• окна документа

• режимные диалоговые окна

• безрежимные диалоговые окна

• палитры

• окна браузера (поскольку используемая в интернете технология существенно отличается от технологии ПО, этот тип окон стоит несколько особняком).

Элементы окна

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

Строка заголовка. Текст и, в меньшей степени, пиктограмма заголовка играют важную роль в ПО (они заведуют переключением задач) и очень важную в интернете (заведуют навигацией). С переключением задач всё просто и сложно одновременно. Просто, поскольку правило тут простое «Релевантное выводится в первую очередь». Поскольку пользователю нужен именно конкретный документ конкретной программы, а вовсе не программа просто (окна документов, не попадающие в переключатель задач, нехороши), названия документов, как более релевантные, нужно выводить в первую очередь. Наоборот, сложность состоит в том, что из-за жесткости интерфейса Windows много не сделаешь. Тем не менее, сокращать название программы нужно безусловно.

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

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

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

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

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

Панель инструментов для опытных пользователей. Зачастую система обладает функциональностью, которая с одной стороны важна, а с другой – способна свести с ума неподготовленного пользователя. Обычно это касается не столько собственно функций, сколько режимов работы системы. В таких случаях строка состояния является отличным решением проблемы. С одной стороны, делая переключатели режимов непохожими на поля вывода (знаете ли вы, например, что метки ЗАП0, ИСПР, ВДЛ и ЗАМ в статусной строке MS Word не только индикаторы?) можно снизить вероятность ошибочного переключения. С другой стороны, если уж пользователь нечаянно щелкнет на переключателе, он сразу же увидит изменение его вида и впоследствии, вероятно, сможет переключиться назад. С еще одной стороны, опытный пользователь сможет переключаться между режимами так же легко, как если бы он переключался через панель инструментов.

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

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

• Размер ползунка должен показывать общий объем пролистываемого документа.

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

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

• Необходимо обеспечить обработку погрешности перемещения курсора. Когда пользователь курсором перемещает ползунок, а смотрит в это время на документ, курсор может сойти с полосы. До определённого момента (смещение на 30-70 пикселей) система должна такое смещение игнорировать.

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

Все панели имеют следующие достоинства:

• они позволяют пользователям быстро вызывать нужные функции мышью

• они позволяют пользователям меньше задействовать память

• они повышают визуальное богатство интерфейса

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

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

Панель инструментов нежелательно делать единственным способом вызова функции.

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

Изображения (Иконки)

 

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

Все иконки можно классифицировать согласно тому, насколько точно они отображают несущую функцию.

Иконки подобия - иконки похожи на объекты, которые они отображают (типа ножниц, чтобы отобразить операцию «вырезки»);

Иконки по образцу представляют пример типа объекта (например иконкой, показывающей линию, чтобы представить средство рисования);

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

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