{"id":408193,"date":"2010-03-09T10:24:00","date_gmt":"2010-03-09T14:24:00","guid":{"rendered":"tag:blogger.com,1999:blog-5587346.post-1682063285184576255"},"modified":"2010-03-09T10:25:31","modified_gmt":"2010-03-09T14:25:31","slug":"reimagining-realtime-focalcast-communication-%e2%80%93-buzz-and-twitter-2-0","status":"publish","type":"post","link":"https:\/\/mereja.media\/index\/408193","title":{"rendered":"Reimagining realtime focalcast communication \u2013 Buzz and Twitter 2.0"},"content":{"rendered":"

Google<\/a>, and Buzz<\/a>, are flailing<\/a>. Facebook is evil<\/a>. Twitter is annoyingly limited [1].<\/p>\n

We need to reimagine focalcast realtime communication [1].<\/p>\n

As a first pass we can think of a realtime communication message channel as having two key properties: Audience and (primary) Purpose.<\/p>\n

Audience is the set of permitted subscribers. Example: \u201cFamily\u201d or \u201cPublic\u201d.<\/p>\n

Purpose is a single sentence definition of what the the channel is used for. Example: \u201cLocation sharing\u201d or \u201cPolitical opinions\u201d or \u201cMate attraction<\/a>\u201d.<\/p>\n

The resemblance of Audience and Purpose to century old definitions of printed media marketing is not accidental.<\/p>\n

To be truly useful Buzz or Twitter 2.0 need to allow any message (not<\/em> length limited) to be characterized by Audience and Purpose [2]. We can imagine these as two metadata elements [3] represented in a user interface as \u201cdrop down\u201d or select boxes.<\/p>\n

On the client side users subscribe to a channel defined by Author and Purpose for which they have access rights (Audience).<\/p>\n

Since some Audience-Purpose pairs are far more common than others (\u201cLocation sharing\u201d+\u201dFamily\u201d or \u201cLocation sharing\u201d+\u201dMate attraction\u201d) combining these in a user interface would increase usability.<\/p>\n

A single \u201cidentity\u201d or \u201caccount\u201d should own the definitions of Audience and Purpose, though it may be useful to associate Audience-Purpose pairs with a \u201cpersona\u201d [4]<\/p>\n

When I see a solution emerging that uses open data standards without data lock (Buzz API?) and that supports Audience and Purpose in a useable way, I\u2019ll know it\u2019s time for me to fully engage. Until then, I\u2019m just playing.<\/p>\n

[1] Geezers will remember email lists as the original focalcast medium. Since list communication was not realtime messages resembled postal letters; they often resembled exchanged essays. Twitter\u2019s accidental length limit<\/a> (determined by the quirks of the text (SMS) message hack) makes Twitter exchanges either staccato status updates or metadata pointing to discussions held elsewhere. Neither realtime length limited Twitter nor slowtime unlimited length email are adequate focalcast communication technologies.<\/p>\n

[2] A third attribute of \u201carchive\u201d would cause the communication to become the equivalent of a blog post, but that\u2019s a nice-to-have. Author is an implied attribute; it\u2019s used by subscribers.<\/p>\n

[3] Ontology strictly optional, though many will emerge.<\/p>\n

[4] As of a few weeks ago I thought that persona management was a key component of Buzz<\/a>\/Twitter 2.0, but now I think the combination of Audience\/Purpose pairs makes persona management less critical. One could handle other persona issues through separate accounts (identities).<\/p>\n

See also <\/p>\n