Directional Feedback for the Next-Gen Admin UI

I work with journalists since 15 years on a day to day basis, and I'm pretty sure that the side by side authoring/preview experience would be a major and positive change. Great job!

TL;DR version, based on what's already successful in WordPress, Medium, et al:

1. Save entities in "draft" state as soon as content editors enter anything on the edit screen.
2. "Required" status for fields is enforced on a per-state basis, allowing incomplete drafts to be saved without errors.
3. Derive all previews from persisted entities, not intermediary pseudo-entities that only exist during the edit process.
4. Provide two approaches to previewing in core — an edit form with a link to a stand-alone view of the Entity in its default build mode, and a "side by side" Preview Panel that loads that same entity build mode in an iFrame or some similar DOM-isolated mechanism alongside the edit form.
5. Allow contrib modules to alter the preview panel (adding a locale switcher, changing the build mode, changing the iFrame's dimensions to simulate different screen sizes, etc)
6. Allow site builders to disable the preview panel entirely and replace it with other mechanisms from contrib.
7. To improve the actual editing experience itself (not just the preview step)…
   1. Trim cruft from our standard field widgets, especially multi-instance fields. This is a major contributor to the visual clutter of the content forms.
   2. Examine ways to lead people through the full content creation workflow (Selecting a content type, creating it, reviewing it, and publishing it). Focusing on the edit form in isolation (or alternatives to it) will always be clunky, because real world creation requires all of those steps.
   3. Assess the readiness of tools like Entity Embed, Inline Entity Form, Entity Browser for inclusion in core. Highly relational content models are a Drupal strength, but the workflow of creating and associating "clouds" of related entities is where it breaks down badly.

Longer version:

How do we modernize Drupal's authoring experience without damaging aspects of Drupal that make it great? How have others approached this?

In an attempt to answer the "How Have Others Approached" this, I reached out to a number of architects and integration specialists who work with both Drupal and systems like SiteCore, Adobe Experience Manager, Ektron, and a few others. While they're definitely skewed towards medium-to-large implementation projects, those are also the projects where resources to actually try new things tend to exist, rather than just grabbing what's easiest to snap in from the modules directory.

Some standout quotes:

• "I've seen vendors [launch big admin redesigns] a lot. They shouldn't. It's silly. [Editorial customization] work best with partners on the front line smashing down product constraints to meet client needs to get shit done."
• "it's always from the process backwards for me. what are the things you can do to make people lazy?"
• "The tricky part is understanding all the important ways people tailor their [editorial] processes in-market, and how your product can support that."
• "The embedding-content model is tougher to implement [than paragraphs-style stacking], but, done correctly, is considerably more flexible and powerful."

An informal poll of the CMS and Content Engineering groups that I participate in revealed that 50% of respondents simply "view content on its native page while it is still unpublished" to preview, rather than using any specific preview mechanism or system. about 10% use "side-by-side preview" and the rest are split between Medium-style in-place editing and having no preview at all. My hunch is that the side-by-side preview is not as common as an out-of-box option in existing publishing systems, so fewer people are exposed to it, but a more rigorous followup questionnaire is probably called for.

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?)

I would argue that the use case we must preserve is the integrity of meaningfully structured, remixable content with a content model that is designed by the builder of the site. It's important to remember that this isn't a pie-in-the-sky dream of an imagined future: it's the foundation of how Drupal already works today. Things like build modes, teasers, calendar views, sidebars of related content, and so on are built on a foundation of structured content. If we sacrifice that, there is literally no reason to use Drupal other than historical affection for the hook system. and the fact that we like blue.

Figuring out how to make managing and manipulating those things more straightforward, and easier for site builders and developers to tailor for specific projects, is good. But sacrificing those things to duplicate the Just-Click-And-Drag UI of a tool like Squarespace is not a way to make Drupal better, it's a way to make it irrelevant. We will end up with a more complicated version of Squarespace that still takes a dedicated developer to set up, and is harder to customize for non-Squarespace applications.

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.)

