Startseite / Blog / The Truth About WYSIWYG Editing in your CMS

The Truth About WYSIWYG Editing in your CMS

Yesterday at DrupalCon I saw Karen McGrane speak for the first time. Karen is a respected content strategist and frequent keynote speaker. She's fantastic, and I was thrilled to see her speak live for the first time.

The main point made during Karen’s keynote is that we need to think differently when thinking about digital content. Legacy processes designed for print publishing shaped much of the way we work today in a CMS. This in turn has shaped how CMS products have evolved. Here’s how Karen puts it:

So I really believe, guys, that we are in a war of Blobs versus Chunks. We are in a war between giant, unstructured blobs of content, and clean, well-structured fields of content that have metadata attached. We are in a war of Blobs versus Chunks. You all are on Team Chunk. We cannot let the blobs win.

The idea is that Content Management Systems need to manage content fragments that are well described by metadata. By doing this, you can ensure that your content can be appropriately rendered in any format on any device. It’s the best way to future-proof your content, because we simply cant predict the devices of the future. Google Glass? iWatch?

(By the way, Karen called Google Glass the Segway of Mobile. GENIUS!)

The problem is that users often demand to work in the traditional desktop publishing paradigm, where content and design are intertwined. Make the content authoring experience just like Microsoft Word and the users will be happy. CMS authors prefer using the WYSIWYG editor and big blobs of HTML, because they can format and markup content while having some control of the layout. But by doing this, the content becomes impossible to repurpose and re-imagine in other ways.

Karen argues that content must be separated from form, the key to future-proofing your content strategy. Karen is the self-proclaimed “president of the WYSIWYG haters club”. The problem is that the WYSIWYG mentality forces uses to think about the page as the container, just like the in desktop publishing world. But in the digital world, the page is just one container. Your content is likely going to be consumed in all sorts of ways, in all sorts of formats, and all different types of devices.

To WYSIWYG or not WYSIWYG, that is the question.

The DrupalCon audience seemed to overwhelmingly support Karen’s position. When the discussion of Drupal came up, Karen questioned the addition of improved WYSIWYG editing and its cousin in-line editing to Drupal 8. From Karen’s perspective, Drupal is already well suited towards the modern needs of digital. It cleanly separates content from how it's consumed, perhaps better than any other CMS. Then why does Drupal 8 have WYSIWYG and in-line editing in core? Here’s Karen’s take:

I’m sure it looks great in sales demos, but when your shiny new feature has its collision with the real world, you’re going to discover it doesn’t necessarily solve usability problems. In some cases it’s going to make them worse.

I’ve given hundreds, maybe thousands of those sales demos and without fail, the users want WYSIWYG, and they want in-line editing. In many cases, Drupal would be eliminated as an option because it lacked those capabilities. Having both in Drupal 8 will allow Drupal to better compete against some of the proprietary CMS vendors. There are many valid use cases for both WYSIWYG and in-line editing, and now Drupal 8 supports both.

My honest take on Karen’s keynote is that she’s right. We need to get back to the basics of CMS, especially now that the web “page” is all but dead. Content fragments tied to metadata offer the ultimate flexibility to publish your content wherever it needs to go – from a webpage to Twitter to Google Glass to even a toaster printer - because who doesn’t want to eat delicious toast, personalized with content! But it isn’t always black+white. I’m glad that Drupal 8 offers enhanced WYSIWYG and in-line editing. It will make Drupal more appealing to content authors, who often just want to make a change, quickly. But we have to be careful when (and where) we allow it.


Posted on by Cameron Tod (nicht überprüft).

Structured, chunked data is far more interesting, flexible, and practical than big blobs for those that understand it.

The problem as I see it is that people are unconvinced of that because most web platforms don't demonstrate the power that structured data enables.

Changing that paradigm means building great sites, tools, and demos that give users that "wow" moment where everything just clicks. The demo that Dries gave in his keynote of a mobile app that was fed from a Drupal view was a great example.

Posted on by Adriaan Bloem (nicht überprüft).

It's 2013 and we still have to explain this... but yes, I am not, nor have I ever been, a fan of WYSIWYG or in-line editing. Because it's "what you see is what you get"... on your screen, in that context. Even if it would create beatifully semanticly marked-up chunks in the background, it's still an impediment for editors' understanding that this is not how others are likely to see it (on another page, on Facebook, on Google, on mobile, ...)

So... let's keep explaining it, until it's no longer a requirement in sales demos ;)

Posted on by Peter (nicht überprüft).

We were having this discussion around Vignette and Interwoven back in the late 90s - even the sales objection Tom describes was the same back then. It's sad that after a decade and a half the WCM establishment still hasn't figured this out.

Posted on by Geoff Bock.

I think you need to go back to Geoffrey Moore's book Crossing the Chasm to make sense of what's going on here.

The mainstream (those to the right of the chasm) needs WYSIWYG for all kinds of reasons -- they are publishing their stuff on the web, and like most of us, have been schooled to think in linear documents. So the forthcoming WYSIWYG editing in D8 will really appeal. And the early adopters (those to the left of the chasm) are going to want the chunking with integrated metadata management -- it powers the digital disruption that makes Drupal such a great platform for innovative apps.

So with D8, there's a winning case for Drupal on either side. The market development problem is to figure out how to get chunkers to cross the chasm. This is coming, probably over the next 24 months, as mobile apps become mainstream. Responsive design is going to help but it is only one part of the conversation.

Posted on by Bishnu Sharma.

WYSIWYG in D8 core is a no brainer if we want to cater the mass. I manage 10+ WP sites, and I constantly deal with content writers who don't want to learn html but rely on WP WYSIWYG. If you look at how WP 3.5.1 handles <p> tag, you are not alone sharing the pain. I wish I could completely turn the visual editor off forever, but I don't have that luxury. Even after turning it off, and manually inserting the proper tags, WP still overwrites it! What a pain. WP fits best for for these sites at the moment, but if D8 can match the simplicity WP offers I will migrate my new site <a href="htt p://"></a> and all other sites to D8 and say bye bye to WP.

Neuen Kommentar schreiben

Plain text

  • Keine HTML-Tags erlaubt.
  • Internet- und E-Mail-Adressen werden automatisch umgewandelt.
  • HTML - Zeilenumbrüche und Absätze werden automatisch erzeugt.

Filtered HTML

  • Use [acphone_sales], [acphone_sales_text], [acphone_support], [acphone_international], [acphone_devcloud], [acphone_extra1] and [acphone_extra2] as placeholders for Acquia phone numbers. Add class "acquia-phones-link" to wrapper element to make number a link.
  • To post pieces of code, surround them with <code>...</code> tags. For PHP code, you can use <?php ... ?>, which will also colour it based on syntax.
  • Internet- und E-Mail-Adressen werden automatisch umgewandelt.
  • Zulässige HTML-Tags: <a> <em> <strong> <cite> <blockquote> <code> <ul> <ol> <li> <h4> <h5> <h2> <img>
  • HTML - Zeilenumbrüche und Absätze werden automatisch erzeugt.
By submitting this form, you accept the Mollom privacy policy.