I am slowly making up a set of blog posts about the components of content management systems, starting with the earlier one on content repositories. Coming up next will probably be templating systems.
In the beginning the web was editable in the browser. Tim Berners Lee made it so. But this did not last for long. Eventually Microsoft restored this, to some extent, with the
Should you use one at all?
Almost every CMS supports wysywig HTML editing, but it is not entirely clear how much they are used. To be quite blunt, they have always been among the worst editing environments ever devised, overlaid with a poor HTML model and a tendency towards presentational markup. Most users do their editing elsewhere, at least for originating content. I think though that we are at the point where this can be improved.
The first thing is to kill the presentational markup, and instead support customised semantic use of classes. On the basic level this is easy to implement; there is probably more work to easily support more advanced HTML templates, for example to mark up recipes or other specialist content in consistent semantic ways through this type of interface. Pluggable schema guidance might be needed for this.
The second is to make the editors themselves sane. First step is of course local offline HTML5 storage, so that drafts are still there if you wander off, your computer runs out if battery or whatever. Then just make them nicer to use, keyboard friendly and so on.
Then there is the concurrency question, you may want to show concurrent editing, and the versioning model that applies. This does not have to be the Google Wave style simultaneous editng, although that is one option. People may be editing content for release in different versions.
Import from other editors is of course still important, and making it as painless as possible for the common tools is of course important.
Also, remember it is an editor, people like a choice of editors, so loosely couple it, make it standalone and easily changed.
What not to use
Not off to a good start here as the demo does not work in Chrome, works in Opera and Firefox. I guess it is not really in development then. Does not create paragraphs by default, just uses
<br>. Still believes in web safe colours and fonts. A classic example of the old school, but not up to date. Open source.
Much more promising demo, . Paragraphs are real (uses a
for blank ones, which is I suppose ok), there is a paragraph style dropdown that manages paragraphs, headings and divs. The style dropdown is a bit disappointing as it sets styles not classes, and you can still set fonts and so on. Works in Chrome, Firefox and Opera. The old school done right. Open source.
Ah yes, the classic one. Feature set similar to CKEditor, in taht it treats paragraphs the same, has a dropdown with predefined styles, that are style tags not classes. Seems a bit clunky and flaky in comparison, and has odd terminology, since when has a div been a layer? Both have a smiley insertion feature that suggests that people have been wasting time on pointless stuff rather than reconsidering how these programs should work. Open source.
Good blurb about supporting CSS properly and the importance of markup and presentation separation, but in a bout of massive fail there is no demo on the website. Your reviewer has no intention of installing it to test it, especially as it does not support Linux as a platform in a second fail. Commercial.
No demo either, apart from animated screenshots. Why are these commercial companies so full of fail? Web 2.0 products with no web trial? Seems obsessively to be about dimensions and fonts from the features list, not about separation of concerns.
ActiveX DHTML with Java fallback for other platforms. Need I say more? Commercial.
Well at least here the demo is the homepage. All inline with a simple-ish mechanism to mark blocks as editable. Stupidly though, while it appears to be non modal, all the menus are modal popups, which completely destroys the usability.
Very simple editor. Adds divs not paragraphs around everything. Open source.
Largely based on
contentEditable, fixing up the inconsistencies, although Dijit is based on the less flexible
designMode which means it has to run in an iFrame.
Note there is also a YUI 2 version. In many ways the demo is not much use, as of course this is part of the YUI framework and needs some Javscript infrastructure to customise it effectively. There is also a YUI2 version demo, and linked demos of plugins. Much better than anything above. Open source. Iframe based for compatibility with the grade A browsers.
This is the editor that comes with the Dojo widget set. Still iframe based, not a full contentEditable implementation.
Some nice demos available, indeed probably the best demo site of any editor. Aims to fix up the issues and cross browser quirks contentEditable, and looks nice too. Open Source.
Other ways 1: Canvas
A survey of what is up is not complete without mentioning Skywriter, which is a (code) editor written entirely in canvas. As far as I can see this is an utterly pointless approach long run. It is especially a bad idea for HTML, where fitting in with the CSS of the page matters, so lets ignore this.
You can in principle implement the whole of a
Other ways 3: Markdown and Wiki markup
I have to say I use Markdown a lot, this blog is generally written in it. There are two issues I see. One is that it is limited, and while you can add native HTML, this often means everything has to be redone in HTML (trying to add anchors to a list for example). There are extensions with more features, but then you get into compatibility issues. ALso there is no sanely reversible transformation that will generate the sme output as there are notational choices, so it is generally best to keep the content in Markdown all the way through. There are much the same issues with Wiki markup, although it is extensible too, which causes more issues of trying to remember constructs, and compatibility is weakened. The difficulty is that HTML is not a very good markup for humans to write, but once you get past the very restricted domain that say Markdown handles, producing something that works well is hard, maybe impossible.
Other ways 4: Don’t use HTML
A number of people I have worked with, and some content management systems go with a very minimalist use of HTML, pretty much text is paragraphs, everything else is structured fields. A slightly enhanced version of this, effectively a very minimalist tiny markup, corresponding to even less than Markdown is the COPE system.
Personally I believe we need to expand the use of rich text, for many use cases “just the words” is not enough, and we need equations, images, notes, asides, sidebars, tables, captions, and all the richness of rich text, so I don’t think this is viable for much serious writing, and we need to expand from the dumbed down web that this enforces.
While the wysiwyg editor as it has been in content management systems is pretty awful, I think we need to expand the principle and try to do better, go back to the really editable web, and support well structured semantic HTML in rich ways, not forms and simple text boxes. There is a lot to do to get this working though still.