Графічна нотація для документування інформаційної архітектури та взаємодій користувача з веб-сайтом

Джесс Джеймс Гарретт

Одним із способів подання інформаційної архітектури та взаємодій користувача з веб-сайтом є використання діаграм. Цей документ представляє деякі аспекти моделювання інформаційних систем, основні графічні символи для документування інформаційної архітектури та способів взаємодії користувача з веб-сайтом у вигляді діаграм, а також методику створення і використання таких діаграм.

Історія розвитку документа

Версія 1.1b (06 березня 2002)

OmniGraffle 2.0 - перші додаток, що поставляється з вбудованою підтримкою VisVocab. Зараз OmniGraffle встановлювати на всі Apple Power Macs і PowerBooks. Можна також завантажити з сайту Omni.

Версія 1.1 (31 січня 2001)

долучення елемент «набір файлів»

долучення елемент «умовний селектор»

Модифицирован елемент «стрілка», можна використовувати кілька покажчиків (arrowheads)

Модифицирован елемент «кластер», тепер цей елемент використовується тільки в спадному потоці від умовної гілки або селектора

Модифицирован елемент «умовна гілку», елемент може приймати значення «порожньо» (null)

Покращення в бібліотеках символів

Нова бібліотека для Adobe InDesign

Версія 1.0 (17 жовтня 2000)

Перша версія документу

Передмова перекладача

Велике вплив на переклад цього тексту справила книга А. Леоненкова «Самоучитель UML», багато термінів і словникові конструкції використані мною в тому ж сенсі, що й А. Леоненковим. Взагалі, ця книга є ключем до правильного розуміння графічної нотації для моделювання ІА і способів взаємодії користувача з сайтом.

Зауважу, що дана нотація не має ніякого відношення до UML і, по суті, є всього лише одним із способів подання ІА, створеним архітектором для власних потреб. Однак цей спосіб моделювання інформаційної системи видався мені досить простим і гнучким для того, щоб його можна було запропонувати використовувати іншим. Приємного прочитання.

Передмова

Графічна нотація - це набір символів, що використовуються для візуального моделювання чого-небудь (зазвичай системи, структури чи процесу). Нотація, представлена тут, може бути використана інформаційним архітектором або дизайнером взаємодій (Interaction Designer) для того, щоб описати на високому рівні абстракції інформаційну архітектуру та/або процес взаємодії користувача з веб-сайтом.

Ці опису (діаграми) розробляються для п'яти основних аудиторій:

Спонсори проектів і менеджери проектів використовують діаграми, щоб отримати загальне уявлення про структуру та формі проекту.

Редактори використовують діаграми, щоб визначити вимоги до змісту (інформаційному наповнення) проекту.

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

Веб-Технологи використовують діаграми, щоб визначити функціональні вимоги.

Інформаційні архітектори та проектувальники інтеракцій використовують діаграми для подальшої розробки більш деталізований документів, що представляють навігацію і інтерфейс окремих сторінок.

Кожен з представників будь-якого типу (крім спонсорів) має потребу у величезній кількості додаткових деталей, щоб успішно виконати свою роботу. Проблема в тому, що компоненти моделюється системи, необхідні для роботи однієї аудиторії дуже сильно відрізняються від компонентів, потрібних інший.

Єдиним вирішенням цієї проблеми є використання мінімального рівня деталізації (максимального рівня абстракції) на діаграмах таким чином, щоб діаграми були однаково зрозумілі будь-якому типу аудиторії. Діаграма в цьому випадку служить основою для створення більш деталізований документів, орієнтованих вже на конкретні потреби кожної аудиторії.

Деякі ключові вимоги графічної нотації для документування інформаційної архітектури і способів взаємодії користувача з веб-сайтом включають в себе:

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

Незалежність від використання конкретних інструментів: нотація повинна бути незалежна від використання конкретних програмних інструментів для створення діаграм, так ж, як не повинна орієнтуватися на будь-який конкретний інструмент. Архітектура нотації повинна припускати конвертацію графічних символів нотації у формат бажаною архітектором програми.

