Sunday, July 01, 2007

Functional Animation, revisited

Since my blog post on Functional Animation, there's been some movement towards the idea of setting DOM nodes to equal functions of other (potentially varying) nodes.

In fact, this idea already exists in XSL - see the code below, where the second paragraph is set to contain the same text as the first paragraph.


<?xml version="1.0" encoding="ISO-8859-1"?>
<html xmlns="http://www.w3.org/1999/xhtml/" 
  xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
<body>
<p id="p1">p1 content</p>
<p id="p2" title="{//p[@id='p1']}">
          <xsl:value-of select="//p[@id='p1']"/>
</p>
<a href="javascript:document.getElementById('p1').textContent 
  = 'test'">Test</a>
</body>
</html>

When you click on the "Test" link, the value of p1 is changed - and p2 should automatically update too (both its content and its title attribute).

Unfortunately, p2 doesn't update - it seems that browser makers don't automatically re-execute XSL stylesheets. Interestingly, CSS stylesheets do re-execute when you add or change nodes, and there's no mention of what should happen in the XSL spec. I don't see why browser makers couldn't extend their code.

An idea whose time has come

This idea of Functional Animation is so useful and intuitive - probably replacing most awkward DOM Events code - that it's a real shame there aren't any widescale implementations.

Having said that, I recently saw the idea cropping up in several places:

Personally, I like the XSL approach with inline XPath, because it's much more natural at selectors. On the other hand, some might prefer javascript due to its familiarity and extra features (e.g. Math and String functions).

Either way, it's clearly an idea whose time has come!

REST, Ajax, and personalization

I didn't realise it until recently, but if you follow REST principles, then you're pretty much forced towards Ajax - the two come together. That's due to page personalization.

When I navigate to www.amazon.com, several parts of the page are personalized. It says "Hello, Chris Jay" at the top, and offers recommendations for me, presumably based on purchases I've made in the past.

Although it's a very nice touch, this bothers me. At first glance, following REST, shouldn't the URL www.amazon.com be the same for everyone? Otherwise it can't be cached!

Option 1: Separate URLs for everyone

One option would be to redirect me immediately to something like www.amazon.com/ChrisJay/, containing my personalized homepage. This would require permissions, as set by the cookie - otherwise, other people could access this URL too. But that also holds for the current Amazon site.

There are several benefits to this approach. Amazon and my ISP can now both cache my homepage, so when I access it again, I see it much more quickly. And it's obvious from the URL that the page is personalized.

Unfortunately, following this option, the main body of the page - the bit that's not personalized - is not cached separately. It has to be produced again for every user.

Option 2: Same URLs for everyone, use Ajax

Another approach would be to keep using www.amazon.com for everyone, but include some Ajax that scans the HTTP header, reads the current user id, uses it to GET another REST URL (e.g. /recommendations/ChrisJay), and displays it inline.

That way, the homepage can be cached for anyone (including the Ajax code), the personalized bits can also be cached separately, and the REST architecture is still followed.

For this reason, Option 2 is the better approach.

Designing your URLs

The first step to building REST sites is to select your URLs.

You might think the rule is "one URL for every page". But that's not necessarily true, as Option 2 shows, especially if you're offering personalized sections to a page.

A better rule would be "one URL for every page and for every personalized section".

Then you can use Ajax to tie the two up.

Friday, June 29, 2007

Content Management

Content Management is one the most important categories of software. Two years ago, Microsoft Office was the inevitable choice, with various hosting applications like Sharepoint for the enterprise. But there's been a huge amount of change in the last two years - from OpenOffice to Google Spreadsheets to Youtube.

It's now (just) possible to see what Content Management will be like in future - and it's already clear that no one is near yet.

About Content Management

The first question is, what is content?
  • text (e.g. HTML, doc or xls)
  • raster images (e.g. JPG, PNG)
  • vector images (e.g. SVG)
  • audio (e.g. mp3)
  • video (e.g. mpeg)
  • structured data (e.g. various XML)

The last category is really a miscellaneous bucket, which I don't expect to contain much except for niche applications. Raw XML is great for data crunching and back-end configurations, but I don't see it being used much for content - we have more specific languages (like HTML and SVG) for that.

The second question is, what is management?

  • CRUD (create, read, update, delete)
  • publishing
  • collaboration (CRUD permissions, discussion tools)
  • versioning & audit trail
  • syndication (subscribing to feed)
  • search
  • storage (includes records management)

Web Office Suites

If you look through this list, Microsoft Office only really handles the first option. Sharepoint handles most of the rest, but that's only used in the enterprise - what about other people?

That's why you can't rule out web office suites like Google Apps - they may be very basic at CRUD, but they can be excellent at management functions 2 through 7 - and how many people really want complicated document formatting options anyway?

The most interesting content management technology is, of course, the Wiki. Wikis naturally cater for all seven management functions above. The only problem is, traditionally Wikis have been restricted to plain text and totally open permissions, but there's no reason why that couldn't change.

For example, JotSpot was (until being acquired by Google) selling a Wiki for corporate use that included HTML calendars and spreadsheets as editable pages. And I don't see why you couldn't edit other media collaboratively using a Wiki - especially vector graphics.

Ideas for a Web Office

Google has been suprisingly quiet about the future of JotSpot since acquiring it. If I'm right, their strategy will be to convert Google Apps into a Wiki suite that covers all types of content (1-6 above), and all types of management (1-7 above).

For example, Youtube could become a Wiki, including video editing capability (with permissions settings). Picasa will become a Wiki-based competitor to Photoshop. They could be packaged up with general Wiki website editing functionality, and sold to corporates (or made available to consumers, supported by ads).

To compete, Microsoft will have to cannibalize their existing Office suite, including Sharepoint. I'm still not sure they're ready for this yet.

In summary

The future of content management is Wikis, allowing management of all types of content: web pages, photos, vector diagrams and videos. It'll be based in the browser, using standard web technology like HTML, CSS, javascript and SVG. There'll be a lot more emphasis on collaboration, syndication, and search. And now the future is clear, there will be a race to achieve it - and Google has the head start.