Обсуждение

Технически все, что Вы рассказываете, звучит привлекательно, но само по себе это - техника поддержки контента - ничего не значит, пока не возникла система генерации этого самого контента. То есть первый вопрос при том возникает, как сделать так, чтобы туда кто-то понес свои "тезисы". Опыт показывает, что в рунете это умеют делать немногие, но абсолютным лидером даже среди них все-таки остается r_l. От многих иных тусовок народу в рунете, жеже нынче отличается не техническими своими фичами, а масштабом перекрестных связей - кругом общения.

в общем, уже понятно, что пользоваться этим будет невозможно :)

ну так речь не об идеологической альтернативе жж >>А без поиска о корпоративных системах можно забыть. похоже, этот сервис будет продвигаться не только для показа возможностей новой версии двимжка, но и как возможного прототипа корпоративного блога для крупных заказчиков. жаль, что демонстрация этого _готового_ проекта мало что скажет об удобстве использования коммунивера (ну разве что только косвенно).

Семаджик - он не из-за неудобства ЖЖ, а для дополнительного удобства. Клиенты вообще рулят, на мой непросвещенный взгляд. Что же касается скрещения ужей с ежами, то как минимум еще пара человек думает/работает над проектами скрещения мультиблога и вики. Вы, кстати, как к викам относитесь?

„Мы хотим развеять миф, что Коммунивер.* -- медленная платформа. Она не медленная. Она неподвижная.“

Да, клиент -- это именно удобство. WYSYWIG-же редактор без альтернативы, конечно, ужасен (особенно для пользователей уровнем повыше секретарш, которые хотят что-то сделать „лучше“, и знают, как это сделать, а не могут -- нету средств).

вот и вот

мне кажется, это не принципиальные отличия, а отличия по фичам. принципиально было бы - по внутренней структуре БД и по внешним интерфейсам. а так - непрозрачно и неубедительно.

1) Разработка, которую мы затеяли, предназначена не для рунета, а для корпоративных применений. Там все те же самые вопросы (почему там появится контент) плюс новые вопросы (а почему это появление контента будет полезно компании). Конечно, мы над этим работаем -- и это 80% работы. Сама система -- это 20% работы. Обычное соотношение для "систем управления знаниями" ;) 2) В своих постингах я неоднократно сравнивал ЖЖ с другими сервисами -- и в том числе приводил отличия от всяких там сплошьдотов и эвристингов2. Я считаю, что популярность ЖЖ и наличие в нем "перекрестных связей" существенно зависят от выбранной архитектуры. Поэтому просто хочу продолжить эксперименты в данном направлении.

Вот мы и поэкспериментируем ;)

Я бы сильно удивился, если бы оказался одним человеком в мире, думающим о скрещении "библиотечных" и "дневниковых" сайтов -- на мой взгляд, это одна из самых актуальных сейчас задач. Связь ленты и "базы знаний" определяет два режима деятельности людей: взаимокоординацию и рефлексию/обучение. Впрочем, я об этом уже писал. Думаю, что причины экспериментов других "думателей" немного другие. К wiki у меня отношение не самое хорошее. Я неоднократно тыкался в сам wiki и подобные проекты, они мне не нравились -- но я, пожалуй, еще не пробовал четко выразить свое отношение. Я подумаю, и напишу на днях подробнее.

Если честно, то Коммунивер.сервер в этом проекте был взят просто из-за того, что задача верстается на нем очень быстро, и возможны эксперименты (то есть цикл "что-то поменять-попробовать-опять поменять" будет быстрее, чем в большинстве изученных нами систем -- включая сам движок ЖЖ). Проект нужен нам для консалтинговых проектов TechInvestLab.com, а не с целью демонстрации возможностей Коммунивер.сервера. Для демонстрации возможностей лучше бы иметь массовые интернет-сервисы, об этом я писал ранее.

Ну, целевой платформой для этого проекта является не тот Коммунивер.сервер, который есть сейчас, а тот, который будет выпущен где-то весной (то есть реально быстрая система). Поэтому в скорости у меня есть сомнения, но эти сомнения не очень большие. Вообще, цель проекта -- не демонстрация способностей Коммунивер.сервера, а отработка "людских вопросов" (внедрения систем поддержки человеческой деятельности). Поэтому вопросы не к ядру (Коммунивер.серверу), а к сваянному на его базе приложению (у системы еще нет названия -- но назовем его пока CommuniKlog ;)

Мы внимательно глядим на развитие клиентов. Конечно, клиенты rulezzz. Пока. Задача в том, чтобы тип интерфейса (веб-интерфейс или клиентский интерфейс) мог различить только специалист. А пользователю это было все равно ;) Всякие плагины идут именно в этом направлении, в этом же направлении идут веб-сервисы (хотя они и "мы пойдем другим путем" ;)

