Wieviele aktive Benutzer braucht eine Community?

Inspiriert durch Many-to-Many: Lots on lurking

Oder anders gefragt: wie hoch muss die Konversionsrate registrierte Benutzer -> aktive Benutzer sein?

Vor einiger Zeit war ich einen halben Nachmittag mit Taschenrechner im Netz unterwegs, um das an existierenden Beispielen zu messen. Die genauen Zahlen sind leider einem Festplattencrash zum Opfer gefallen, aber Phi mal Daumen sah das Ergebnis so aus: Wenn 66%, also zwei Drittel aller Benutzer einer Communities wenigstens hin und wieder etwas beitragen, scheint die kritische Masse erreicht und die Community lebt. Sind es weniger, sagen wir 50%, sieht das schon anders aus: die Community versandet oder wird zur Spielwiese der wenigen aktiven. Sind es noch weniger, so geschieht rein gar nichts.

Wohlgemerkt ist die hier angenommene Basis die Anzahl der registrieten Benutzer, nicht die der Besucher. Wollte man dies zur Basis machen, müsste man einen nicht unerheblichen Aufwand betreiben, um einzelne Sessions zu verfolgen. Da HTTP ein zustandloses Protokoll ist, stößt man hierbei auf einige Probleme, zum Beispiel die Frage, anhand welchen Kriteriums man entscheidet, ob/wann ein Besuch von einer bereits erfassten IP-Adresse ein neuer Besucher ist oder nur der schon bekannte, der wiederkommt? Bäh, grunt work ;)

Siehe auch: Meatball: TheAudience

Dipsie, ein Bot fürs Deep Web?

Gary führt ein Interview mit Dipsies CEO Jason Weiner: ResourceShelf

Q. How will Dipsie be different than what web search companies are making available
today? Database size? Search functionality? Clustering? What makes you
confident that you can play with the current industry giants?

A. Dipsie is different in several important ways. First, we search the 99%
of the web that other engines cannot reach (as well as the 1% they can.) It’s
the difference between “static” content and “dynamic” content, which is
increasingly prevalent across the Web. We can index pages that utilize cookies,
database back-ends, forms and client-side scripting, among others. Our scalable
technology will allow us to have over 10 billion pages within our first year
alone. […] The dipsie.bot was created to leverage integrated machine learning
with on-board heuristics to crawl sites from a stereotypical user’s experience.
It’s able to get past traditional technology barriers such as cookies, complex
querystrings, forms and client-side scripting that drive modern user
experiences.
[ResourceShelf]

Das erklärte Ziel ist also das Deep Web, wie man auch am Firmennamen erkennen kann.

2004 verspricht ein spannendes Jahr zu werden :-)

The Difference Between Communities and Networks

Many-to-Many: The Difference Between Communities and Networks

Ross kann Gedanken lesen: genau mit diesem Thema war ich heute auch zeitweise beschäftigt.

Seit den 90ern hat sich an der Technologie nichts wesentliches geändert, so das man heute Zeit hat sie zu vervollkommnen und leichter nutzbar zu machen - nicht für den Anwender, sondern vor allem für den Entwickler.

Mittlerweile ist diese Evolution an einem Punkt angelangt, an dem man, ohne die grundlegende Technologie zu verändern, keine bahnbrechenden Techniken mehr entwickeln kann: der Prozess verlangsamt, Resourcen werden frei, neue Ideen werden geboren.

Der Blickwinkel verschiebt sich hin zu den Inhalten und zur Nutzung: im Gegensatz zu früheren Zeiten fragt man nun in erster Linie ‘Was wollen wir erreichen?’ und nicht mehr ‘Wie soll das funktionieren?’.

Ausdruck dieser Veränderung ist die Social Software, Software, die Menschen in ihrer Sozialisierung unterstützt. Nur damit keine Mißverständnisse aufkommen: diese Software gab es schon immer, allerdings wurde sie unter einem technischen Gesichtspunkt betrachtet und nicht nach ihrem Wert für eine/die Gemeinschaft.

An dieser Stelle kommen wir zu Ross’ Gegenüberstellung:

Communities

  • Top-down
  • Place-centric
  • Moderator controlled
  • Topic driven
  • Centralized
  • Architected

