The long, slow death of the WYSIWYG editor

Content management systems have evolved over the last couple of decades to be extremely powerful and indispensable tools for marketers worldwide. The tools we use have become more and more advanced and user-friendly, yet one lone feature from the 90s just keeps holding on. It's time to embrace the future of omnichannel digital content, and leave the "MS Word-style editor" behind.

Picture of Luminary CTO Andy smiling with a black background

By Andy Thompson, 4 June 202010 minute read

Content management has been around almost as long as the World Wide Web itself. The tools and processes we use to design and build content-managed websites have evolved continuously, but one feature has remained constant throughout: the "Microsoft Word style" What You See Is What You Get editor. Marketers love it... or do they? Developers tolerate it, and it's the bane of Brand Managers worldwide. The rest of the industry has moved on, and now it's time to leave the WYSIWYG editor behind too. WYSIWYG is dead, long live structured content!

This post is a summary of my presentation at Kentico Connection Melbourne 2019. Check out my .

A quick intro to WYSIWYG in CMS

WTF is a WYSIWYG?

WYSIWYG means a lot of things to a lot of people, and fair enough. "What you see is what you get" is very broad, and has been applied to a bunch of different technologies over the past three decades.

I'm not talking about some of the really cool visual editing technologies that have been developed more recently, such as live preview, drag-and-drop components, or in-context, on-page editing of structured content. I'm also not talking about the basic ability to edit "rich text", in other words applying basic semantic structure to your content such as headings and lists.

I am talking about free-form, unstructured HTML editing; this guy pictured below, the ‘Microsoft Word style HTML editor’:

The full-featured rich text editor in Kentico CMS

Rich text editor in Kentico CMS

But as marketers, is what we see always really what we want?

Rich text editor with content that looks terrible

Wow. Much style.

This kind of fixed-width, free-form HTML editor with all the bells and whistles available has been a staple of Content Management systems for a long time. But it comes with a few problems, including:

  1. By design, it allows the editor to break the design that was carefully created by designers and implemented by developers. Providing font face, weight, size and style options, foreground and background colour options, and even the ability to edit the HTML directly and do anything.
  2. Marketers are burdened with spending their time on the style and layout of their content (which we have designers for), rather than the content itself.
  3. It assumes you're editing a fixed-width web page, that will be displayed on a large/desktop device. It ignores other channels such as mobile, apps or social, other screen dimensions, and potential future design changes to the site.
  4. The content is very difficult to reuse or repurpose, beyond using copy and paste (and readjusting the style and layout).
  5. The markup produced by the editors is notoriously messy, and can contribute to poor SEO and accessibility.

Now of course, marketers want to see what they're going to get. We'll get on to what we do want as marketers in a bit, but first...

A look at best practice web design & development

Over the past few decades, just about every area of web design and development has evolved significantly. Some of the key advancements we now take advantage of on every modern project include:

Atomic/componentised design

A focusing on designing the core elements of a design system, and using them to build up designs hierarchically or like using Lego blocks, rather than designing each page one by one. Typically uses modern tools such as Sketch or Figma, rather than Photoshop.

Mobile-first responsive design

Not locking ourselves to a fixed ratio when designing, and making mobile devices first class citizens on the web. A critical component of proper responsive design, meaning we don't need to maintain a mobile and a desktop version of a site.

Modular front end components

Flowing on from componentised design systems, Front End Developers typically build out a layered component library, with reusable components representing everything from the tiniest icon or button, through to complex elements such as forms or carousels.

Reusable CMS widgets

A large part of any CMS developers job, and increasingly the CMS vendors themselves with the rise of "low code" solutions, is the development of reusable components, or widgets, or blocks. These might be reusable pieces of content, or complex pre-built functionality, which an editor can place on pages and know it will just work.

Omni-channel delivery

Content is no longer just for websites. Whether it's email, social, mobile apps, ecommerce marketplaces, or even just more than one website, most digital projects of any significant size now need to consider multiple delivery channels for the same content.

Designing pages in MS Word

No, wait... what is this item doing here? Sure, Microsoft FrontPage was pretty sweet back in 1997, and everyone has always loved how Outlook renders emails, but is anyone still using Word to design and build websites? So why are we bragging about our favourite CMS platform's MS-Word style editor?

The answer...

As marketers, we want and need:

Quick and efficient content entry.

  • We don’t want to wrestle with a system, we just want to get our job done.

Content to look good, everywhere.

  • We have a brand to conform to.
  • We have beautiful designs already.
  • We just want our content to look great.

To not be a designer.

  • We know we’re not! This is often why we stress about presentation.
  • We still need the flexibility to apply the brand.
  • In other words, we need to be able to easily build a page within the brand guidelines, rather than design a page from scratch.

Content performance.

  • It needs good SEO.
  • It needs to convert.
  • It needs to load quickly.
  • We shouldn’t have to worry about this 💩.

Is a free-form WYSIWYG what we really want?

  • It's not quick and efficient.
  • It doesn't look good everywhere.
  • You're going to break the design.
  • It will (allow you to) ruin performance.
  • It's just nasty.

(In other words, no.)

So what do we want?

Recapping, we want:

  1. Quick and efficient content entry.
  2. Content to look good, everywhere.
  3. To not be a designer.
  4. Content performance.

How do we get all of this? If we borrow a long-standing principle from software engineering called Separation of Concerns, we can find ourselves with a win-win. It boils down to being really quite simple in this case:

  • Let designers design.
  • Let developers develop.
  • Let content editors edit content.

