Your WYSIWYG Editor sucks

Recently I spoke at the Highland Fling Conference in Edinburgh and, as part of my presentation on Choosing the right Content Management System, I had a bit of a rant about the use of WYSIWYG editors in Content Management Systems. I think these things are responsible for not only a lot of badly formatted content, but also for holding back the development of better ways of allowing non-technical users to deliver content.

WYSIWYG Editors suck because firstly, they are a flawed premise. What You See Is What You Get WHERE exactly? On a regular desktop browser, on your iPad, phone, in RSS, read out by a speaking browser? In most CMS implementations, you don’t see what you get on the web anyway, what you see is a textarea replaced by a box with a bunch of buttons at the top and you can see what your changes will look like in the context of that box – not on the site you are managing.

WYSIWYG Editors suck because they promote thinking about style rather than content. While content editors are busy changing headings to Comic Sans, pondering the use of a grimacing smiley on their about us page or getting creative with colour, they are not considering the actual copy they are adding to the site.

WYSIWYG Editors suck because as a designer you lose control over big chunks of the design. Anywhere that allows people to enter HTML via an editor allows them to get as creative as they like, using any mark-up that they like. Unless you carefully go through and remove all the creativity that stuff is going to stay there. For developers, even if you switch off most of the buttons, just allowing the administrator to enter simple formatting and links, you still have a situation where a user is entering HTML which you then display on the website. This can enable all kinds of stuff to get into your content, which is then very hard to remove and fundamentally tied to the current design of the site.

For a content administrator a WYSIWYG editor is actually a very poor way for them to add content to the website. They end up with a big area and need to work our what to add in order for the content to be formatted as the designer intended. Consider adding an event to a page listing events for example, the designer may have created rules in the CSS to make the title, description and date display a certain way – but only if the correct mark-up and classes are added. It is hard to get the average content editor to use the correct heading level – never mind use microformats to enter an event or contact information!

So they suck. What’s the alternative?

I think the alternative comes in two forms. Firstly, a lot of content that we are asking people to edit is not freeform, it has structure, semantic meaning. We need to provide a way to enable people to enter content in a way that maintains the meaning. This is something we’ve been doing with custom CMS builds for a long time over at edgeofmyseat.com and is really the core concept in Perch – our small CMS product. In Perch if I want the editor to add some contact details, I create a template with those details marked up using microformats.

A Perch template for a contact

In the admin this template turns into a form, the content editor just needs to fill in the form with the right details. She doesn’t need to worry about adding any style – the designer will worry about that and because the data is marked up correctly it is going to be very easy to use CSS to make it look exactly as we want.

The content entry form in Perch

We can use this approach to create templates for anything – a block with a chunk of descriptive text and an image, an event, a product listing and so on. The content editor just completes the form. As I have written before I think it is important that our systems make the job of writing good copy easy for the often non-professional content writer. By presenting her with a form – we can also add help text to remind her of the style and tone that the content strategy requires. This approach of using structured content removes much of the requirement for formatting tools in the CMS.

However there are valid reasons why editors need to do some formatting. This really comes down to adding links, setting text as strong or emphasised, and perhaps adding inline images or file downloads. Without WYSIWYG how do they do this? Even if we were to teach the editor HTML, as previously discussed, we don’t want HTML ending up in the database to be rendered straight out onto the site.

A new kind of editor

We need a new kind of content editing tool. In Perch the default editor we use is MarkItUp with Textile formatting enabled. Textile is pretty simple to learn and MarkItUP means that users can select a bit of text and hit the bold button which will then wrap it correctly so when the form is submitted Perch transforms it into HTML strong elements.

The administrator has access to just a few simple tools for adding formatting, and the formatting is related to the content and not the design of the site. If it is correct for content to be emphasised that should remain the same after a redesign or if the content is used elsewhere other than on the site.

When the form is submitted we have the data the user entered in Textile format, which we then run through a Textile class to convert it to HTML, stripping out any extraneous HTML elements first. That is the version we render to the site – we know exactly what is in that data because we converted it. We also store the Textile version – this will be presented back to the user at edit time.

This works fine for basic formatting and links, however we do see people using a WYSIWYG editor plugin in Perch – despite taking advantage of structured content – and this is mainly down to the following reasons.

“My client doesn’t want to see the codes” – the client has complained (or the designer assumes they will) about seeing Textile code rather than rendered output in the editor.

“My client wants to be able to embed images/files anywhere in the page” – rather than adding an image to a predefined slot they want to be able to insert these anywhere.

