Optimise the content-centric edit experience in the Site Editor

[jameskoster]

This is a part of #41717.

When you invoke edit view with the primary intention of modifying content (IE by selecting a page in the Navigation panel), the experience is rather lacklustre, due mostly to it being designed and built around the idea of editing templates.

Since we want to re-introduce content editing (#44461) in the Site Editor we should identify and address these issues.

• The lack of boundaries between template & content make it too easy for folks to inadvertently edit the template rather than the content. Experimenting with ability to focus on editing the post or editing the template #49292
• The document title is currently only capable of displaying the template title Document title when opening a page via Site Editor's Navigation panel is a bit confusing #48641
• The Post Content block is invisible when empty Blank state for post content block #49086
• The document inspector should reflect what you're editing (Page or Template, etc).
• Add key features to achieve parity with the post editor:
  • Site Editor → Page Details: Link 'Last modified' detail to revisions #51343
  • Site Editor: enable option to publish pages #49873
  • Editing meta like status (Site Editor: enable option to publish pages #49873)
  • Template switching (Site Editor → Page Inspector: Add ability to switch templates #51347)
  • Trashing (Command Palette: Mapping Contextual Commands #50407)

[porg]

As a concretely actionable improvement for content-centric editing please add:

• Site Editor shall know from which ID it got invoked and initiate with that page/post content and the underlaying template #49438

[annezazu]

Want to note these two issues for possible inclusion: #49871 & #49873

[SaxonF]

The lack of boundaries between template & content make it too easy for folks to inadvertently edit the template rather than the content

Adding context to this piece.

Problem

One of the major pain points we’ve observed is confusion around whether you’re editing page content or template content when in the site editor. This is currently mostly an issue when editing your homepage on a theme that doesn’t make use of the front-page template. However, with the introduction of the navigation panel in the Gutenberg plugin you can now browse and edit any page on your site which will only exacerbate the issue. The way we navigate to content to edit may change in future (e.g. introduction of pages panel to site editor) but this problem will remain.

Proposal

One of the proposals that has been discussed is drawing stronger lines between template and page to the point where editing any global element requires a deliberate action. This is a behaviour we should aim to adopt for all global elements, including in future synced patterns. One mental model to learn no matter what you’re editing.

POC

It’s incredibly difficult to get a feel for how this would work through a static Figma prototype, so over the last couple of weeks @noisysocks and I have been working on a branch that you can now play with to see how these stronger lines feel in practice.

This piece of work, and the rest of the related issues across here and here, begin to transform the editor from just a template editor, to an actual site editor that paves a pathway to a unified editing experience.

[porg]

I hope this very issue here is the correct place for my feedback

• Until including v15 there was this "very blurry line" between Site Editor and Block Editor.
• As of v16 the first thing which was VERY noticeable to me was the clear segregation/distinguishment between editing a template vs. a concrete page-instance.

Usability — Self observation

• A clear distinguishment between template vs. page editing certainly helps orientation/onboarding for beginners and also inattentive pros.

• But for advanced and expert users: Template editing with concrete instances is SO MUCH MORE powerful than with sample/placeholder content. The difference is like day & night!

  • Because very often you can only judge the stability and consistency of your template with concrete data, e.g. long titles that wrap, or the interplay of a menu with very different types of Post Content, etc.

  • So much better and efficient when having Site Editor and Block Editor in one!

User Experience — Professional Opinion

• Having only these strictly segregated modes is honestly a step back!

• Leads to the oldschool behavior: "Edit here, preview there"

  • Browser window/tab °1: Template with placeholder content opened in Site Editor.

  • Browser window/tab °2: Concrete page instance in Frontend or Block Editor.

    • Reload, Reload, Reload…
    • Just plain oldschool in regards to the Frontend.
    • Even more problematic if the page is opened in the Block Editor.
      • Takes way longer to initialize (all the JavaScript stuff) in comparison to Frontend, and loads the template stuff likely only on init.
    • Whereas in the combined Site/Block Editor template and page content were always up to date and in sync!

  • This is a real big regression to typical Webdesign workflows as common since the end of the 1990ies.

• The intermix of Site Editor and Block Editor in comparison is so very progressive!

  • Admittedly mentally challenging at the very beginning (because not transparently informed during entering but the earliest explicit notice is as late as when saving! )

  • But once you grasp this, you have very powerful & efficient capabilities!

Followup

• Don't got me wrong: Being clearly informed along the way, and having to explicitly switch modes, please keep!

  • But I very strongly propose to also offer a way to get to the behavior of also opening concrete page instances for editing templates. I guess you came to similar conclusions, hence opened:

  • Re-Introduce Content Editing in the Site Editor #44461

• Publishing as the situation is in 16.0.0 into main WordPress would be a step forward in transparency but a step backwards in capabilities.

  • Please only push Gutenberg to WordPress once BOTH transparency and capabilities are fine enough to constitute a worthy update for mainstream WordPress!

[jameskoster]

I think this issue can be closed – the content edit experience in the site editor has evolved a lot in the lead up to 6.3. The remaining items can be handled individually and are more about achieving functional parity with the post editor.

---

But I very strongly propose to also offer a way to get to the behavior of also opening concrete page instances for editing templates

@porg I'm not entirely sure what you mean here, but it sounds a bit like #28466?

[porg]

@jameskoster Yes that linked issue deals with my concerns. Re-posted there in shortened & updated form.

[porg]

Please take it to heart really. My feedback is a high level feedback, not an actionable proposal. But take the gist of it please!