?

Log in

No account? Create an account
Лабораторный журнал -- Day [entries|friends|calendar]
Anatoly Levenchuk

[ website | Лабораторный журнал ]
[ userinfo | livejournal userinfo ]
[ calendar | livejournal calendar ]

Что мне не нравится в викоидах [11 Aug 2003|11:11am]
Да, я понимаю, что викоиды (ибо уже сильно отличаются они от орагинальной wiki 1995г. -- это уже не wiki, хотя на wiki в чем-то похожи) прошли очень большой путь от многопользовательской "словарной" системы к полномасштабным системам управления контентом. Сейчас какой-нибудь drupal обязательно обзаводится "модулем" wiki, а какой-нибудь tikiwiki имеет не меньшее количество "модулей" и "объектов", которые можно найти в традиционных CMS-невикоидах. Wiki стремительно теряют свои особенности -- например, использование языка разметки для редактирования текста (помните nroff и troff -- ну или даже HTML? У виков ведь тоже свои заморочки с форматированием. Викоиды уже ничем не отличаются от других CMS, предлагая ныне WYSIWYG-редакторы со спецфункциями для выражения "традиционной" виковской разметки). Многопользовательское редактирование и непосредственно связанное с ним версионирование отдельных айтемов тоже можно найти сейчас где угодно. Свойство "совместной работы над чем-то" поддерживается, конечно. Как и в любой другой CMS с уже описанными свойствами версионирования и многопользовательского доступа. Форумы и комментарии в этих системах практически сравнялись по качеству. Синдикация контента (журналы, регистры) в викоидах также уже есть. Система "кармы", популярная для коллаборативной фильтрации, тоже уже есть в викоидах. Викоиды, как и традиционные CMS, стремительно осваивают все новые и новые способы по сбору и презентации самого разного контента. Поэтому и тормознутость -- чудес ведь с реализацией любых гипертекстов не бывает -- у этих систем практически одинаковая (отдельные айтемы выдаются мгновенно, запрос по сборке 100 айтемов по сложному критерию в одну страницу тормозит нещадно). Распределенность -- то же. Темы (с разной функциональностью, конечно -- ибо исполняемые шаблоны) тоже есть. Все одно и то же. Чего нельзя найти в одной CMS, всегда можно указать в другой. Чего нет в одном викоиде, всегда найдешь в другом (не сейчас, так через год). Поэтому сравнение "фича" в "фичу" традиционных сайтовых конструкторов и викоидов некорректно. Кроме одной особенности, отличающих истинные викоиды от прочих CMS -- системы адресации.

Система адресации в викоидах представляет собой ассоциативную память. Имя объекта и есть его адрес, упоминание имени -- это и есть адресация. Эта возможность дает великолепные способы построения небольших сильно провязанных одноуровневых картотек -- прежде всего словарей, глоссариев, хранилищ паттернов и прочих систем, сильно "лингвистически" провязанных между собой. Очень удобно для организации справочников, отдельные гнезда которых сильно используют имена других гнезд. Чрезвычайно удобно. Ежели я буду делать какой словарь или энциклопедию, да еще и вмногером -- то всенепременно на wiki (кстати, а есть ли еще русифицированные викоиды, кроме WackoWiki? Я бы попробовал начать делать "рабочий" глоссарий для OpenMeta).

Но это же главное достоинство быстро превращается в недостаток. Wiki поощряет и стимулирует написание настоящего гипертекста. Никакие дополнительные средства современных викоидов (типа введения иерархий-кластеров и прочих средств организации айтемного месива) его убрать не могут. Когда смотришь на странички wiki, то вспоминаешь прежде всего старинные вебсайты образца 1994-1995г.г. -- "Здравствуйте, уважаемые посетители! На нашем сайте вы найдете то-то и то-то, а еще вчера мы поместили то-то, а еще по соседству у нас делают то-то, и два файла мы не знаем, куда деть, поэтому найдете их тут и тут. До скорых встреч!". Ежели ребенку дать в руки молоток, он немедленно все предметы в доме превращает в гвозди. Ежели человеку дают в руки wiki, то все вебсайты из структурированных превращаюся в месиво однородных файлов и файликов. До оглавлений и прочей классификации дело никогда не доходит -- это же месиво еще и живое! Идеи насчет того, что за контентом нужно следить, им нужно управлять приводят нас не к wiki. Они приводят нас к средствам, имеющимся в CMS. Только в очень продвинутых викоидах вы найдете следы метаданных -- основы основ управления контентом (так, у объекта в большинстве обычных CMS есть пермалинк, заголовок, аннотация, собственно содержимое, тип, шаблон показа по умолчанию, какие-то другие связи и т.д. Минимальное использование всего этого хозяйства -- аннотированные ссылки на страницах рубрик. В викоидах все это в разы беднее -- поэтому на страницах рубрик можно ожидать увидеть только имя-заголовок и вручную прописанную к нему аннотацию, что не спасает ежели этот текст появится в десятке рубрик...).

Данные о данных -- основа управления контентом -- в викоидах представлены очень вяло. Ибо в них сознательно поддерживается не столько разнообразие, сколько однообразие. Все есть текст -- он же гипертекст. А ведь именно метаданные позволяют эффективно организовывать автоматизированное управление сборкой страниц в осмысленные структуры. Викоиды поневоле предполагают ручное, а не автоматизированное на основе метаданных управление сборкой страниц.

