I Have a Huge Problem with WYSIWYG Editors

I’ve yet to see a WYSIWYG implementation that’s in the least bit helpful when considering both the client and the design itself. I’m not talking text editors here, no. I’m talking copy editors in content management systems. I hate to write a rant, but unfortunately this piece is shaping up to be just that.

Again with content management?

I’ve come to the realization that clients and content management systems do not mix. As an example, in a recent RFP (a subject unto itself), the outlined requirements of the provided CMS included the ability to adjust kerning, line-height, typeface, and color of all content on the page.

Going beyond the fact that this request was put together by someone who has absolutely no idea about modern Web design, I’m beginning to see more fluff along these lines. Are we really at such a level where average potential clients are making the leap to such things as kerning and line-height?

The client issue

What it comes down to, I suppose, is the level of client you’re working with. There are clients who just want what they have seen as possible. If there is a feature available and you don’t offer it, your skill is inferior. We’re well aware of scope creep and bloat, but clients do not often respect either.

I’m not knocking the client perspective in the least. I, in fact, truly enjoy doing client work. I feel accomplished when a client is both impressed and pleased with their project once things have been pushed live. It’s a great feeling, knowing you have helped make their project a reality. My company makes a consistent effort, however, to debunk many of the preconceived notions that follow clients through our door. It’s often a strenuous process, but everyone is better off for it.

I’m consistently in a battle with trying to better the overall experience for a client, while keeping a close eye on the direct effect any change will have on the design. I’ve written before on the general abuse of content management systems by clients. I’ve even brought up the trouble with WYSIWYG in CMSs. While both pieces shine a harsh light on client interaction with your designs, I’d like to start focusing on any positives that can come from using a WYSIWYG editor.

Overall effectiveness?

I understand that every CMS under the sun employs a WYSIWYG editor for most copy-areas, but it’s not working. I cannot in good faith discredit all the time and effort that has gone into the leading editors, and I don’t see them going anywhere soon. The trouble, however, is that they’re too easy to break. I can’t count the number of times I’ve had to manually edit a WYSIWYG block because the editor lost track of a strong tag somewhere along the line. Clients will call, furious that the entire page is bold, questioning the value of our entire CMS based on the fact that he pasted directly from Word.

It’s not his fault he used Word, however. Commonality shows that Word is a standard method of formatting text in the business world. To say that he is “not allowed” to use Word because it breaks his website goes back to the age-old issue of Internet Explorer “breaking” the Internet. Designers know it to be true, but to everyone else, the project itself is the failure, not the utility.

The trouble here is the divide between how I view the Web, and how clients view the Web. Not just taking into consideration the quality and semantic value of markup, but the design itself. A client doesn’t realize that a stylesheet has been carefully prepared for his benefit, that center justifying, bolding, and typing in all caps isn’t going to achieve the effect he’s looking for.

Stuck in a rut

I truly wish I had a flawless solution for this issue I can’t seem to leave behind, but I don’t. At the very least, I will make a continuous effort to provide the most streamlined, stripped down WYSIWYG copy editor I possibly can.

One thing I’d like to specifically raise as an issue is that of including imagery in WYSIWYG editors. I haven’t thought too much into it, but I think preventing the addition of images directly in a WYSIWYG field will solve quite a bit of my issue. That is not to say that the inclusion of images will be removed completely, simply delegated to the CMS itself as opposed to the editor. While impressive, the handling of images directly within a WYSIWYG editor has never worked out in my favor. I can’t count the number of times a client has requested that someone “look into the image on the About page, it looks funny.”

While I don’t see the omission of images in WYSIWYG as a plausible solution, it’s something I’d like to work at over the coming months. I’m not sure how, but it will be a goal of mine.