Малий розмір і самодостатність: оскільки діаграми орієнтовані на дуже широкий спектр аудиторій з різним рівнем знань (або зацікавленості) систем діаграммірованія, що використовуються в інших областях моделювання, діаграми, що створюються за допомогою цієї нотації, повинні бути зрозумілими без спеціальних знань. Загальна кількість записів на діаграмі повинна бути мінімальною для вірного розуміння зв'язку між елементами концепції і графічним символом для його подання. Концепція, представлена на діаграмі, може бути як завгодно складною (комплексної), діаграма, що представляє концепцію, повинна бути простою і зрозумілою.

Моделювання статичної інформаційної системи

Інформаційна архітектура та дизайн взаємодій як способи моделювання інформаційної системи - це дві сторони однієї монети (див. елементи структури «Досвіду Користувача », там є визначення цих термінів у тому сенсі, в якому вони використані тут.) Створення діаграм структури сайту пов'язане з обома типами моделювання. Але цілі діаграм для кожного типу будуть дещо відрізнятися.

В обох випадках діаграми представляють макроструктури, з необхідним мінімумом деталей для того, щоб розробники могли побачити картину цілком. Тому завдання архітектора полягає в тому, щоб заздалегідь визначити необхідний рівень деталізації діаграми. Мікроструктура (структура окремо взятої сторінки) описується в інших документах і, швидше за все, не архітектором (а дизайнером - Прим. пер.)

Діаграма інформаційної архітектури повинна представляти концептуальну структуру і організацію змісту сайту. Зауважимо, що концептуальна структура - це не те ж саме, що структура навігації. Мета діаграми ІА не полягає в тому, щоб уявити повну специфікацію системи навігації по сайту, це краще зробити в іншому документі, де можна дозволити собі більший рівень деталізації.

Діаграма взаємодій повинна представляти, способи виконання користувачем окремих задач на сайті, а також дискретні кроки, які йому потрібно вжити для виконання завдання. Як і у випадку з навігацією, деталі інтерфейсу не повинні бути присутнім на діаграмі - якщо ви раптом виявите, що займаєтеся малюванням кнопок та полів вводу, значить, ви йдете в бік зайвої деталізації діаграми.

Ця нотація заснована на простій концептуальної моделі, що представляє інформаційну архітектуру і способи взаємодії користувача з сайтом (системою) разом:

Користувач взаємодіє з системою за допомогою шляхів (paths)

Користувач переміщається по шляхах за допомогою дій (actions)

Ці дії можуть змусити систему згенерувати події (результати) (results)

Прості елементи: сторінки, файли та набори сторінок і файлів

Основна структурна одиниця будь-якого веб-сайту - це, звичайно, сторінка (page). На діаграмі сторінка зображується простим прямокутником. Зауважимо, що сторінка на діаграмі - це одиниця уявлення, а не реалізації. Наприклад, одна сторінка на діаграмі може представляти в дійсності кілька HTML файлів (наприклад, сторінка містить набір фреймів) або кілька розрізнених фрагментів коду (коли використовуються включення на стороні сервера (SSI) або бази даних).

Крім сторінок, існують файли (files) - Одиниці організаційної структури сайту, що не мають навігаційних властивостей. Користувач працює з файлами поза браузера (аудіо та відео файли, окремі документи, такі, як PDF, або виконувані файли (програми)). Файли зображаються на діаграмі добре відомим позначкою - прямокутник з загнутим всередину верхнім правим куточком.

Рис. 1а (ліво): сторінка та файл

Рис. 1б (право): набір сторінок і файлів

Набір сторінок (pagestack) представляє на діаграмі групу функціонально ідентичних сторінок, навігаційні властивості яких несуттєві по відношенню до макроструктуру сайту. Аналогічно, набір фалів (filestack) представляє на діаграмі групу файлів, доступ до якої здійснюється за загальною для всіх системі навігації і яка може бути класифікована як одне безліч (наприклад, колекція ігор або бібліотека PDF документів).

Використовуйте ярлики (labels) щоб ідентифікувати сторінки та файли. Ярлики мають бути унікальними для кожної сторінки або файлу на діаграмі і не повинні представляти реальні імена файлів або значення тегів, наприклад. Унікальні числові ідентифікатори і префікси типу файлу можуть бути успішно використані в якості ярликів на діаграмі.

Стосунки: зв'язку та стрілки

