Why are HTML editors in CMSes?
Submitted by David Hobbs on 14 June 2010 - 2:42pm
This may be a sensitive issue to many, especially those that like getting their hands deep into HTML, but should we even have HTML editors in CMSes?
Most users don't care about the HTML details -- they just want to make their content look nice. For instance, my last blog postincluded a table. Since I didn't have a quick and easy way of embedding a nice-looking table, I created a table in InDesign, took a screenshot, and then included that screenshot in the blog post. Yuck. Obviously not a good thing to do, but I didn't want to spend a few hours getting an HTML table looking half-decent. A couple days later the table was still bothering me enough that I did spend an hour or two (using help from Smashing Magazine) to put in a pretty nice-looking table into the blog post. But it was a one-time workaround and I don't have an especially clean way of doing this the next time I need a table. People do these sorts of workarounds in CMSes all the time. When this occurs on a big site, the extra work, inconsistency, quality and frustration multiplies quickly.
Just taking a table as an example, here's the process to creating and using table that would be great:
- User indicates where they'd like to insert their table.
- User creates the table content, giving headings to the table, perhaps merging some cells, adding columns and rows, highlighting some particular cells, and inputting content. Then publish.
- The table then appears on the site with a nice-looking, consistent format -- let's say it has rounded corners.
- User adds a column and row, and the rounded corners still appear.
- Globally the CSS is changed in one place in one file and the highlighted cells are now longer yellow but blue. A similar change could be made for the rounded corners, cell padding, globally dropping Arial for Verdana, etc.
Notice a few key elements in this:
- User doesn't have to know anything about HTML (hiding for instance the fact that the first and last column and first and last row have to be classed differently)
- The table looks nice and will be consistent across the entire site without effort by the user
- Styling changes can be made globally to all tables
When putting together requirements for selecting CMSes, I often hear about the need for the editor to completely control the HTML. But I think this is based on a broken model since most users are just dropping into HTML since the system isn't set up to easliy allow them to do what they need. Another reason this model is broken: it shifts the burden of consistency across content to training / documentation / content publisher when the system could both be providing consistency for the site visitor as well as easier use for the content publisher.
When looking at improving your system or selecting a new CMS, consider how common elements are published and whether deep HTML editing is needed for your content publishers. Obviously this will depend on your industry (for instance newspapers would want very streamlined publishing without HTML control) and how distributed your publishing is (this is more important for a large number of publishers), but make sure to think about the tradeoffs of deep control and ease of publishing.
Bookmark/Search this post with
Get the Transformation Notes newsletter every quarter
Comments
Thank you Jay. Your list of features to give content contributors is useful. And you make a good point about why the view HTML can be helpful.
Do you (or other readers) have any thoughts on the best way to handle the table use case listed above, especially if preview is to work? There seems to be that tension between ease of editing, standardization, more complex elements, and live preview (so pure XML editing would mean good standardization but probably not as good for the other aspects, a limited palette with regular HTML editor will help but only for simple elements).
Thanks,
-- David
David,
In the case of TinyMCE (and likely other RTEs) you can assign a user stylesheet (a special CSS sheet that is only used to style for the RTE) to the RTE that mimics the front end type and design styles of the elements. While this is yet another additional step in implementation, it is worth it for some clients or users. So the case of having a table that has branded/styled display that isn't hosed by the RTE and looks on the back end as it does on the front is a non issue if we as implementors take the time to do it.
I addition, as an implementor, you need to customize the input fields. Pages are often structured and site sections have individual on-page information architecture. It is important that we don't expect users to have to maintain complex information layouts where they have no choice but to refer to a style guide or copy some template. This is another place where limiting decisions of the editor wins. Custom fields that relate to specific content elements, checkboxes and radio buttons for selecting optional page elements such as a sidebar block or comma separated lists of tags.
Giving a content editor the keys to HTML or an RTE that still requires manual formatting is little better than the days of using GoLive or Contribute from a desktop editor to update the site via ftp. Failure to do the above is our failure and any complaint about the client breaking the site (in most cases) should be at our selves for not doing it right.
I'd love to hear your thoughts on the above.
Don't give users choices. Don't leave them every styles or oblige them to learn HTML to manage site content. It is critical that whomever implements the site should tailor it for the content type or the end user.
When I was building sites daily for clients it was important for me to limit the Rich Text Editor toolbar to only those essential items the user will be permitted or need to use.
It typically boils down to the following:
* Format: p, h3-h6 ( I reserve H1 and H2 for page title and subtitles), blockquote
* Strong/bold
* Em/Italic
* Lists (numbered and bulleted)
* Custom CSS classes
* Copy/paste tools (text/Word)
* Occasionally Tables and View HTML
The reason I occasionally leave view HTML in case a user needs to view the source to remove orphaned elements, anchors and etc that all the RTEs eventually will (CKEditor, TinyMCE, WysiwsygPro and etc).
Most of these can limit the toolbar buttons and plugins can extend the buttons available or add additional actions.
The fact that the default toolbar is there is specifically because the implementor didn't customize it, the tool can't be customized or the implementor didn't know it could be done.
In any case this is critical for maintaining corporate standards and in addition making it easier and more approachable for site editors to work with the tools.
Post new comment