Symphonious

James Robertson mentions the importance of a good authoring environment in CMS solutions.

Considering that the primary purpose of a web content management system is to help staff to write and publish content, the editor has to be front-and-foremost when it comes to selecting a product. And yet, many organisations specify little more than "the CMS must provide a web-based WYSIWYG editor".

I also found Seth Gottlieb's comments on the subject interesting, particularly:

Recently, a client was having his first look at the WCM system that we were implementing [...] To him, the WYSIWYG editor was the CMS.

It's amazing how many users see things this way purely because even when they really do need the full functionality of the CMS, users still use the editor more than 90% of the time. If you're developing a CMS, the quality of the editor should be among your most important considerations because it's what you'll be judged on.

Coming back to James Robertson, I agree with most of his comments but one of the requirements struck me as a really bad idea:

• Ability to specify what window links appear in, including whether they are displayed in a new window, the size of the window, browser controls, etc. Ideally, this should be point-and-click for authors.

This may seem like a nice feature to have, and most editors provide a simple way to set the target of links, but it actually encourages users to make pages that aren't accessible. In particular WCAG Priority 2 includes the requirement that:

10.1 Until user agents allow users to turn off spawned windows, do not cause pop-ups or other windows to appear and do not change the current window without informing the user. [Priority 2]

Granted, it's exceptionally common1 for this rule to be broken, but including it as a core, default requirement when looking at WYSIWYG editors seems a little off. If the client already has a site that breaks this accessibility guideline then they problem need such a feature, otherwise you should probably be steering them away from it and configuring the editor to help users create accessible content as much as possible.

Other than that, it's a pretty good list of basic requirements for a WYSIWYG editor. I've commented before on some key things to look at when evaluating WYSIWYG editors that comes at it from a slightly more technical side. Combine the two and you have a good system out of the box that can be customized and extended to provide the best possible editing experience for users.

1 - and exceptionally annoying↩

This weekend I switched from DSpam back to SpamAssassin because of DSpams high false positive rate and my dislike of having to review all the spam it caught constantly. While doing so, it occurred to me that the way I’ve set up my anti-spam solutions is really pretty cool. I’ve essentially set up a partially self-training system with a user-friendly interface for providing feedback via Mail’s Junk mail button.

SpamAssassin is set up to run via procmail and dump any spam into the folder that Mail.app uses for its Junk mail. Mail.app is also set to move any spam it detects into that folder so there’s a two layer spam filter in place to move everything into that one folder for review.

The partial self training comes in by running sa-learn in a cron job to teach spam assassin that everything in that folder is spam. Any spam that SpamAssassin put there is ignored, but anything it missed and Mail.app detected is automatically used to train SpamAssassin. False positives are handled by manually fishing them out and running sa-learn –ham on my inbox to teach SpamAssassin that anything I’ve pulled out isn’t spam. Fortunately, Mail.app automatically moves messages back to the inbox when you click the “Not Junk” button.

The nicest part of it is that by having a two layer spam filter, I can switch one of them (in this case DSPAM to SpamAssassin) without being deluged by spam, because one of the filters is still well trained.

It’s all kind of neat really.