8 800 550 54 53

Прием звонков: с 09:00 до 21:00 (мск).

Без выходных.

Заказать

Прием заказов:

круглосуточно.

Четыре положения, которые следует учитывать при проектировании

Четыре положения, которые следует учитывать при проектировании
Четыре положения, которые следует учитывать при проектировании
Статья создана: , обновлена:

Аксиомы

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

Идентификаторы

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

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

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

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

Пользователь должен иметь возможность идентифицировать себя, и смена идентификаторов должна сопровождаться каким-то штрафом. Наказание за смену идентификатора не обязано быть тотальным. Но пользователь, меняющий свой идентификатор в системе, должен потерять часть репутации или контекста. Тем самым обеспечивается функционирование системы.

Конечно, такой подход противоречит настроениям ранних работ по психологии в Интернет. «О, в Интернете все смогут менять личности и пол, как мы меняем носки». Однако ощущение полной свободы в выборе личности разрушается такими историями, как история Кейси Николь.

История довольно долгая, но суть ее проста: одна женщина из Канзаса существовала в сети под видом альтернативной персоны, студентки по имени Кейси Николь. Поскольку друзья выдуманной студентки начали проявлять уж слишком живое участие, женщина решила убить свою сетевую персону и сообщила от имени Кейси Николь, что у нее обнаружено смертельное заболевание.

Привлекательная молодая женщина, с которой все подружились, умирает; что происходит? Все хотят встретиться с ней, пока она еще жива. Женщина запаниковала, и Кейси Николь пропала. В нескольких сообществах Интернета, особенно в сообществе MetaFilter, заподозрили неладное. И десятки людей потратили сотни часов, пытаясь разобраться в происходящем, - своего рода распределенное расследование. В конечном счете, сложив фрагменты из разных посланий Николь, они обнаружили обман.

Теперь многие люди ссылаются на эту историю и говорят: «Вот видите, я же говорил, насколько свободен выбор личности в Интернет!» Но не этот урок следует вынести из истории Кейси Николь; важно другое: смена личности - неординарный шаг. И если сообщество понимает, что вы сделали, это воспринимается как огромный и непростительный проступок. Люди готовы потратить невероятное количество энергии, чтобы найти и наказать вас. Таким образом, личность в Интернете не столь гибка, как нас убеждает ранняя литература; хотя технология упрощает смену личности, социальная жизнь требует определенной степени устойчивости. Все, что вам потребуется, - это система с некой разновидностью постоянных идентификаторов, а уже пользователи наделят их виртуальными личностями и даже эффектами более высокого уровня вроде репутации.

Хорошие дела

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

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

Интересная схема встречается в одной группе обмена музыкой, связывающей Токио и Гонконг. Они работают через список рассылки и пересылают друг другу курьерской почтой FedEx 180-гигабайтные жесткие диски. Пересылаются файлы в формате WAV, а не МРЗ, притом пересылаются в больших количествах.

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

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

Ограничение влияния в группе

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

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

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

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

Масштабирование

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

Это одно из проявлений проблемы обратной пропорциональности ценности и масштаба. Представьте свой список контактов: тысяча имен, около 150 людей, которых вы считаете друзьями, около 30 близких друзей и 2-3 человека, которым вы готовы пожертвовать почку. Ценность обратно пропорциональна размеру группы. И вы должны придумать механизм защиты группы в контексте этих эффектов.

Иногда проблема решается «мягким ветвлением». Из всех виденных мной сред этот механизм лучше всего реализован в Livejournal, где концепции «вы» и «ваша группа» тесно переплетены. Средний размер группы Livejournal составляет около 12 участников, а значение медианы где-то около 5.

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

Некоторые социальные среды (такие, как каналы IRC и списки рассылки) самомодерируются с увеличением масштаба, потому что с ухудшением отношения «сигнал-шум» люди начинают покидать группу, ситуация улучшается, приходят новые люди и так далее. В системе возникают колебания, но в целом производится автокорректировка.

В этой области моим любимым образцом является MetaFilter: при проявлении эффектов масштабирования страница нового пользователя отключается. «Кто-то упоминает нас в прессе и говорит, какие мы замечательные? Пока!» Это способ поднять планку; это создание порога для участия. И каждый, кто ставит закладку на эту страницу и говорит: «Знаете, я действительно хочу здесь быть; возможно, я вернусь позже» - и принадлежит к числу пользователей, желательных для MetaFilter.

Итак, нужно найти механизм защиты пользователей от масштабирования. Впрочем, это не означает, что масштаб системы не должен расти. Но нельзя пытаться увеличивать систему, надувая отдельные разговоры, как воздушный шарик; человеческое общение, построенное по схеме «многие ко многим», надуваться не может. Оно либо рассеивается, либо превращается в широковещательную трансляцию, либо умирает. Так что продумайте заранее, что вы будете делать с масштабированием, потому что это все равно неизбежно произойдет.

Заключение

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

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

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

Разработка социального программного обеспечения - дело сложное. И как я уже говорил, эта работа больше напоминает работу экономиста или политика, нежели программиста. А акт размещения социального программного обеспечения и предоставления доступа к нему ближе к отношениям владельца дома с жильцами, нежели к отношениям владельца склада с хранящимися на нем коробками.

Люди, пользующиеся вашими программами, обладают правами и ведут себя так, как обладатели этих прав - даже если это программное обеспечение принадлежит вам, а они платят за его использование. И если вы начнете игнорировать эти права, то узнаете об этом очень быстро. Это лишь часть той проблемы, из-за которой теория сообщества Джона Хейг-ла - «сообщество порождает содержание, а это ведет к коммерции» - никогда не работала. Посмотрите: кто бы ни приходил на форумы Clairol, люди иногда желают поговорить о вещах, не имеющих отношения к продукции Clairol.

«Но мы заплатили за это! Здесь сайт Clairol!» - говорят спонсоры. Неважно. Пользователи приходят сюда друг ради друга. Возможно, они работают на оплаченном вами оборудовании и программах, но пользователи приходят сюда друг ради друга.

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

Спасибо за внимание.

Дополнительная информация по теме

Предложение JOIN советы и хитрости программирования

Некоторые советы по использованию предложения JOIN в базах данных на различных платформах

Предложение ORDER BY cоветы и хитрости программирования

Некоторые советы использования предложения ORDER BY в базах данных на различных платформах

Какие данные не следует располагать на домашних страницах

Статья приводит список данных, которые не следует давать на всеобщее обозрение на своей домашней странице

Предложение ORDER BY cоветы и хитрости MySQL (продолжение)

Дополнительные секреты использования предложения ORDER BY в базах данных на платформе MySQL

Ссылка для обмена:

Ссылка для форума:

Ссылка для сайта:

Есть вопросы, замечания, дополнения? Пишите в комментариях.
Заказать тексты для сайта (онлайн форма) - цена от 60 рублей, срок 24 часа
проектирование, рекомендации

Страница: Четыре положения, которые следует учитывать при проектировании

Дата публикации: 2012-12-12 11:32. Последние изменения: 2015-07-29 11:58

наверх