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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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