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”.
5 Comments
Quite right. I do dream of there one day being a tool that regular users find as usable as Word, but that produces HTML. Maybe that’s not the right way to go though.
Great to have more “not bullshitting the client actually turned out pretty well in the end”.
For me, I’d never sell full WYSIWYG and I’d concentrate on “the page will look fine if you just put content in”, but I don’t think I’m brave enough to just suggest MarkDown. People still like inline images and I don’t think that’s unreasonable.
While I understand where Rachel is coming from, (I have spend many an hour wrestling with the vagaries of TCPDF to appease my client), I also see the point of view of the client.
On a website that is structured to accommodate simple text and image input, such as a blog, newsletter or product info then yes Textile & Markdown is perfectly usable, although why we can’t have simple icon selection for the various attributes ( *, **, ****, etc ) I don’t know.
But, for sites that are required by such business as the Legal Profession, Town Planning, Architectural and other professionals it is by no means straight forward.
They are required to place on-line some fairly complex documents, with – wait for it – Tables, these can be vary from document to document in the number of column, size etc. so you can’t just create a template.
They have big secretarial pools who input all this data, and they like Word
So what are we to do, and don’t say link to PDF’s I want the sites to be responsive and not crash.
It’s a problem that is not going away, and the web industry needs to find a solution.
Markdown/Textile etc is no solution. Client’s will learn how it renders and just use it as crappy hard-to-learn WYSIWYG.
There’s a few lessons to learn when building content editors and CMS’s
1. Some content should be WYSIWYG and some shouldn’t. Some data is structured and some isn’t. Sacrificing yourself on the high-altar of ‘semantic markup’ is silly if the benefits are marginal.
2. People don’t add metadata unless there’s a tangible benefit. (semantic markup is essentially metadata). Read http://www.well.com/~doctorow/metacrap.htm
3. There is a real benefit to providing WYSIWYG. All else being equal then WYSIWYG is always preferable (note that ‘all things being equal’ is the key part of the preceding sentence). I’m a coder and I prefer WYSIWYG if there is no downside.
Just make sure you turn off as much formatting as possible. Text color? No. Font size? No. Configure a few custom “as semantic as you can manage” styles and allow users those in addition to strong, em, ul etc. Need a couple of non-semantic styles? I won’t tell and no kittens will die. And ignore the purists unless they give you a decent argument based on real-world cost vs benefit (and “real-world” doesn’t mean whispering ‘accessibility’ like a magic spell. It means testing in an actual screen-reader)
Does any CMS systems let clients manage their content in the form of a “structured” word document? I imagine a (rather precarious) workflow could be that the content manager edits a word doc with special headings or styles used for tagging content blocks with keys to drop-in locations, and then a macro upon saving parses and ingests this structure (stripped of ilegal media and layout chunks but preserving things like bold, italics, hyperlinks, etc) and performs check-ins of deltas as needed. The system should ideally build a new, “clean” master content word file after every check-in to ensure all the tags remain unsullied by grubby user paws… not saying it’s an ideal workflow but maybe it would be good for some users.