PurpleFS

Posted on Published by Eugene Eric Kim

Paul Visscher announced PurpleFS:    (KCN)

PurpleFS is a FUSE filesystem that allows you to transclude Purple Numbers.    (KCO)

In other words, PurpleFS is a filesystem interface to the Purple library. Super coolness.    (KCP)

(This, by the way, is an excellent example of Leave A Trail. Paul is part of the Church Of Purple, and there were any number of public places he could have announced this tool. I didn’t happen to be on any of the ones he chose (although it’s also possible that he just hasn’t posted to any of those places yet). And that’s perfectly okay, because he blogged it, and I follow his blog. He left a trail. It’s nice and efficient for all involved. It’s loose coupling, but it’s tight enough to maintain a sense of community and to enable tighter collaboration in the future.)    (KCQ)

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)

A Series of Open Conversations

Posted on Published by Eugene Eric Kim

What the heck is Blue Oxen Associates supposed to be about. Why the heck am I in this business? Forget about my Elevator Pitch for a moment. Forget about collaboration and collaboratories, Pattern Languages and Purple Numbers. What do I want, and why do I care?    (K1V)

I haven’t been able to answer these questions to everybody’s satisfaction, but I’ve found folks of all types who get either it or me pretty quickly and who share many of my hopes, dreams, and values. Being around these people has kept me going both personally and professionally, and further catalyzing this community is a big part of what Blue Oxen Associates is about. I often think about the negativity that one of my mentors, Doug Engelbart, faced for so long early in his career, and I’m grateful at how different my world has been.    (K1W)

Katrin Verclas and Seb Paquet are two of my favorite conversational partners. I’ve had the pleasure of working with Katrin (and Allen Gunn, another favorite) on the FLOSS Usability Sprints. I haven’t had the opportunity to work with Seb yet, but I’m quite certain it will happen eventually.    (K1X)

Katrin is in Massachusetts, and Seb is in Montreal. My conversations with both are always incredibly rich, and I’m constantly wishing that we could talk more often and that we could capture some of those conversations. Of course, thanks to technology (and a bit of process), we can.    (K1Y)

In the spirit of old school letter writing, I’ve proposed to both of them a series of conversations with a twist. Instead of emailing back and forth, we’ll post our letters on our blogs so that others can participate and hopefully join in.    (K1Z)

I think the open conversations will be revealing and hopefully entertaining. Katrin has already kicked things off with a nice list of things she wants out of her career and life. I’ll respond in my next blog post. And when Seb decides to return to the blogosphere (*nudge, nudge*), we’ll have an open conversation as well.    (K20)

I’d love to have conversations with many others, beyond what already occurs on our respective blogs. If you’d like to join in on this little experiment, write me a letter and post it on your blog. Don’t forget to link back here so I can find it.    (K21)

Looking forward to the conversations!    (K22)

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)

Queer Numbers

Posted on Published by Eugene Eric Kim

At BAR Camp, I ran into Kragen Sitaker who had an idea for a variant on Purple Numbers called Queer Numbers. Kragen recently blogged the idea (spotted by Matthew O’Connor).    (JWJ)

In brief, Purple Numbers are wonderful, assuming the author has generated them. If the author hasn’t, you can use a proxy, such as PurpleSlurple. The problem with PurpleSlurple is that the addresses aren’t stable. If the author inserts a paragraph into the document, the PurpleSlurple address will point to the wrong place.    (JWK)

Queer Numbers solve this problem by generating stable (maybe) identifiers based on some content analysis. Using this algorithm, you can address granular content on any page and feel fairly confident that the link will go to the right place. The level of confidence is still up in the air, as Kragen notes in his blog post.    (JWL)

Kragen referenced some work on lexical signatures for persistent naming of Web pages. (Ironically, Kragen didn’t have the link, and the original link is broken!) That work was Thomas Phelps and Robert Wilensky‘s Robust Hyperlinks, and it’s good stuff.    (JWM)

Some additional prior art: Doug Engelbart once told me that his lab had explored the idea of generating granular addresses through a hashing algorithm similar to Kragen’s. (Great minds think alike!) If I recall, their algorithm was less sophisticated than Kragen’s, and I don’t think they got too far with the idea, but I’ll have to double check with Doug to be sure.    (JWN)

About four years ago, I met a fellow named Alon Schwartz through Doug. Alon had founded an Israeli startup called BrowseUp, where he had independently come up with ideas such as granular linking and Backlinks, only to discover that Doug had thought of these ideas a half century earlier. Alon was delighted by this discovery and tried to convince Doug to join forces, but Doug wasn’t interested in getting involved with proprietary software, and BrowseUp eventually suffered the fate of most Dot Coms.    (JWO)

BrowseUp‘s product was a proxy server and browser plugin that gave you granular linking, backlinks, and link types to existing web content. It was pretty cool, and it’s too bad it never got much attention. Alon used a hashing algorithm to generate unique granular addresses that he claimed were over 90 percent stable across different versions of a document. Of course, he wouldn’t tell me what the algorithm was, because the product was proprietary.    (JWP)

I think Kragen’s onto something good, and I hope he’ll turn his idea into code soon so that we can start playing with Queer Numbers in earnest.    (JWQ)