Directional Feedback for the Next-Gen Admin UI

Background/Context

The Admin UI & JS team showed off some great progress at Drupal Europe with wireframes for a "next gen" content authoring experience for Drupal, heading in the general direction of "WYSIWYG / edit in place" UIs like Cohesion DX8 or Gutenberg. It seemed to be well-received by those in attendance.

Once we all came back from Drupal Europe, however, there was some discussion and push back about actually creating the type of experience referenced in the "next gen" wireframes.

Balancing Drupal's strengths with general UI trends

(Image source: https://www.codeinwp.com/blog/wordpress-gutenberg-guide/)

One of Drupal's greatest strengths, and arguably the main reason it has remained relevant for nearly 20 years, is its focus on structured content, which can be easily repurposed, in Views, view modes, in decoupled apps, etc.

However, the type of "WYSIWYG" UIs represented by applications like SquareSpace/Cohesion/Gutenberg toss out the idea of structured data, in lieu of one large clump of HTML with various formatting. This gives the advantage of a "true" WYSIWYG experience, since you are directly manipulating the page output. But, this "one clump" approach actively works against arguably the biggest strengths of Drupal, because it is then impossible to extract the raw data back out again and woe be to you if you're trying to extract actual content from a glop of HTML data.

A compromise was proposed of offering both: a WYSIWYG, edit-in-place, page building experience (Paragraphs-esque) for "landing page" types of content, as well as the current structured, "fill in forms and handle preview separately" approach for structured content. However, this still involves assumptions about the way in which data will be presented being "baked in" to the data itself. This was what was proposed at Drupal Europe.

Navigating competing concerns

However, based on what users have told us they want, content authors are likely going to flock to the edit-in-place version. So there were also concerns expressed that if we only offer a "modern" authoring experience to the unstructured content approach, we are going to guide site builders to making suboptimal architectural decisions, which have future-reaching implications. (For example, if the site suddenly wants to offer a mobile app, it's no longer possible to expose the content in an API format that would make sense for non-web applications.)

But, the "edit in place" approach is also dangerous, because by definition it assumes the content generated will be output will be the same device, and even the same application, on which it is authored, which is a mistaken assumption in this day and age. And while we can offer approximations of what content will look like in various devices/screen sizes, and while we can attempt to have a decoupled React authoring app mimic the site's front-end theme (one idea that's being kicked around), these will only ever be approximations, and could themselves lead to user confusion. ("It didn't cut off the title at that embarrassing location in the preview! What gives?" or "How come the preview doesn't have the site's new logo yet?" and so on...)

For this reason, there's a general trend around decoupled CMSes of concentrating the authoring experience of the CMS on purely the content creation, and explicitly *not* on what it will look like. However, this would be quite a dramatic shift from what we presented at Drupal Europe, which was well received. It also would be similar to what we had in Drupal 7, which was previewing the content in the generic admin theme, vs. the front-end theme, and we already know from usability studies → that this presented a huge stumbling block for folks.

A way forward?

So a counter-counter-COUNTER proposal (lol) was to instead try and handle rich preview in a "side by side" manner, similar to what Craft CMS does, where you retain the forms for entering data (which has the advantage of allowing you to handle non-visual data in a consistent way) but a preview pane next to the form / optionally in a new window, to handle the general "what will this look like once I hit save?" problem. Something like this: https://monosnap.com/file/BQQ7xx13ZZIkpy00HMjdYPe1U2W4qy#.

However, a "side by side" preview is both a far cry from what we showed at Drupal Europe. The rich experience that we showed is also where our competitors who target content authors and marketers are going/are already at. And, this approach also backs up what our users have seemed to indicate so far that they wanted. Additionally, we basically have this method of preview already (D8's preview works in the front-end theme, and you can switch which view mode you want to preview in), and it doesn't seem sufficient to offset concerns about usability/ease of use of Drupal's content authoring experience (although there is lack of research on how enhancing the preview with React's ability to "live" update it would improve the UX).

We should also bear in mind that this entire debate is to some extent also a "If I had asked people what they wanted [when inventing the automobile], they would have said faster horses." problem, so we should be mindful of that. The viewpoint represented in things like surveys and UX testing often represents the non-trivial portion of our users that are still predominantly building just *websites* with Drupal. But, with the proliferation of 50 gazillion new devices every year, this approach is not future-proof, and from a product POV, we really should be heading more towards facilitating an "omnichannel" approach, even if it doesn't benefit the majority of our users today.

Wrap up/Questions

Sorry, that was long. :) But the point being, the team is feeling pretty blocked on continuing designs on "next gen" UI until and unless we get to the bottom of what it is we're actually building (reasonable! lol). And we're hoping to get more feedback from the community on this point, particularly those who work closely with content authors, and/or omnichannel applications.

Some questions to get the discussion started:

• How do we modernize Drupal's authoring experience without damaging aspects of Drupal that make it great? How have others approached this?
• Who/what use cases are we building this for, and who/what use cases are we willing to make harder in the process? (For example, do we make the process of building a web page in Drupal easier at the expense of making an Alexa Skill harder?)
• Is offering a "side by side" authoring/preview experience like https://monosnap.com/file/BQQ7xx13ZZIkpy00HMjdYPe1U2W4qy# an acceptable way of balancing ease of use with flexibility to account for lots of different types of content Drupal might be generating? (Including those that don't lend themselves well to visual preview, such as those served by a separate application.)

Thanks in advance for your thoughts!