Відносини між елементами на діаграмі зображуються у вигляді простої лінії, або зв'язку (connector). Зв'язки обов'язково будуть трансформовані в навігаційні відносини, але не всі навігаційні відносини можуть бути відображені на діаграмі.

В випадку моделювання інформаційної архітектури, стосунки найчастіше відображаються через ієрархічну організацію сторінок (у вигляді дерев). Однак це не завжди потрібно і в деяких випадках взагалі не рекомендується.

На діаграмі взаємодій зв'язку повинні бути спрямованими, щоб представляти шляху покрокового виконання користувачем того чи іншого завдання. Для цього використовуються стрілки (arrows). Далі терміни вище (висхідний, upstream) і нижче (спадний, downstream) в потоці (шляхи) визначають розташування елемента на діаграмі.

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

Рис. 2а (верхня діаграма): проста деревоподібна структура

Рис. 2б (нижня діаграма): та ж структура, що й на діаграмі 2а, але представлена інакше

Якщо з яких-небудь причин необхідно заборонити рух у зворотному напрямку (якщо мало місце необоротне дію, наприклад, видалення запису з бази даних), використовується перекреслюються лінія (просто вертикальний штрих на протилежному кінці стрілки). У разі комплексної архітектури іноді може з'явитися необхідність в тому, щоб додати додатковий покажчик напрямки (головку стрілки, arrowhead) близько елемента, розташованого на діаграмі у висхідному потоці (вище), щоб ясніше уявити напрямок руху.

Рис. 3а (ліво верх): Стрілка показує напрямок вниз по потоку, у напрямку до виконання завдання

Рис. 3б (ліво низ): Вертикальний штрих символізує заборону на рух назад по шляху

Рис. 3в (право): Безліч покажчиків полегшують розуміння діаграми.

Зв'язкам і стрілок можуть бути присвоєні ярлики, але краще обмежити використання ярликів для цих елементів тими випадками, коли необхідно позначити яке-небудь конкретну дію користувача, не більше. Якщо ярлики стають занадто довгими і заважають іншим елементам на діаграмі, краще винести їх в легенду або програми.

Рис. 4а (ліво): Приклад неправильного ярлика

Рис. 4б (центр): Приклад правильного ярлика

Рис. 4в (право): Посилання на ярлик

Паралельний набір

Символ паралельного набору (concurrent set) на діаграмі зображується півколом, використовується в тих випадках, коли дія користувача генерує кілька одночасних подій (наприклад, запуск нового вікна одночасно із завантаженням документа в основне вікно, або відображення сторінки одночасно з діалогом завантаження файлу). Як і стрілки, символ паралельного набору має напрямок. Елементи діаграми, розташовані вище по дорозі з'єднуються з іншого символу, нижче - з плоскою частиною (підставою) символу.

Рис. 5: Паралельний набір

Точки входу і виходу

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

Для того, щоб можна було розбити діаграму на кілька аркушів, використовують точки входу і виходу (continuation points), які зображуються за допомогою квадратних дужок і є «мостами» між листами діаграм.

Рис. 6а (ліво): Продовження діаграми від елемента «D» на іншому аркуші (на рис. 6б)

Рис. 6б (право): Початок діаграми на іншому аркуші (на рис. 6а)

За міру необхідності, одна точка виходу може вести до декількох точок входу. Орієнтація дужок (горизонтальна або вертикальна) принципового значення не має і залежить від естетичних уподобань архітектора [1] .

спільності: області і повторювані (ітеративні) області

Елемент область (area) зображується на діаграмі як прямокутник із закругленими кутами, використовується для позначення групи сторінок, що мають загальний атрибут (наприклад, сторінки з'являються в випадаючому вікні або мають загальний елемент дизайну). Використовуйте ярлики, щоб позначити цей спільний атрибут (або, як у випадку зі зв'язками, зробіть виноски в програму або легенду діаграми).

Рис. 7: Регіон, що об'єднує сторінки за ознакою "показуються в випадаючому вікні»

Часто архітектура припускає повторення основної структури елемента стосовно деякій кількості функціонально тотожних елементів. Наприклад, архітектура сайту може моделювати каталог продукції, де кожен елемент каталозі має асоційований набір сторінок. Щоб уявити цей момент на діаграмі, використовується повторювана область (iterative area) (набір прямокутників з закругленими кутами).

