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.
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.
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.
In 2009 I was one half of a successful web development consultancy business. We launched our product as a side project alongside our client work. It became profitable within 24 hours of going on sale and as of the beginning of 2013 became our entire business. My new book is for anyone who would like to create a product business - without needing to risk it all in the process.