Метафоры пользовательского интерфейса
Метафора № 1: слуга
До сих пор эта метафора интерфейса пользователя широкого распространения в "овеществлениях" (реальных компьютерных системах) не получила, несмотря на явно присутствующую в названии историческую подоплеку. Действительно, слуги существовали почти во все времена, отлично известно, каким должен быть хороший слуга - исполнительным, ненавязчивым, недорогим, всегда сопровождающим своего хозяина. В соответствии с этими историческими канонами сформировано и новое направление в пользовательском интерфейсе и компьютинге в целом – ubiquitous computing, активно развиваемое в исследовательском центре Xerox в Пало-Альто. Основная идея пользовательского интерфейса-"слуги" – полное отсутствие этого интерфейса, точнее, его абсолютная незаметность. Просто ваш будильник, зазвонив утром, оповещает вашу кофеварку о "побудке" хозяина, кофеварка спрашивает, хотите ли вы кофе, в это время на настенную графическую панель выводятся новости (с учетом ваших интересов и вкусов), устанавливается любимая вами температура воды в ванне и так далее. Естественно, что все это осуществляется с помощью разветвленной сети независимых контроллеров (сколько услуг - столько и слуг).
При реализации пользовательского интерфейса обычного персонального компьютера в соответствии с метафорой "слуги", разнообразие "слуг" означает непреодолимые сложности в управлении ими и просто катастрофический рост их количества по мере развития потребностей "хозяина" (программы, делающей ВСЕ, еще никто не написал и никогда не напишет). Хотя в самом PARC предполагают лавинообразное распространение этой технологии, начиная с 2005 г.
Метафора № 2: ускоритель
В соответствии с этим представлением об ИП он позволяет значительно ускорить процессы взаимодействия пользователя с машиной, сократить как количество необходимых операций для постановки задач, так и облегчить (а значит, и ускорить) восприятие и осознание результатов выполнения этих задач. В "овеществлениях" эта метафора присутствует в качестве концептуальной основы всех систем, в первую очередь специализированных, предназначенных для работы в реальном времени и высококритичных к надежности. Здесь делается все, чтобы довести до минимума управляющие органы интерфейса, - одна-две кнопки, многопозиционный рычаг (аналог джойстика), системы позиционирования головы, зрачков глаз.
В более привычном нам мире ПК, к сожалению, является раритетом – все реже удается встретить программы с хорошо продуманным интерфейсом. Высокая динамика рынка программного обеспечения требует очень быстрого выхода новых продуктов, и здесь уже не до оптимизации взаимодействия пользователя с компьютером.
Метафора № 3: рабочий стол
Самая распространенная из метафор ИП, относительно напоминающая настоящий рабочий стол - папки, бумаги, инструменты - все в куче и тщательно перемешано J. Существенные недостатки: так называемая проблема "четырех сам" (выбирай сам, вспоминай сам, знай сам, догадывайся сам) и ограниченность представления объектов-абстракций понятием иерархии документов. Удобство манипуляций с "виртуальными документами" (окна, экраны и пр.) в достаточной степени компенсируется отсутствием хорошо продуманных механизмов ассоциирования объекта-абстракции (файла, документа) со множеством доступных инструментов. Например, в 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, в которую было вложено множество денег, и которая была прикрыта после нескольких месяцев микроскопических продаж (это самые шумные падения, были и другие).
Поможем написать любую работу на аналогичную тему