Рис. 8: повторюється область, представляє безліч продуктів в каталозі

Зауважимо, що зв'язки і стрілки не можуть вказувати просто на область. Область служить тільки для того, щоб представити на діаграмі спільність сторінок, а не конкретний розділ, наприклад. Використовувати області на діаграмі слід акуратно, тому що дуже легко збитися на моделювання за допомогою областей таких структур, які не мають ні найменшого відношення до питання взаємодії користувача з сайтом (наприклад, які сторінки на яких сайтах повинні бути розташовані і т.п.).

Багаторазово використовувані компоненти: потокові області та посилання на потокові області

Іноді (особливо часто при проектуванні взаємодій) може знадобитися представити певну процедуру як послідовність кроків (процедура входу в закриту облась сайту, наприклад). Передбачається, що ця процедура багаторазово використовується на сайті в різних контекстах. Часто такі последовательності є структурними компонентами завдань, які користувач виконує на сайті (аналогом може служити процедура в мові програмування (Subroutine )).

Подібна послідовність кроків називається потік (flow) і зображується на діаграмі за допомогою двох символів: потокової області (flow area), яка моделює власне процедуру та посилання на потокову область (flow reference), яка представляє потік в різних контекстах на діаграмі. Обидва елементи мають однакову основну форму - прямокутник з обрізаними кутами (або, якщо хочете, витягнутий восьмикутник).

Рис. 9а (ліво): Посилання на потокову область «Процедура»

Рис. 9б (право): Потокове область «Процедура»

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

Посилання на потокові області функціонують схожим чином з точками входу і виходу. Призначення цих елементів одне - дозволити архітектору розбити діаграму на кілька сторінок.

Моделювання динамічної інформаційної системи

Дуже часто інформаційна архітектура і структура взаємодій повинні мінятися залежно від різних умов. Ці зміни описуються в термінах умовної логіки і інші елементи нотації є специфічними для динамічних систем. Ось основна концептуальна модель динамічної системи:

Система стежить за станом своїх атрибутів (attribute). Ці атрибути можуть мати відношення до:

Користувачеві (наприклад, тип користувача)

Сесії (наприклад, статус користувача в системі)

Типу змісту, до якого отриманий доступ

Реальному світу (наприклад, час і дата)

Атрибути мають значення (values) ( «3 Р.М. »одне з можливих значень атрибуту« дата і час »)

Асоціація атрибута з певним значенням називається умовою (condition)

Система відстежує (evaluates) зміни умов

В випадку статичної архітектури кожен шлях видається кожному користувачеві в будь-якому випадку (в будь-яких умовах), і кожен шлях завжди веде до одного і того ж результату. У динамічній системі система сама вирішує, які шляхи пропонувати користувачеві і які результати представляти в залежності від тих чи інших умов.

Щоб діаграма залишалася «чистої» умови, як правило, описуються або в додатку, або в легенді.

Точки прийняття рішень

Коли дія користувача може згенерувати кілька результатів, система повинна вирішити, який результат представити у відповідь на дію (самий звичайний приклад такої логіки - процедура обробки помилок при роботі користувача з формою). На діаграмі такий момент зображується точкою прийняття рішення (decision point) у формі ромба. Зауважимо, що стрілки повинні використовуватися разом з точками прийняття рішень, інакше буде незрозуміло, чи розташовані такі елементи діаграми вище або нижче точки.

Рис. 10: Точка прийняття рішення (10а) в потоці «вхід користувача в систему»

Умовні зв'язку та стрілки

Умовна зв'язок (conditional connector) зображується пунктирною лінією, використовується у випадку, коли шлях може бути або представлений користувачеві, або ні, залежно від певних умов.

Рис. 11а (ліво): Умовна зв'язок

Рис. 11б (право): Умовна стрілка

Наприклад, сторінка може містити інформацію, доступ до якої дозволений тільки співробітникам фірми. Умовою в такому випадку буде тип користувача (співробітник), якщо умова задовольняє цій вимозі, шлях відкритий. Якщо ні, шлях просто не існує.

Вибір «одна з багатьох»: умовні гілки