Going back to our industry best practices, we then have:

  • Designers design responsive components
  • Developers develop modular components/widgets
  • [NEW] Content strategists model content types
  • Content editors edit structured content

What do we want?

Structured Content!

Probably the easiest way to think of the difference between structured and unstructured content is to imagine you're entering a product into your online store. You don't just expect to be given a blank page, and it's up to you where to put the SKU, name, retail price (in three different currencies), images, description and so on. You expect to see fields prompting you to enter this data in a specific format. Not just text boxes either - you expect to see strong validation, instructions, image selectors/uploaders. And in some cases, you expect to see rich text, or the ability to add limited formatting such as headings, paragraphs, emphasis, lists and so on, to the text.

In this example, of course it makes sense to use structured content. You'd be crazy not to! Well here I am saying that you can apply that same mindset to all of your content management.

Content Modelling

The secret ingredient that really makes this work, is content modelling. That's the part that's missing when you just give people free-form WYSIWYG areas. In a nutshell, it involves:

  • Planning and designing how your content works
  • Identifying content types and relationships
  • Creating the types for your editors in the CMS
  • (And this all happens as early as possible.)

Content modelling could easy be a post (or a series) of its own. There are some great resources out there already, such as:

Is structured content what we want?

Let's check our list again:

It's quick. ✔

  • Entering content is as easy as filling in a form.
  • Copy and paste actually works!
  • Training and onboarding is much simpler.
  • QA is much more straight-forward.

It's going to look right. ✔

  • It’s no longer up to a content writer to adjust the design and layout.
  • You can still work visually with structured content components provided by your designers and developers.

You won't break the design. ✔

  • Because you can’t!
  • You can certainly work within it, and be confident that what you're creating is taking full advantage of the design.

It's great for performance. ✔

  • Performance is up to the developers, who are great at it. 
  • SEO optimisation is in the hands of developers too, and driven by the same content as your pages.
  • Metadata is a first-class citizen.
  • Delivery can be optimised for every channel.

But wait, there's more! 😱

There are a host of other benefits from adopting a structured-content approach:

  • Structured doesn't necessarily mean headless - Kentico Xperience (MVC) ♥ structured content too!
  • Little to no duplication of content
  • Easier translations
  • Simpler personalisation
  • Clean code
  • Omni-channel options
  • Content recommendations
  • Better search
  • Machines love structure
  • Accessibility

What I'm NOT saying

OK, this post may come across as a little aggressive, so I need to make sure I haven't gone too far.

  • I'm not saying that rich text editing is bad. It's absolutely fine. Just exercise restraint!
  • I'm not saying visual page composition is bad. It's awesome, especially with structured content in components!
  • I'm not saying on-page editing is bad. It's brilliant.

Mythbusting

Some common misconceptions around structured content management:

"I don’t know what my page will look like."

  • Let’s face it, WYSI is not quite WYG.
  • Visual page composition (i.e. structured widgets/components) usually give you a much better preview of what you're going to get.
  • Kentico Kontent (headless CMS) has preview too!

"I need complete flexibility."

  • You need flexibility yes, but not complete flexibility, if you're working within brand guidelines or a design system. Structured content can give you the flexibility to do anything you like with the options available, and let the presentation sort itself out the way the designer intended.
  • Structure doesn’t mean inflexibility. It means confidence, efficiency, future-proofing, and reusability.
  • Think of structure as more like building with Lego instead of drawing with crayons. You can create amazing things given some really great tools and systems. You don't need to start with a blank canvas.
  • With the right set of components, a content editor can be set free and build beautiful content.

"Structured content = plain text."

  • Rich text can still be structured!
  • Clean, semantic HTML is highly structured, and includes headings, paragraphs, lists, all that awesome stuff we’ve been using since the 90s.

"I need WYSIWYG because I need tables."

  • It's no longer best/accepted practice to use tables to lay out your content on a page, for a number of reasons, but the main one is probably that it's highly likely to mess with the responsiveness of your page (in other words, it's not going to look right on mobile). Every CMS I know of provides much better solutions for giving editors control over layout while working within design constraints.
  • If you're talking about tables of data, then great, they are the original structured content! But... I would strongly recommend not managing that data inside an HTML editor designed to emulate a word processor.
  • Responsive design of data tables is a complex and difficult problem, which is much easier to solve if you allow the designer and developer to have complete control over the behaviour and HTML markup of the tables, and the editor only edits the data itself.
  • Most CMS platforms provide special functionality for managing and embedding tabular data in other, more effective ways.
  • In a headless/microservices world, you have even more options to choose the right tool to manage your data. I assure you, the table icon inside the WYSIWYG editor is probably not your best option. 
  • There's easily a whole post in this subject itself, so I'll just summarise with a politically correct "please reconsider your need to use tables in a WYSIWYG editor". 😊

Questions (and attempted answers)

Taking live questions at the end of a static blog post with no comments section is a challenge, but feel free to shoot them my way for the whole world to see on Twitter at @andythompy!

Here are some of the questions that came up from the live audience:

Are you now forcing all of your clients to not use WYSIWYG editors?

No. 😊

Do you remove most of the options in rich text editors on all of your projects? 

No, but... I very strongly recommend reviewing what options are available every time, and consider limiting it to the very basics, like what you would see in a markdown editor. Just a few heading styles, hyperlinks, maybe bold and italic. Probably not underline!

And of course... allow the insertion of widgets/components that are powered by structured content. 😉

Keep Reading

Want more? Here are some other blog posts you might be interested in.