Джесс Джеймс Гарретт
Одним из способов представления информационной архитектуры и взаимодействий пользователя с веб-сайтом является использование диаграмм. Этот документ представляет некоторые аспекты моделирования информационных систем, основные графические символы для документирования информационной архитектуры и способов взаимодействия пользователя с веб-сайтом в виде диаграмм, а так же методику создания и использования таких диаграмм.
История развития документа
Версия 1.1b (06 Марта 2002)
OmniGraffle 2.0 - первое приложение, которое поставляется с встроенной поддержкой VisVocab. Сейчас OmniGraffle предустанавливается на все ApplePowerMacs и PowerBooks. Можно так же загрузить с сайта Omni.
Версия 1.1 (31 Января 2001)
Добавлен элемент «набор файлов»
Добавлен элемент «условный селектор»
Модифицирован элемент «стрелка», можно использовать несколько указателей (arrowheads)
Модифицирован элемент «кластер», теперь этот элемент используется только в нисходящем потоке от условной ветви или селектора
Модифицирован элемент «условная ветвь», элемент может принимать значение «пусто» (null)
Улучшения в библиотеках символов
Новая библиотека для AdobeInDesign
Версия 1.0 (17 Октября 2000)
Первая версия документа
Предисловие переводчика
Большое влияние на перевод этого текста оказала книга А.Леоненкова «Самоучитель UML», многие термины и словарные конструкции использованы мной в том же смысле, что и А. Леоненковым. Вообще, эта книга является ключом к правильному пониманию графической нотации для моделирования ИА и способов взаимодействия пользователя с сайтом.
Замечу, что данная нотация не имеет никакого отношения к UML и, по сути, является всего лишь одним из способов представления ИА, созданным архитектором для собственных нужд. Однако этот способ моделирования информационной системы показался мне достаточно простым и гибким для того, чтобы его можно было предложить использовать остальным. Приятного прочтения.
Предисловие
Графическая нотация — это набор символов, используемых для визуального моделирования чего-либо (обычно системы, структуры или процесса). Нотация, представленная здесь, может быть использована информационным архитектором или дизайнером взаимодействий (InteractionDesigner) для того, чтобы описать на высоком уровне абстракции информационную архитектуру и/или процесс взаимодействия пользователя с веб-сайтом.
Эти описания (диаграммы) разрабатываются для пяти основных аудиторий:
Спонсоры проектов и менеджеры проектов используют диаграммы, чтобы получить общее представление о структуре и форме проекта.
Редакторы используют диаграммы, чтобы определить требования к содержанию (информационному наполнению) проекта.
Дизайнеры и дизайнеры интерфейсов используют диаграммы, чтобы определить количество типов страниц с уникальным дизайном, а так же для того, чтобы получить общее представление о системе навигации и требованиях к интерфейсу.
Веб-Технологи используют диаграммы, чтобы определить функциональные требования.
Информационные архитекторы и проектировщики интеракций используют диаграммы для дальнейшей разработки более детализованных документов, представляющих навигацию и интерфейс отдельных страниц.
Каждый из представителей любого типа (кроме спонсоров) нуждается в огромном количестве дополнительных деталей, чтобы успешно выполнить свою работу. Проблема в том, что компоненты моделируемой системы, необходимые для работы одной аудитории очень сильно отличаются от компонентов, нужных другой.
Единственным решением этой проблемы является использование минимального уровня детализации (максимального уровня абстракции) на диаграммах таким образом, чтобы диаграммы были одинаково понятны любому типу аудитории. Диаграмма в этом случае служит основой для создания более детализованных документов, ориентированных уже на конкретные потребности каждой аудитории.
Некоторые ключевые требования графической нотации для документирования информационной архитектуры и способов взаимодействия пользователя с веб-сайтом включают в себя:
Широкоформатность: нотация должна быть достаточно простой для того, чтобы можно было набросать основные символы то руки. Элементы диаграммы должны размещаться таким образом, чтобы позднее можно было добавить элементы без излишнего «утяжеления» внешнего вида и без ущерба для понимания диаграммы.
Независимость от использования конкретных инструментов: нотация должна быть независима от использования конкретных программных инструментов для создания диаграмм, так же, как не должна ориентироваться на какой-либо конкретный инструмент. Архитектура нотации должна предполагать конвертацию графических символов нотации в формат предпочитаемой архитектором программы.
Малый размер и самодостаточность: поскольку диаграммы ориентированы на очень широкий спектр аудиторий с разным уровнем знаний (или заинтересованности) систем диаграммирования, используемых в других областях моделирования, диаграммы, создаваемые с помощью данной нотации, должны быть понятными без специальных знаний. Общее количество элементов на диаграмме должно быть минимальным для верного понимания связи между элементами концепции и графическим символом для его представления. Концепция, представленная на диаграмме, может быть сколь угодно сложной (комплексной), диаграмма, представляющая концепцию, должна быть простой и понятной.
Моделирование статичной информационной системы
Информационная архитектура и дизайн взаимодействий как способы моделирования информационной системы — это две стороны одной монеты (см. элементы структуры «Опыта Пользователя», там есть определения этих терминов в том смысле, в котором они использованы здесь.) Создание диаграмм структуры сайта связано с обоими типами моделирования. Но цели диаграмм для каждого типа будут слегка отличаться.
В обоих случаях диаграммы представляют макроструктуру, с необходимым минимумом деталей для того, чтобы разработчики могли увидеть картину целиком. Поэтому задача архитектора состоит в том, чтобы заранее определить необходимый уровень детализации диаграммы. Микроструктура (структура отдельно взятой страницы) описывается в других документах и, скорее всего, не архитектором (а дизайнером — прим. пер.)
Диаграмма информационной архитектуры должна представлять концептуальную структуру и организацию содержания сайта. Заметим, что концептуальная структура — это не то же самое, что структура навигации. Цель диаграммы ИА не состоит в том, чтобы представить полную спецификацию системы навигации по сайту, это лучше сделать в другом документе, где можно позволить себе больший уровень детализации.
Диаграмма взаимодействий должна представлять, способы выполнения пользователем отдельных задач на сайте, а также дискретные шаги, которые ему нужно предпринять для выполнения задачи. Как и в случае с навигацией, детали интерфейса не должны присутствовать на диаграмме — если вы вдруг обнаружите, что занимаетесь рисованием кнопок и полей ввода, значит, вы уходите в сторону излишней детализации диаграммы.
Эта нотация основана на простой концептуальной модели, представляющей информационную архитектуру и способы взаимодействия пользователя с сайтом (системой) вместе:
Пользователь взаимодействует с системой посредством путей (paths)
Пользователь перемещается по путям при помощи действий (actions)
Эти действия могут заставить систему сгенерировать события (результаты) (results)
Простые элементы: страницы, файлы и наборы страниц и файлов
Основная структурная единица любого веб-сайта — это, конечно, страница (page). На диаграмме страница изображается простым прямоугольником. Заметим, что страница на диаграмме - это единица представления, а не реализации. Например, одна страница на диаграмме может представлять в действительности несколько HTML файлов (например, страница содержит набор фреймов) или несколько разрозненных фрагментов кода (когда используются включения на стороне сервера (SSI) или базы данных).
Кроме страниц, существуют файлы (files) - единицы организационной структуры сайта, не имеющие навигационных свойств. Пользователь работает с файлами вне браузера (аудио и видео файлы, отдельные документы, такие, как PDF, или исполняемые файлы (программы)). Файлы изображаются на диаграмме хорошо известным значком — прямоугольник с загнутым внутрь верхним правым уголком.
Рис. 1а (лево): страница и файл
Рис. 1б (право): набор страниц и файлов
Набор страниц (pagestack) представляет на диаграмме группу функционально идентичных страниц, навигационные свойства которых несущественны по отношению к макроструктуре сайта. Аналогично, набор фалов (filestack) представляет на диаграмме группу файлов, доступ к которой осуществляется по общей для всех системе навигации и которая может быть классифицирована как одно множество (например, коллекция игр или библиотека PDF документов).
Используйте ярлыки (labels) чтобы идентифицировать страницы и файлы. Ярлыки должны быть уникальными для каждой страницы или файла на диаграмме и не должны представлять реальные имена файлов или значения тегов <title>, например. Уникальные числовые идентификаторы и префиксы типа файла могут быть успешно использованы в качестве ярлыков на диаграмме.
Отношения: связи и стрелки
Отношения между элементами на диаграмме изображаются в виде простой линии, или связи (connector). Связи обязательно будут трансформированы в навигационные отношения, но не все навигационные отношения могут быть отражены на диаграмме.
В случае моделирования информационной архитектуры, отношения чаще всего отображаются через иерархическую организацию страниц (в виде деревьев). Однако это не всегда требуется и в некоторых случаях вообще не рекомендуется.
На диаграмме взаимодействий связи должны быть направленными, чтобы представлять пути пошагового выполнения пользователем той или иной задачи. Для этого используются стрелки (arrows). Далее термины выше (восходящий, upstream) и ниже (нисходящий, downstream) в потоке (пути) определяют расположение элемента на диаграмме.
Заметим, что стрелки на диаграмме взаимодействий не имеют семантического значения «движение только в этом направлении». Стрелки, как правило, представляют наиболее вероятное направление движения пользователя.
Рис. 2а (верхняя диаграмма): простая древовидная структура
Рис. 2б (нижняя диаграмма): та же структура, что и на диаграмме 2а, но представленная иначе
Если по каким-либо причинам необходимо запретить движение в обратном направлении (если имело место необратимое действие, например, удаление записи из базы данных), используется перечеркивающая линия (просто вертикальный штрих на противоположном конце стрелки). В случае комплексной архитектуры иногда может появиться необходимость в том, чтобы добавить дополнительный указатель направления (головку стрелки, arrowhead) около элемента, расположенного на диаграмме в восходящем потоке (выше), чтобы яснее представить направление движения.
Рис. 3а (лево верх): Стрелка показывает направление вниз по потоку, по направлению к выполнению задачи
Рис. 3б (лево низ): Вертикальный штрих символизирует запрет на движение обратно по пути
Рис. 3в (право): Множество указателей облегчают понимание диаграммы.
Связям и стрелкам могут быть присвоены ярлыки, но лучше ограничить использование ярлыков для этих элементов теми случаями, когда необходимо обозначить какое-либо конкретное действие пользователя, не более. Если ярлыки становятся слишком длинными и мешают другим элементам на диаграмме, лучше вынести их в легенду или приложения.
Рис. 4а (лево): Пример неправильного ярлыка
Рис. 4б (центр):Пример правильного ярлыка
Рис. 4в (право): Ссылка на ярлык
Параллельный
Символ параллельного набора (concurrentset) на диаграмме изображается полукругом, используется в тех случаях, когда действие пользователя генерирует несколько одновременных событий (например, запуск нового окна одновременно с загрузкой документа в основное окно, или отображение страницы одновременно с диалогом загрузки файла). Как и стрелки, символ параллельного набора имеет направление. Элементы диаграммы, расположенные выше по пути соединяются с дугой символа, ниже — с плоской частью (основанием) символа.
Рис. 5: Параллельный набор
Точки входа и выхода
Архитекторам часто приходится работать с огромными листами бумаги, на которых изображена диаграмма системы. Но даже в том случае, когда есть возможность использовать устройство широкоформатной печати, например, плоттер, не всегда возможно уместить диаграмму особенно комплексной архитектуры в один лист.
Для того, чтобы можно было разбить диаграмму на несколько листов, используют точки входа и выхода (continuationpoints), которые изображаются при помощи квадратных скобок и являются «мостами» между листами диаграмм.
Рис. 6а (лево): Продолжение диаграммы от элемента «D» на другом листе (на рис. 6б)
Рис. 6б (право): Начало диаграммы на другом листе (на рис. 6а)
По мере необходимости, одна точка выхода может вести к нескольким точкам входа. Ориентация скобок (горизонтальная или вертикальная) принципиального значения не имеет и зависит от эстетических предпочтений архитектора[1]
.
Общности: области и повторяющиеся (итеративные) области
Элемент область (area) изображается на диаграмме как прямоугольник с закругленными углами, используется для обозначения группы страниц, имеющих общий атрибут (например, страницы появляются в выпадающем окне или имеют общий элемент дизайна). Используйте ярлыки, чтобы обозначить этот общий атрибут (или, как в случае со связями, сделайте сноски в приложение или легенду диаграммы).
Рис. 7: Область, объединяющая страницы по признаку «показываются в выпадающем окне»
Часто архитектура предполагает повторение основной структуры элемента применительно к некоторому количеству функционально тождественных элементов. Например, архитектура сайта может моделировать каталог продукции, где каждый элемент каталога имеет ассоциированный набор страниц. Чтобы представить этот момент на диаграмме, используется повторяющаяся область (iterativearea) (набор прямоугольников с закругленными углами).
Рис. 8: Повторяющаяся область, представляет множество продуктов в каталоге
Заметим, что связи и стрелки не могут указывать просто на область. Область служит только для того, чтобы представить на диаграмме общность страниц, а не конкретный раздел, например. Использовать области на диаграмме следует аккуратно, так как очень легко сбиться на моделирование с помощью областей таких структур, которые не имеют ни малейшего отношения к вопросу взаимодействия пользователя с сайтом (например, какие страницы на каких сайтах должны быть расположены и т.п.).
Многократно используемые компоненты: потоковые области и ссылки на потоковые области
Иногда (особенно часто при проектировании взаимодействий) может потребоваться представить некоторую процедуру как последовательность шагов (процедура входа в закрытую облась сайта, например). Предполагается, что эта процедура многократно используется на сайте в разных контекстах. Часто такие последовательности являются структурными компонентами задач, которые пользователь выполняет на сайте (аналогом может служить процедура в языке программирования (Subroutine)).
Подобная последовательность шагов называется поток (flow) и изображается на диаграмме при помощи двух символов: потоковой области (flowarea), которая моделирует собственно процедуру и ссылки на потоковую область (flowreference), которая представляет поток в разных контекстах на диаграмме. Оба элемента имеют одинаковую основную форму — прямоугольник с обрезанными углами (или, если хотите, вытянутый восьмиугольник).
Рис. 9а (лево): Ссылка на потоковую область «Процедура»
Рис. 9б (право): Потоковая область «Процедура»
Потоковая область предполагает использование точек входа и выхода в поток. Точки располагаются за пределами области и являются ассоциативными ссылками на множество структурных элементов в зависимости от контекста (в отличие от тех точек, используемых чтобы разбить диаграмму на несколько листов, там точки действительно являются структурными элементами).
Ссылки на потоковые области функционируют сходным образом с точками входа и выхода. Назначение этих элементов одно — позволить архитектору разбить диаграмму на несколько страниц.
Моделирование динамичной информационной системы
Очень часто информационная архитектура и структура взаимодействий должны меняться в зависимости от различных условий. Эти изменения описываются в терминах условной логики и остальные элементы нотации являются специфичными для динамичных систем. Вот основная концептуальная модель динамичной системы:
Система следит за состоянием своих атрибутов (attribute). Эти атрибуты могут иметь отношение к:
Пользователю (например, тип пользователя)
Сессии (например, статус пользователя в системе)
Типу содержания, к которому получен доступ
Реальному миру (например, время и дата)
Атрибуты имеют значения (values) («3 Р.М.» одно из возможных значений атрибута «дата и время»)
Ассоциация атрибута с определенным значением называется условием (condition)
Система отслеживает (evaluates) изменения условий
В случае статичной архитектуры каждый путь представляется каждому пользователю в любом случае (в любых условиях), и каждый путь всегда ведет к одному и тому же результату. В динамичной системе система сама решает, какие пути предлагать пользователю и какие результаты представлять в зависимости от тех или иных условий.
Чтобы диаграмма оставалась «чистой» условия, как правило, описываются либо в приложении, либо в легенде.
Точки принятия решений
Когда действие пользователя может сгенерировать несколько результатов, система должна решить, какой результат представить в ответ на действие (самый обычный пример такой логики — процедура обработки ошибок при работе пользователя с формой). На диаграмме такой момент изображается точкой принятия решения (decisionpoint) в форме ромба. Заметим, что стрелки должны использоваться вместе с точками принятия решений, иначе будет непонятно, расположены ли следующие элементы диаграммы выше или ниже точки.
Рис. 10: Точка принятия решения (10а) в потоке «вход пользователя в систему»
Условные связи и стрелки
Условная связь (conditionalconnector) изображается пунктирной линией, используется в случае, когда путь может быть либо представлен пользователю, либо нет, в зависимости от определенных условий.
Рис. 11а (лево): Условная связь
Рис. 11б (право): Условная стрелка
Например, страница может содержать информацию, доступ к которой разрешен только сотрудникам фирмы. Условием в таком случае будет тип пользователя (сотрудник), если условие удовлетворяет этому требованию, путь открыт. Если нет, путь просто не существует.
Выбор «один из многих»: условные ветви
Когда система должна выбрать один путь из нескольких взаимно исключающих, используется символ условной ветви (conditionalbranch), на диаграмме изображается треугольником. Элементы диаграммы выше ветви соединяются с вершиной треугольника, элементы ниже — с основанием.
Рис. 12: Условная ветвь
Пример на рисунке 12 на первый взгляд похож на пример, изображенный на рисунке 10, но поведение системы, моделируемое на рисунке 12, сильно отличается от поведения на рисунке 10. В точке принятия решения только один путь (или навигационный элемент) будет представлен пользователю; место, в которое пользователь будет перемещен в этом случае, определяется конкретным условием. На рисунке 12 система принимает похожее решение, но происходит это до того, как пользователь предпринял какие-либо действия. Условная ветвь показывает, что система принимает решение о том, какой путь представлять пользователю. Пути со страницы А на страницы B, C и D взаимно исключают друг друга, т.е. если существует путь B, то пути C и D нет.
Как и в случае с условными связями и стрелками, условные ветви могут вообще не представлять пользователю никакого пути. Разница в том, что отрицательный результат («пустой» путь) может быть разрешен, т.е. атрибут системы может принимать трех возможных логических значения (истина, ложь, ничто (null)), а не два (истина, ложь). Способность системы представлять пустые пути обязательно нужно указать в приложении к диаграмме.
Выбор «один или много»: условные селекторы
Функции условного селектора (conditionalselector) (на диаграмме изображается трапецией) схожи с функциями условной ветви, за одним важным исключением: в случае с селектором, нисходящие пути не исключают друг друга, т.е. пользователь видит любое количество путей, удовлетворяющих тем или иным условиям.
Рис. 13: Условный селектор
Например, символом условного селектора можно представить на диаграмме список страниц с результатом поиска в поисковой машине. В этом случае страницы с результатом будут располагаться вверх от селектора, условием будет служить критерий поиска, нисходящий путь от селектора будет вести на проиндексированные машиной страницы. Как и условная ветвь, условный селектор может сгенерировать пустой путь и этот момент необходимо отразить в приложении к диаграмме.
Одно решение, много путей: кластеры
Некоторые условные структуры требуют, чтобы система представляла пользователю более одного пути в зависимости от условия. Эти пути ассоциируется в кластеры (clasters) (изображается кругом). Кластер изображается на нисходящем пути от условной ветви или условного селектора.
Рис. 14: Кластер
Структура, изображенная на рисунке 14 функционирует как обычная условная ветвь, но для одного из условий мы представляем больше одного пути. То есть если значением атрибута станет «X» пользователь увидит путь на страницу B, а если значением будет «Y», то пользователь увидит пути на страницу C и D.
Ограничения: условные области
Когда одно или несколько условий применяется к группе страниц, эта группа изображается на диаграмме как условная область (conditionalarea) (прямоугольник с закругленными углами пунктирной линией).
Рис. 15: Пример условной области, где требуется безопасное соединение
Условные области применяются, как правило, в ситуациях, предполагающих ограничения доступа. В отличие от других типов областей, условные области ассоциируются с результатом, который генерируется системой в случае, когда условие не выполнено.
Загружаемые библиотеки символов
Stencilfile для Visio 2000
Stencil file для Visio 5
Stencil file для Visio 4
PowerPoint file
Library file для Adobe InDesign
IllustratorEPSfile
набор EPS файлов, содержит один элемент на файл, для импорта в другие приложения (1.1 MB)
Заключение
Диаграмма для сайта «MetaFilter» (http://www.metafilter.com) является конкретным примером диаграммы информационной архитектуры и способов взаимодействия пользователя с веб-сайтом (автор не был вовлечен в разработку этого сайта). Данная нотация — это только первый шаг в разработке унифицированного визуального языка моделирования информационной архитектуры и способов взаимодействия пользователя с веб-сайтом. Любые замечания и дополнения рассматриваются по адресу jjg@jjg.net.