Thanks to the power of Twitter I was recently pointed to this article by Rachel Andrew , who amongst other things is one of the founders of the lightweight CMS Perch, titled Your WYSIWYG Editor sucks. It riffs on a couple of topics that I have seen come up a few times recently and have had a few conversations about myself as I work out my thoughts for my next CMS project.
One of the topics is the idea of structuring content – basically creating web forms for defined content types that authors just fill in and the CMS can then cleanly markup and add relevant microformats/microdata/rdfa (or whatever else!).
The original presentation that brought me over to this way of thinking was the Anti-CMS stuff Mike Nolan talked about and then more recently GDS talked a little about how they had built the INSIDE GOVERNMENT publishing tool and it sounded like a pretty similar idea of moving away from a generic, one size fits all editing interface to something more custom.
I have also been looking at a quite interesting start-up called Gather Content that has complimentary goals I think and maybe has the ability longer term to extend the capabilities of some CMSs in this direction without custom development.
Going down this route does remove some of the flexibility from your web publishing I think but in my experience this isn’t always a bad thing and when it is you can usually find a way around it. The challenge would be successfully defining the key content types. I can think of a dozen or so for the sites I am most familiar with and each of those ‘templates’ would have a dozen or so people who would think they know best 🙂
The second topic is one I am less sure about. The pretty universal hatred of rich text editors (RTEs) from developers/designers in this space has become a common theme and also the idea that it will all be OK as “we can just teach them Markdown” is something I have heard more than once.
While I can understand the frustrations designers in particular have with people using RTEs on sites where they painstakingly thought about every pixel the reality (in my little corner of the web world at least) is that content comes in from all corners of the organisation and is rarely ‘web first’ and outside of the digital team very few people have dedicated time associated with publishing to the web. Now clearly there is all sorts things wrong with this in this day and age but that is the reality I face.
I know alot of (public sector) organisations are looking are looking hard at ‘distributed publishing’ again as they seek admin savings and the idea that these myriad content providers are going to buy into learning something like Markdown or Textile in addition to the normal tools they use seems far-fetched and a situation where content is sent to a central team (or in reality these days a single person) to be marked up before publishing seems like a step back to the old ‘webmaster’ days with the real risk of a single point of failure.
I do like the look of something like MarkitUp that seems like some kind of middle ground and has a particularly nice preview feature but I still think the fact it is a code view would intimidate a large percentage of the people I’d need to ask to use it.
As usual I don’t have any real answer but I do have lots to think about anyway!
Digital by Default 
5 responses to “Considering the case against WYSIWYG”
Interesting thoughts. I just read the ‘Your WYSIWYG Editor sucks” blog post, and I think there are a few bad assumptions there. They seem to assume that the only way to use a WYSIWYG editor would be to use it for the entire page and all content in it. This is very much not the case in many systems. For example in Plone, which I’m most familiar with, you define content types with a schema, and any one (or more) of those fields in the schema could be a RTE. So it is common to have title, description, body text, author, date etc split out so that you can template them as required and constrain the formatting for consistency. In the case of TinyMCE used in Plone you cannot go and add arbitrary font tags. You choose from a number of predefined styles (e.g. heading, subheading, pull quote, etc) which in turn are styled via CSS.
So yes, certainly many RTEs suck, and I know I’ve fought TinyMCE a number of times, but it is not necessarily as bad as it sounds. Wikipedia’s use of markup is an interesting example of steadfastly not going down the WYSIWYG route.
In fact, in some circumstances, the divorcing from WYSIWYG and the end result it very desirable. e.g. newspaper sites might re-use content in a number of different channels and so specifically go out of their way to make sure you are *not* seeing the text in the context of a particular device or setting. That way you are not surprised when it looks different on a mobile, or syndicated site, etc.
An interesting project I saw recently was Gliimpse, http://www.aviz.fr/gliimpse/, which attempts to use both structured markup and then animate that into the rendered result. Quite interesting. Might be a bit to avante garde for many users. Actually that is probably one of the main issues here. Most web content editors just want ‘it to work like Word’. Trying to convince them of any other way is a fruitless task.
If you want to see an interesting hybrid approach, take a look at the Deco layout system coming up in Plone: http://www.youtube.com/watch?v=Zklzr_k-0rw it is just alpha at the moment (but that video shows it in production use already). It tries to combine the best of both worlds and uses an intelligent grid system to allow you to lay out discrete blocks of content (text, images, lists, whatever). In fact each ’tile’ as they are known is referenceable by its own discrete URL, so can be easily re-used on multiple pages.
-Matt
I think the “work like Word” thing is the big problem you are right (and considering I can’t make head nor tail of Word half the time it is a big problem for me!).
That Glimpse thing is a bit out there for me I’m afraid but Deco looks interesting – though I have had little success with those kind of ‘on-page’ editors in the past. I really would prefer my authors not to think about what it looks like at all – just think about whether it makes sense!
Yes, YOU want them to not think about what it looks like… but I’m sure they have other ideas 😉
An old debate, since the early applications of SGML to digital publication software. The problem is not that WYSIWYG is bad, in a content management world, content should follow a predetermined style, so filling a form and adding a couple of links to photos should be enough in principle, what it looks at the end should be handled somewhere else, not at the point of content entry. The problem is when those building websites (CMS driven or not) start thinking they can design a complex site this way. Designing a site is more than just a couple of HTML code peppered with the flavour of the day spice technical wizardry, it requires proper understanding of style, it requires, lets be honest, taste. As much as I love expediency when developing, I fear the day when coders (by that I mean those expert at the innards of how a site functions) become ‘designers’ and we end up with pages looking exactly like Rachel’s page (http://tinyurl.com/buxvv2h) or, God forbid, Jakob Nielsen’s page (http://www.useit.com/) There is a place for design in code and there is a place for proper design. the potential for the web to become a place where everything looks the same, uniform and devoid of soul is not something I wish for the future of web development, yet, the assumption that ‘a good seamstress is by default a great fashion designer’ is naive. Mainly because the perceived belief that design on browser supplants the need for the gestation of a design and brand ethos before it becomes code is akin to pretending that an old fashion linotypist is the same as a magazine designer, this precludes the web as being as vivid and adventurous as the paper medium. Maybe I am just getting old and don’t get this anymore.
[…] At the moment I am teetering on the edge of another CMS project rabbit hole from which there might be no escape but before I trip and fall into it I have once again been looking at some of the fundamental issues around using CMS products – especially the WYSIWYG question again. [Previously I wrote about it here] […]