"Side by side" editing and previewing (the "Preview Pane" option described above) would, as KarimB said, be a big improvement for any existing Drupal site that hasn't invested in building its own bespoke preview system. Especially if the preview "on the side" is something that can be toggled off and on or otherwise hidden to reclaim the screen real estate.

The biggest danger is conflating the act of creating/editing and the act of previewing — i.e., making "Edit In Place" mechanisms the default rather than a possible option that can be enabled if the content model is simple enough for it to be practical. I've written a lot about that in the past, and so far nothing has changed.

Update: with quite a few more respondents in the quick poll about preview implementations, the numbers have stabilized around:

• 59% Just view the content in "unpublished" mode
• 25% Use no explicit preview mechanism
• 9% Use some kind of side-by-side preview pane
• 8% Use Medium.com-style in-place WYSIWYG mechanisms

One of my concerns is that a deep look at Drupal's editorial UX is an opportunity to fix a lot of deep "blocking problems" that plague real-world workflows; things like the difficulty many users have in choosing the correct content type from the available options, managing related content in entity-reference heavy situations, any so on. "How we handle previewing content" is a significant editorial concern, but it is not the only concern and a lot of the discussions that have sprung up seem to treat it as the defining characteristic of a CMS.

Are there other problematic scenarios and workflow speed bumps that we can identify in the interviews and research that have already been done — other than the preview/inline-wysiwyg issue? I'm curious what other problems are within reach while we have the metaphorical hood open.

I think a lot about what it is about Drupal that editors dislike. One thing that stuck with me recently was on https://www.gatsbyjs.org/docs/sourcing-from-drupal/#why-use-drupal--gats... :

Drupal is not-so-great for:
Content teams who require a slick content editing experience as it gets complex because of the multiple sections present

I think this is referring to how many Drupal sites are built in a way that they require editors to jump around between Block Administration, then to a Nodequeue, then to configure this entity and that one, in order to edit a landing page. This is not how I build Drupal sites, but I've seen many built this way.

There's a lot we can do in core to improve the editor experience, and I don't think previews or 'on-page editing' or 'inside out' is getting to the main issues.

Let's start with the fact that Drupal does not come with an Editor role by default. There's really no greater testament to the fact that we are not prioritizing for editors than that. We get by default an Administrator role (which I think would be better renamed to Developer to differentiate between the concept of a Webmaster and Engineer which Administrator makes ambiguous). And since we do not get a pre-configured Editor role many sites end up using Administrator role for their editors. The result of taking that shortcut is not only major security issues, but confused editors, as editors now have access to lots of configuration they shouldn't be using (they may have even found out some confusing thing about how sometimes when they configure things they lose the configuration when we next deploy- WAT?) and lots of complicated admin menus they don't need.

In fact, the organization of the 'admin' menus are geared toward admins (developers) and there is no menu built in geared toward editors. This is why they are forced to jump around into something called 'Structure' to add a Taxonomy term.

Personally I like to resolve all these issues by:
- Making an editor role and assigning it permissions to administer content, taxonomy, menus
- Using a contrib module so that I can let my editors manage other editors without having full access to all user management functionality
- Changing menu links and permissions around so that I can give editors a useful menu organized in a way that makes sense to them that doesn't include unwanted sections or access to configurations that are managed in code.
- Adding this 'editor menu' to the 'My Account' page for editors so they see their major options as soon as they log in.
- Creating and customizing content admin pages with Views so they have separate dashboards to handle different kinds of content.
- Creating editor-focused documentation and linking to it from their menu.

In other words, I don't think we need a whole new system for editing content. We just need an editor role with reasonable default permissions and an editor-focused dropdown menu and editors would likely be a whole let less confused.

We also need to build into Drupal the tools that help us keep editors onto a single form for managing a page. We should never have editors jumping around to Taxonomy, Blocks, Nodequeues, and other areas when they're editing a page. To do this we need to include Paragraphs in core so that it's used by default (but please rename from 'Paragraphs' to not be completely confusing), and include some useful basic paragraph types in Standard profile. I also fine the contrb module https://www.drupal.org/project/block_field very useful for letting me include Blocks within Paragraphs on landing pages rather than sending editors over to the Block UI. Inline Entity Form is also great for removing the need to go to multiple pages to edit something.

