Purple v0.9

Posted on Published by Eugene Eric Kim

After RecentChangesCamp earlier this month, I drove up to Seattle to visit Chris Dent and others. Chris and I spent a day talking shop and life, and also taking care of a few things that we’ve been discussing for a while. The biggie was extracting the Purple Number generator from PurpleWiki into its own library and creating a RESTish front-end to it. The result — Purple v0.9, available on CPAN.    (K9N)

Not only will Purple make it easier for folks to incorporate Purple Number generation in their own software, it will also enable us to start properly experimenting with distributed Purple Numbers. Right now, I can transclude content between this blog and my Wiki. With Purple, I’ll be able to transclude from Chris’s blog and any other sites using these Purple Numbers (including all of Blue Oxen Associates‘s collaboratories.    (K9O)

It was very cool to get this done, and more is to come. Chris has already started to incorporate it into PurpleWiki, and Paul Visscher has already started to incorporate it into perplog. You can read Chris’s commentary and follow more on the Church Of Purple‘s progress at the Purple collaboratory.    (K9P)

Purple Numbers and WIKIWYG

Posted on Published by Eugene Eric Kim

For a while, it was looking like I was going to break another personal blogging record last month, then things got so busy I had zero time to blog whatsoever. That means I’m in catch up mode again, so as usual, I’ll post in reverse chronological order (which in the blogosphere is really reverse reverse chronological order).    (JYN)

Yesterday, I spent the afternoon at Socialtext, where they were having an all-hands meeting. They graciously invited me to participate in the Open Space segment of their gathering, which meant quality time with Chris Dent and a rare opportunity to evangelize the Church Of Purple together. Of course, Chris has been spreading the Purple religion at Socialtext for a while now, so it wasn’t as much about evangelism as it was about next steps.    (JYO)

As I’ve mentioned many times before, browser-based WYSIWYG editors are an exciting development because they allow us to make Purple Numbers transparent in the authoring process. Right now, when you edit a PurpleWiki page, you see the node ID tags (e.g. {nid 123}). This is impossible to get around with the default browser text-editing widget. However, with a WYSIWYG editor, you can hide the Purple Numbers while still maintaining their associations with a node behind the scenes.    (JYP)

That’s the theory, anyway. In particular, I’ve been excited about WIKIWYG ever since Ross Mayfield showed me an early prototype last August. I had a personal bias, since Chris Dent and Matt Liggett helped write it, as did Casey West and the inimitable Brian Ingerson, whom I finally met last weekend at Tag Camp.    (JYQ)

Yesterday afternoon, we discussed Purple Numbers and WIKIWYG, and it was good. Then in the evening, Ingy and I spent a few hours trying to get WIKIWYG integrated into PurpleWiki.    (JYR)

We didn’t quite make it. Our biggest roadblock was a bug we discovered in Mozilla’s design mode that we can’t do much about. (My days of statically typed languages are well behind me.) But, we got something somewhat working, and I learned a heckuvalot. You can play with our semi-working demo.    (JYS)

WIKIWYG seems well-architected and is easy to customize. For folks with relatively standard Wiki editing requirements, I highly encourage you to play with it. PurpleWiki has some special formatting funkiness (mainly due to the Purple Numbers), but we were able to get around this fairly easily. (This was also true thanks to PurpleWiki‘s model of parsing to an intermediate data structure, then using view drivers to serialize. I wish more Wiki engines did this. I know Magnus Manske is thinking about doing this for Mediawiki, and I think Janne Jalkanen is already doing it with JSPWiki.)    (JYT)

The Mozilla bug annoyed me, because it’s a show-stopper in some ways, and there’s not much I can do about it. I didn’t realize it, but all of the JavaScript WYSIWYG widgets actually switch to the browser’s “design mode” in order to handle WYSIWYG editing. As with many HTML editors, design mode does not handle structure cleanly, and you end up getting weird artifacts such as spurious break tags. Our problem was that we serialize node ID information as id attributes in the HTML tags. However, Firefox does not maintain those attributes correctly when you move content around.    (JYU)

I’ll report the bug (if folks have suggestions as to the best way to bring this to the right people’s attention, let me know), but it also puts the kibosh on my hopes for WIKIWYG and Purple Numbers. Even if the bug is fixed in the next version of Firefox, we’re still prey to all the folks using older versions as well as Internet Explorer or Safari, which have their own problems with design mode.    (JYV)

Chris and I discussed one workaround that I’m still pondering: render the Purple Number and have users be responsible for maintaining the association with the nodes. That’s the status quo, except users are doing it in WikiText rather than in WYSIWYG. Doing it in WYSIWYG certainly lowers the bar, and it’s probably the next best thing for us to do.    (JYW)

Purple Numbers Are Ugly

Posted on Published by Eugene Eric Kim

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)

