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
ptime! = TIMER: WHILE ptime! = TIMER: WEND' Pause
K$ = INKEY$
IF LEN(K$) = 2 THEN
SELECT CASE ASC(RIGHT$(K$, 1))
CASE 59 'F1
IF Rock1Exist = 0 THEN
ELSEIF LEN(K$) = 1 THEN
SELECT CASE ASC(K$)
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
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
- instant messaging
- cellphone text messages
- email, voice mail, fax
- wiki, weblog comments, message boards
- social bookmarking
- 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
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
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
broadcast message streams (popular blogs, news sites, etc.)
- the perception of social interaction and the discovery of novelty are both
- 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...
:: read the margins