Purple Numbers Are Ugly

Evan Henshaw-Plath thinks that Purple Numbers are ugly. He’s not the first.    (JW1)

A bit of history. The original Purple Numbers were a dark purple. Then Murray Altheim came up with a brilliant idea. Let’s make them lighter! So he did. That was better, but it wasn’t enough.    (JW2)

As Chris Dent and I started taking the identifier scheme to the next level, blogs started becoming popular. Permalinks, as rabble and others have pointed out, are granular addresses. Because our new identifier scheme was uglier by design (universally unique IDs can get quite large), we decided to jump on the blogging bandwagon and use hashes instead.    (JW3)

Then a funny thing happened. Peter Yim, a long-time Engelbart follower and an avid PurpleWiki user, complained. A lot. He said it was too hard to figure out what the links were. And as much as I tried to ignore him, I couldn’t. He was right. Or, more accurately, we were wrong. So we changed it back.    (JW4)

Our decision to go with hashes was wrong specifically in the context of PurpleWiki. Wikis are wonderful because you can Link As You Think. This is possible because page names are automatically linked, and it’s easy to remember page names. We added syntax for easily linking to Purple Numbers (for example, Purple Numbers). The problem was that when we replaced the addresses with hashes, we made it harder to Link As You Think.    (JW5)

With WikiSym coming up in a few days, I’ve had Wikis on my mind big-time, and I recently had an epiphany. It turns out I was wrong about being wrong.    (JW6)

The identifiers underlying Purple Numbers are designed to be stable, unique, and meaningless. In other words, not human-friendly. The notion of linking to Purple Numbers via our extended Wiki syntax isn’t tremendously useful, even if the identifiers are easily visible, because they’re impossible to remember. You’re rarely going to Link As You Think, because you’ll most likely have to go to the page to check what the number is. If you’re going to do that, you might as well just cut-and-paste the link, the status quo of the web.    (JW7)

Phil Jones almost stumbled onto something quite profound in his commentary last May, but he couldn’t quite put his finger on it, and Chris and I consequently jumped all over him. We were right, of course, but Phil was onto something.    (JW8)

In a Wiki context, here’s the right way to use Purple Numbers. By default, Purple Numbers should look pretty. So far, the best scheme I’ve seen for this is Simon Willison‘s nifty CSS hack. If folks want to link to a Purple Number in a Wiki, they can do it the way you do it anywhere else — get the link address by clicking on the number (or hash or paragraph symbol or whatever), and copy-and-paste it into your document.    (JW9)

However, the Wiki should add an additional feature: the ability to add a human-friendly label to any paragraph. Some Wikis implement this capability by using special WikiText tags, but you should be able to implement this using AJAX goodness.    (JWA)

In other words, suppose you’re reading a Wiki page, and you find one paragraph particularly compelling. All you do is click on the paragraph and add your human-friendly tag. Let’s say the page is DeepThoughts and you enter the label indeed. The label should appear next to the paragraph, and anytime somebody wants to link to that paragraph, they just type DeepThoughts#indeed.    (JWB)

Here’s where it gets cute. Doing this feels like tagging. You’re just tagging granular content instead of documents… which is what Purple Numbers are designed to enable in the first place. So, make the label a tag across the entire Wiki. In other words, if you click on the label indeed, you get a search page showing all paragraphs on the Wiki that have been tagged indeed. If you really want to be cute, you can make it a Technorati Tag so it gets crawled.    (JWC)

This makes cosmic sense. Both Wikis and tagging work when labels are not unique — the exact opposite requirement of Purple Numbers. You want namespace clash, and Wikis and tagging give you that. This way, you get the best of all worlds. You still have the immutable, unique Purple Numbers, but now they’re not so ugly. You also get Link As You Think granular addresses and granular tagging. Everyone wins.    (JWD)

(By the way, rabble, looking forward to seeing pretty Purple Numbers in typo!)    (JWE)

The Brilliant Essence of Wikis

Over the past few weeks, I’ve had an unusually large number of discussions about the essence of Wikis — why they are so beautiful and important as Collaborative Tools. I realized I’ve never posted my thoughts on the topic, so I’m correcting that here.    (JTE)

Wikis have this brilliant feature, a feature that’s so simple and obvious, it’s often overlooked, yet it’s largely responsible for the success of Wikis. Incidentally, it’s also an intentional feature, which is yet another reflection of Ward Cunningham‘s design genius.    (JTF)

In a nutshell, that feature is the ability to Link As You Think by writing the name of the page, even if the page you want to link to doesn’t currently exist.    (JTG)

While you’re letting that sink in, let’s look at a measurable way this feature is valuable. A lot of folks view Wikis as a crude CMS. I don’t dispute this perspective — you can certainly use Wikis that way — but it’s not what makes Wikis interesting. Nevertheless, I see queries all the time on various nonprofit technology lists asking to compare Wikis to other CMSes, so here goes. It takes at least three steps to link to a new page with most CMSes (create new page, go to old page, create link), whereas it only takes only one with Wikis (write page name). That’s significant.    (JTH)

What really makes the Wiki’s Link As You Think feature special is that it facilitates the creation of Shared Language among the community that uses it. As I’ve said so often here, Shared Language is an absolute prerequisite for collaboration. The lack of Shared Language is the most common roadblock to effective collaboration, be it a small work team or a community of thousands.    (JTI)

Look at the page index of any Wiki, and you’ll see the vocabulary of that community. Thanks to the other affordances of the tool, that vocabulary accomodates multiple definitions while encouraging convergence where appropriate. Most importantly, that vocabulary is Shared Language that has emerged from the community itself and that continues to evolve.    (JTJ)

Here’s a real example. At the AdvocacyDev Wiki, which Blue Oxen Associates hosts, the top six most linked-to pages (out of 363 total) are:    (JTK)

From this very small sample, we can see that VoIP (and Asterisk in particular), IndyVoter, and CivicSpace are all much discussed tools among folks working on online advocacy tools. We can also see that Carl Coryell-Martin is an active member of this community (or at least one of the more diligent members when it comes to documenting).    (JTR)

The Wiki’s ability to facilitate Shared Language — a direct consequence of Link As You Think — is what makes it so important as a Collaborative Tool. In the future, when enough developers recognize this, we’ll see widespread integration of Wiki functionality in other Collaborative Tools, such as blogs, online forums, and more. It’s already started. Blog-Wiki integration (such as what I use) is not uncommon, and software like TWiki and JotSpot are showing the benefits of custom applications that use Wikis as the fundamental data structure.    (JTS)