Purple Numbers: Optimized for Synthesis

Posted on Published by Eugene Eric Kim

Chris Dent has been having some good exchanges about Purple Numbers with Adina Levin and Phil Jones. I don’t have much to add, as I think Chris is spot on. Two comments struck me, though.    (IQV)

First, Phil claims that Purple Numbers are optimized for reading at the expense of writing. His point is that Purple Numbers, as currently implemented, add overhead to the writing process, whereas the pay-off comes for the reader. I emphasize as currently implemented, because we just haven’t gotten around to making them mostly transparent in the writing process. Hacking one of the WYSIWYG JavaScript text editors to support Purple Numbers should do the trick.    (IQW)

However, I really liked Chris’s response:    (IQX)

Yes, purple numbers do try to favor the reader and the act of reading, but not just for reading. They favor the reader so the reader may more easily do more writing. The whole point is for purple numbers and tools like it to be a generative force in the synthesis of new understandings.    (IQY)

Phil can write all he wants, and I can read all I want, but until I write down something that builds on what Phil says, while making chains of reference back through the many layers of context, there’s been no synthesis, at least not any that is available outside the confines of my own mind.    (IQZ)

Granular Addressability enables synthesis. Wanna know what makes blogs conversational? Permalinks, which are a form of Granular Addressability.    (IR0)

A lot of people don’t get this. I read The Sports Guy over at ESPN.com all the time (despite the fact that I hate all Boston sports teams with a passion), and at the past two Super Bowls, he wrote what ESPN.com called a “blog.” It sure looked like a blog, but in reality, it was just one-way publishing. Folks couldn’t comment on his entries, because they couldn’t link to any of them. I see this all the time with other major media outlets trying to jump on the blog bandwagon.    (IR1)

Which brings me to the second comment that jumped out at me. In his response to Adina, Chris wrote:    (IR2)

Clearly I am in far too deep with purple stuff: I need a translator. The above can be so much meaningless noise and I find little time to make things cogent.    (IR3)

I’m not the best proselytizer of Purple Numbers, not because I’m not proud of them (I am), not because I don’t value them (I do), and not because I can’t explain their value clearly (I can). There’s a tremendous amount of deep thinking underlying these little purple critters, and the implications are fascinating. But before you can understand any of this, you’ve got to care. And unless you’re one of those strange individuals who just gets it, you’ve got to try them before you’ll buy them.    (IR4)

A lot of folks think I invented Purple Numbers. Not true at all. I was one of those folks who didn’t care, one of the first in fact. Purple Numbers are an HTML manifestation of Augment’s granular addressability scheme, invented by Doug Engelbart and made purple years later by his daughter, Christina Engelbart. When I first started working with Doug, he kept insisting that all of our knowledge products on the Web have Purple Numbers. I didn’t think it was a priority, but I knew I could easily whip up a tool to generate them, so I wrote Purple to humor him. Then a funny thing happened. Once I had them, I used them, simply because they were there. Then I started missing them when they weren’t there. Then it dawned on me: These little purple thingies sure were darn useful. And I started thinking about why.    (IR5)

The point of my story is this: I’m perfectly happy to have a deep, convoluted discussion about some esoteric aspect of Purple Numbers. If you don’t believe me, try me. Or read my blog entries on the matter. But if you really want to understand why they’re so important, just give them a try for a month, then try living without them.    (IR6)