Немного истории: десятичная классификация Дьюи
Система классификации книг, разработанная в XIX веке американским библиотекарем Мелвилом Дьюи.
Классификация предназначалась для систематизации расстановки книг в общедоступных американских библиотеках, где до того какие-либо общие принципы расстановки книг отсутствовали. Каждая библиотека использовала свои классификационные системы.
В 1873 году Дьюи применил эту схему в библиотеке колледжа, а спустя 3 года анонимно опубликовал под названием «Классификация и предметный указатель для каталогизации и расположения книг и брошюр библиотеки».
«Установление главных классов, не превышающих по числу десять, и обозначение каждого класса одной из десяти значимых цифр. Последующее деление каждого из этих классов осуществляется не более чем на десять подклассов с обозначением присоединяемой справа новой цифры, как в десятичной дроби. Дальнейшее деление каждого из этих 81 подкласса производится не более чем на девять подотделов. Таким образом все подотделы одного класса образуют часть библиотеки с возможностью неограниченного дальнейшего деления».
Индексация осуществлялась только с помощью цифр. Впоследствии стало основой для машиночитаемости индексов.
ИА — это не внешний вид библиотеки и не то, как и где расположены полки и из чего они сделаны. ИА — это то, как рассортированы книги.
А карточки картотеки — это инструмент навигации, который помогает пользователям найти то, что они ищут.
Об этапах разработки цифрового продукта
Когда на различных уровнях проекта принимаются решения, которые не соответствуют общей стратегии и иерархии, это приводит к серьезным проблемам. Проект может сбиться с намеченного курса, сроки проекта могут быть нарушены, стоимость разработки увеличивается, а команда сталкивается с трудностями при попытке согласовать различные компоненты. В конечном счёте, когда сайт будет запущен, он может оказаться неудобным и неэффективным. Например, это означает, что решения, принятые на концептуальном уровне, имеют значительное влияние на все последующие уровни проекта. В то же время, выбор решений, доступных на каждом этапе, ограничен теми решениями, которые были приняты на предшествующем этапе.
Такой «волновой эффект» подразумевает, что выбор определенного решения на одном уровне требует пересмотра уже принятых решений на других уровнях.
Однако, принимая решения на высоком уровне только после завершения работы на нижнем уровне, вы рискуете не только сроками реализации проекта, но и его успехом вообще.
Вместо этого целесообразнее организовать проект таким образом, чтобы работа на текущем этапе не завершалась до того, как будет завершена работа на предыдущем этапе. Главное, чтобы строительство крыши дома не предшествовало закладке его фундамента.
Пример значительно более подробного таймлайна разработки сайта:
Определение Алексея Бородкина, основателя Гильдии Вольных Проектировщиков
Информационная архитектура — это описание связи всего со всем!
Более строгое определение
Информационная архитектура — это совокупность данных об информационной структуре цифрового продукта, способствующая его правильной работе, выполнению задач и интуитивному доступу к содержимому.
Почему это важно
Сокращение времени разработки
Выделив заранее время на разработку продуманной ИА сайта, общее время разработки сайта можно сократить на 10–25%.
Масштабируемость без редизайна
Уделив должное внимание ИА, мы с лёгкостью сможем добавлять любые новые материалы, и при этом нам не придётся полностью переделывать сайт.
Упрощение обслуживания и контент-менеджмента
Те, кому приходилось обслуживать большой веб-сайт, знают, как много времени уходит на поиск файла, который надо обновить. Чем лучше ИА, тем быстрее мы отыщем этот файл.
Улучшение юзабилити
Если сайт имеет правильную ИА, с сайтом станет легче работать. Благодаря ИА будут чётко определены ключевые элементы навигации и их расположение, что облегчит работу графическому дизайнеру.
Положение в рейтинге поисковиков
Разбивая сайт на правильные разделы (с логически обоснованными заголовками), ИА помогает вывести на первый план те ключевые элементы, которые используются поисковыми серверами при вычислении релевантности страниц, в результате чего сайт оказывается выше в поисковой выдаче.
Этапы создания ИА
1. Подготовка (целеполагание, концепция)
Работа над информационной архитектурой начинается сильно позже старта проектирования. Сперва определяется концепция, суть продукта. Нам нужен базис, от которого мы уже начнём выстраивать IA.
Мы должны как минимум очертить высокоуровневые границы проекта, сформировать базовое понимание его функциональности. И только на этом этапе приступать к информационному проектированию.
2. Декомпозиция
Разбираем проект на отдельные информационные сущности. Каждая такая сущность обладает определёнными свойствами. Некоторые сущности могут быть вложенными (каталог и товар, например), некоторые — независимыми.
Например, для интернет-магазина
5 сущностей (в реальности их бывает больше)
Страница (статические страницы, содержащие какую-то информацию; например, страницы «О компании», «Доставка и оплата»).
Товар (обычный товар с описанием, фоточками, ценой и т. п.).
Каталог (каталог — это тоже сущность; у него есть свои свойства, вроде параметров поиска или уровня вложенности).
Корзина (которая обладает динамическими свойствами: вложенные товары и их количество, скидки, даже связь с конкретным пользователем).
Пользователь (тут всё понятно: как минимум, у пользователя есть регистрационные данные, адрес доставки и платёжные реквизиты).
3. Классификация
Теперь надо классифицировать получившиеся сущности, но не только их. Для грамотного составления архитектуры нам потребуется классифицировать ещё и возможные операции с этими сущностями.
3а. Классификация пользовательских потребностей
опирается на результаты пользовательских исследований. Мы должны понимать, что действительно нужно нашим потенциальным покупателям. Исходя из этого, мы выясним, как именно следует связать наши сущности, а также определяем все возможные способы манипуляции с нашими сущностями: как будет осуществляться поиск, по каким параметрам будем сортировать товары и так далее.
Все действия напрямую связаны с товарами, и опосредованно — с остальными сущностями (например, поиск товара осуществляется в каталоге, а покупка — в корзине).
Найти товары (с помощью поиска, фильтрации и сортировки).
Сравнить товары (выбрать наиболее подходящий вариант).
Почитать про товары (ознакомиться с характеристиками).
Купить товары (положить в корзину, оплатить и ждать доставку).
3б. Классификация информационных сущностей
По какому принципу они будут объединяться, и как пользователю будет удобнее с ними обращаться.
Вся информация, которую видит пользователь, должна быть структурирована. Страницы должны объединяться в разделы, товары — в категории. И те, и другие должны быть доступны для поиска, а последние — ещё и для сортировки. У товаров могут быть общие свойства, вроде скрытых от глаз пользователя «тегов/меток» или доступных для просмотра «размеров».
Добавляем три таксономии и одно общее свойство:
Категория (иерархическая таксономия сущности «товар»).
Метка (не-иерархическая таксономия сущности «товар»).
Размер (не-иерархическая таксономия сущности «товар»).
Цвет (общее свойство для всех экземпляров сущности «товар»).
Таксономии состоят из терминов. Например, таксономия «Размер» содержит несколько терминов: «XXL», «XL», «L», «M», «S», «XS».
Иерархические таксономии могут быть вложенными: например, категория может иметь подкатегорию (зимняя одежда ⟶ пуховики). А вот у метки, например, родительского термина быть не может.
4. Выявление связей
Мы разобрались, что у нас за сущности и таксоны. Теперь нужно понять, как они будут между собой связаны. Связи сущностей могут быть совершенно разными. Рассмотрим только простые варианты, когда связи являются либо «плоскими», либо «иерархическими».
Плоские связи — это связь терминов таксона «метки» между собой. У них нет родителей, они «равны». Или связь товаров с одинаковыми «метками» — она тоже плоская.
Иерархическая связь, например, у терминов таксона «категории» — они почти всегда вложенные. Также иерархическая связь будет между сущностями «каталог» и «товар», так как первый всегда включает в себя несколько товаров. Если пойти дальше, то в игру вступают термины таксона и у нас получается целая цепочка связей: каталог ⟶ категория ⟶ … ⟶ товар.
5. Фиксация свойств
Во время всей работы над информационной архитектурой мы всё время попутно выясняли, какие именно свойства будут у наших сущностей. Пришло время их зафиксировать.
У товара — 10 свойств:
Идентификатор (внутренний, в базе данных, он есть у каждой сущности и термина таксономии).
Артикул (внешний, для обмена данными, например, с системой складского учёта).
Название.
Описание.
Основное изображение (используется в карточке товара в каталоге).
Дополнительные изображения (используются в галерее изображений на странице товара).
Цвет (общее свойство для всех товаров; оно не «сквозное», как метки и категории, а может быть уникальным для каждого товара — например, цвет «синий с белым узором»).
Размер (прикреплённый термин таксономии).
Категория (прикреплённый термин таксономии).
Метки (несколько терминов таксономии, на основе которых будут показываться «похожие» товары).
6. Схематизация
Составление предметных и навигационных схем продукта. Самый последний и самый сложный этап. Главная сложность — в психологическом факторе: в голове у архитектора картинка уже сложилась. Переносить её на бумагу (пусть и цифровую) кажется второстепенной задачей. Гештальт закрыт, мозг получил свою дозу дофамина.
Из чего состоит информационная архитектура сайта?
Из электронных документов, таблиц, диаграмм, а не из макетов или прототипов веб-страниц.
Пример информационной модели
Инфоблок (альбом: Soulside Journey, A Blaze in the Northern Sky, Under a Funeral Moon и т. д.) — самая низкоуровневая сущность, «молекула» информационной архитектуры, содержащая произвольную информацию (например, текст, цитату, изображение и тп). Из инфоблоков, собственно, и строится почти вся контентная часть продукта.
Год — статическая среднеуровневая сущность, которая объединяет инфоблоки в разрезе определённых лет. Они единые для всех исполнителей, но конкретные годы у конкретных исполнителей могут не совпадать.
Период (Death Metal, Black Metal и т. д.) — уникальная для каждого композитора среднеуровневая сущность, проходящая через все слои и объединяющая годы в определённый этап в творческой биографии исполнителя.
Слой — статическая информационная сущность, объединяющая разные периоды в некий тематический срез творчества исполнителя. Слоёв ограниченное количество.
Исполнитель (Darkthrone) — высокоуровневая, главная сущность проекта.
Навигационная модель
Есть главная страница, на ней перечислены исполнители.
Для всех исполнителей есть общий список слоёв.
Каждый слой представлен отдельной страницей.
Внутри каждого года может находится произвольное количество инфоблоков.
Связи сущностей
Исполнитель — главная и независимая сущность.
Слои едины для всех исполнителей и вообще — для всего проекта, они ни от чего не зависят.
Период уникален для каждого исполнителя, а значит, ссылается на него (имеет в своих свойствах идентификатор того исполнителя, которому принадлежит).
Годы тоже едины для всего проекта, независимы от остальных сущностей.
И только инфоблоки (альбомы), как низшая сущность, зависят от всх остальных сущностей.
Навигация сайта и ИА
Навигация сайта — набор компонентов пользовательского интерфейса. Основная цель навигации — помочь пользователям найти контент и функциональные элементы ресурса (другими словами, «органы управления» UI), чтобы затем мотивировать к совершению запланированного маркетологом действия.
«Толстые футеры»
Что могут содержать «толстые футеры»
- Копирайт.
- Карта сайта.
- Навигация.
- Политика приватности.
- Terms of Use.
- Форма обратной связи.
- Адрес или карта.
- Телефон.
- Социальные иконки.
- Соцмедиа-виджеты.
- Подписка на рассылку.
- Логин.
- Пресс-кит.
- Поиск по сайту.
- Картинки.
- Мини-галерея.
- Айдентика.
- Миссия и ценности.
- Ключевые слова и SEO-блок.
- Награды и сертификаты.
- Членство в ассоциациях.
- Цитаты.
- Последние материалы.
- Предстоящие события.
- Видео.
- Аудио.
- Призыв к действию.
Взаимосвязь между ИА и навигацией
Игнорирование ИА может привести к издержкам и потерям.
Например, непродуманная навигация, не охватывающая весь контент сайта полностью и не раскрывающая весь функционал веб-ресурса, рано или поздно потребует тотального редизайна, а это дорого.
L-образная навигация
Верхний навигационный бар и левый сайдбар.
Проблема: можно разместить ссылки на контент, логическая иерархия которого не превышает 4 уровня в глубину.
Если контент раздела будет превышать этот запас — 5 и больше уровней (а это вполне обычная глубина информационной архитектуры для современных ресурсов типа интернет-магазинов), — что выяснится уже в ходе эксплуатации, — то останется два выхода: либо с нуля создавать новую навигационную структуру, либо пытаться втиснуть все содержимое в 4 иерархических уровня.
Типы информационной архитектуры
- Категории
- Задачи
- Поиск
- Время
- Люди
Категории
Представьте себе розничный книжный магазин. Перед глазами сразу возникает меню с категориями: Новинки, Популярное, Аудиокниги, Что почитать и так далее.
Задачи
Еще один способ структурировать ваш сайт или приложение — это положить в основу задачи, которые пользователю нужно решить. Если вы банк, то задачи могут быть примерно такие: Вклады, Займы, Инвестиции, Помощь, Открытие счета.
Поиск
Если ваш сайт достаточно сложен или практически полностью состоит из контента, создаваемого самими пользователями, то, вероятно, вам стоит построить вашу архитектуру на поиске, как у YouTube. Если бы у YouTube были только категории (Музыка, Видеоигры, Скетч-шоу, Сейчас в эфире и т. д.), пользоваться сайтом было бы сложно.
Время
В случае с веб-сайтом это бы выглядело как страницы типа: Актуально прямо сейчас, В архиве, Почитать позже, Новинки и т. п. Примеры такого дизайна — новостная лента или френдлента.
Люди
Любая социальная сеть имеет информационную архитектуру, построенную на людях. Дизайн вращается вокруг конкретного человека и его отношений с другими людьми.
А вот внутри каждого профиля соцсеть использует для организации информации систему категорий (Фотографии, Друзья, Места и т. д.).
Тенденция
Категории ⟶ Задачи Библиотека ⟶ Приложение
Глубокое и широкое
Сайтам, на которых много продуктов и категорий, чаще всего подходит «глубокая» архитектура, иначе размеры меню будут выходить за все рамки. Сайты вроде YouTube, где все строится вокруг пользователей и видео-роликов, обычно «плоские».
Если ваш сайт — и глубокий, и плоский одновременно, это плохо.
Миф о трёх кликах
Якобы до любого интересующего объекта «всегда должно быть три клика».
Но главное, чтобы люди всегда понимали, где они находятся и что могут сделать. Если ваша навигация — простая и четкая, то количество кликов значения не имеет. Но если
Подробнее об этом — в статье Пейджа Лаубхаймера.
«Не все клики одинаковы».
«Чтобы найти, куда сообщить о сломанном счетчике воды, требуется всего 3 щелчка мыши, но по пути к нему пользователь все равно сталкивается с трудоемким процессом сканирования и прокрутки. На главной странице пользователи должны нажать кнопку NYC Resources (1), а затем просмотреть длинную страницу ссылок. На полпути вниз по странице (под сгибом на большинстве ноутбуков) находится раздел Housing & Building со ссылкой Tenants (2), которая приводит пользователя к очень длинному списку ссылок, в котором Water Meter Complaint (3) находится в самом низу, 133-я ссылка в списке».
