Three Lessons From Taking Gutenberg to Drupal

Content authoring can be painful. Drupal Gutenberg is an editor, originally written by the WordPress community, that makes it easy to create content—from long-form feature articles to rich landing pages. 

As soon as we started presenting Gutenberg in client meetings, we knew it was huge. “How fast can we get this?” was the usual response. The people most eager to get started were always content producers. We were not surprised. 

Editors expect to create landing pages with ease. Sure, some power users can make wonders with Paragraphs or Panels. But with Gutenberg, anyone can create smashing pages, and it’s much faster. A client told me: “I’m used to editing non-visual templates where I have to guess what the end result will look like after I add my copy. With Gutenberg, I can see the end result as a I type. It’s a WOW experience!”

Structured Content is (Still) King

Yet, with great flexibility, comes big responsibility. While Gutenberg could limit access to blocks per content type, it’s very possible for content producers to go wild. This is where Drupal’s field-based approach shines. With Drupal fields, each part of a page is stored as a separate field that can be presented differently based on context. It’s also great for building APIs. How could Drupal’s field system fit into the Gutenberg editing experience?

The solution is quite simple. This is where Gutenberg in Drupal improves upon the WordPress implementation: You can map any block to a Drupal field! 

Let’s say you want all Event pages to display an image and a call to action button. This is how it works:

1. Go to the Event content type, and fix the Image block and the Button block at the top of the editor.

2. Lock the blocks, so they can’t be moved or deleted.

3. Instruct Gutenberg to map data from the Image block to your Featured Image field, and map the Button block to your Call to Action field. 

All this is done with two minutes of configuration in the Drupal backend. There’s even an example included in the module.

Talking to Drupal developers, the #1 issue they had with Gutenberg, is: What happens if we want to serve the content in an app? What if we go headless? Finally we can have both: Store the data in fields, and edit them in Gutenberg. It’s the best of both worlds.

Designing the Admin Experience

The Drupal admin experience can be great or not so great—based on how much thought has gone into planning the UX. With Gutenberg you get a lot for free: All content are blocks, and adding blocks to a page is easy. But blocks can have settings: Perhaps pick a background color from the theme’s color palette, provide some alignment options, turn visual elements on/off, big or small version… it quickly becomes overwhelming. Keep it simple!

We quickly established some principles for designing custom blocks:

• Design out all variations of the block. What should your hero block look like if you don’t add a CTA button? What happens if you add two buttons?
   
• Work on the options UI as a team (with a designer). Bring UX competence to the development process: Would it help to add a thumbnail to visualize the block varitions in the sidebar? Is it enough to display a warning if you combine low contrast text and background colors? Can we bring all the options away from the sidebar and into the main Gutenberg area?
   
• Launch with few UI options, roll out more if needed. Some ideas: Limit the background color options, limit what kinds of blocks you can add inside other blocks, hide the columns block. Each new block and each new block option makes it slightly harder to focus on the main goal, which is alway to create great content. Don’t impress anyone with fancy features! The top feature for any CMS admin is ease of use.
  
   

TL;DR

There’s a huge demand for Gutenberg in Drupal projects. By combining Drupal’s sophisticated field system with the visual simplicity of Gutenberg, Drupal is an amazing platform. Keep it simple, and content producers will love you.