Eaton mentioned another lowish hanging fruit we have always had with editing above: we need the concept of deferred validation. Editors should not have to fill in every required field before being able to save a draft. I've often implemented custom solutions for that.

Another point he mentioned: the appearance of widgets for multiple fields. It needs to be optional whether we add tabledrag to fields as many multiple fields do not require reordering and the tabledrag makes your form look like crap. I've been using a patch for this functionality since 2014 and think it's an important issue. BTW editors have no idea what 'Show row weights' means.

One more point about Editors for my rant. I notice in many of Dries's presentations and materials that there is this lumping together of Site Builders and Editors. https://dri.es/drupal-long-term-growth-obstacles is a good recent example of this. As long as we lump together Site Builders and Editors as if they are doing similar things and have similar needs we will get nowhere with better usability for Editors. The two roles have almost nothing in common. They should not be using a single 'Admin' role and 'Admin' menu and a single 'Help' system. We should not have all this confusion in the UI between is it a 'node' or 'content' because we can't figure out if we're talking to a web developer or a marketing person. We've already got a config system that separates the concepts of what is config and what is content with a red line. Now we need that line in the interface as well.

As long as we lump together Site Builders and Editors as if they are doing similar things and have similar needs we will get nowhere with better usability for Editors. The two roles have almost nothing in common.

Jody, thanks for posting this. It's gold. I think one thing that's worth pointing out is that even on small sites where one person is filling the role of site builder and content creator, the two tasks are very different, and are rarely done at the same time. The exceptions — sites with just a few one-off nodes and not much structure — really are a better fit for tools other tools in most cases, and chasing after that use case is unlikely to help the scenarios that exist today in the Drupal ecosystem.

Agree with a lot of what Jody said, particularly:

Eaton mentioned another lowish hanging fruit we have always had with editing above: we need the concept of deferred validation. Editors should not have to fill in every required field before being able to save a draft. I've often implemented custom solutions for that.

Another point he mentioned: the appearance of widgets for multiple fields. It needs to be optional whether we add tabledrag to fields as many multiple fields do not require reordering and the tabledrag makes your form look like crap. I've been using a patch for this functionality since 2014 and think it's an important issue. BTW editors have no idea what 'Show row weights' means.

There is a lot of power, but also a lot of technical stuff in the UI that editors have never grasped nor should they need to. Generally, the clients I worked with were more aligned to the "I should only see what I need" group (less access to various sections, better naming for users, decluttered forms) in the admin vs a Gutenberg approach. The bigger ask was how to effectively preview content as they were doing it. In my case, most were indifferent to whether it was point-n-click/drag-n-drop blocks or form driven, so long as they could preview without saving and leaving the same screen. Jeff touched on preview enough so I won't go further.

Beyond that I largely share the same same sentiments.

I would argue that the use case we must preserve is the integrity of meaningfully structured, remixable content with a content model that is designed by the builder of the site. It's important to remember that this isn't a pie-in-the-sky dream of an imagined future: it's the foundation of how Drupal already works today. Things like build modes, teasers, calendar views, sidebars of related content, and so on are built on a foundation of structured content. If we sacrifice that, there is literally no reason to use Drupal other than historical affection for the hook system. and the fact that we like blue.

While I agree with what a lot of Jody is saying, I think most of that is crappy developers not setting up an editor menu, or assigning permissions, or creating roles... we don't need that out of the box. Developers need to take the time to think about their editors and set the site up correctly. That's what they get paid to do. Hell, I think it's highly doubtful those developers even test out the editor role and what it can do to even make sure the permissions are set correctly. Most of them don't even add help text for their fields... So if people are just using the "Admin" role to create content, they should be looking at their QA process.

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.

I have no idea how creating a true WYSIWYG experience takes away from Drupal's biggest strength of structured data. How? I know on every single Drupal site i have created, they all had/want some type of basic page that will allow them to create/add whatever they want to it. I'm sure quite a few of us use paragraphs, but once you start adding sliders (paragraph within paragraphs), views (which is structured data btw), accordions... etc, then you have all these collapsible fields to contend with. As an editor, I should be able to edit what I want, and see everything. But instead, I have to sit there and open each one, until I find the right paragraph I need to edit. Contextual links helps with this a lot so I train my editors to find the content on the page you want to edit, and then use those links. Helps with editing, not so much as creation though.