Викоиды подразумевают не столько коллективное написание больших связных текстов, которые придерживаются какой-то логики, сколько написание маленьких отрывков, которые отличненько "самосвязываются" через взаимоупоминания внутри себя. Ну, современные системы контент-менеджмента тоже можно в этом обвинить. Но они хотя бы пытаются специально заниматься структурой своего содержимого (метаданные), развивают именно этот инструментарий. Викоиды считают, что дело спасения утопающих -- дело рук самих утопающих, они подразумевают коллективный структурирующий разум -- но которому обычно до общей структуры дела нет, это четко прослеживается на многих вики-сайтах. Там на первой странице указана пара входных точек, а дальше вы можете пытаться разматывать клубок сами -- ибо ни у одного участника такого "коллективного проекта" в голове нет понимания его общей структуры, порядка просмотра и т.д. Гм. Вы когда-нибудь пробовали учиться, читая какую-нибудь Энциклопедию (да еще не подряд, а с любого места, запоминая непрерывно множащиеся ссылки на предмет "читал-не читал")? А пробовали сдать заказчику сделанный десятью человеками отчет, устроенный наподобие той же энциклопедии?

Главный недостаток wiki -- это то, что их стиль поощряет писательство. Но не читательство. Впрочем, справедливости ради о многих других CMS можно сказать то же самое: даже лучшие системы могут быть использованы самым непотребным образом. Да и вообще, интерфейсы к сложному гипертекстово устроенному контенту -- это терра инкогнита. Непонятно, как не заблуждаться (простите за каламбур) в сложных катакомбах гипертекстов.
.
Итак, викоиды не снимают главных вопросов, которые я ставил бы для идеальной системы работы над проектом -- с этой точки зрения они не обладают никакими особыми свойствами, отличающими их от других типов CMS -- в них нет нормальной системы аннотирования (не считать же аннотированием wiki-дискуссию?), в них нет онтологически-ориентированных средств синдикации контента, в них нет обилия (опять же онтологических) метаданных, позволяющих организовать альтернативные развертки гипертекстового клубка в нормальное чтиво и т.д. и т.п.

Где искать выход? Выход нужно искать в Semantic Web, annotation system и прочих современных университетских и промышленных наворотах для virtual community of practice. Но выхода в организации коллективной разработки нельзя искать в публичных системах "для всех" и вселенских "однородных" проектах типа everything2 или wikipaedia. Там не разработка чего-то для кого-то. Там просто разработка чего-то. И недаром критики замечают, что контент в таких проектах получается пониженного качества -- серая слабо организованная масса и дает серый слабо организованный контент. Задача в том, чтобы эту массу организовать, дать не только удобные средства фиксации наработанного -- но и взаимофокусирования работ, а также подключения новичков (не в смысле легкости редактирования! В смысле овладения предметом нового для них контента), презентации результатов для широкой публики и прочими свойствами, отличающими коллективную разработку чего-нибудь сложного типа микропроцессора от коллективной вечеринки в стрип-баре.
70 comments|post comment

Анализ контента и синтез контента [11 Aug 2003|04:30pm]
Вот еще в копилку "потребностей" при создании контента:

Все современные CMS (включая wiki ;) поддерживают "темы" -- попросту, механизм шаблонов. Все эти шаблоны на основании тех или иных метаданных способны собрать "из кусочков" большие красивые страницы. А вот "кусочки" должны заполняться контентом обычно индивидуально (в лучшем случае -- с доступом к кусочку через кнопку "редакт." рядом с отображением этого кусочка). Это страшно неудобно. Представьте себе предельный случай: ежели вы редактируете текст в Ворде, и он заставляет вас для каждого параграфа, каждой главы и т.д. заполнять мааленькую такую формочку, показывая затем только результат интеграции этой формочки в общий текст. Ну да, конечно, отделение оформление от содержания -- но почему так тогда силен переход к WYSIWYG на уровне редактирования одного текста? Что мне мешает произвольно отредактировать, перенося строчки и делая контекстные замены в общем контексте, скажем, пять айтемов, чтобы они были потом парсированы системой куда ей угодно? Вот в языках программирования трудно себе представить, чтобы каждая крошечная процедурка оформлялась заполнением отдельной формочки в отдельном окошке. Ибо неудобно. А аналогичная работа обчного-текста-писателей поддерживается только в этом "окошечном" режиме. Непорядок, однако. Всякие "разметки" тут не выход. Нужен переход к другого типа интерфейсам, WYSIWYG с поддержкой редактирования "насинтезированного" из кусочков с последующим парсингом туда, откуда эти кусочки были взяты. А то сейчас удобней совместно наредактировать нужный контент в Ворде, а затем -- быстро-быстро кат-пейст в разные окошки CMS...

Я понимаю, что это нелегко. Но когда-то и привычные редакторы текстов были "командные", а не "экранные", без поддержки шрифтов и уж тем более без undo. Ничего, справились.
6 comments|post comment

navigation
[ viewing | August 11th, 2003 ]
[ go | previous day|next day ]