1) Про альтернативное (плоское vs тредовое) представление комментариев -- это должно быть, это обсуждалось. 2) несколько дневников одного пользователя -- обсуждалось, пока решили не реализовывать (ввиду противоречия нашей рабочей метафоры "синдикация людей, а не синдикация контента". Можно передробить контент, это тоже плохо. Конечный вердикт был "от добра добра не ищут", оставим как в ЖЖ). Реализация этого на Коммунивер.сервере тривиальна. 3) Насчет того, насколько мемориз являются альтернативой "библиотеки", и как вообще строить "френдовые библиотеки" (интеграция мемориз) -- это отдельная дискуссия. Я уже неоднократно писал, что режим координации деятельности и рефлексивный режим -- это про разное. Напишу-ка я эту мысль в своей ленте -- уже было несколько комментов, которые требуют подобного ответа... 4) Иерархия в "библиотеке" (даже если это "мемориз") -- на раз. Даже с несколькими корнями, и вхождением одного item в несколько поддеревьев... Но про "библиотеку" пока вообще думаем. Wiki повторять не будем ;)

Требуется, однако, определить, начиная с какой фичи идут принципиальные отличия :) Для меня принципиальное отличие -- это возможность применения результата в корпоративной практике. Меня слабо волнует механизм реализации (но структура БД будет точно иной -- все-таки Коммунивер.сервер онтологический движок. Так, он может поддерживать иерархию групп людей, постингом могут выступать сложные объекты, имеющие свои связи с другими объектами и т.д. и т.п.). Больше волнует интерфейс -- он неминуемо будет отличаться от интерфейса ЖЖ (и на первых порах не обязательно в лучшую сторону. Но кто знает, какая сторона "лучшая"? ;) Насчет "прозрачности" -- наверное, мой постинг требует хоть какого-то понимания, зачем я это затеял (для меня это развитие проекта "Праксеологическая ОС" -- я писал он нем ранее, и не раз), и понимания возможностей Коммунивер.сервера, как платформы для разработки. После этих пререквизитов "прозрачности" можно обсуждать "убедительность" моего описания.

а для меня принципиальное отличие - это возможность свободного манипулирования областью применения результата - в очень широком смысле. вот именно начиная с этой фичи и идут принципиальные отличия. не буду останавливаться на том вопросе, что возможности интерфейсов находятся в прямой зависимости от структуры БД или - более широко - архитектуры и механизма реализации, так ка не хочу порождать лишний флейм. просто спрошу - что в данном случае Вы понимаете под интерфейсом? какой именно интерфейс? из вашего поста я сделала вывод, что речь идет о пользовательском интерфейсе. для меня это развитие проекта "Праксеологическая ОС" -- я писал он нем ранее, и не раз я видимо это пропустила. не дадите ссылочку?

>Задача в том, чтобы тип интерфейса (веб-интерфейс или клиентский интерфейс) мог различить только специалист До тех пор, пока браузерные страницы не научатся сворачиваться в трей, этого не произойдет :-)

Спасибо, ждём.

>Я считаю, что популярность ЖЖ и наличие в нем "перекрестных связей" существенно зависят от выбранной архитектуры. Разумеется зависят. Зависит безусловно от технических особенностей системы потолок достижимой таким образом популярности - с одной стороны, и плотности гиперлинковой оболочки расширяющейся этой самой очередной "мини-вселенной" - с другой. Однако в любом случае - в любом процессе обсуждаемого типа - сначал должен начать работать самый примитивный пусть по конструкции но "пускач". Ни Лексус, ни Ягуар, ни БМВ, .... ни, наконец, турбина Боинга не сдвинутся с места, до начала работы стартера, который их раскрутит сначала. Только об том и замечание было. Только об нем - пускаче этом самом, который должен запустить генератор контенту в в любом случае. Каким бы он ни был это генератор сам по себе - простейшей самой из возможных конструкции типа конфы политру образца 1998 года, или LJ образца 2000, - в любом случае его запускали сначала только и исключительно в ручную небольшая группа энтузиастов. А уж на какой уровень эффективности генерации контента эти системы затем выходили - это, согласен, зависило, но уже потом от конструкции технического обеспечения. После того как система раскручивалась до возможности проявить эти свои особенности - не ранее. Сколько много более совершенных систем - в том числе и тех, что сам наблюдал в процессе разработки - так и остались великолепными хайтек игрушками только потому, что не оказалось в нужный момент у CTO проекта понимания роли обсуждаемого "контент-пускача" ...