Add new comment

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.

Plain text

  • No HTML tags allowed.
  • Web page addresses and e-mail addresses turn into links automatically.
  • Lines and paragraphs break automatically.

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.
  • Web page addresses and e-mail addresses turn into links automatically.
  • Allowed HTML tags: <a> <em> <strong> <cite> <blockquote> <code> <ul> <ol> <li> <h4> <h5> <h2> <img>
  • Lines and paragraphs break automatically.
By submitting this form, you accept the Mollom privacy policy.