The first I feel is often a non-issue if dealt with from the outset by the designer. We’ve used Textile formatting for several years in large-scale CMS projects and once the benefits of not using HTML directly have been explained we have only ever had one client who insisted on “WYSIWYG” (and it came back to bite them). Once you are using structured content extensively the number of formatting “codes” are few in any textarea. However seeing Textile or Markdown in the content is something new for the client to encounter so lets keep this as a possible objection for now.

The second issue makes the first more relevant. If you have a news story for example that you want to drop images in throughout the copy, you don’t have a structured content area of one image plus copy – you have several. In this situation the most elegant thing to do would be to allow the user to insert any number of images via the editor, and those images be constrained by something set by the designer (so that the user doesn’t upload an image 2000 pixels wide for example). You can insert images using Textile or Markdown but this does add to the amount of “code” the user sees.

It’s at this point where we often see people decide to switch to WYSIWYG in Perch. Even if they accept the benefits of not using it.

How do we fix this?

I currently think MarkItUp is the best thing we have, and we could go some way in Perch by creating a plugin for MarkItUp that enabled image browsing and upload and file uploads. We may well tackle that (UPDATE: we did tackle that in Perch 1.7.3). There is also the WYMeditor project, however that creates XHTML directly and I’d prefer to be able to transform content as described above. What I’d really love to see is some more thinking around this issue by everyone who uses or develops a content management system or anything that requires users to be able to format content.

I think that the prevalence of the WYSIWYG editor has held back this discussion because we have a way to do it, it might be sub-optimal but we can let our clients format content if they so desire. As a CMS vendor there are lots of interesting things to tackle and areas where “people have a way to do it” tend to get pushed to the back. Designers have settled on WYSIWYG being a necessary evil, and don’t insist we look at alternatives. I’m sure the situation is the same for all other CMS developers – we respond to what we are asked for by our users and prioritise accordingly. This is why I think this is something that could and should be discussed more widely than being tackled by each of us individually. How should we help users to format content on the modern web? How can we make best use of HTML5 and modern development principles in doing this? The WYSIWYG Editors we see today haven’t changed much in the last decade. I think we can do better.

The Profitable Side Project Handbook

The Profitable Side Project Buy the book
  • Have you always wanted to launch a product and supplement your freelance income or job with recurring revenue?
  • Do you struggle to make decisions about pricing models, taking payments or providing technical support?
  • Do you find that it is hard to make time to create a side project?

In my practical new book, I'll help you answer all of these questions and more as you work towards the launch of your own revenue generating side project.

Comments

Guy Carberry: 27 Jul 2011 at 12:36:05

Excellent article. I share your pain! I’d love to see an elegant solution that suits all parties and hopefully this article will spark some creativity to deliver one.

Ben Bodien: 27 Jul 2011 at 12:36:05

I really like the way the new Campaign Monitor editor works; editing within the context of the template, which I imagine returns to the editorial emphasis to content rather than style. Much closer to actual WYSIWYG too!

http://www.campaignmonitor.com/blog/post/3510/coming-monday-huge-editor-update-and-new-template-language/

(obviously a bit of a beast to implement though)

Phil Leggetter: 27 Jul 2011 at 12:36:58

Been feeling this pain over the past few days as I’ve been reviewing a few customer engagement/support systems (UserVoice, Assistly, TenderApp). We currently use TenderApp and whilst it’s not as whizzy as the other two it uses MarkDown. This means replying to user question and creating knowledgebase articles is super-simple. UserVoice allows textile in its KBs but has no formatting support whatsoever in normal message replies. Assistly is very similar but uses a WYSIWYG editor in the KBs.

For me, MarkDown does everything I need and it would most definitely be my choice when writing blog posts, replying to support calls or writing KBs. If I want to get created I can just stick HTML in the post. Otherwise, the MarkDown syntax is much clearer to read and edit.

Rachel: 27 Jul 2011 at 12:40:41

@Ben Bodian in context editing like this works well for simple stuff, however it is not without problems. See this post from Drew McLellan (my partner in life, business and web-related grumbling) on the subject: http://allinthehead.com/retro/357/the-lure-of-on-page-editing

It works well for Campaign Monitor because they are dealing with an email, which is a single piece of content.

Ben Callahan: 27 Jul 2011 at 13:10:49