I think that first mockup will solve a lot of that. I don't see why we couldn't have some type of react/angular app that handled all the ajax calls and saving/loading of data for the draft states and previews. I should be able to select a view, "Upcoming Events" and place it above/below other content that may exist on the page. I should be able to edit that view on the fly which will change the display, so could change from grid view to carousel view, it would just change it. Sounds simple in my head? Once done there is a publish button that publishes the latest draft and removes the editing experience.

("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...)

Seriously? 2019 all my sites are responsive, that should solve w/e problem you think could exist with using a preview. Besides that preview should be the actual page in an "edit" state so it takes advantage of everything theme related. Just need the architecture in place to save a draft and load the draft versus the actual page. Right now going to an admin theme to edit content that's displayed on a different theme isn't it. Drupal should be able to hook into the actual theme and load the editing experience right on top of it.

Is it that complicated, or is it just the workload?

@iLLin I think the concern is that by offering a page-building experience as part of the default WYSIWYG editor, you're encouraging creating a lot of arbitrary content/markup in the body field, instead of breaking that content down into fields.

Most Drupal sites I see these days have a combination of structured content, and content that allows editors to pick the structure by adding different types of Paragraphs (not the same as putting arbitrary markup into a body field, but still less structured than distinct, predictable, required fields). And as part of the usability testing we've done recently (https://evolvingweb.ca/blog/drupal-admin-ux-study-what-we-can-learn-cont...), it seems that content editors understand the need for both.

As a follow-up to the usability testing, I did a write-up of more intermediary improvements that could be made to the Drupal content UI - including the suggestion to add a content editor role, autosave, etc: https://evolvingweb.ca/blog/5-ways-improve-usability-drupal-content-edit...

As our next step in the Drupal admin UX study, we're planning to conduct a follow-up usability test looking at how content editors create complex content (both structured and landing-page/magazine style content) to get more data about what UI patterns work well for both these use cases. Any feedback or suggestions about what we should test would be very helpful.

@pixelite I'm not talking about arbitrary markup. Im saying we should enhance the crap out of paragraphs which is all structured content. A WYSIWYG HTML Editor is only one piece of that. That first wireframe represents exactly what I'm talking about, I just don't know why we are moving away from (to me) seems like the right approach. Granted that wireframe still needs some work but its the right direction. I should be able to click "Add Slider", it should open some modal that has all my structured fields in it, I should be able to insert into page, it should render exactly like it should look, I should be able to drag it up and down below other paragraphs, and then press edit and the modal should come back up with my structured fields so I can make edits. Then I should have a publish button. Seems simple to me?

I thought panels was doing a good job with the frontend of drag and drop, but their editing experience was out of control. I haven't used panels in quite some type but it was an absolute mess.

iLLin: While I agree with what a lot of Jody is saying, I think most of that is crappy developers not setting up an editor menu, or assigning permissions, or creating roles... we don't need that out of the box. Developers need to take the time to think about their editors and set the site up correctly.

That's what the "Basic Profile" is for; a clean slate starting point for developers who are scratch-building a site and don't want cruft out of the box. The Standard Profile (and now, additional ones like the Umami profile) are explicitly empowered to go farther in setting things up "the right way" for common use cases.

So, I agree in the sense that I don't think we should hard-code a single "blessed" editorial workflow into Drupal. However, configuring the standard profile to separate the tools needed by devs and sitebuilders from the tools needed by content creators and editors strikes me as an uncontroversial place to score some easy points.

The problem is that setting up roles and permissions and workflows is simultaneously one of the easiest high-value, low-cost improvements… AND one of the places where the "perfect" setup is most likely to differ wildly from site to site. I think that's one of the reasons that we as a community are often so eager to treat big "moon-shot" features like In Place Editing as the solution to all of our ills; they're a big feature, but they don't require us to figure out how it should be deployed and integrated into a real-world workflow. We can demo it, then leave it to someone else to customize for real editorial needs… just like all of the other editorial capabilities.

It sounds like your'e trying to solve everything at once? Never gonna happen. You should pick one issue, and that's solving the content editing experience and making it better, like you said, Drupal has been "talking" about this for 10 years. I don't get how exposing API methods to a native IOS app, with decoupled data has anything to do with an awesome editing experience. Those are two different sites and quite frankly, and from your stats, sounds like its not worth this conversation. This editing experience should be something you can turn on like everything else and should be geared towards the web, not some native IOS app. I know Drupal has been "pushing" this whole headless Drupal stuff, but that's not the majority of users. Sorry to go on a rant here but I have been building sites with Drupal quite some time and this has been one of the biggest problems that has never gained traction.

[P]review-first UIs help basically ALL of the biggest "mental model" issues that new Drupal users face,

I know I keep saying this, but it needs to be pointed out: the data gathered in these UX studies you reference does not say that. It's not what was asked, or what was tested. The supremacy of preview-centric direct manipulation editorial tools is something you are convinced of, which is totally fine but not synonymous with "the data." I say this because I want it to be very clear that when I and others propose alternative appoaches, we are not "barriers to what must be done" — we are proposing different solutions to the same problems you care about.

[Preview-first UIs] are becoming *the* standard for pretty much everything "downstream" from us (WordPress, SquareSpace, Wix, Google Sites, you name it)

They have been the standard for low-structure, high-disposability content on the web for longer than Drupal has existed; this is not new. But editorial approaches that work for those low-structure, high-disposability content are not just suboptimal but actively harmful in many of the scenarios that Drupal has thrived in for more than a decade.

It's critical to remember that meaningfully structured content is not simply an investment in a far-off future full of Alexa and mobile apps. It's an investment in Tuesday, when you need to add webinars to the calendar of events. It's an investment in next week, when you need to fix the information that appears on Google when someone searches for your store hours. It's an investment in next year, when your boss wants a redesign and you don't have the budget to recreate every page from scratch.

Those are the kinds of scenarios that break first when preview-centric direct-manipulation tools are the centerpiece, and it's not because the people who build those tools are dumb and don't try hard enough.

direct manipulation / aka "WYSIWYG" is just the most inherently intuitive to humans, and sadly we have not yet replaced all content authors with robots

Again, this is not a fact, it's a (bold and somewhat controversial) opinion. Suggesting that preview-first direct manipulation editorial tools are the only alternative to "replacing content editors with robots" is a cop-out, and devalues the decades of work that content, UX, and publishing professionals have put into systems that support their editors' needs in complex content scenarios.

To reiterate, I propose the following approach for our "next generation" editorial interface:

1. Save entities in "draft" state as soon as content editors enter anything on the edit screen.
2. "Required" status for fields is enforced on a per-state basis, allowing incomplete drafts to be saved without errors.
3. Derive all previews from persisted entities, not intermediary pseudo-entities that only exist during the edit process.
4. Provide two approaches to previewing in core — an edit form with a link to a stand-alone view of the Entity in its default build mode, and a "side by side" Preview Panel that loads that same entity build mode in an iFrame or some similar DOM-isolated mechanism alongside the edit form.
5. Allow contrib modules to alter the preview panel (adding a locale switcher, changing the build mode, changing the iFrame's dimensions to simulate different screen sizes, etc)
6. Allow site builders to disable the preview panel entirely and replace it with other mechanisms from contrib.
7. To improve the actual editing experience itself (not just the preview step)…
1. Create an "Editor" role that ships with the standard Install Profile and tailor its permissions for organizing, creating, and reviewing content.
2. Trim cruft from our standard field widgets, especially multi-instance fields. This is a major contributor to the visual clutter of the content forms. (Thanks, Jody!)
3. Examine ways to lead people through the full content creation workflow (Selecting a content type, creating it, reviewing it, and publishing it). Focusing on the edit form in isolation (or alternatives to it) will always be clunky, because real world creation requires all of those steps
4. Assess the readiness of tools like Entity Embed, Inline Entity Form, Entity Browser for inclusion in core. Highly relational content models are a Drupal strength, but the workflow of creating and associating "clouds" of related entities is where it breaks down badly.

This is a testable, achievable approach that would deliver incremental benefits at every step of the way without crippling meaningful structure. I'm willing to organize efforts to wrangle developer-time to implement them, and coordinate with the ongoing JS Modernization initiative, which has been uncomfortably tangled with administrative design efforts.

There's lots of other low-hanging fruit that can fit under item 7 in that list, but I believe — strongly — that it will take considerably less work and create fewer negative ripple-effects than universalizing a preview-first direct-manipulation interface that actually works for real-world Drupal sites.

Any specific objections to this plan?

Sorry, no, no objections to that overall plan! I'm trying to respond in bits and pieces in between other things and it's taking a bit. :)

The ever-popular fractal explosion of reply chains that characterizes the most memorable d.o. threads ;)