Networks

  • Bottom-up
  • People-centric
  • User controlled
  • Decentralized
  • Context driven
  • Self-
    organizing

[Many-to-Many: The Difference Between Communities and Networks]

Basieren die meisten Gemeinschaften auf klassischen Formaten wie Foren/Boards, Mailinglisten oder dem Usenet, und sind damit vor allem anderen an eine bestimmte Technik gebunden, sind Netzwerke wesentlich liberaler in der Wahl der Medien und Technologien, auch wenn den Aspekt der Technik immer geben wird (und für den Anwender immer unwichtiger und unsichtbarer wird).

Diese Betrachtung ist natürlich nur technischer Natur ;-) Inhaltlich sind Gemeinschaften und Netzwerke kaum unterscheidbar.

  • Beiden haben ein Thema, auf dem sie basieren.
  • Die Kommunikation mit Gleichgesinnten steht im Vordergrund.
  • Die möglichen Motivationen zur Teilnahme sind ähnlich: Altruismus, Egoismus, Profilerung, …

Winer getting angry - RSS vs. Atom Part $put_large_number_here

Nach diesem Kommentar fühle ich mich fast verpflichtet, meine RSS-Feeds auszuschalten. Sind wir denn im Kindergarten, das wir persönlich werden müssen?

Gegen sachlich vorgetragene Argumente hat niemand was, aber diese persönliche Attacke hätte Herr Winer sich sparen können.

Dieser Zug von Google macht natürlich mißtrauisch bzw. regt die Phantasie an, um das mal wertungsfrei zu formulieren.

Anyway, wie Mark Piligrim andeutet/hofft, wird Atom im Sommer durch die IETF zu einem RFC gemacht und damit tatsächlich zu einem offenen Standard, im Gegensatz zu RSS:

In the past, Winer has answered charges that he exerted undue control over RSS by pointing to its transfer from UserLand, a blog software company he founded, to the Berkman Center for Internet & Society at Harvard Law School, where he is a fellow. RSS is also now available for use under a “creative commons” license, which frees it from commercial copyright claims. [Google spurns RSS for rising blog format - News - ZDNet]

[…] Pilgrim estimated that Atom, which dates back only to June of last year, would work its way through the IETF and be ratified as a “request for comment” draft no later than August. [Google spurns RSS for rising blog format - News - ZDNet]

XML-Parsing in PHP

PHP Everywhere: High Speed XML Parsing is Not Intuitive

John benchmarkt RegEx gegen explode(!) DOM, SAX und XPath.

Results

Here are the timings for processing the RSS file 1000 times. Faster is better.

        seconds     Relative to REGEX
REGEX   0.1080      1.00
EXPLODE 0.1696      1.57
DOM     6.3212     58.53
XPATH   8.3417     77.24
SAX     10.0851    93.38

[PHP Everywhere: High Speed XML Parsing is Not Intuitive]

Wie aus den Kommentaren ersichtlich ist, ist das zwar ein an sich beachtenswertes Resultat, allerdings fehlt der Bezug zur realen Welt. XML mit Regulären Audrücken zu Parsen funktioniert nur dann, wenn über die Form des XML absolute Gewissheit besteht.

Auf meinen akuten Fall, nämlich eRONA, bezogen: da es fast 10 Versionen von RSS gibt (inkl. Atom 0.3 sind es 10) kann ich hier nicht mit RegEx arbeiten, da ich garnicht weiß, wie die Daten aussehen, die ich bekomme. Also bleibt nur der Weg über einen Parser wie SAX oder expat, der aus dem XML einen Baum zaubert, in dem man sich bewegen kann und auf gut Glück versucht, Daten zu extrahieren.

Der Feed Parser [dive into mark] aka Ultra Liberal RSS Parser (basierend auf SAX) geht einen Schritt weiter und ‘normalisiert’ eingegebene Daten in dem Versuch, ein möglichst sinnvolles Resultat sogar für eigentlich unbrauchbare Feeds zu liefern.

Note to self: Wie kann ich den ULFP (sind Abk. nicht was dolles ;)) in eRONA (noch eine! Juhu!) einbauen?

Update: John’s PHP Benchmarking Suite (ZIP)