ЧМВ лекции АТ

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

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

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

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

5

«черного» и «белого ящика».

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

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

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

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

Эффективность является критерием функциональности интерфейса,

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

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

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

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

До сих пор эта метафора интерфейса пользователя широкого распространения в "овеществлениях" (реальных компьютерных

5

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

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

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

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

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

Вболее привычном нам мире ПК, к сожалению, является раритетом

5

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

Метафора № 3: рабочий стол

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

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

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

5

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

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

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

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

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

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

восвоении и требует недюжинных знаний, что существенно

5

ограничивает области применения созданных в соответствии с ней систем.

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

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

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

5

угодно, например так: где в вертикальном узком поле А представлены классы объектов-данных или объекты-данные, в горизонтальном поле В - ассоциированные с выбранным (активированным) пользователем классом/объектом доступные инструменты, и в самом большом поле С располагается область, в которой пользователь может "собрать" в виде графа произвольный и абсолютно новый процесс обработки

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

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

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

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

5

несколько существенных недостатков.

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

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

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

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

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

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

5

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

следующие правила:

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

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

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

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

Суммируя, можно сказать, что применять метафору можно, но с

большой осторожностью. Не надо забывать, что большинство систем, сильно базирующихся на метафоре, проиграли конкурентам. Таков уже упоминавшийся 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) и др.

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

5

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

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

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

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

5