There’s been a bit of discussion recently about the central role of the WYSIWYG editor in a CMS solution.

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”.

Now, we’ve been working with a lot of organisations to help them select a CMS, and we have a uniquely narrative approach which means that the requirements document will be less than 20 pages in length, and completed in 2 days (or less).

If it helps, this is what we commonly put for the authoring environment requirements (with variations for each client, of course!):

Authoring environment

The WYSIWYG authoring environment will be used by non-technical business users. The simplicity and ease of use of the authoring environment is therefore a key consideration.

Specific CMS requirements:

• Support for heading levels and other paragraph styles, with the published presentation applied through the use of CSS.
• Locking down the formatting controls available to authors, with the expectation that general users will be only able to specify bold, italic, links, etc (and not font, colour, and the like). This should be configurable on a user-by-user basis.
• There should be strong support for tables in the authoring environment, including resizing columns, row and column spanning, and overall table formatting.
• Much of the content will be cut-and-pasted from Word. The CMS must therefore strip out the formatting and hidden codes introduced by Word, to ensure the HTML is valid and accessible. Formatting should automatically be reworked to match standard website styles, including paragraph formats.
• Lists and bullets in the source Word document should be mapped across to standard HTML list tags.
• Tables should not be deleted as part of the Word clean-up, and the tables should be automatically reworked into clean standards-compliant table markup.
• Special characters and symbols (such as accents, trademarks, etc) in the source Word document should be mapped across to HTML entities, wherever possible.
• The CMS should be designed so that cleaning of content is done automatically, without requiring the author to take additional steps. This should happen both when content is cut-and-pasted from Word, and when the page is saved.
• 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.
• Ensuring that the text editing area is sufficiently large to allow authors to write content without requiring excessive scrolling.
• Users should not be required to have HTML knowledge when writing content. For general authors, access to any ‘view as HTML’ mode should be restricted.
• Support for spell-checking, including user-customised dictionaries.
• Ability to preview the content in context, with the correct layout and design. This includes being able to test links from the previewed pages by clicking on them.

Sadly, almost half of the individual items are devoted to ensuring that the Word rubbish is correctly removed when cutting-and-pasting. Sigh. If only Word actually created sensible HTML…