Fist, I’d like to thank you all. You can’t imagine how useful this issue is being. Really.

Our responsibility is to make future-proof decisions that will keep Drupal meaningful. We’ve been talking about the Web vs «“content store” to be accessed via API» product direction for months and I’m sure nowadays there’s no doubt the later is the future (if not the present) and structured content is the only answer to that. We can’t talk just about serving content to the classic responsive Web anymore even it’s still a big portion of our cake.

From #9:

There's a lot we can do in core to improve the editor experience, and I don't think previews or 'on-page editing' or 'inside out' is getting to the main issues.

With everyone's comments I’m starting to have this same feeling: maybe we’ve been too focused on content preview, and it’s not the only key point to improve Drupal’s UX.

From #9:

I think this is referring to how many Drupal sites are built in a way that they require editors to jump around between Block Administration, then to a Nodequeue, then to configure this entity and that one, in order to edit a landing page.

+1 to this. IMHO plan a good Information Architecture for content authors (instead for site builders/site admins) is a huge step forward to improve Drupal’s complexity perception.

About including Paragraphs in core, I agree on the need to have some way to use predefined pieces of content AKA components. But maybe Paragraphs is not the solution. Maybe tools like Entity Embed or Inline Entity Form can open new ways to work towards that direction. I’d leave this discussion for another issue though, since it’ll need technical points to be made that could move this useful discussion from its main purpose.

