Friday 7 August 2009

The Flow Past Web: even better than the RealTime thing

The 'RealTime Web' may be a name we are stuck with, but it is still a misleading one. Real-time software is a well-defined field where computing has to complete or fail cleanly by a deadline, because latency is paramount. A two-way phone conversation is an example - if the delay between parties exceeds a few hundred milliseconds, normal conversation becomes impossible, and people have to formally take turns. This is because a true verbal conversation is a flow state, where you are both engaged and responding.

With text, the latency requirement can be relaxed - historically conversations have been conducted by exchanges of letters with latencies in weeks. What's happening is that all kinds of media are having their latency domains expanded.

Technological constraints used to make buffering audio or video prohibitively expensive, so they only domain they could work in was real time, hence Telephony's interruptive call model, and Radio and Television's 'one way to many people at once' model. As storage has got cheap and ubiquitous, these give way to answerphones, TiVo's, iPods and YouTube.

At the same time, the latency of text has been moving the other way, from newspapers' and mail's daily cycles, to hours for webpages, minutes for blogs down to seconds for SMS, Twitter, Facebook and other activity streams. However, as audio and video have added persistence, text hasn't lost it - we do have the ability to review and catch up with the past of our flows, or to re-point people to older points in time, as well as marking out times in the future.

Text's natural parallelism means we are seeing new kinds of public flow states that we have become used to as private ones - hence the "Twitter is public IM" explanation; but the other addition needed to make this stable and not a cacophony is the semi-overlapping publics that mean we don't all see the same flow, but that it is mediated by the people we choose to pay attention to.

Much of the supposed 'Real-Time' web is enabled by the relaxation of realtime constraints in favour of the 'eventually consistent' model of data propagation. Google Wave, for example, enables simultaneous editing by relaxing the 'one person can edit at a time' rule in favour of reconciling simultaneous edits smoothly.

As Robert Hof says:

"Real-time" is actually a bit of a misnomer. Most of this activity doesn't truly occur in real time, the way talking on the phone does, and social gestures such as sharing links with friends are just as important a part of the appeal as immediacy

Instead, we should think about a web that flows past, a web where the flow is important, as well as its past. The Flow Past web.

20 comments:

  1. I prefer the "Sushi Boat" web. When you sit down, dozens of fresh - if unfamiliar - sushi selections flow by you.

    It's best that you don't eat everything that comes by you.

    Instead, sample a few things, and if you find something you like, get more.

    ReplyDelete
  2. go further ... "flow past" is still a linear, old-paradigm mindset, compared to what the mind wants ..

    which is total immersion in all dimensions simultaneously, and not linear at all ..

    ReplyDelete
  3. I love the flow past web and description. But, having now spent a lot of time on the other end of the adoption curve working on culture change and adoption - the big objection I hear is the fear of information overload - and it is a huge barrier to adoption.

    But then again, perhaps by the time the flow past web reaches mass adoption - those who complain of information overload - maybe their brains will have evolved or they'll be retired.

    ReplyDelete
  4. Kevin, I really like this description. But I also like Brian's sushi boat (sushi conveyor belt is more like it) analogy. Things may come back around if you miss them the first time.

    ReplyDelete
  5. I particularly like the use of the words, ".. marking out times in the future.". The future as they say is where we all live, it is past and present information that will take us there.

    ReplyDelete
  6. Well, the flow past web could be a kind of 'asymmetric' real-time.

    The test could be that if it the flow past web, activity streams etc were symmetric would they match your definition of real-time from voice world, i.e. low latency. :)

    ReplyDelete
  7. Hi Kevin

    Thanks for the pointer to this. I'd love to find time to talk about it all more. Needless(?) to say, I agree.

    One thing I've often told people is that a problem with the real-time web is that things like Twitter lack a locus for ongoing information exchange (publishing?) around an object. Twitter's annotations are a nod (but no more) in that direction. See http://blogs.fluidinfo.com/fluidDB/2009/12/01/putting-metadata-onto-tweets-with-fluiddb/ which allows both - a real time web but also something which is not by its nature so ephemeral.

    It seems to me that it doesn't have to be an all-or-nothing choice.

    I wonder if I'm making sense? Anyway, very nice to read your thoughts & thanks again. Let me know if you'll be in Barcelona or NY any time soon.

    ReplyDelete