В номинации «неологизмы» по итогам прошедших трех месяцев у нас побеждают слова «инфосфера» и «социальный грид». Только не просите объяснить значение этих неологизмов — я в них сам плохо разбираюсь.
Но, по тому, как их употребляют, вырисовывается вот какая картина:
Инфосфера — пространство, где информация валяется там-сям. Аналогично слову «блогосфера» ближе к сферическому коню в вакууме (в контексте w2z многое сводится к этому коню), чем к чему-то осязаемому. Почему-то ассоциируется с помойкой.
Социальный грид — это когда человек имеет N аккаунтов на разных сервисах, чтобы обсуждать одну и ту же новость на этих N сервисах. Поэтому у такого пользователя и появляется «постоянное недержание внимания». Инструмент для расширения инфосферы.

Лирическое отступление (вообще то лирическое отступление втыкают куда-то в середину текста, но сегодня мы немного нарушим эту традицию).
socal GRID (англ «Grid computing» — распределенные вычисления) в моем понимании:
- распределение собственных мощностей на нескольких сервисах с возможностью консолидации (поскольку один сервис не может дать необходимый и достаточный feature list). Грамотного распределения и балансировки у среднего лемминга не получится.
- мощная распределенная коллаборационная система с социальными связями. Средний лемминг к коллаборационной работе как-то не расположен, и с большим удовольствием генерирует мусор, чем что-то полезное

Когда мы вводим логин-пароль, то пароль хорошо бы сделать нетривиальным, хорошо бы — нечитаемым, а еще лучше — незапоминаемым. Я тут вот чего подумал… почему бы вместо пароля «sobaka» не вносить md5(«sobaka»)? Если не принимать во внимание, что некоторые системы такую длину пароля не осилят — насколько проще подбор md5-хеша vs «девятисимвольный набор букво-цифр»? На первый взгляд, md5 подбирать сложнее, но уверенности в этом что-то нет.

Но вот идея использовать message digest для генерации пароля мне нравится. Т.е. вместо зазубривания ненормальной последовательности букв можно взять обычное слово или фразу, прогнать его через алгоритм «ужимания» (не md5; и желательно, чтобы он охватывал весь надор букв и цифр) — и получить пароль. Т.е. технология получается такой: на своем сайте (или прямо у себя на компе) в формочку вносим «обычное» слово, а в ответ получаем «шифрованное», которое и используем в качестве пароля. Который запоминать собершенно необязательно.

ps. Кстати, а почему не один из публичных сервисов не поддерживает регламент одноразовых паролей? Иногда приходится пользоваться интернет-кафе или не своим компом. А кто может поручиться, что там нет кейлоггера или записи трафика?

 — А почему футболка не мокрая?
 — Так я же без нее бегал

Пока urbansheep тоскует в поисках б-клиента, я хочу немного пофилософствовать на тему клиентов.

Я достаточно давно отказался от использования клиентов (LJ не в счет — там без Семаджика что-то написать чертовски трудно). Да, клиент удобнее и позволяет сделать некоторые вещи, реализовать которые в web-интерфейсе затруднительно, но в большинстве случаев каких-то сильных преимуществ у клиента нет (пользуясь случаем, передаю привет Диме Смирнову за удобный регистровский интерфейс). Ситуация несколько меняется, если клиент может использовать все функциональные особенности движка (не интерфейса, а движка!), но, как говорится, «сейчас такое уже не делают» (да и движок на 50% будет состоять из api).
Если же клиент «универсальный» (т.е. не специально написан под этот движок), то начинают сказываться различные нюансы, когда клиент что-то понимает так, а движок (и его разные модификации) — эдак; а в результате — «щастья нет» и «дельфин и русалка — не пара».

Вот чего мне не хватает — так это удобной системы подготовки записей (типа редактора?) с последующей выдачей написанного в формате html. А если такую штуку можно настроить на сборку всех полей в miniXML согласно заданному шаблону — это было бы совсем замечательно: написал запись, сформировал miniXML и скопировал его как plain text прямо в админку блога, в формочку для новых записей.

Кстати, есть один интересный момент, когда клиент начинает проигрывать — при модернизации движка и внедрении новых технологий.

…представляет собой графическую демонстрацию перемещений пользователей по всему сайту. С помощью него можно отобразить движение потоков пользователей по всем страницам сайта, проанализировать влияние каждой страницы на совершение различных действий и выявить проблемные места на страницах.

Метод предполагает, что пользователь должен двигаться по сайту заранее заданным маршрутом, например, от главной страницы к оформлению заказа через страницы с описанием продуктов и прайс-листы. При этом, все остальные страницы играют второстепенную роль, они должны возвращать пользователя в так называемый «коридор», по которому он должен пройти, чтобы принять решение о покупке. Те же страницы, которые теряют трафик или позволяют пользователям разбредаться по сайту, признаются проблемными. [ >>> ]

update. Воообще-то я представлял себе это не в виде примитивных глистограмм, а наглядную graph-based схему. Типа схемы метро.

