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.
32 Comments
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.
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)
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.
@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.
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.
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…
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.
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/
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:)
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?!
What, no textile formatting on these comments? 😉
@Dr. Martin van Nostrand Aloha Editor is “Edit in Place”, see my comment above for why that isn’t always a solution. It’s a solution for one problem but not for all.
@Emily Heath we’ve found MarkItUp solves a lot of the problems of formatting Textile as it inserts it correctly. As I say I don’t think it is the ultimate solution but I do think a solution that provides an interface between the user and the HTML which is rendered out to the site is important. That might not be visible for the user – maybe they don’t see the Textile/Markdown or whatever tags – but as a developer I want to control the mark-up.
.. and no, no Textile here. This is WordPress, I think you can use Textile in WP comments but that’s probably something for if I ever have time to redesign this site 🙂
Emily Heath hit the nail on the head when she brought up the issue of content being published in a rush. We have to remember that most content creators don’t care about the code. The code could be all tables and it wouldn’t matter to them as long as the image they embedded is in the right place.
One of our biggest obstacles as web weavers is instilling that care/concern for proper semantics, meta-tagging, etc. The problem is not only a technical one, it is also a problem with workflow/process. In print, authors create the content while designers lay out pages. With the web, we’ve given writers control over the layout and design. However, their job is to write. In general, we can’t expect them to care about principles and nuances in design or specifics/technicality in the code/meta-data.
Of course as Rachel alluded to in her article, there are those writers who see all these nifty WYSIWYG tools and spend their time playing around with fonts and colours and as a result both the design and content suffer.
Beautiful insights! This essay really hits at the heart of what has been one of the biggest heartaches since the dawn of Web design.
I’m redesigning my personal website and had strongly considered Perch. I don’t think it’s the right tool for that particular job (because I actually want to get my hands dirty with the HTML), but I plan to purchase Perch to learn it, because I think it would be a perfect choice for a dozen other projects I can think of.
Thank you for articulating the problem so well, and for illuminating the future of a better Web!
Great article and couldn’t agree more. Standard WYSIWYG editors are becoming more and more frustrating to use due to the limitations they impose on the layout, flow and design of content. I’ve worked on some big sites for big clients and it’s always a shame when the whole creative process (design & content) gets boiled down to essentially content editors using stock templates to populate information in the same manner on every page.
Long live the content revolution!
Yes I agree with everything here. My current approach is to provide users a very stripped down WYSIWYG editor and to sanitise content when it’s plonked in the database. This solution gets me by, but it still sucks.
There are innovations in this area. The Aloha Editor (edit in place) mentioned above is clever, although I understand the reasonings why this isn’t always a perfect solution.
The Google Docs new WYSIWG (Kix) is unique in that it doesn’t rely on contenteditable or designMode like all other WYSIWYGs. This more constrained and controlled approach alleviates some of the typical problems with WYSIWYG. Similarly, there are Canvas based text editors emerging that could in theory be used to provide WYSIWYG-like functionality, without some of the inherent problems of the usual editors.
An interesting approach I’ve seen recently (not on the web) is how iA Writer on the Mac handles markdown text, focussing strongly on typography and providing nice visual feedback on your markdown syntax.
I dont know what the one single solution is, but there’s a few different ways of tackling this problem. There IS a better way.
Fab post – love the third paragraph in particular. Too many content editors think that a WYSIWYG editor means that what they are writing will automatically be awesome…drives me round the twist!
Excellent article! Love it!
It looks like “Provide a Wysiwyg editor” is a case of “damn if you do, damn if you don’t”. I recently worked with DITA documents (which are highly structured by nature) and think, that the approach DITA editors take (e.g. oXygen XML), while not perfect, could point in the right direction (which seems a little like the path using templates you described).
What might work: have a Editor a little like the scratch source code editor where you can drag content types on your page and then format within the constraints of the content type. e.g. drag a headline or drag a “site note” or a “important tip from the editor” —- the idea would be to move business vocabulary into the content types (of course that requires a good configuration system). These “business types” are then mapped to HTML elements and CSS classes.
I get your point. BUT It is ‘principled’ and not at all pragmatic. When I implement a wysiwyg editor I strip alot of stuff out but asking a client to markup text in markdown! We tried this years ago. Customers hate it. It feels like being forced to drive a Lada when you thought you were getting a BMW.
I took a quick look at perch a few months ago but this is the one issue that is the deal breaker for me. For the rest I think perch is a great product. Respect oke 🙂 But I think the customer should be given a choice on this. CKeditor imo is a highly configurable and produces good html.
@DC Crowley we give our Perch users the option to use CKeditor, TinyMCE or any other editor plugin they wish as explained in the article. So where is it that we don’t give our customers a choice?
Your attitude is exactly the problem I’m describing, if we settle for what we have, then we don’t move forward and find better solutions.
We will have to disagree then 🙂 But I do make sure they can just add links, strong, emphasis and not comic sans, clashing colours…
Great post, saves me the trouble of forming my thoughts into words!
I agree 100%. I hate WYSIWYG. They wreck everything and you spend more time trying to get things aligned, then you end up with random tags everywhere and it’s just plain yuck. BBCode or Markdown are much better options.
Structured content is royalty!
So, should be What You See Is What You Mean:
http://en.wikipedia.org/wiki/WYSIWYM
http://en.wikipedia.org/wiki/WYMeditor
🙂
Here’s the thing…
Is it REALLY that hard to build a FORM and a processor for a custom data structure on every page? If so, you probably have no business building a website in the first place…
Also, on the multiple pictures on a page…
Break it down into “chunks” with one picture.
Your UI and CSS can even let them pick from several layouts: Every other pic on the left/right, all on the right, all on the left… Whatever.
As they add each paragraph/pic, build up the “how it looks” so they see it.
Well, i really saw that you will giving us the miraculous editor for CMS…well i just dreamt…that doesn’t exist!
Anyways, thanks a lot for this great article.
I’m going to link to this discussion from 2009 (exactly 3 years ago) and conclude we really haven’t moved on from there: http://www.mikeindustries.com/blog/archive/2009/04/the-sorry-state-of-wysiwyg-web-editors
I’m a firm believer like you to let editors edit content and not be ad hoc designers but currently we’re still noy there and at this rate of progress it seems like we’re still a ways off.
I mostly agreed, and tried to make progress on this topic in 2006, coming from an accessibility point of view.
However, I think that for many situations a well configured WYSIWYG / WYSIWYM editor is better than wiki-style syntax (e.g. for images and tables). A few things that help with that approach:
– Removing ‘style’ buttons, and making the structure ones primary.
– Including a pre-defined styles drop down that adds classes to certain elements.
– Using within-editor CSS to make things appear similar (in size and colour) to the published versions.
– Using within-editor CSS to add structural labels to each element (example).
– Using customised pop-ups relevant to your CMS.
You could probably do a similar list of things that would help wiki-style editors, which means there isn’t an ideal solution for this yet.
I suspect one-size will never fit all, some things are better as structured data (taking the form approach), some things are not very structured, and some can be inbetween (e.g. a pop-up that inserts microformated content details into general HTML content).
If anything, HTML5 makes this whole issue more complicated because there are no ways of taking advantage of HTML5 elements. The guy behind the Xstandard editor even wrote Why do WYSIWYG editors hate HTML.
However, how valid those points are depends on how much you think you should rely on an editor to do those things.
Great post, I’ve always hated implementing WYSIWYG anything for clients.
However, in WordPress, I discovered a neat plugin called Advanced Custom Fields. This allows you to 100% control the data input experience for clients, and I have been successful in creating a form-like input experience. This allows you to keep all of the styling in the template but allow the client to add content as they see fit.
Hope that helps anyone using WordPress for clients.
So, in other words, wysiwyg editors suck because they are user-centric functionality, rather than designer-centric. Great. We’ll just require the user to unlearn the visual metaphors that were such a great, necessary leap forwards in usability several decades ago now.
And now, “markdown” is creeping out of internet forums and into word processing and page layout apps meant for general users, displacing simple “B” and “I” buttons with nonintuitive codes — two whitespaces to indicate a line break, anybody? — and needing to hit “preview” buttons to have any idea what your document is going to look like. Not to mention breaking URLs with requirements to insert escape codes to handle things like underscores and tildes.
Sorry, WYSISOLWYG (what you see is sort of like what you get) is not a step forwards. For coders, or technical content, sure. But when I can’t find an RTF editor for my phone because everything is “markdown”, that’s a huge, insane, embarassing-for-the-industry step backwards.
I have been working on a REAL wysiwyg editor:
– inline editing (like Aloha but more slick)
– limited set of buttons (configurable)
– strict (configurable) validation
So users edit the text in its own context.
The editor is part of the DirectEdit project https://github.com/carloroosen/directEdit-FREE
As someone who normally acts as a content editor, I often get the opposite issue. The developer has created a form or CMS section that’s too restrictive. While this is probably great from a designer and developer viewpoint, it can restrict speed of change where marketing may need to adjust layout or add elements as business needs change, or even for one-off campaigns.
The perfect answer is to have the developer make the changes, but for many people this is not always practical. They may be working on another project, or if it’s an outside developer there may be no budget left for change requests at that point.
This leads to content editors having to bodge things as best they can, leading to some strange and non-standard stuff being done to make it look right. such as jamming HTML into form fields.
So much this => “WYSIWYG Editors suck because they promote thinking about style rather than content.”
It goes way beyond content editors. I see the same problem in a crowd of visual website builders and drag & drop builder plugins in WordPress realm. After all these years of pushing toward separation between style and content, semantic HTML, and proper content structure, those visual editors are leading users to believe in “style first, drop in contents later” backward approach. Their answer to my concern is “Nobody cares about the code as long as it works.” Craftsmanship and good practice all going down the drain. It’s maddening.