Mon, Jul 02, 2007
purple-include: Granular Transclusions for the Common Man #
Many thanks to JonathanCheyer, CraigLatta, and KaliyaHamlin for coming to the HyperScope sprint this past weekend, and special thanks to ChristinaEngelbart for hosting. Also thanks to ThomCherryhomes 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)
The big news, though, is that Brad, Jonathan, and I wrote a cool hack called purple-include, based on MarkNottingham'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 PurpleNumber) or by using an XPath expression. Thanks to TonyChang 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)
/tech/purple | Posted at 11:36pm
Tue, Apr 03, 2007
Spreadsheets 2.0 and Transclusions #
A few weeks ago, I had dinner with my old HyperScope buddies, BradNeuberg and JonathanCheyer. We talked a bit about this Office 2.0 madness, and how a lot of these Web-based applications were disappointly uninteresting. Don't get me wrong. There's a lot of really nifty hacking going on behind the scenes to make this all work. But in the end, all you have is a Web-based office application. Most of these applications do little to take advantage of the network paradigm. (M2P)
A simple and extremely cool way for Web-based spreadsheets to exploit the medium would be to support TransClusions across multiple web sites. As I've observed before, spreadsheets were the first applications to popularize the notion of a TransClusion, even though they didn't call them that. When I type =E27 in a cell, it displays the content of cell E27. This, in a nutshell, is a TransClusion, and oh, is it useful. (M2Q)
With Web-based spreadsheets, if you made cell addresses universally resolvable, you could easily support TransClusions across web sites. In other words, I could transclude the content of cell =E27 from a spreadsheet hosted on my web site into a cell on a spreadsheet hosted on another web site. (M2R)
Why would this be useful? Well, why is it useful to link to other web sites? Today's Web-based spreadsheets are no more collaborative than desktop spreadsheets. In theory, they're more convenient than emailing spreadsheets back-and-forth, but they're no different in capability. Cross-spreadsheet TransClusions would break down silos and encourage collaboration. (M2S)
I would start with spreadsheet-to-spreadsheet TransClusions with an eye toward supporting TransClusion of non-spreadsheet content using PurpleNumbers or something similar. The main technical barrier is coming up with the right addressability scheme. Seems to me that the SimplestThingThatWorks would be to use fragment identifiers (which is what we did for the HyperScope). In other words, cell =E27 on a spreadsheet at http://foo/bar would have the address: (M2T)
http://foo/bar#E27 (M2U)
Eventually, you'd want persistent, non-URL-based identifiers, but first things first. (M2V)
/tech/purple | Posted at 1:40am
Mon, Mar 13, 2006
PurpleFS #
PaulVisscher announced PurpleFS: (KCN)
PurpleFS is a FUSE filesystem that allows you to transclude PurpleNumbers. (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 LeaveATrail. Paul is part of the ChurchOfPurple, 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)
/tech/purple | Posted at 5:26pm
Mon, Feb 27, 2006
Purple v0.9 #
After RecentChangesCamp earlier this month, I drove up to Seattle to visit ChrisDent 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 PurpleNumber 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 PurpleNumber generation in their own software, it will also enable us to start properly experimenting with distributed PurpleNumbers. 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 PurpleNumbers (including all of BlueOxenAssociates'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 PaulVisscher has already started to incorporate it into perplog. You can read Chris's commentary and follow more on the ChurchOfPurple's progress at the Purple collaboratory. (K9P)
/tech/purple | Posted at 12:57am
Wed, Nov 02, 2005
Purple Numbers and WIKIWYG #
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 OpenSpace segment of their gathering, which meant quality time with ChrisDent and a rare opportunity to evangelize the ChurchOfPurple 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 PurpleNumbers 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 PurpleNumbers 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 RossMayfield showed me an early prototype last August. I had a personal bias, since ChrisDent and MattLiggett helped write it, as did CaseyWest and the inimitable BrianIngerson, whom I finally met last weekend at TagCamp. (JYQ)
Yesterday afternoon, we discussed PurpleNumbers 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 PurpleNumbers), 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 MagnusManske is thinking about doing this for MediaWiki, and I think JanneJalkanen 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 PurpleNumbers. 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 InternetExplorer or Safari, which have their own problems with design mode. (JYV)
Chris and I discussed one workaround that I'm still pondering: render the PurpleNumber 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)
/tech/purple | Posted at 4:23pm
Fri, Oct 14, 2005
Queer Numbers #
At BAR Camp, I ran into KragenSitaker who had an idea for a variant on PurpleNumbers called QueerNumbers. Kragen recently blogged the idea (spotted by MatthewOConnor). (JWJ)
In brief, PurpleNumbers 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)
QueerNumbers 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 ThomasPhelps and RobertWilensky's RobustHyperlinks, and it's good stuff. (JWM)
Some additional prior art: DougEngelbart 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 AlonSchwartz 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 DotComs. (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 QueerNumbers in earnest. (JWQ)
/tech/purple | Posted at 11:21pm