From #12:

we don't need that out of the box. Developers need to take the time to think about their editors and set the site up correctly.

Basically, I 100% agree with @eaton’s comment on #17. Good decisions made by UX expert improving the out-of-the box setup for authors is needed because the Standard profile has remained almost intact for years. Time for improvements here too :)

From #12:

as an editor, I should be able to edit what I want, and see everything. But instead, I have to sit there and open each one, until I find the right paragraph I need to edit.

That's a really good point that we can't forget. But maybe good project documentation can solve this, or even a Style Guide or better icon representations. Let’s not try to solve everything from the beginning and in core and… let’s not forget about the incredible work done by the Layout initiative for this “in-place” editing experience that can be used in current projects. Maybe we're not even talking about the same node editing workflow when we talk about landing pages.

From #16:

such as adding an editor role (this was one of the issues identified in the most recent 2015 study (and probably others), but sadly no one has volunteered to do it yet)

+1, this has to be part of this initiative.

Finally, I totally subscribe @eaton’s plan, but I’d add to plan the IA for content authors. We need to create a new menu or restructure the current Administration one. This is a key decision we need to make now to move forward with the wireframes: 1. same or separate menus, and 2. its placement (only ––as Jody’s suggestion–– in the “My account” page/dashboard” or an all-pages menu). Personally, I’ll go with a new menu present in all pages that we’ll handle how to place nicely in the wireframe/design steps. Let's see it as the shortcuts menu refresh ;)

+1 to this. IMHO plan a good Information Architecture for content authors (instead for site builders/site admins) is a huge step forward to improve Drupal’s complexity perception.

I think this is one of the key assets for the new experience. I also think that currently the UI is very focused on a site builders daily job and little on the content authors experience. Bringing in a good experience for content authors doesn't mean a bad experience for site builders. Trying to get the best experience for both is key in my eyes.

I like Eaton's plan in comment 19!