This is something we always struggle with. You asked for some thoughts on how we could address the two main issues, so here’s a start on how you could allow clients to place images inline without a bloated editor. Allow a customer to upload all the images they would like to see in the content, then present these somewhere on the page as thumbnails with some kind of ID—could be as simple as “1”, “2”, and “3” if there are three images. Then some very simple reference to those in the “MarkItUp-like” editor would be enough to place the images where the user would like in the content. Just a starting thought for further discussion. You are right, this needs to be fixed. We’ve lived too long with the same old problems…

Great post, thanks for starting the conversation.

Tom Leitch: 27 Jul 2011 at 14:05:26

This is something I faced at the BBC. Our mantra was to always separate content from presentation but found that providing a quasi-preview was something that journalists felt more comfortable with – it allowed them to create a page much more quickly. They also liked to see if they were emboldening some text, or if an inline link was present, the visual clues were important and the difficulty with sanity/cleaning manual tag input (a la wiki code) wasn’t going to fly. We implemented our CMS editor using TinyMCE and writing custom plugins that threw-up a light-box editing interface that allowed the journalists to enter data into the various fields and drag and drop images, etc. which then inserted a tiny, specialised HTML tag into the editing screen which would then be decorated with CSS and Javascript to provide an indication as to what the “module” was – be it an embedded quote or FAQ box or image with caption…

James: 27 Jul 2011 at 14:11:37

Some great views as usual.

Dealing with client formatting has always been problematic and it’s tough mixing very fixed template element/inputs with some freedom which, lets be honest, are still a working requirement of many commercial projects.

One of the options you might want to investigate is something I got a brief demo of when I went to some level 1 Umbraco (http://umbraco.org) training a few months back and that is the integration between Windows Live Writer and Umbraco and it allows the client to basically use Live Writer as their wysiwyg editor and when it posts to Umbraco, their funky inline styles, rotated images etc are magically converted to valid HTML.

It’s unfortunately not very well documented as far as I can see but I’m sure it will be as it was an amazing bit of integration and the output was spot on.

If you want to find out more it may be worth asking @drobar who does the training who might be able to give you some additional reading.

J.

Dr. Martin van Nostrand: 27 Jul 2011 at 14:21:43

All WYSIWYG editors are a pain. They cause a lot of trouble. I have had instances where, under unexplained circumstances, the editor did not close tags correctly and ruined my whole layout.

I have recently discovered the Aloha Editor. Full HTML5 (or just HTML is you wanna be correct :P). Did not try it in production yet but it seems promising.

Check it out: http://www.aloha-editor.org/

Emily Heath: 27 Jul 2011 at 14:30:05

Although we provide detailed, structured CMS entry forms for our clients, we are still left facing the 2 problems you identified here.

The first problem as you describe it: “My client doesn’t want to see the codes” isn’t exactly what we’re confronted with. The Client doesn’t mind seeing the code, they just don’t understand it, so mistakes happen. When we use textile formatting, these are just some examples of the kind of results we see:

(the editor:)

  • uses heading style indicator but doesn’t leave a line break after heading so entire following paragraph is marked up as a heading
  • doesn’t leave a space after hyperlink so following word gets added onto end of URL they’re trying to link to
  • space at beginning of line of text, before the p. (for paragraph) so the p. gets displayed

Of course if the website editor were approaching their content creation task with due care, they would check the published page (or a preview if your CMS provides that) and see the mistakes, read the documentation to learn how to correct them, and fix them.

But unfortunately, content seems to be published all in a rush, and it is usually me who happens to notice these mistakes long after they’ve been made live, when I either email the editor with a lesson in textile formatting or go in a fix them myself.

With a simple WYSIWYG (with all the controls except bold, italic and hyperlink stripped out) these problems don’t occur.

Regarding the second problem, I implemented a solution much like Ben Callahan suggests above for a couple clients using our preferred CMS, ExpressionEngine. I wrote up a detailed explanation of how I did this here. Make adding inline images to ExpressionEngine entries safe and easy for your clients

It looks complicated, because there is another problem you have to deal with once you’ve decided on offering this solution (of letting clients intersperse images within their text): should the images be aligned left or right? Are they full width (appropriate for a landscape image) or half width (for portraits). My solution attempts to deal with that.

The only problem I’ve seen happen with what we implemented was the client forgetting to paste the image code into the textarea. I actually found myself on the phone to a client, having logged into the CMS, reading back the inline instruction above the textarea to her, which said to remember to paste the code in where appropriate.

Can you ever win?!

Emily Heath: 27 Jul 2011 at 14:31:47

What, no textile formatting on these comments? ;)

Leave a reply