WYSIWYG Editors still suck - and we only have ourselves to blame

Yesterday I read Mark Boulton’s blog post WYSIWTFFTWOMG and once again it highlights how little we have progressed in terms of how we as an industry provide modern content editing experiences, tailored for content that will and should exist beyond the boundaries of a web page.

As a CMS vendor, with a product that has structured content at the core, I am hugely frustrated about this issue and I believe that a lot of the issue lies, not with clients demanding WYSIWYG editors, but with designers and developers agreeing to implement them. I spoke on this subject last year at Smashing Conference and while everyone nodded along, and it was the talk I had most post conference email about than any other talk I’ve done, that talk is still completely relevant today.

When we were in the business of building fairly large-scale (though not at the “Enterprise level”) content management systems for clients, with only one exception, we managed to explain to them that a WYSIWYG editor was not beneficial to them and their content. It was never the difficult sell that people seem to assume.

Our clients would ask for a WYSIWYG editor and we would tell them no, that instead we would be providing a way for them to properly manage their content without needing to worry about how it looks. That the system would ensure it stayed consistent with all that design work they had paid for. We could also show them how entering content based on what it was rather than how it looked meant we could reuse their content around the site. Rather than dwelling on the negative, on how WYSIWYG is a terrible thing, we showed them the real and tangible benefits of a structured content approach.

Our clients asked for an editor that was like Word, just like all clients do. However ten years ago I realised that they were not asking for a Word-like editor because of any insight into the best way to develop websites. They were asking for it because Word was the one tool they knew how to use well, they were in it all day. It made sense to them that their website CMS should be “the same”. All that was needed was to explain why that kind of thing doesn’t really map directly onto creating web content, and what we could do that was better and less problematic and it became a non-issue.

As for the misconception that non-technical users won’t be able to cope with Textile or Markdown, this is largely untrue. Where the use of these languages is just for the very simple text mark-up required once you have a structured content approach, I have never come across anyone struggling significantly. If you promise them design tools and give them Markdown they won’t be happy. If you show them that all they need to worry about is very simple formatting, they get it. It’s not a problem, in fact most people are happy there is no chance of them breaking their site.

On a technical level, once you step away from trying to be like Word, you free up a lot of development resources that can be put back into really working out what a modern, content-centric, CMS should be like. There are far more interesting problems to solve than trying to implement yet another in-browser, shoddy version of Word.

At Perch we sometimes say that we build opinionated software, and we do. We ship a product minus any kind of WYSIWYG, we encourage people to take the structured content approach that Perch is developed for. However as a business, we have had to enable people to implement WYSIWYG editors due to customer demand. We then have to support people who are jumping through hoops to reuse their WYSIWYG-mangled content elsewhere on the site. It is frustrating, and change will not happen until the people speaking with clients have the confidence to say, “let me show you a better way to do this”.