Agile Ajax

Radiant CMS: Some tradeoffs, but they're worth it

We're continuing to iterate on our redesign of the Pathfinder website using Radiant CMS, which I posted about last month. Now that we actually have IA and design artifacts and content for the new site, I'm getting more intimately acquainted with this Rails-based CMS tool. Our main objective with Radiant is to allow business users to create content in Textile without dirtying their hands in markup. I think Radiant will do the trick, but it takes some work to set it up.

Like a lot of UI engineers, I'm used to building systems that separate content from rendering. Usually, though, I've had a commercial-grade templating system at my disposal to help build and enforce this separation. I've used Tiles, Struts and various roll-your-own frameworks in the past with great success. Unlike those tools, however, Radiant is designed primarily for simplicity, not flexibility. As with Rails itself, Radiant encourages you to take the "happy path" and do things its way. Instead of fine-grained, n-depth templating, you get layouts, pages and snippets:

• A layout is a page-level template.
• A page is a bunch of content plugged into a Layout.
• A snippet is an include that can be plugged into either a layout, a page or another snippet.

What's missing? A module- or snippet-level layout. This makes it difficult to abstract away the presentational aspects of a recurring content block. Let's say, for example, that your layout has a sidebar with an arbitrary number of content blocks within it. CSS considerations demand that you apply a markup wrapper to each one of those content blocks, like so:

Radiant CMS: It's all about the extensions

As we prepare to overhaul Pathfinder's corporate website, my colleague Dietrich and I have been giving Radiant CMS a spin. An open-source, Rails-based content-management system, Radiant offers up the slogan "content management simplified." Although Dietrich has been doing most of the heavy lifting, thus far Radiant seems to live up to its tagline.

More Killer App - OpenRecord, a Wiki/Spreadsheet

I've been promoting the idea of the collaborative spreadsheet as the killer app for AJAX for a while now. First there was WikiCalc, then Google spreadsheet. The folks over at the Dojo Foundation -- yes, the Dojo Toolkit folks -- have been working on a Wiki app that fits into this category as well. From their about page:

The goal of the project is to create an open source software product. The product we're making is a wiki engine, but where most wiki engines are geared toward pages of text, OpenRecord is geared toward loosely-structured database content.

It's still in an early development stage, but you can take a peek at some prototypes here. Click around to the various pages and try adding and editing cells and rows.

Speaking from experience, these types of applications will need professional support if they are to make a dent in the corporate world. Look for the document and knowledge management folks (OpenText, EMC/Documentum, etc.) to start introducing these "Office Lite" functions in their products.

CMS and AJAX

Back in April, CMS Watch published an article entitled Ajax and Your CMS. The article looks at the impact of AJAX on CMS systems from both the content author's and the site visitors perspective. From the author's perspective, the news is all good and pretty conventional as far as AJAX articles go: fewer click, drag-and-drop, faster, more powerful UI. There are a few noteworthy points to the article, however. For one, content management with AJAX enabled, single-page sites puts a premium on managing assets:

If you are going to use a heavily-Ajax-driven interface on your websites, then it is worth considering a CMS to manage intra-page snippets and interaction as discrete elements. In practice it could be difficult to manage a rich, interactive site that uses single page interfaces without a CMS, since at this point you are managing content components rather than entire "pages." The whole notion of "pages" tends to dissipate, which would call for a more component-oriented -- rather than page-oriented -- CMS for those looking to manage Ajax-driven websites.

So, if you're publishing content rather than constructing an application, then composing a bunch of widgets together using a CMS sounds plausible. However,

Web CMS tools are notoriously poor at managing stylesheet elements and client-side scripting in particular. The rise of Ajax should prompt some improvements here.

Improve or die, I guess.

The few bad patches for the content author are things that people are already working on: back button, refresh/reload an state, etc. Previewing content from a single page interface is a problem not just restricted to CMS's. You can identify the "states" within the single page interface and preview those, i.e. "show me the state after a restaurant has been picked."

That's It?

The fact that CMS Watch really struggled to find much more to say about AJAX than "will make it easier to use, may make content harder to manage," I think points out that nobody really has a clue about how to effectively use AJAX for content sites. All of the major AJAX enabled sites these days seem to be collaborative filtering excercises like digg and dzone. There must be better ways than this to apply this nifty technology.

I think we can come up with a few ideas. What are some of the content display issues we can tackle with AJAX? Let me give three off the top of my head:

• Screen real estate - we can summarize an article and expand the full test into a new reading context when the user navigates to it. I have a primitive little example here. Just click on one of the text boxes to read the full article in place.
• Breadcrumbs on steroids - this is more about providing a better reading metaphor. We can make the sections of the paper fold and unfold, allow the reader to rapidly navigate through tabs or trees. No more slow postback means we can try more stuff.
• Contextual control - the WSJ already has the capability to right click on a selected word and perform a search. But contextual search, navigation, and other operations are the next step. Imagine an online newspaper where a reader can right click in an article about their neighborhood and get restaurant review listings for nearby establishments. You no longer have to cram every single relevant thing into the sidebars!

The day is still young on CMS and AJAX. Think outside the box and share your own thoughts on what AJAX can do for CMS.