Тем не менее предлагаемые рынком решения для сам-себе-инфоарха практически без остатка можно свести к двум базовым концепциям: принцип иерархической системы файлов-и-папок (где "файлом" может быть письмо, запись в ежедневнике и т. п.) либо "принцип гуглопочты" - поиск плюс "плоский" список меток-тегов. Все, что сверх того, - та или иная разновидность "записных книжек" (будь то хоть "системы сбора информации", хоть 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, и там же - критика этого подхода Д. Завалишиным с позиций реакционной метафоры "строительства"). Однако и эта метафора почти столь же дырява, как и предыдущая: она игнорирует тот факт, что почти любой минимально законченный кусочек работы программиста может быть запущен, отлажен, переписан; а логический скачок, называющий компиляцию "стадией производства", заставляет странно выглядеть переработку-рефакторинг (оставаясь в рамках метафоры, получается нечто вроде "спроектировали машину абы как, произвели, запустили, не едет, чуть подправили проект - произвели, запустили, едет, но не туда..." - очевидно, что метафора не очень-то хороша).