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 Craftsman Approach to Building

Scott McMullan uncovered this great quote on the craft of building, one that’s as applicable to software as it is to buildings:    (JVV)

The Craftsman type of building is largely the result not of elaboration, but of elimination. The more I design, the more sure I am that elimination is the secret of beauty in architecture. By this I do not mean that I want to think scantily and work meagerly. Rather, I feel that one should plan richly and fully, and then begin to prune, to weed, to shear away everything that seems superfluous and superficial.    (JVW)

Gustav Stickley, More Craftsman Homes (1912)    (JVX)

Social Implications of Data Sharing

A few weeks ago, Evan Henshaw-Plath was explaining to me his epiphany about 43people, where an aggregation of different services tied together by Social Networks was starting to look very compelling. He then said that the next natural step for the folks at The Robot Co-op was calendaring. If anyone knows about calendaring, it’s Evan, who started a calendaring company with Kellan Elliott-McCrea in a past life. (Evan, you need Purple Numbers in your blog. Everyone needs them, dammit!) Trying to find relevant event information works much better when tied to Social Networks. Folks are starting to recognize this en masse, and the industry is reacting accordingly.    (JV3)

In an ideal world, Social Networks wouldn’t be tied to a particular site. Instead, that information would be distributed, and users would control the distribution. I’d love to tie my Google searches with my social network profile at LinkedIn, for example. That’s not going to happen unless Google acquires LinkedIn, or unless there are specs and a culture for distributed data sharing.    (JV4)

The culture is the tricky part. For as long as I’ve known him, Ross Mayfield has had an email signature that says what recipients are allowed to do with that email. (The choices are “bloggable,” “ask first,” and “private.” I think “ask first” is his default.) That, my friends, is a link contract.    (JV5)

Andy Dale has been working on the technical details of distributed data sharing with his XDI work. XDI is hairy stuff, but it’s graspable. Recently, Andy blogged about the form that link contracts and data sharing agreements might take. Victor Grey has said many times that we need a Creative Commons for data sharing agreements — simple, understandable, reusable, and legally enforceable contracts for our data.    (JV6)

That’s just a start. What will the user interface for specifying these agreements look like? Will users pay any more attention to these then they already do to Terms of Agreement on web sites?    (JV7)

Designing for Minimal Facilitation

Gail Taylor once explained to me her philosophy of designing large-scale events. If you have a large enough group, you will generally have all types of people, from obnoxious type-A personalities who dominate the conversation to thoughtful facilitator-types (whom she would call Yellow Threads).    (JV0)

If you’re designing an event for such a group, facilitation is more a result of your design than of designated facilitators. The trick is to mix people up and create an environment where folks facilitate themselves. Active facilitation of a large, diverse group is a pretty good indication that you’ve failed in your design. It’s not that it can’t work, it’s just that you’re not maximizing group potential.    (JV1)

Gail told me a story about an event she facilitated for a large company, where several of the higher-level executives were being uncooperative and impeding the entire process. Her solution? She didn’t admonish them or intervene with their breakout groups. She simply assigned them to their own breakout group and let them go. By the end of the event, everyone had achieved their objectives successfully except for that small group of executives. More importantly, these folks realized and acknowledged first-hand their failures and failings.    (JV2)