Dead Ink Vinyl

Brian Riggs shows us how to perform client-side XSL/XSLT in an AIR application. Thanks to Brian for shining light on this, and thanks to Mike Chambers for sharing the link on Twitter today. Brian’s post is from May, so many of you may have already seen it.

The solution Brian outlines requires JavaScript because the only XSL toolkit AIR provides is inside of the WebKit HTML rendering engine. Consequently, AIR developers working with the Flash or Flex APIs will need to use an ActionScript-JavaScript bridge. Brian provides a nice code snippet showing how to create that bridge. Great, but still a kludge.

Unfortunately, XSL doesn’t seem to have made it into the Gumbo API for the next version of Flex and AIR. There is also no mention of XSL in Mike Chambers’ September post about AIR 1.5. I have not had an opportunity to pull down a recent nightly build of the Flex trunk to verify that the ActionScript API for AIR continues to lack XSL support, but all indications are that XSL is not present.

A little bit of Googling indicates that I am not alone in desiring XSL capabilities in AIR that do not require a bridge to JavaScript. I know that XSL is not like the hot stuff that Adobe like to tout in its products (OLAP only made it in because of its use in visualization), but it’s a real asset for enterprise developers.

I suspect that Adobe’s plan may be to leave out XSL—and a lot of other large-but-niche APIs—and let teams needing those capabilities include them with FlaCC, the upcoming C/C++ to Flash byte code compiler. (More info about FlaCC, including links to slides and a hi-res presentation video is available here). Specifically, for XSL, Xalan and Xerces could be imported. In truth, I find this to be an attractive solution, in part because I’m sure someone else will go through the hassle of compiling the popular C/C++ libraries to SWCs for me—I will only need drop those into my project.

However, if you are an AIR developer who cannot wait for FlaCC or want to see XSL make it into AIR’s officialy ActionScript API, consider submitting an enhancement request.

It seems to me that thinking about the problem as “indexing Flash” is to approach the matter backward. We want the data to be indexed—the presentation is irrelevant. Take this blog as an example. It’s database-driven and generates documents with my content—these words you’re reading now—wrapped inside of some HTML garnish to make the reading experience pleasant. If you’re reading this in a feed reader, then the content is wrapped in Atom or RSS garnish. Do I care what garnish surrounds my content? Not particularly.

The same principle holds true for other Web applications, whether the garnish is Ajax, Flash, Flex, Silverlight, or—like this blog—good old fashioned dynamically generated HTML. It is the data that must be indexed, the presentation around that data is (conceptually) irrelevant for SEO purposes. I think the matter may be confused because for so long the data and the presentation were bundled together in HTML (like this blog). Now with Ajax and Flash/Flex, we are back to separating the user interface from the data. However, when the data isn’t part of the user interface document sent by the server, it’s harder for search engines to access and index.

So what’s the solution? Expose the data for indexing and detect when incoming links should launch the Flash/Flex app instead of responding with the raw information. Naturally, the Flash/Flex app would be launched to deep-linked directly to the relevant content. If you’re not sure how to make the data indexable, I’ll tell you that I take my guidance from RESTful Web Services. The magic in this solution is detecting when an incoming link should launch a deep-linked Flex application and when it should render the raw data. For the moment, I’ll punt on detailing an implementation—consider it to be an exercise for the reader.

An exercise for the reader that can lead to rich rewards! Ryan Stewart has announced the Flex SEO Contest to encourage the community to establish best practices for Flash/Flex indexing. The rules are straightforward and the top prize is CS4 Master Collection. I like the challenge and may try my hand creating an entry that meets the contest criteria just for the experience of it.

On the eve of Amazon’s announcement that was entering the ebook reader market with its Kindle device, I wrote an overly long article examining the reasons why I felt the concept of reading books on an ebook reader wouldn’t gain broad acceptance. During that discussion, I made the assumption that most digital books are either little more than raw text and images (I’m including HTML here) or were PDFs of the print edition.

The “raw text and images” approach is fine for shorter content—blogs, newspaper articles, and the like—but I’ve found that for longer content, real attention to typography and page layout is needed to make the experience enjoyable for me. (This is also why the current implementation of O’Reilly’s Safari service doesn’t work for me.) However, it never occurred to me that PDFs could be made specially for the ebook reader screen—complete with appropriately sized text and all of the traditional design touches normally reserved for print. Now I’ve learned that Rosenfeld Media’s PDF edition of Indi Young’s book Mental Models is designed to be read on the 4×6 screen found on many popular ebook readers. From the screenshot provided in Jorge Arango’s article, I have to admit: that looks like an ebook I would be happy to curl up with for hours.

In hindsight, it’s really obvious that publishers could design PDF ebooks specifically for consumption on ebook readers. In fact, it’s so obvious that I believe PDF books designed primarily for viewing on an ebook reader is the future of digital publishing¹. It certainly is a prerequisite for me to embrace reading books on a digital device.

¹ The technical implementation doesn’t have to be PDF. Any format that tightly defines the typography and layout of pages will work.