Joel Spolsky (of “Joel on Software” fame) has been getting a lot of attention lately for his observation that software designers need to think about the impact their designs have on the way their software mediates between people. In general, I’m all for this, as you might gather from my posts here, here, here, here, here, here, here, here, here, and here. If you’ve read even a few of these posts, you know that there’s a lot more attention being paid to social interfaces by a lot more people than Joel suggests (although he is correct that a lot more work needs to be done to gather this work under the auspices of one field of study and disseminate what we have learned so far). Off the top of my head, the earliest work on internet-based social interfaces that I know of is Phil Greenspun’s. As far back as the mid-nineties, Greenspun built an Open Source toolkit called the ArsDigita Community System (ACS) that was designed (as you might guess from its name) as social software. It was originally built to support Photo.net, an early internet knowledge-sharing community that still thrives today. The software also became the toolkit for Greenspun’s now-defunct consulting company and the ancestor of the still-thriving OpenACS toolkit and community as well as the basis for the dotLRN Open Source LMS. Spolsky surely knows about Greenspun’s work; in fact, in his younger (humbler?) days, he freely admitted that Greenspun had been a major inspiration to his own career path. It’s somewhat disappointing to see that Joel fails to acknowledge the foundational work of his one-time virtual hero, despite the fact that it’s clear that Joel’s own ideas about discussion board design are derivative of (in the cases of the good ideas) or reacting to (in the cases of at least a couple of the bad ideas) Greenspun’s work.
Which brings me to my main beef. In the post that everybody is applauding, Joel links to his article “Building Communities With Software” (Jeez, how Greenspun-esque can you get?) as a blueprint for a discussion board that has “dozens of features and non-features and design decisions which collectively lead to a very high level of interesting conversation with the best signal-to-noise ratio of any discussion group I’ve ever participated in.” Between this article and the post that has everybody’s attention, we get a pretty good picture of what design elements that Joel thinks are important for which reasons. So what are these design elements? What does Joel consider to be good social interface design?
Here’s a sample:
Q. Why don’t you show me the post I’m replying to, while I compose my reply?
A. Because that will tempt you to quote a part of it in your own reply. Anything I can do to reduce the amount of quoting will increase the fluidity of the conversation, making topics interesting to read. Whenever someone quotes something from above, the person who reads the topic has to read the same thing twice in a row, which is pointless and automatically guaranteed to be boring.
Joel amplifies on this position in the “social interface” post:
In addition to absolute success and failures in social software, there are also social software side effects. The way social software behaves determines a huge amount about the type of community that develops. Usenet clients have this big-R command which is used to reply to a message while quoting the original message with those elegant >’s in the left column. And the early newsreaders were not threaded, so if you wanted to respond to someone’s point coherently, you had to quote them using the big-R feature. This led to a particularly Usenet style of responding to an argument: the line-by-line nitpick. It’s fun for the nitpicker but never worth reading. (By the way, the political bloggers, newcomers to the Internet, have reinvented this technique, thinking they were discovering something fun and new, and called it fisking, for reasons I won’t go into. Don’t worry, it’s not dirty.) Even though human beings had been debating for centuries, a tiny feature of a software product produced a whole new style of debating.
Well…no. Actually, this form of discourse has been around for as long as debate has been written down, i.e., for several millenia. It’s called quoting, and it’s a perfectly legitimate form of written discourse. It’s especially valuable in coversations where line-by-line responses are critical, such a philosophical discussion, a legal debate, or program debugging session. Now, Joel could have made a more legitemate argument by saying, “The kind of line-by-line responses that the traditional interface affords is not what is most useful in bug-reporting forums for the purposes of supporting discussions around identifying and eliminating software bugs.” A more legitimate and more interesting argument would be, “The kinds of responses that are most useful in bug-reporting conversations more closely resemble spoken conversation than written conversation. Therefore, I want to discourage quoting for my particular purposes.” But Joel makes neither of those arguments, choosing instead to issue a blanket condemnation of quoting in all discussion boards and going out of his way to make it difficult for users to do. This is somewhat akin to having your discussion board software automatically remove all exclamation points from all posts because you think people tend to overuse them. It’s arrogant.
Here’s another example:
Q. Could you make a feature where I check a box that says “email me if somebody replies to my post?”
A. This one feature, so easy to implement and thus so tempting to programmers, is the best way to kill dead any young forum. Implement this feature and you may never get to critical mass. Philip Greenspun’s LUSENET has this feature and you can watch it sapping the life out of young discussion groups.
What happens is that people go to the group to ask a question. If you offer the “notify me” checkbox, these people will post their question, check the box, and never come back. They’ll just read the replies in their mailbox. The end.
If you eliminate the checkbox, people are left with no choice but to check back every once in a while. And while they’re checking back, they might read another post which looks interesting. And they might have something to contribute to that post. And in the critical early days when you’re trying to get the discussion group to take off, you’ve increased the “stickiness” and you’ve got more people hanging around, which helps achieve critical mass a lot quicker.
So. I’m a customer, or a reader, and I’ve posted a question to a discussion board. You could easily send me the information right to me via email the minute it’s available. But you choose not to. Instead, you choose to make me check in periodically to see if there is any new information available or not. (There may not be.) Why? Because you want to force me to come back. Sorry, this isn’t the attitude of a community that I want to join. Again, it’s arrogant. And besides, I don’t believe it would actually work in most cases. In the age of RSS, I have very little time for a community that makes me check a web page periodically to see if something has changed. Give me an RSS feed for the board or, at least, a daily email alert. I’ll scan that to see if there’s something worthwhile and, if there is, I’ll visit the site. But I don’t have time for sites that are clearly not making it as easy as possible for me to get the information I need. It’s a buyer’s market for information on the internet.
I could go on, but you get the idea. Not all of Joel’s ideas are bad; for example, I share his disdain for threading. But I think he crosses the line on a number of occasions between trying to identify affordances that will facilitate the kinds of conversations that potential participants want to have and arbitrarily dictating what kinds of discourse will be permitted based on his personal needs and whims. Social interface design, like any other social engineering effort, requires attention to ethics.