Clustering in the Margins

Seb Paquet posits the following theory: “people who pioneer group-forming practices are those who have a marked interest in something that is not generally shared by the rest of the population.” He cites evidence from a First Monday paper entitled, “A social network caught in the Web.”    (4L)

Said a different way: Niche topics generate greater Shared Intensity.    (4M)

William Kent at Extreme Markup 2003

For my blog entry on e-mail clients, I had to look up the link for the Extreme Markup conference. In so doing, I noticed that William Kent will be keynoting this year’s conference.    (4I)

Bill Kent‘s book, Data and Reality, is awesome. I consider it a must-read for anyone interested in data modeling. I won’t be able to make it to Montreal for the conference this year, but I’d recommend it for those of you who can. It’s August 4-8 in Montreal, Quebec, Canada.    (4J)

Won’t Someone Write a Decent E-mail Client?

Brian Lincoln was complaining about e-mail clients recently, and he said that he was willing to pay $1,000 for a good e-mail management tool. That’s a stunning statement, if you think about it. E-mail is probably more widely used than word processing, and probably ranks near even with Web browsing. Several companies have devoted large budgets to building e-mail clients, and there are several open source initiatives as well. You would think that there would at least be once decent e-mail client by now.    (40)

Despite all of this, I completely agree with Brian. I haven’t found anything that comes close to doing even mostly what I want.    (41)

(I have to throw in a brief disclaimer about mutt, which I’ve been using for about a year. Mutt is very customizable, which I like very much, and is fairly UNIXy, which I also like. It’s supposed to be easily extensible, but I haven’t had a chance to test this myself. At some point, I will.)    (42)

I get tons of e-mail. I save a large percentage of it, including e-mail that I send. My archives date back to 1994. There’s a wealth of information there, and I’d like to be able to easily retrieve what I need when I need it. I want:    (43)

  • Powerful search capabilities.    (44)
  • Categorization.    (45)
  • Ability to link e-mails with other types of information: calendar, datebook, Web pages, source code, other e-mails, etc.    (46)
  • Useful views.    (47)

I’m not going to expand on these here, except to say that doing all of this stuff right has significant architectural ramifications. One reason I may be so difficult to please in this regard is that I have fairly well thought-out ideas on what that architecture should be, and I have yet to see this kind of architecture in any tool. I was heavily influenced in this regard by Doug Engelbart, who’s also on our Advisory Board. (Some of these thoughts are loosely captured in my paper, “Towards a Standard Graph-Based Data Model for the Open Hyperdocument System”, which Ken Holman presented for me at Extreme Markup 2002.)    (48)

The e-mail tool whose architecture comes closest to my vision is Helium, a class project at Indiana University that emerged out of Gregory Rawlins‘s KnownSpace in Fall 2002. Using Known Space as its data architecture, the team explored and prototyped a lot of interesting ideas. Unfortunately, there are limits to what a team of students can accomplish in a semester, and the project is unfinished and in stasis.    (49)

Chandler holds a similar appeal as Helium, as I explained to the Collaboration Collaboratory last January.    (4A)

Here are some other pet peeves regarding today’s e-mail clients:    (4B)

  • HTML e-mail. If you’re going to use it, at least implement it consistently.    (4C)
  • Moronic word-wrapping and line lengths. More evidence of widespread disinterest in interoperating well with other e-mail clients.    (4D)
  • Reply-to behavior. Most users have no conception of the “To” header. They hit their “Reply” button, and simply expect the e-mail to go to the right place. This is a solvable usability challenge, but somebody needs to tackle it.    (4E)
  • Quoting. How difficult would it be to come up with a standard for quoting other e-mails? More importantly, wouldn’t it be great if people could send one-word responses to e-mails without citing an entire three-month thread at the end of the message?    (4F)
  • Header control. Most e-mail clients hide headers by default. That’s okay. But sometimes, there’s valuable information in the headers. Many e-mail clients make it extremely hard to view this information, or to forward it to other people.    (4G)
  • Folder management. Blech. Folders are not a good way to categorize e-mail. The first vendor who figures this out is going to make a lot of money.    (4H)

WikiWords Versus External Links

Suppose you are writing in a Wiki or WikiWord-enabled blog. Why would you use a WikiWord instead of an external link?    (3T)

For a more concrete scenario, consider a link to Blue Oxen Associates. You could either create an external link to, or you could use the WikiWord Blue Oxen Associates. I see several advantages to the latter:    (3U)

  • Easier to remember. Is it or WikiWords are human-friendlier link names.    (3V)
  • Enter the link once. If your Wiki page includes the appropriate external link, and if that link changes, you only have to update the link once.    (3W)
  • Annotation. I often create Wiki pages to organizations that contain an external link and the contact information. Having the contact information on the Wiki page saves me from having to search the external site for that information.    (3X)
  • Backlinks. If you use a WikiWord, you inherit your Wiki’s Backlink functionality, which allows you to find other interesting and relevant pages.    (3Y)

The primary disadvantage occurs when the Wiki page simply consists of an external link. In this case, you force the user to click twice instead of once to get to the relevant information. I believe that this is offset by the other advantages of WikiWords.    (3Z)