Помоги проекту - поделись книгой:
Обычно он предпочитает быть независимым консультантом - и вынужден быть готовым, что заказчик нарушит две трети всех его рекомендаций, лишь только хвост щедро оплачиваемого специалиста скроется за поворотом (заказчик сделает это не из вредности - лишь из непонимания некоторых основополагающих принципов, а хуже того - из ощущения, что "все стало понятно").
Так и живет это странное существо, полезность коего до сих пор очевидна далеко не всем.
...и другие звери. Друзья, коллеги, соперники.
Информационный архитектор - метафорический родственник архитектору "настоящему"; да не любому, а тому, что проектирует пути и структуры, работает скорее на уровне района и города, чем на уровне отдельного здания. Но у "настоящего" архитектора есть, помимо типовых решений и авторитетных источников, множество ограничивающих факторов: возможности среды и материалов, особенности существующих транспортных средств, технологические нормативы застраиваемого города или местности…
У инфоарха, на первый взгляд, никаких ограничений нет: ни официальных нормативных актов, ни сопротивления среды, ни стоимости строительства. Нет ограничений - нет ориентиров? Конечно, есть! Представители смежных профессий накидают ограничений сколько угодно: программисты - ограничения на возможности "движка"; графические дизайнеры - ограничения на визуальные решения; юзабилисты - ограничения на опыт пользователей (что те поймут, а чего - нет); пиар-менеджеры - указывают, что пользователи должны увидеть в первую очередь и/или как можно чаще (с точки зрения владельца сайта, а не пользователей) и так далее. Какая часть перечисленных специалистов должна быть "внутри" информационного архитектора, а какая "снаружи" - величина переменная. Мерка здесь снова бытовая: у инфоарха должны быть "хотя бы какие-то знания" в тысяче отраслей, от графического дизайна до прикладной психологии; понятное дело, что многое зависит и от того, "приходящий" ли инфоарх, или он - часть команды (или же один из членов команды, взявший на себя еще и такие обязанности) [Заметим, что в идеале инфоарх взаимодействует с окружающими, будучи на позициях "самого главного" - вплоть до указания копирайтерам плана и стиля информационных статей. Такое положение для архитектора логично, но далеко не всегда возможно (особенно если учесть, что информационный архитектор не единственный архитектор в большинстве проектов)].
Что ставит нас перед следующим вопросом: откуда они, собственно, приходят?
…места разведения. Способы содержания. Процедура кормления. Человек из ниоткуда.
Термин "информационная архитектура", введенный архитектором и графиком Р. С. Вурманом, изначально обозначал отрасль графического дизайна, занимающуюся визуальным представлением больших массивов информации (сейчас принято называть эту деятельность "информационный дизайн"; он является не то отраслью информационной архитектуры, не то смежной дисциплиной).
Нынешнее значение термина (как процесса, искусства, науки и сообщества одновременно) скорее всего принадлежит кому-то из создателей Института информационной архитектуры (Information Architecture Institute, IAI) - Питеру Морвиллю, Луи Розенфельду, Кристине Водтке, Виктору Ломбарди. Все они известные теоретики и практики, все - авторы книг с "говорящими названиями", из коих наиболее общая - "Информационная архитектура в Интернете" - принадлежит перу Морвилля и Розенфельда, издана O’Reilly и переведена на русский язык [Для полноты картины: русскоязычные инфоархи группируются на сайтах info-arch.ru (на момент написания статьи сайт находился в переделке) и wiki.in4arch.ru, а также в ЖЖ и отдельностоящих блогах - в районе ЖЖ-юзеров urbansheep и moedusa].
У читателя может сложиться впечатление, что информационная архитектура - некая узкая (а возможно, и спекулятивная) отрасль, являющаяся прерогативой вышеозначенных заведений и лиц. Отнюдь! Как и юзабилити (и графический дизайн, и копирайтинг, и прочие смежные и несмежные), ИА - деятельность, которой занимались задолго до того, как было придумано само название. Выделение инфоархитектуры как отдельной дисциплины лишь помогает разделить ответственность между различными специалистами и сформулировать отдельные принципы и паттерны. Скажем так: тот, кто занимается созданием и поддержкой сложной информационной системы, в любом случае занимается информационной архитектурой, но лучше, если он осознает это явно.
Отсюда следует, что искать дипломированного специалиста с записью "инфоарх" в документах - бессмысленно, по крайней мере в ближайшие годы. Как и юзабилисты (и прочие наши аналогии), инфоархи - специалисты "самопровозглашенные", и зачастую единственная порука их возможностям и профессионализму - знание нужных имен и терминов, в лучшем случае - проекты, на которых успел "засветиться". Учитывая молодость дисциплины (точнее, самого слова, а не занятия), "профессиональные инфоархи" возникают как бы из ниоткуда - выходят из рядов тех же юзабилистов или дизайнеров, а равно - из рядов журналистов, психологов, библиотекарей, просто "нашедших себя в жизни". И это совершенно нормально.
Информационного архитектора мы определим так: неглупый, "адекватный" человек с некоторыми знаниями в областях, перечисленных выше, осознающий, что занимается именно информационной архитектурой.
Идеального же инфоарха мы определим так: человек, который ко всему миру подходит исключительно с позиций организации информации и которому это успешно удается.
Как он делает это?
…ингредиенты. Питательные вещества. Энергетическая ценность.
ОБЩИЕ ПРИНЦИПЫ
1. Информация, которая у вас есть, не та, которую вам хотелось бы иметь.
2. Информация, которую вам хотелось бы иметь, не та, которая вам на самом деле нужна.
3. Информация, которая вам на самом деле нужна, вам недоступна.
С портретом инфоарха мы вроде как разобрались. Осталось всего-то понять принципы его деятельности - и дело в шляпе.
Что такое, в сущности, информационная архитектура? "В сущности" - всего лишь ответ на вопрос "как сделать так, чтобы посетитель нашего сайта на нем не потерялся?" [С учетом оговоренной ранее относительности понятий "сайт" и "посетитель"] Для этого достаточно соблюсти обычные условия для любых навигационных систем: наш гипотетический посетитель, он же инфопутешественник, всегда должен понимать, где он находится, где находится другое, интересующее его, место и как туда попасть. А чтобы обеспечить это, необходимо:
• логически сгруппировать единицы контента (organizing, "организация");
• установить структурные отношения между единицами и группами (structuring, "структуризация");
• дать "правильные", понятные инфопутешественнику, имена всем этим сущностям (labeling, "предметизация" [Устоявшийся, бессмысленно-наукообразный перевод; надо бы просто - "называние"]);
• найти способ объяснить эти имена, структуры и связи путешественнику-пользователю-посетителю (навигация, поиск и многие другие "детали").
Вот эти-то задачи и решает специалист, занимающийся информационной архитектурой (при сотрудничестве либо противодействии специалистов из смежных областей).
…засучить рукава. Думать. Изучать. Балансировать.
Как уже было неоднократно сказано, разработка информационной архитектуры - это набор действий, которые легко назвать, нетрудно описать и крайне сложно выполнять. Разработка инфоархитектуры - это изучение (предметной области, участников информационного обмена). Разработка инфоархитектуры - это размышления, анализ и множество попыток. В конце концов, разработка архитектуры - это баланс.
Инфоархитектура - баланс между иерархичностью и доступностью. Иерархии, логическое разделение на категории, красивые ветвистые деревья выбора - все это помогает свести сотни и тысячи разнородных элементов в общую структуру; иерархии - самая понятная человеку модель описания мира; иерархический взгляд на все понятия предметной области порождает красивую "ментальную модель" - и у инфоарха, и у инфопутешественника. Но схема организации информации, учитывающая только иерархию и жестко следующая ей, лишена человечности; "см. также", "близкие понятия", "вам может быть также интересно" - друзья человечности. Но перегружая информацию необязательными связями, мы рискуем под их грудой потерять иерархию.
Приходится держать баланс.
Инфоархитектура - это баланс между "шириной" и "глубиной". Слишком много уровней иерархии-вложенности - плохо, далеко идти. Но и слишком мало уровней порождает меню-развилки на сотню элементов - тоже плохо. Необходимо соблюдать равновесие.
Инфоархитектура - это баланс между людьми. Это поиск слов, понятных целевой аудитории; это поиск путей логичных и "интуитивно понятных"; это учет интересов одновременно инфопутешественника и владельца сайта. Жизненно важно слушать людей.
В конце концов, инфоархитектура - это баланс между общей картиной и деталями.
…дьявол и его детали. мелочи, от которых седеют. "не моя ответственность".
Даже самая распрекрасная структура информации не стоит и копейки, если не сделать ее очевидной пользователю. И вот здесь начинаются пограничные области - взаимодействие специалистов, временами переходящее в вооруженные столкновения.
Это вопросы навигации и поиска.
Разрабатывая карту-схему всей предметной области разом, инфоарх чувствует себя в безопасности, - заинтересованные лица, как правило, соглашаются, что это его область компетентности. Но вот вопрос, где поставить навигационные ссылки на странице, какие, и как они должны выглядеть, - это вопрос, процесс решения которого столкнет лбами юзабилистов и графических дизайнеров, менеджеров и программистов; вопрос с переменным числом противоположных мнений. А самое страшное - некоторые из них могут оказаться верны. (В частности, юзабилист, работающий непосредственно с пользователями и собирающий их отзывы, может оказаться более прав, чем инфоарх, ограничивший себя "чистой логикой".) Построение навигационных меню и ссылок - процесс, требующий от всех участников интуиции и дипломатизма, сочетания уступчивости и настойчивости в принципиальных позициях.
Второй "фронт конкретных действий" - обустройство поиска; здесь инфоарху противостоят технические специалисты. Дело в том, что "правильный" поиск в сложном инфоокружении - это не просто "подключить поисковый движок" (или кнопку "искать Гуглом по этому сайту"); обустройство поиска задает вопросы "в какой части информации искать" (например, по тексту статей - да, а по служебным заголовкам и меню - нет; по предметным статьям - да, а по спискам статей и категорий - нет), как представлять результаты поиска, какие уточнения допускать в поисковых запросах - каждая из этих особенностей требует отражения и в технической, и в логической частях сайта. Каждая из этих особенностей требует взаимопонимания - понимания инфоархом технических особенностей, а программистом - логических необходимостей.
Инфоарха, способного - нет, не настоять на своем, а найти наилучший компромисс - мы станем носить на руках и давать молоко за вредность.
Задачу-минимум - рассказ о том, что же такое загадочная "информационная архитектура", кто этим занимается и зачем - будем считать выполненной. И все же эти скупые наброски осиротеют без привязки ко времени - взгляда в настоящее и будущее молодой дисциплины.
…раз веб, два веб.
Группа явлений, известных под условным названием "Web 2.0", не могла не задеть информационных архитекторов. Строение сайтов меняется; само понятие "сайта" меняется; отношение к инфопутешественнику-пользователю меняется - что же остается инфоарху? Только радоваться.
Не парадоксально ли? Ведь одна из основных сентенций Веба-Два - вся власть "умной толпе". Нет больше "сайта и его посетителей", есть пустая оболочка, которую сами же "посетители" и обустраивают (можно ли их при этом продолжать считать инфопутешественниками? скорее уж инфожителями). Нет больше разработанных экспертами сложных ветвистых структур-таксономий, есть фолксономии - теги-"ассоциации", приписанные пользователями информационным сущностям... Инфоархитектура умерла (или умерла профессия - став прерогативой пользователей)?
Как бы не так.
Те же "теги", если использовать их как единственный способ организации информации на крупном сайте, вскоре потребуют разумного управителя - иначе сам список тегов превращается в тот самый "крупный массив информации, в котором без пол-литра не разберешься". Инфоарх может использовать заданные пользователями теги как сырье для своей работы, "начальный словарь" - и сделать своей задачей организацию этого словаря: разобраться с синонимами и омонимами, ввести дополнительные структурные отношения, разделить слабосвязанные области на явные кластеры... По сути, изменения, несомые Вебом-Два, лишь облегчают жизнь инфоарху: взгляды пользователя на предметную область, о которых раньше необходимо было догадываться либо извлекать из "подопытных кроликов" на стадии проектирования, теперь эти взгляды излагаются пользователями явно, влияя на архитектуру системы во время ее жизни. Не зря ведь именно с "новым вебом" ассоциируются рекомендательные системы ("пользователи, которые купили этот товар, также интересовались...") - что это, как не еще один способ "прокладки удобных дорог", то есть инфоархитектура и только.
Короче говоря, Веб-Два делает более явными функции инфоарха именно как специалиста, проектирующего пути (тогда как своими инфо-жилищами занимаются сами инфо-жители).
Информационную архитектуру принято рассматривать как дисциплину организации веб-сайтов в частности и многопользовательских систем вообще.
В то же время если признаком необходимости инфоархитектуры считать лишь объем обрабатываемой информации, то можно прийти к парадоксальному выводу: имеется насущная потребность в персональной, "десктопной" инфоархитектуре уже на десктопах "информационных работников" - от редакторов и журналистов и до "простых людей", стремящихся держаться на гребне волны в своей области интересов (профессиональных или любительских). Сотня RSS-потоков, десяток почтовых рассылок и пара десятков параллельно ведущихся "почтовых диалогов", три дюжины одновременно открытых страничек в браузере (по прочтении каждой из них по ссылкам открывается еще штуки три) - это реалистическое описание "информационного положения", в котором находился и автор этой статьи на момент ее написания.
Тем не менее предлагаемые рынком решения для сам-себе-инфоарха практически без остатка можно свести к двум базовым концепциям: принцип иерархической системы файлов-и-папок (где "файлом" может быть письмо, запись в ежедневнике и т. п.) либо "принцип гуглопочты" - поиск плюс "плоский" список меток-тегов. Все, что сверх того, - та или иная разновидность "записных книжек" (будь то хоть "системы сбора информации", хоть mindmap’ы, хоть персональные вики-системы).
А задачка, меж тем, нетривиальная до интересного: предельная разнородность информационных сущностей, отделение существенного от служебного, анализ и запоминание инфопутей (был ли я "здесь"? а откуда я сюда попадал?). Не знаю, сулит ли рынок "инфоархитектуры для одиночек" миллиардные прибыли удачным решениям, однако неожиданные находки и немеркнущую славу (в случае удачной находки) сулит определенно.
Множество дисциплин, идей и возможностей современных технологий до сих пор не заняли четкого места в арсенале информационной архитектуры.
Например, современные методы визуализации (тот самый "информационный дизайн", изначально и называвшийся "информационной архитектурой"), полноценно использующие цвет, объем, форму для эффективного представления информации, а не для красоты. Отдельные "креативные решения" встречаются [Ознакомиться с целыми залежами оных можно на сайтах вроде infosthetics.com или visualthesaurus.com], но использование богатых визуальных средств в мейнстримном инфоархе ограничивается "псевдо-визуальными" облаками тегов, которые проблем порождают больше, чем решают.
Или технологии искусственного интеллекта - у редкого сайтостроителя хватит смелости добавить в ядро, в движок информационной среды алгоритмы нечеткой логики, нейронную сеть или другую разновидность самообучающейся системы - тем более, что у тех существуют давно доказанные ограничения (но равно - и давно доказанные преимущества). В конце концов, продолжая "дорожную" метафору, до полноценной "системы управления движением" мы доживем еще не скоро.
Наконец, социальный компьютинг, использование ресурсов и мощностей, возникающих от самого факта взаимодействия инфопутешественников. Несмотря на все громкие слова и массивные капиталовложения, сегодняшний "социальный компьютинг" находится на уровне "собрали огромную махину и радуемся, когда она считает 2х2 с погрешностью ±1". А ведь, как говорилось выше, "инфопутешественник созидающий" - идеальное сырье для инфоархитектора, возможность получения неимоверных "синергетических" эффектов.
"Необработанные" области, конечно же, не ограничиваются перечисленным. Но есть и повод для оптимизма: кто, как не информационный архитектор с его умением и страстью к организации информации, способен принять и эффективно использовать новейшие идеи?
Следите за рекламой: будет круто.
Органичное строительство
С тех самых пор, как программирование оформилось в отдельную деятельность и профессию, представители этой профессии и просто посторонние философы все стремятся рассудить, какова ее природа. Они стремятся найти одну, понятную и всеобъемлющую метафору, из которой бы естественным образом проистекал и процесс организации, и необходимые инструменты, и способ подготовки профессионалов.
Об отсутствии ответа на вопрос "что есть программирование" свидетельствует хотя бы и количество статей с заголовками вроде "Programming is like A", "Programming isn’t like A, programming is B", "Software developer is C", чуть не ежедневно вызывающих горячие дискуссии в техно-блогах.
Самая старая, очевидная и по сию пору соблазнительная метафора - программирование как аналог любой другой инженерной деятельности, строительства дорог, домов и мостов. "Дырки" в этой метафоре слишком давно известны, чтобы на них подробно останавливаться: все компоненты "моста"-программы суть плод интеллектуальной деятельности, а не объекты физического мира, что подразумевает возможность пере- и доделки виртуального "моста" в любой момент его жизни; сочленение его с другими, существенно разнородными сущностями; повторное использование компонентов - в общем, такие способы действия, которые "настоящего" инженера привели бы к быстрому и надежному помешательству. Тем не менее, эта рабочая модель, мало общего имеющая с действительным положением вещей, и по сию пору привлекается в дискуссиях достаточно часто.
Как только стало очевидным несовершенство "строительной" метафоры, стали появляться ее замены-развития, суть которых, в основном, сводится к аналогиям между деятельностью разработчика и инженера-проектировщика: как бы весь цикл написания программы есть проектирование, а процесс "производства" сведен лишь к фазе компиляции (наиболее полно этот подход отражен в статье Дж. Ривза "Как проектировать ПО?", ее можно найти в "КТ"#589, и там же - критика этого подхода Д. Завалишиным с позиций реакционной метафоры "строительства"). Однако и эта метафора почти столь же дырява, как и предыдущая: она игнорирует тот факт, что почти любой минимально законченный кусочек работы программиста может быть запущен, отлажен, переписан; а логический скачок, называющий компиляцию "стадией производства", заставляет странно выглядеть переработку-рефакторинг (оставаясь в рамках метафоры, получается нечто вроде "спроектировали машину абы как, произвели, запустили, не едет, чуть подправили проект - произвели, запустили, едет, но не туда..." - очевидно, что метафора не очень-то хороша).
Как бы то ни было, почти любая попытка определить деятельность разработчиков ПО приводит к тому или иному компромиссу между производством (production) и творчеством (creation) [На научные же методы, как основу процесса разработки, мало надежды осталось со времен краха автоматизированных средств написания и верификации программ]. Соответственным образом выглядит и большинство современных средств разработки: как среда для созидания с множеством возможностей анализа структуры и процесса, а также использования "типовых решений".
Но попробуем взглянуть пристальнее на процесс и его результат - на то, что происходит в реальности, а не должно бы происходить в некоем "идеальном процессе разработки". Разработчики (один, десяток или тысяча) могут действовать в соответствии с простой метафорой или 1000-страничным "описанием архитектуры", но в любом случае проект движется от небольших "атомов" (или "клеток"), от отдельных строк кода, к модулям, подсистемам и целому. В процессе этого движения атомы-клетки многократно изменяются под влиянием тестирования, изменений в требованиях к проекту и в команде разработчиков, эффектов, возникающих от сочетания с другими частями. Изменения этих (и множества других условий) приводят к образованию и изменению сложных структур, модулей и подсистем: структуры эти обладают своей логикой и стройностью, но эта логика практически не может быть в точности спланирована заранее. На уровне отдельных функций и объектов программист - царь и бог; на уровне общей цели проекта царь и бог - системный архитектор; но вот сочетание отдельных мельчайших частей в более крупные сущности, направление и скорость роста этих сущностей - все это происходит как бы "само по себе".
Не вызывает ли такое описание аналогий с органической системой, ее моделью жизни и развития? Возможно, это и есть такая метафора, сполна описывающая процесс разработки нетривиальных программных систем; она представляется вполне полезной "ментальной моделью".
Следует заметить, что взгляд на программный проект как на форму органической жизни, конечно же, не нов (хотя и не слишком распространен). Другое дело, что большинство апологетов "органической метафоры" смотрят на нее, как на нечто, требующее создания новых, особенных языков, технических средств или методологий (например, см. [1], [2], [3]). В явном виде мысль "мы все работаем именно так, достаточно просто это осознать сполна" выражена, пожалуй, только в работе [4]; а ведь ценность объемлющей метафоры - именно в "сдвиге точки зрения", а не в разработке новых инструментов и средств (по крайней мере - не в первую очередь).
Впрочем, чтобы нетривиальный подход к известной проблеме стал общим местом, апологетам этого подхода нужно "очень громко кричать": поддержка авторитетов, книги в уважаемых издательствах - вот что выводит идею в мейнстрим, вовсе не сам факт высказывания идеи. А пока - "мейнстримный" спор о метафоре болтается между "строительством домов" и "проектированием домов" (с редкими уклонами в "написание стихов").
1. Исключение - это правило.
2. Наш мир богат и сложен, а не стуктурирован и прост.
3. Программы должны соответствовать нестандартным, меняющимся проблемам, а не стандартным, статичным паттернам.
4. Программная система - органическое создание, а не набор математических алгоритмов.
5. Программные компоненты - составная часть нашего сложного мира, а не описательные мета-сущности.
6. Разработка программ эволюционирует от малого к большому, а не от конкретного к абстрактному.
Автор считает пункты 1-3 общим местом, а пункты 4-6 - своим нововведением.
O. Imbusch, F. Lanhammer, G. von Walter, "Ercatons and Organic Programming"
O. Imbusch, F. Lanhammer, G. von Walter, "Ercatons and Organic Programming" (
Поделиться книгой: