Tuesday, October 17

And out my window it's snowing.

the one about the real problem of networked text communication

Just the other day:

<Alan> while we're at it brennen, let's just fuse all forms of online communication into one big system that is a blog, a wiki, a chat server and an email server.

after all, one could argue that these forms all forked via a now rather arbitrary discretization along the axes of realtime-ness and access control. i.e. 2-way chat is like fast email. blog is like email readable to the world. wiki is like blog organized by idea space instead, of by idea time. wiki is like an open-invite chat room except not real-time.

The history is more complicated, but conceptually this is exactly right, isn't it? Access control is interesting, but it's the realtime-ness that I want to address, because I think the cognitive costs and risks of text communication are carried on this axis. I'll explain why in a second, but first —

When and how did you learn your first programming language? Because I suspect that if it was before the web ruled the world, and if you were more or less self-taught, and if it was in a context where you had to deal with user input in realtime, that this analogy is going to make a lot more sense.

My first programming language was Microsoft's QBasic, which came bundled with MS-DOS for years and years. The reason I learned QBasic was that I wanted to make games. And in the process of making games, one of the very first tricks I learned was to write a loop and trap input from the keyboard. The program sits and hums, doing whatever it is that makes your game go 'round, checking the same spot for input over and over 'til it finds a keypress waiting for some kind of response. Here is a truncated real-world example from when I was around 15:


ptime! = TIMER: WHILE ptime! = TIMER: WEND' Pause

CASE 59 'F1
IF Rock1Exist = 0 THEN
CASE 27: quit = 1

LOOP UNTIL quit > 0
'End of main program loop.

Dijkstra may have had a point about BASIC.

The other night I found myself sitting at the computer, cycling between a set of input streams: Two email accounts, about two dozen site feeds, and reddit. I was aware of this, but I didn't stop until I was exhausted and could barely focus on the screen. I was mirroring the process of those old games: Iterating over the state of external inputs, making some occasional response to a change, and then resuming the iteration. This is a familiar pattern, and not one I'm fond of.

I want to argue that a process like this is a defining thing about almost all of the ways we communicate over the network, and further that the way this process emerges determines the human impact of a given protocol, be it the US Mail or IRC.

Here is a rough continuum of message protocols, arranged from most to least realtime:

  • face to face conversation
  • telephone, VOIP
  • full-duplex radio
  • half-duplex radio
  • talk(1)
  • IRC
  • instant messaging
  • cellphone text messages
  • Usenet
  • email, voice mail, fax
  • web
    • wiki, weblog comments, message boards
    • social bookmarking
    • weblogs
    • semi-static documents, file collections
  • snail mail

The first thing you probably notice is that there are problems here. The ordering is arbitrary, based on things like my notion that Usenet and IRC feel more realtime than email and IM because they're more crowded. The ordering seems flawed because access control and scale are really important, and because much of what makes a medium more or less realtime are usage conventions. Wiki, for example, could slide to almost any point on the list depending on implementation and user culture. Various elements of the web are hard to place, until you start looking at individual services and sites. Even that wouldn't be enough for something like Wikipedia. Permanence is another important quality I'm not taking into account.

I'll leave all that aside for the moment, because my point isn't that you can construct a rigorous hierarchy. It's just that there's a shared pattern for most of these protocols, starting somewhere around the level of talk(1). Messages are passed in discrete chunks, starting with single characters and scaling up to various kinds of documents. Users begin by either reading the available messages, or passing messages in, and then wait for new input to act on.

talk and IM protocols which mimic its keystroke-at-time message passing are very close to realtime systems as long as both parties to a conversation are actively involved. There are pauses, but they're something like what you get in a face-to-face interaction while people process what's been said. (It's important that the pauses don't carry things like body language, but more about that later.) In fact, since on-screen composition of the message is visible to all, talk(1) can feel more realtime than speech, or at least more temporally confused. As in a voice conversation with bad lag or one-way-at-a-time constraints, users have to develop a social protocol for back-and-forth signaling.

Once the message chunks become larger and the lag time between messages greater, we see the real ramifications of those pauses. Let's suppose that in a single conversation between two people across a relatively realtime protocol, you can expect to spend half of your engaged time reading a message or composing a new one, and the rest waiting for the next message from the other party. This is not so bad, right? Useful multitasking is next to impossible, but you can always shuffle songs around, drink a beer, and surf desultorily in the meanwhile.

So what happens in the real world, where:

  • parties to discussion are asynchronously/asymmetrically interested/committed
  • much message passing is closer to broadcast than discussion
  • most people are parties to multiple discussions across multiple protocols and cultures at varying degrees of realtime-ness, and interested in multiple broadcast message streams (popular blogs, news sites, etc.)
  • the perception of social interaction and the discovery of novelty are both literally addictive
  • people like me have compulsive tendencies
  • good message composition is hard

I think that what happens is you get lots of people acting like input trapping routines over a range of I/O streams.

Another way to look at this is that since good message composition is harder than waiting for new messages, most people idle, and cheaply composed (usually cheaply interesting) messages proliferate, thus reinforcing the tendency to cycle through your potential sources of new messages.

No one's on AIM? Maybe there's a new story on Slashdot. No? Maybe Ralph has some new links to CGI pictures of dinosaurs fighting robot tanks up on his blog. No? Well, have I gotten any email yet? Dammit, maybe somebody responded to that blog post about strains of indigenous mesoamerican popcorn? Nope. Well, I might as well see if Jack's on AIM yet...

p1k3 / 2006 / 10 / 17