How to Retain Site Quality After Delivery

Published 6 years 8 months ago on August 13, 2007 — 5 min read

Content management systems have done a great deal to change the way many websites are created and maintained. Quality content management systems are elegant in the way they organize and control a website, while sub-par installations often create mountains of extra work while degrading user experience.

Destroying aesthetics with each update

Personally, I think content management systems are an extremely effective way to increase functionality and organization of websites large and small. They come in extremely handy when providing a website as a product for a client, allowing updates to be made at any time without the assistance of the site developer. While all intentions can be positive, sometimes a gorgeous product can be all but destroyed upon delivery when it comes to creating or modifying site content. With each update, a well thought out design can be further altered from original intention, reflecting poorly on the site aesthetics. There are a number of ways for clients to make updates in various CMSs, but which is best?

WYSIWYG

First and foremost is WYSIWYG content editing. This option, to me, seems most appropriate for people who have no experience with (X)HTML and are looking for the easiest way to make updates to their content. It is probably the most attractive option for clients as it bridges a gap between the copy they’re editing on the back end and the copy displayed on the front end.

I’ve got a bit of a personal gripe with WYSIWYG editing, not only when it comes to any particular CMS, but in general as well (when it comes to the Web). While there are benefits to this form of editing, they all lay with the particular user actually making the edits to the content.

Most of the time, the markup which results from WYSIWYG editing is far from semantic, and often gives the editor far too much control over how various elements appear. All of a sudden, copy can be filled with long strings of bold, underlined, and italicized text simply because the icons are there to click. Awkward font colors and sizes are suddenly used throughout the website, and greatly degrade the overall look and feel the original design worked to establish. What is the best way to handle something like this?

Markdown & Textile

Plain text and readable editing systems have become a very popular way to give the ability to edit content while attempting to retain a semantic and valid document structure. While the resulting interaction is (more or less) easy to read and decipher, it still requires a bit of a learning curve to undertake. There is a certain breed of client that would be willing to put forth the effort to learn a tool such as Markdown or Textile in order to manage the content of their website. To be completely honest, I would have to say the majority of clients I’ve directly worked with would greatly prefer a WYSIWYG editor. As a developer, however, I’d definitely prefer a plain text editing system simply because of the comfort in knowing the resulting markup will be valid and (mostly) conform to the styles established in the site design.

BBCode

Another system implemented in some of the wide range of CMSs is that of BBCode, a markup language originally established for use in forums. BBCode shares a bit of raw (X)HTML and Markdown/Textile in that plain language is used, but proper tags must be maintained in order to obtain your intended results. While this form of editing has more-or-less stuck to forum installations, it’s another method to consider.

WYSIWYM

There are many ways to implement a system of editing in a CMS, each with their pros and cons. By far, the most attractive solution I’ve come across to date is WYSIWYM editing. The idea is a healthy blend between WYSIWYG to help make ‘the sale’ to the client, while including the importance of each element used. Styles can be directly applied in order to assist the editor visualize how published copy will appear, but proper attention is also given toward the markup involved.

At first glance, this system seems to seek the happy medium between client and developer approval. While the idea is fairly young (to me at least), and the flagship editor, WYMeditor is still in it’s infancy, I think this direction could bring some extremely positive results.

Conclusion

Content management systems try to cut the middle man out of site maintenance for site owners, but is it acceptable to completely stray from the way things work? Is hiding the markup that makes the Web work the right thing to do? Something about that doesn’t sit well with me completely. Playing devil’s advocate, does HTML belong only in the hands of developers? I think this is a bit of a gray area, but I’d love to hear what many of you think.

All in all my personal favorite of this bunch is WYSIWYM editing. Having the benefits of a visual depiction as well as maintaining semantic value seem like the ideal situation to me. The trouble we face is the fact that our clients can not be expected to understand (or care about) the semantic Web, accessibility, or the intention behind our designs. Which system of editing does your CMS of choice employ? Have you had past projects lose aesthetic appeal as a result of giving editors too much freedom with editing? What do you feel is the most effective system of editing, both for the client as well as the semantic, accessible Web?

There's a conversation brewing

  1. I regard working with wysiwyg editors as a necessary evil, but with extensive customization of the editor, something resebling compliant xhtml can be attained. The key is to keep the available options for the end user at a minimum, and if possible, enable stripping of superfluous tags.

    I like to limit tag usage to strong, links, a couple of header elements and ul’s. Let CSS take care of the styling (as God intended). If the user is likely to need tables, you can enable them as well.

    Images get a class assigned (I like to make a left, right and centered option for my users), and you’re done.

    It’s all about limiting the users options to what he/she actually needs.

    If all else fails, “wash” the code serverside.

    I’ve also noticed that end users love to paste copy from word, retaining font tags, bold, italics and other such ugliness. There is usually a “paste from word”-function, so remember to instruct your end users to, uhm, use it.

  2. I think WYSIWYM can be the best choice for it.

    I’ll try WYMeditor to know more about it :)

  3. In my experience, it doesn’t seem to matter how simple and elegant of a CMS you give the client, the content will always suffer once you hand over the reigns.

  4. @sensei: Indeed, I do try to limit the extent to which a client can modify content that will appear on the front end. Copying and pasting with Word is one of those things that seems to be a never-ending battle with our current CMS — we’re constantly trying to refine our cleaning algorithm to take care of everything, but even when invalid markup is stripped, the copy still looks awful.

    @Carlos Eduardo: Indeed, it will be a good project to keep an eye on.

    @beth: I can absolutely agree — is it something that should be accepted as ‘the way it is’? Or do you feel a more aggressive approach should be taken on the part of the developer?

  5. Honestly, this is the first I’ve heard of WYSIWYM and I absolutely love it!

    Since I joined the Graphics.net team, I’ve seen some stellar sites go down the drain with days of handing them off to the client. To the point where I would be embarrassed to see them in our portfolio. Most of the problems we’ve been having are outlined above, in your article or other comments. Pasting from Word is a big one as all sorts of nastiness tags along with the copy.

    I’ve been meaning to look into customizing the default WordPress WYSIWYG editor for some time now. Mostly to add elements like headings, but I see WYSIWYM has them out of the box. Very nice. Now to see what’s involved in integrating it with WordPress.

By all means, contribute

Leave a comment

Powered by Fusion

This article is so meta

Published August 13th, 2007

Random article

css.php