Seth Nickell

GNOME’s desktop-devel-list today is just what gnome-hackers list used to be. Its not like this is a new problem. Lists start out good, but then too many people get on them, so we eventually restrict who can be on the list, and then some people think we are too elitist and start a new list. Which is non-elitist and has a high signal to noise ratio… until the effects of non-elitism creep in, and we have these problems all over again.

1. Having a central desktop list seems like a thing that happens naturally, and is also the list I’m most likely to read. Thus I personally at least consider it good.
2. Restricting access removes much of the cluelessness, but at the cost of greater administrative burden, and locking out valuable potential contributors
3. Restricting access does not typically make lists regain their old “high signal to noise ratio” status. For example, gnome-hackers was periodically prone to extended technical discussions (by clueful people) that became tiresome for most people on the list and ideally would have jumped list. They were often good discussions to have, but not everybody needed to be party to them.
4. Fragmented lists tend to be ignored, even by the people they are most relevant to (such as the relevant maintainers, often)

In short, it is best to have fewer lists, but we need to alleviate the problems that make a few central lists occasionally painful.

It seems that the real problem is not the variety of the threads, but that some threads don’t die which we’d really rather not have on the list-that-everyone-reads (or at least, used to read . Flags and the recent release name discussions come to mind. What if there was a way to create quick temporary break out discussion lists? Something that required no admin maintenance. That way rather than fragmenting general discussion, we could create immediate outlets for in-depth (and sometimes important, othertimes not) discussions that most people don’t want to read (or in my case Mark As Read).

Rather than fragmenting lists by “general topic”, which seems not to work, why don’t we fragment list traffic on a per discussion basis. Very few discussions will need this, but the few that do we can not destroy the public list’s readability for the week+ it takes to run its course.

Say we have 10 or so responsible people who can create a breakout discussion “list”. There’s a little web form one of these people can use to break-out a discussion. The person gives the subject of the discussion into the web form, and an “End of Discussion” ultimatuum/message gets automatically posted to ddl. In this ultimatuum is a link. When the message is received, clicking on the link pops up a form where you can enter your e-mail address, and *poof* you’re in on the discussion in the breakout list. Every post to the breakout list has a link appended for leaving the list. Basically people interested in the conversation can keep at it, but the conversation moves off-list in a convenient manner. Some considerations for the breakout lists:

• We don’t try to do any security or passwords or confirmation e-mails for adding/removing people from lists, because these things are supposed to be cheap, dirty, and ephemeral. They need to have a ridiculously low barrier of entry.
• We don’t want too many people who can create breakout lists, or any discussion that generates a dozen messages will get somebody trying to break out the discussion. When breakouts happen too often, people will start ignoring the breakout ultimatum and will keep posting on d-d-l, destroying the efficacy of the technique when it is really needed. On the other hand, we need enough people who can create lists that at least a few of them are active on the list every day. That way it doesn’t become some onerous task for which an “admin” has to be tracked down, and coaxed to waste their precious time on (for example, its not like trying to get somebody to do CVS surgery for you).

It is interesting to compare the “list problem” to how discussions work in the “real world”. In the real world we would have serious trouble if everybody had to listen to every discussion involving more then four participants. The fragmented lists suggestion is somewhat akin to having 25 separate rooms, each devoted to a particular topic. This is a sort of weird division, and people are probably going to drift into larger rooms (or have off topic conversations). Naturally people control conversation and topic interest pretty well by drifting in and out of groups. Basically, breakout discussion lists is a way to try and accomodate that sort of ephemeral shift.

January 22, 1984: the Apple Macintosh is unleashed on the world. The world blinks and keeps on turning.

The release of the Macintosh wasn’t the revolution, it was a symbol of the revolution. It wasn’t merely the introduction of an “insanely great” product line but of the debutante ball of the process that birthed it. And at the heart of that process (human-centered design) was a paradigm shift. The question was no longer “What will this computer’s specs be?” but “What will people do with this product?“. That question is as relevant (and almost as frequently overlooked) today as it was twenty years ago. The importance of the revolution was less in Windows Icons Menus and Pointer and more in approaching product development from the right direction. Until widespread development and design in the computer industry is focused on a question like that, the Macintosh revolution is far from over.

The Star desktop, circa 1981

There is widespread disagreement as to when and where this revolution began, but it is not contentious that the ideas took root in the feracious ground of Xerox PARC in the 70s. The end result was the Xerox 8010 (aka Star) desktop, released in 1981. To a large extent the Star interface is extant in modern desktops, but this belies the importance of the Star: it was the result of human-centered design. Engineers and researchers at Xerox tried to create a computer that could be used to “do people things” rather than just crunch numbers. Focus was not on specs and technology but on what Star could accomplish.

The Alto’s “Executive”, circa mid 1970s

It is interesting to compare the Star interface with the interface of the Executive program from the equally famous Xerox Alto (from the mid 70s). The Alto was a technical marvel, with a bitmapped display, windows, a mouse, and ethernet. But while the Star really adds nothing to this impressive list of technology, the difference between the two, in terms of user experience, is like night and day. Technological invention can enable real improvement, but its not enough (usually its not even necessary). Anyway, enough historical meandering. The story of the Macintosh, Star and Alto is very interesting, and there’s a lot of period documents dealing with that subject… maybe I’ll post a list of links another day. But back to my agenda:

At best I think most people ask “What could people do with this computer”. That’s a very different question from “What people will people do with this computer”… there are so many nifty features that if people pushed themselves they could use, but have a high enough barrier to entry that people don’t bother.

Example: I have a nice thermostat in my apartment. Its fairly well designed and has quick push buttons for “Daytime”, “Night” and “Vacation”. It was even straightforward to set these to my preferred temperatures for “In the apartment, awake”, “Out of the apartment or asleep”, and I haven’t bothered with the vacation button. Now I have noticed that I don’t like to get out of bed in the morning because it is sort of cold. In fact, sometimes I’ll lie in bed for 30+ minutes because its cold, which is a big waste of time (I’m not very rational when I’m waking up). I have noticed that my thermostat supports scheduling changes between day and night temperature. I even looked at the instructions beneath the faceplate, and it looks like it’d be fairly easy to program. But I haven’t done it. The device is usable in the sense that if I wanted to, I could program it, and probably get it right on the first or second try. Its not hard to use. But its a little too inconvenient, because I’d have to special case my weekend schedule, I’d have to set several different times using the fairly slow “up”, “down”, “next item” interface for setting time (on most alarm clocks etc). The point is, its not hard to figure out, but its stills too much hassle. So while I could program the thermostat, I won’t. There’s always something that seems better to do with my time, and I can’t be bothered (even though rationally I know it’d be better overall if I just program the silly thing).

The Macintosh revolution, at least how I see it, was about conceiving your (computer related) product in terms of what people will do with it. Sometimes we need to “get back to the basics”…