About including Paragraphs in core, I agree on the need to have some way to use predefined pieces of content AKA components. But maybe Paragraphs is not the solution. Maybe tools like Entity Embed or Inline Entity Form can open new ways to work towards that direction. I’d leave this discussion for another issue though, since it’ll need technical points to be made that could move this useful discussion from its main purpose.

Although I think it's super important to evaluate where it (and other similar options) are at, I'm not convinced it's ready for core either; I've spent some time comparing notes with the Layout Builder initiative team to figure out whether the block system might be a good starting point for a paragraphs-esque/entity-embed/layout-builder solution that would bring some unity to the currently fragmented component content landscape, but there are lots of smaller blocking issues along the way before any of it could be called fully baked.

Agreed it's a parallel path, but I think it's probably a good one to spin off a side discussion for. After some Slack discussions, I'll be moving some of the high level points in the plan outlined above to the github issues of the js admin project, and we can figure out if others merit specific d.o issues etc. Sound good?

There's a link ("wireframes") in the first sentence of the issue summary, without a href. Should that point somewhere?

That's a really good point that we can't forget. But maybe good project documentation can solve this, or even a Style Guide or better icon representations.

How sucky is it, that to be able to edit content, I have to open up some manual to figure out what to do. Yea, that's putting the content editors first.

We don't need paragraphs in core if the layout builder will solve this issue. We just need something component driven, with a preview that is just easy to use, and simply just works. Drupal would be so much easier to sell...

i personally like how medium & gutenberg bring content to the center of attention so that the editor can focus on its main task: writing meaningful & well structured content.

having a great preview functionality would be nice to have or important for certain types of users but there's also a lot of arguments against wysiwyg approaches as mentioned before.

i would focus on improving the editing experience itself as a first priority and put previews into its own experimental side-project where the idea can evolve without being a blocker for the rest. would there be concerns against this approach?

Fixed the link to the wireframes
Thanks for pointing out @andrewmacpherson

If everyone thinks that a solid editing experience doesn't involve a preview... you're all wrong.

If everyone thinks that a solid editing experience doesn't involve a preview... you're all wrong.

I think preview is definitely a critical feature — but what it means and how it's presented and integrated into the editorial workflow is not a foregone conclusion. Having a "Preview" button that actually reliably displays how a piece of content will look on the front end of the site, for example, is currently impossible in Drupal due to the way the FormAPI and entity persistence interact. Fixing that will make Drupal's existing "Preview" button orders of magnitude more useful, regardless of whether realtime preview-while-you-type, decoupled preview-as-a-service, or WYSIWYG edit-in-place gets the spotlight.

The only preview while you type should be the WYSIWYG editor. Everything else should be structured with fields and a "insert into page" button. THEN it renders correctly. THEN you should be able to drag it, re-edit it, change the view mode or delete it... etc. Clicking a "Preview" button (even if it did work) is annoying to the user. But that solves nothing as far as the editing experience goes. I think both of these endeavors should be strongly linked.

Thank you all for this discussion, I'm very happy about that. The nice thing about Drupal is -- like every good democracy -- it's not only about what "the majority" of users would like to have next week, but to find a future proof solution everyone is okay with. :).

I personally use Drupal mostly to build web applications and I'm very happy about the route Drupal takes here. WYSIWYG is not the only use case as eaton pointed out already.

Also, for editors working in magazines with a lot of text, it can be rather distracting to be bothered with the layout details. It is a good feature not to always mix layout and content -- you would not want to write a novel in Page maker...

Under our continuous upgrade path and deprecation policy, feature and API additions should be added with backwards compatibility in minor releases, so moving to 8.8.x. I realize this is a high-level issue that is actually about Drupal 9 and the future in general, but it does belong on a minor feature branch as something that would be added to a minor eventually. Thanks!

For WYSIWYG future better use #3091226: [META] Select the best modern editor for Drupal 9
There's also related
- #2966864: Add optional support for CKEditor 5 in D9 so we can remove CKE 4 from Drupal 10
- and even #3091766: Make Gutenberg as D9 Core module

We use the dxpr Builder somewhat obligated because it is the only Builder the users like!