purple-include: Granular Transclusions for the Common Man

Posted on Published by Eugene Eric Kim

Many thanks to Jonathan Cheyer, Craig Latta, and Kaliya Hamlin for coming to the HyperScope sprint this past weekend, and special thanks to Christina Engelbart for hosting. Also thanks to Thom Cherryhomes and others who hung out with us on IRC. The notes from the day are up on the Wiki, and I put up some pictures as well.    (MEL)

https://i0.wp.com/farm2.static.flickr.com/1134/681861752_857ef74d28_m.jpg?w=700    (MEM)

The big news, though, is that Brad, Jonathan, and I wrote a cool hack called purple-include, based on Mark Nottingham‘s most excellent hinclude. It lets you transclude granular chunks of content from any web site by using an img-like tag. Check out the examples. I think this will go a long way in making Transclusions more common on the Web.    (MEN)

You address granular content either by using a fragment identifier that the document author provides (such as a Purple Number) or by using an XPath expression. Thanks to Tony Chang for his cool interactive XPath tester.    (MEO)

The planned next step is to create a Firefox plugin that adds a “Transclude” option when you right click inside of a browser text widget. This will allow you to transclude copied content, rather than paste it. Don’t know whether any of us will get to this soon, so we encourage the lazy web and all you Firefox hackers to beat us to the punch.    (MEP)

This was my first non-trivial foray into JavaScript, and I was disturbed by what I saw. The language itself is not horrible, although its object system makes Perl 5 look like Smalltalk. What’s shameful is its API support. We had to use a very ugly, although apparently common hack to get a DOM of external web pages. This is pure silliness. The browser is already doing the hard work of parsing broken HTML and XML and turning it into a DOM. Why not easily expose that functionality to the developer?    (MEQ)

As Brad dryly noted, “Welcome to my world.”    (MER)

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)