Okay, an email arrives in my mailbox a few minutes ago from Mark Morgan (one of the excellent things about Conversant is you can subscribe to these sites via e-mail) pointing out that Dave Winer’s Manila CMS has added a flat discussion view to its toolset.
This is one of the few things on the short list of things that I’d like to do on my sites but that Conversant can’t do yet … sort of. Morgan himself hacked a pretty good implementation of a flat view within Conversant that I plan on implementing soon, and Seth Dillingham did say that a flat discussion view is on the list of things to add to Conversant, though it was on schedule for a Q1 2001 date since there are other features that are being worked on.
One of the things I keep congratulating Seth on is the fact that when Conversant implements a feature, generally it has a pretty open structure so I can implement a feature the way I want. Personally I’m amazed that this isn’t the default attitude of software developers, but in discussing Manila’s implementation of the flat discussion group view, Winer illustrates the typical attitude of developers toward users.
Somebody asked Winer how he would handle letting people break long threads into multiple pages, which is a pretty standard feature in flat threaded discussion group software. Winer’s response,
First, there’s no limit to the size of a browser page.
Second, when the page gets “full”, start a new topic.
Yuck. First, although there is no limit to the size of the browser page, some of us have difficulty keeping thing straight when the page gets huge. Also, I don’t know about Winer but I have had people write me from remote locations — one person was accessing my site from a remote part of Alaska — where getting reliable 28.8k connections is iffy and huge pages would pretty much destroy the ability for them to participate in a meaningful way.
As for starting new topics when a page gets “full”, personally I’ve visited sites that did this, and I really hate that approach. Lots of people swear by it, but I think it’s self-defeating to have say 12 different thread pages going on about the same topic.
But beyond whether Winer or I are right about the “best” way to format a flat discussion group thread (and this is all a matter of personal preference), why not just write your software so that you support whatever option the administrator and/or user is most comfortable with? Since the page being served in this case is dynamic anyway, why not give administrators, and preferably users, control over how many messages they are served? It seems like such a small thing, why impose the “one true interface” on users?
The other thing I dislike about traditional flat discussion groups, which Winer’s uses, is they tend to order the messages in strict chronological order. This is helpful the first time you read the thread, but is a real pain in the butt, in my opinion, when you’re revisiting a thread. I much prefer ordering the messages in reverse chronological order so I always see the newest messages first. Others vehemently argue for the opposite. Again, let administrators, and preferably users, make that choice.
Mark refers to leaving out these sort of options as “only partway doing things.” Sometimes developers initially only partially implement a feature with the intent of adding on and fully implementing other features later, which is fine, but the goal to my mind should always be to make features as flexible as possible, especially in something like a CMS system.