Если я хочу поработать с почтой, то буду использовать почтовый клиент, а не универсальный комбайн (который к том уже умеет и на машинке с ЧПУ вышивать). Если я хочу поработать с текстовым документом, то буду использовать текстовый редактор, а не универсальный комбайн. Если я хочу початиться в IM, то …
Логично?
А если я хочу поработать одновременно с текстовым документом и с почтой, это стройная система (несколько) нарушается, хотя это вполне обыденная ситуация. Поработать в едином информационном поле, как того требует задача, не получится и придется скакать туда-сюда. Но универсального комбайна я все равно не хочу.
Хочу интегрирующую рабочую среду. Т.е. операционную среду, которая позволяет соединить на одном рабочем поле несколько приложений без необходимости как-то переключаться. Приложение при этом остается вполне самостоятельной кошкой Мебиуса.
Через какое место это будет достигаться (через api или через задницу) мне не столь важно.

Ситуация в Я.ру напоминает ситуацию «Суслика за занавеской видишь? А он там есть!». Т.е. сервис есть, но «извне» его не видно.
Поэтому Яндекс рискует достичь эффекта противоположного запланированному: первопроходцы наиграются и уйдут (за железным занавесом игры становятся скучны и неинтересны), а у новых не будет мотивации.
Но, раз Яндекс таким образом препятствует service bootstraping — им зачем-то это нужно.

 — А чего меня френдят? Я ничего такого не пишу
 — Издеваются, наверное…

(inspired)

Если раньше сайты/сервисы составлялись из нескольких стандартных кубиков (нередко без какой-либо интеграции между), то сегодня основное внимание уделяется гибридизации технологий и гибридизации использования технологий (дурацкие термины, но какие есть).

[формально объяснять лень; в данном случае речь идет о технологиях работы с информацией. Скрещивание двух разных технологий так, что со стороны трудно отличить, где заканчивается одна и начинается другая — это и есть гибридизация. Например, если раньше система публикации была сама по себе, а обсуждения статей (в виде форума) — сами по себе, в виде двух несвязанных (самостоятельных) подсистем, то «скрещивание» приводит к встраиванию минифорума в систему публикации — т.е, с точки зрения пользователя, к объединенной гибридной системе]

Т.е. кубики не только измельчали (как например, плагины в WP) и склеились, но и практикуется взаимопроникновение их функций и технологий исполнения. За счет «скрещивания» разных технологий получается достаточно гибкий движок, без органичений «в пределах выбранной модели». Именно это и сыграло свою роль в популярности, развертывании и популярности w2z-сервисов. А нечеткость «скрещивания» и размытость модели допускает «гибридизацию использования» — возможность использования технологий не «традиционно» и не так, как это изначально планировалось, а так, как удобнее или в «смешанном функциональном режиме».

Вот, к примеру, Хабр начинался как бы «социальное СМИ», но за счет гибкости движка и по способу использования больше форум, чем что-то другое. Но продвинутый форум (по возможностям) — с социальной функциональностью (оценки, связи).

Так вот, такое мичуринство — штука перспективная (особенно для работы «поверх» нескольких сервисов) и удобная, но ведет к усложнению (+усиление монолитности и сильной компонентной связанности) и к избыточности/перегруженности. И вот этот побочный эффект что-то не радует.

ps. Сорри за сумбурность; надеюсь, основная идея понятна

Основной темой этого года, похоже, будет «Как нам заебать всех монетизацией UGC». Как со стороны монетизаторов, так и со стороны самих монетизируемых.
Те, кто сидят на stand-alone, уже «отмонетизировались» (кому нужно было). И заинтересовать их можно только более выгодным предложением (т.е. ощутимо подняв цены).
Поэтому для монетизации остаются пользователи сервисов, сообществ и блогохостингов. Но тут свои проблемы — у пользователей нет у этому особой тяги. Потому как текущая модель монетизации напоминает вот что:

 — Святое дело, — сказал Остап, — капитальные затраты не требуются, доходы не велики, но в нашем положении ценны.

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

 — Давай денги! Денги давай! — закричал он сердито.
(Ильф и Петров)

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

update: Это было написано пару месяцев назад, но как-то не было повода выложить
ps. Но ситуация интересная: сначала «монетизаторы» раздразнили пользователей (и «зомбировали» их идеей монетизации), а потом выяснилось, что хорошего варианта не могут предложить

Если мы условно разделим сообщества на распределенные (например, т.н. блогосфера) и централизованные (например, Хабр), то несложно догадаться, что активность в централизованных сообществах будет выше, хотя бы за счет одинаковой коммуникационной среды. Точнее, не столько активность, сколько плотность активности — потому как в распределенной среде активность тоже распределяется («размазывается»).
Да и само по себе взаимодействие (и его активность) в разных видах сообществ различается.
Правда, эту разницу не все замечают (или не хотят замечать?):

А вот ру-блоггерам следовало бы быть по активнее в комментариях любимых блогов и брать пример с хаброчеловеков, которые с удовольствием вступают в дискуссии [ >>> ]