Коли система повинна вибрати один шлях з декількох взаємно виключають, використовується символ умовної галузі (conditional branch), на діаграмі зображується трикутником. Елементи діаграми вище гілки з'єднуються з вершиною трикутника, елементи нижче - з основою.

Рис. 12: Умовна гілку

Приклад на малюнку 12 на перший погляд схожий на приклад, який ви бачите на малюнку 10, але поведінку системи, що моделюється на малюнку 12, сильно відрізняється від поведінки на малюнку 10. У точці прийняття рішення тільки один шлях (або навігаційний елемент) буде представлений користувачеві, і місце, в яке користувач буде переміщений в цьому випадку, визначається конкретним умовою. На малюнку 12 система приймає подібне рішення, але відбувається це до того, як користувач зробив будь-які дії. Умовна гілку показує, що система приймає рішення про те, який шлях представляти користувачеві. Шляхи зі сторінки А на сторінки B, C і D взаємно виключають одне одного, тобто якщо існує шлях B, то шляхи C і D немає.

Як і у випадку з умовними зв'язками і стрілками, умовні гілки можуть взагалі не представляти користувачеві ніякого шляху. Різниця в тому, що негативний результат ( «порожньою» шлях) може бути дозволено, тобто атрибут системи може приймати трьох можливих логічних значення (істина, брехня, ніщо (null)), а не дві (правда, неправда). Здатність системи представляти порожні шляху обов'язково потрібно вказати в додатку до діаграми.

Вибір «один або багато»: умовні селектори

Опції умовного селектора (conditional selector) (на діаграмі зображується трапецією) подібні до функцій умовної гілки, за одним важливим винятком: у випадку з селектором, хто сходить шляху не виключають одне одного, тобто користувач бачить будь-яку кількість шляхів, що відповідають тим чи іншим умовам.

Рис. 13: Умовний селектор

Наприклад, символом умовного селектора можна представити на діаграмі список сторінок з результатом пошуку в пошуковій машині. У цьому випадку сторінки з результатом будуть розташовуватися вгору від селектора, умовою буде служити критерій пошуку спадний шлях від селектора буде вести на проіндексовані машиною сторінки. Як і умовна гілку, умовний селектор може згенерувати порожній шлях і цей момент необхідно відобразити в додатку до діаграми.

Одне рішення, багато шляхів: кластери

Деякі умовні структури вимагають, щоб система представляла користувачеві більше одного шляху в залежності від умови. Ці шляхи асоціюється у кластери (clasters) (зображується колом). Кластер зображується на спадному шляху від умовної гілки або умовного селектора.

Рис. 14: Кластер

Структура, зображена на малюнку 14 функціонує як звичайна умовна гілку, але для однієї з умов ми представляємо більше одного шляху. Тобто якщо значенням атрибута стане «X» користувач побачить шлях на сторінку B, а якщо значенням буде "Y", то користувач побачить шляху на сторінку C і D.

Обмеження: умовні області

Коли одну або декілька умов застосовується до групи сторінок, ця група зображується на діаграмі як умовна область (conditional area) (прямокутник із закругленими кутами пунктирною лінією).

Рис. 15: Приклад умовної області, де потрібне безпечне з'єднання

Умовні області застосовуються, як правило, в ситуаціях, що передбачають обмеження доступу. На відміну від інших типів областей, умовні області асоціюються з результатом, який генерується системою у випадку, коли умова не виконано.

Завантажувані бібліотеки символів

Stencil file для Visio 2000

Stencil file для Visio 5

Stencil file для Visio 4

PowerPoint file

Library file для Adobe InDesign

Illustrator EPS file

набір EPS файлів, містить один елемент на файл, для імпорту в інші програми (1.1 MB)

Висновок

Діаграма для сайту «MetaFilter» (http://www.metafilter.com) є конкретним прикладом діаграми інформаційної архітектури та способів взаємодії користувача з веб-сайтом (автор не був залучений у розробку цього сайту). Ця нотація - це тільки перший крок у розробці уніфікованого візуальної мови моделювання інформаційної архітектури та способів взаємодії користувача з веб-сайтом. Будь-які зауваження і доповнення розглядаються за адресою [email protected].

Список літератури

Для підготовки даної роботи були використані матеріали з сайту http://www.webmascon.com/