CMS Grafitti Can Be Reduced
Over the last few years I’ve done a lot of tedious QA (Quality Assurance) which involves poring over front end markup (developer code) and through content written by untrained authors (Corporate Grafitti artists) in any given CMS (Content Management System). In some ways I don’t mind being the one who does QA because I’m a meticulous bastard with no quarter given to the repetitive slugs and slights actioned by less than perfect humans against the W3C specifications. There’s something geekily satisfying about bringing order to the chaos that reminds me of doing crossword puzzles. QA is a simple process of finding and fixing stuff page by page and line by line.
The Developers
The first problem area of QA - the developers themselves - can always be improved over time. Every project teaches new tricks and techniques so by the time you’re doing QA its probably quite an old site, or a migration over to a new CMS. I’d recommend you note and advise as unobtrusively as possible - from a huddled corner behind the water cooler - that there might be more effective ways to skin that cat. Semantics, for example, seems to be a curve rather than a binary step. I’ve learned the hard way over time to appreciate and acknowledge the good factors as well - so don’t just say the code is shit and storm out of the room.
The Corporate Grafitti Artists
The second problem area of QA - the Corporate Grafitti artists - is another kettle of fish entirely. On larger sites authors vary between sections and pages and also within pages themselves as new managers are moved around. This is the area where you run across links with underline tags around them, or the consistent bolding of paragraph text instead of semantic use of headings. These users make their own dot-point unordered lists using break tags and writing stars at the beginning of each line. They use super and subscript at will and insert an entire armful of inline CSS styles for every single image they insert.
The Cure for Corporate Graffiti
The cure for Corporate Grafitti takes a bit more courage than for dealing with trained developers. How about we just deny them the ability to achieve most of these things from their CMS editor? I mean, why are we giving the general untrained manager the ability to do underlines, to apply inline-styles on an image-by-image basis, or to do anything more than the basic functionality that we require? Why aren’t we heavily greying out a lot of that user control? A lot of what QA has to do can be avoided if we develop the text editor interfaces around the limited interactions we want to empower the user with in the real world project. Seriously, if we’re dumb enough to provide the ability to add colours to headings, we’ll see purple and green H1’s on the site within the week! Humans do that stuff. Design is subjective. Garish, to some people, is just lovely.
Provide a Simplified Interface
How about providing the corporate manager with a simple interface that allows them to insert headings, paragraphs, unordered lists, ordered lists and definition lists (all pre-styled by default). Then we add emphasis and strong tags, blockquote and cite tags, and facilities to insert links (with optional title) and images (with compulsory alternate text and optional titles). These managers shouldn’t be inserting decorative images so alt=” ” shouldn’t make it onto their radar. If it’s a content image it requires alternate text.
Take Away their Power and Accept Responsibility
What we take away from them is any ability to insert colour, or inline styles (margin, padding, bold, font-family, etcetera), deprecated or unwanted elements (font tags and underlines come to mind). We strip them of the right to do things like insert tables - we don’t want that behaviour so why are we handing that programmed feature onto them in the first place? Taking ownership of the problem on our end is a key part of the cure.
The Next Step is Education
The next step involves education. With the right internal training you can at least get some ideas over to management about correctly writing for the web - like not using “Click Here” on links. Its not that hard to instill the basic concepts of writing unordered lists and explaining how to use heading structures correctly. This needs to be in simple, short training rather than a full day or three getting pummelled by the HTML Police! Relax. I’d like to think you can get a more effective short-burst message across with a quality coffee and a packet of biscuits than having them endure a 2 hour PowerPoint presentation.
The Very Next Step is Acknowledgement
This might be naive of me but how about, after educating managers, we acknowledge and reward managers who are good authors in the live CMS? By rewarding we’re therefore asserting at ground level the skills required are valuable enough that others should emulate them. We’ll call them CMS heroes. So our organisation, through its CMS heroes, promotes quality content. We could even limit CMS authoring to selective trained managers within the organisation instead of allowing free-for-all access based on page ownership or departmental responsibility. As a silly example, just because I became line manager of the catering department wouldn’t necessarily make me the best cook, right?
Conclusion
Doing QA roles generally means you’re on the bottom of the heap. So this is a shout to the top. This is a statement of fact that we’re as much a part of the problem of bad web authoring as the untrained manager who can’t figure out proper heading structure. We need to empower that manager with the knowledge of what to do and, just as important, why its necessary to do it that way. We also need to develop for their proposed interactions instead of throwing every option onto a text editor available for future abuse. We could even consider adding programmatic solutions to assist them - for example, we could make heading options contextual on where in the standard document they are currently editing. Why the hell are we providing options which aren’t contextually applicable? In the same vein, if they require a specially styled class in the CSS we need to provide them with a single purpose button in the text editor and that’s the final word. We need to be engaged on our end to prevent CMS grafitti.
None of this will eliminate the QA problem. Just like we’ll always have idiot drivers or noisy teenagers in movie theatres. But we can at least solve part of the problem if we stop ignoring it exists.
