Tangled in the Threads
Jon Udell, April 19, 2000Newsgroups and the Wiki way
In last week's column about hybrid web/email groupware, I mentioned that one of the fatal flaws of mailing-list-based discussion is the dreaded re: syndrome. It's the unfortunate result of the conflation, in the email realm, of two contradictory uses of the crucial Subject: header:
- to entitle a message
- to relate a message to its surrounding context
You see the effects of this everywhere -- in your own inbox, and on countless mailing lists. Here, for example, is a snapshot of the ZopeDev list:
Fig 1: A snapshot of the Zope-Dev list
What's wrong with this picture? I can best illustrate by counter-example. Here's how I'd prefer to view this thread:
Fig 2: Idealized snapshot of the Zope-Dev list
ZServer speed enhancement (I hope) - Andy Dustman How much faster is it? - Brian Lloyd Honestly, I don't know. More improvements coming... - Andy Dustman Try apache-bench - Hannu Krosing New version now available - Andy Dustman That one's broken - Ben Leslie Oops, you're right, sorry, fix coming... - Andy Dustman Any performance tests yet? - Hannu Krosing |
In light of Fig 2, Fig 1 is a disastrous information display. For starters, it doesn't even render the complete thread. As it happens, that thread began with Andy Dustman's March 30th ZServer speed enhancement (I hope) message, and Brian Lloyd's March 31's reply. Why are the original messages omitted? This mail archiver (as is typical) chunks on monthly boundaries. Unfortunately, the thread crosses the March/April boundary.
More importantly, Fig 1's display of thread structure is virtually useless in the absence of descriptive message titles. Claude Shannon defined information as what you don't know -- the degree to which the next message in a series of messages surprises you. In Fig 1, the repetition of "ZServer speed enhancement (I hope)" is completely unsurprising. This sequence of message titles, therefore, carries no information.
The difference between Fig 1 and Fig 2 could not be more dramatic. In Fig 2 you can click through to the individual messages (go ahead and do that, they're live links) -- but you don't have to click through to absorb the sense of this thread. The message titles themselves convey information; they tell a story.
This might seem like a pedantic point, but if you spend a lot of time trying to dig information out of mailing lists -- and I'm not singling out Zope-Dev here, all mailing lists suffer this problem -- it's clear that the re: syndrome is responsible for catastrophic information loss and inefficiency.
This theme came up last week in the applications newsgroup.
Michael Simcich:
After getting over my first reaction to Jon's subject tweaking here in the newsgroups (gads, the thread itself is saying something!), I find it's quite useful. Looking at the tree of subject lines conveys information. I built a threaded discussion widget a while ago that only shows the subject line once at the head of the thread, but in the tree of replies below shows the first 30 chars or so of each new post (not a new idea). It has the same effect. Scanning the list can communicate something, especially if the users are aware of and interested in this device, and so construct their first sentences with this in mind.
Michel Pelletier:
If we all took this approach would it make the thread more or less readable? Is there a useful pattern that can be seen here?
Sure there's a pattern, and it's hundreds of years old.
Heads, decks, and leads
Newspaper and magazine editors are obsessive about headlines, subheads ("decks") and introductory paragraphs ("leads") -- and for good reason. They understand the need to layer information -- you can't put everything on the cover or front page. These pages are interfaces that must convey, in the most compact and efficient and meaningful way possible, what can be found at the next level to which the user might choose to drill down. That next click (or page-turn) is expensive! You want as many cues as possible to help you decide whether to invest your time (and attention!) in what may lie behind the link. The title is the single most important cue available.
Imagine sacrificing the ability to write descriptive headlines on the cover of a magazine, or the front page of a newspaper! It's quite unthinkable. Yet we routinely sacrifice that ability in messaging environments.
Michael Simcich: "Consider me converted"
I think subject line changing is a great pattern to get into. These byte newsgroups are pretty new to me, and they are full of interesting conversations. I haven't had time to read all of the messages yet, but Jon's (and others') subject tweaking is helping me pick my way through them. The thread "Corel Office for Linux?" wasn't of immediate interest to me, but seeing the subject line morph into something about Mahogany pulled me in. Even the threads I have read show me information hotspots which are far superior to what I can normally glean from a thread -- author's name, thread depth.
The Wiki way
Think of a thread as an object, and the thread view as the primary interface to that object. In these terms, the interface in Fig 2 is doing a much better job than the interface in Fig 1.
There are, of course, other models for online discussion. One of the most interesting is Wiki, a freeform collaboration tool that prefers hypertextual structure to thread structure. I first encountered Wiki in its original incarnation as Ward Cunningham's Portland Pattern Repository. If you've never been there, go have a look. It's one of most remarkable -- and long-lived -- online collaborations in existence, radical in that every document is editable, always, by every user.
The original Wiki spawned a slew of derivatives. For example, if you're running a Zope site, you can install Simon Michael's ZWiki which enables Zope to host one or more Wiki webs. A longtime contributor to the BYTE newsgroups, Peter Thoeny, is the author of another Wiki derivative, TWiki.
I have been pondering the pros and cons of newsgroup-style vs Wiki-style collaboration. To the extent that a newsgroup can (at its best) offer a layered interface which summarizes discussion as seen in Fig 2, I have tended to believe that newsgroups are potentially more effective than the Wiki approach. However, hardly anybody uses newsgroups in the way that produces results as seen in Fig 2. And as Peter Thoeny pointed out, the Wiki way of collecting related discussion has its own unique strengths:
People used to Wiki-style collaboration tell me they like it more then threaded newsgroups:
- All issues on the same subject are on the same topic (e.g. web page), you only need to scroll down to see text of the same context.
- Simply edit the topic to add text of the same context.
- Create a new topic that is related to the current topic, or to point to an existing topic of similar context. Those topics are hyperlinked automatically because of WikiNames.
- Wiki discussions are fostered by email notification of changes. Simply click on a topic you are interested in (and ignore other topics)
- It is possible to categorize text in some Wiki systems like TWiki. This allows you to group topics of similar context.
In reply, I argued for some of the underappreciated hypertextual capabilities of newsgroups. But, Peter's message prompted me to revisit TWiki and boy, is it powerful! Among other things, TWiki eases one of the concerns about classic Wiki, which is that the radically egalitarian "edit this page" scheme leaves no change log. TWiki includes powerful revision support. Every change leaves a footprint, and you can follow these easily and effectively.
Ultimately I don't think there is One Right Way for online collaboration. We're all just making this stuff up as we go along. Groupware is a discipline still in its infancy. Tools like newsgroups and Wiki are an important part of the equation. But social and literary conventions surrounding the use of these tools are going to take a long time to sort out. We do not, as a species, have very much experience with group messaging. As we work our way up the learning curve, let's not lose sight of common sense and conventional wisdom. In an era of infoglut, heads, decks, and leads matter more than ever.
Jon Udell (http://udell.roninhouse.com/) was BYTE Magazine's executive editor for new media, the architect of the original www.byte.com, and author of BYTE's Web Project column. He's now an independent Web/Internet consultant, and is the author of Practical Internet Groupware, from O'Reilly and Associates. His recent BYTE.com columns are archived at http://www.byte.com/index/threads
