Elements or Lower

Fri, 07 May 2004

Visual editing

Bricolage 1.8.0 has been released, and brings with it support for visual content editing using InteractiveTools’ HTMLArea.

This makes me feel better about using HTMLArea in the CMS I developed for Woking. One of the principle complaints they had with respect to the old, rudimentary, nearly-a-CMS-but-not-quite I had developed for them was that editing text content was too syntax-heavy and onerous.

I’d implemented a system not unlike Markdown. It was different in many ways, and not as elegant, but had the advantage of help from the administration area on the server to clarify things like links. For example, you indicated a link in the text by <wrapping your link text in angle brackets>. The CMS would then ask you to enter the URLs for each item of link text on the next screen. Similarly, {wrapping a phrase in curly brackets} would indicate the presence of an image (with the phrase as alt text) and a subsequent screen would allow you to upload the appropriate images.

The system’s still in use at the NPC site, where they seem to soldier on with it quite happily. But it was plainly inadequate for the Council, who needed to be able to offer more sophisticated markup (tables, imagemaps and so forth) in their pages than the limited structure achievable this way would allow. So, we ended up with a schism where some pages used the Markdown-alike system, and others simply contained fragments of raw HTML. (Unlike Markdown, you couldn’t mix the two.)

When it came time to draw up the specification for the proper CMS, a visual editing environment was therefore a serious priority. A customised version of HTMLArea fit the bill quite nicely.

My cap is doffed to those who work with JavaScript on a regular basis. I found the customisation of HTMLArea a world of pain — not because of any inadequacy in HTMLArea itself, but because I was trying to play it all by ear. It took ages for me to get my head round the Internet Explorer API which allows the live editing of HTML within the browser (in fact, I’m not at all sure I ever really did), and I found the experience of trying to adequately pass contextual information to dialog windows a source of distilled frustration.

Why all the customisation? Well, I wanted to be able to add features unique to the CMS right into the visual editing experience — embedding live content from another source, allowing for timed content (a span or block that is timed to disappear after a given date), a firm distinction between internal links, external links, links that open popup windows and so on.

All of this is stored either as a custom URI scheme that then gets translated on page delivery, or as custom namespace-qualified tags, all wrapped up in an XHTML (Transitional — one thing at a time!) document within the database. (I’d call it the content repository to sound authentic, but really it’s just a big “textcontent” table).

Which led to another problem: HTMLArea and the Internet Explorer API allow the live editing of HTML content, not XHTML or generalised XML content — so the CMS uses a pair of highly specialised XSLT stylesheets to translate between the XHTML + CMS tags content in the database to the vanilla HTML content for the visual editor, and back again, generally using specific stylesheet properties to indicate all the custom stuff that’s going on.

In hindsight, XOpus would have saved me a vast amount of that bother, but it possibly goes too far in the other direction, and the pricing structure is resolutely based on the number of users and the CMS resolutely isn’t. I also feel it would have involved a touch too much of a learning curve for the users of the system. All the background pain and kludgery that the CMS goes through, ultimately, stops the users from having to worry about it.

Incidentally, isn’t Markdown just a stroke of genius as a name for a system like that? I’d settled grudgingly on plaintext formatting. More doffing chez Green.