Tracking issue: Normalize details view with inspector controls in site editor

[ntsekouras]

In site editor currently the details view in navigation sidebar about the selected entity(page, template, etc..) shares a lot of information with contents/panels in the inspector sidebar.

Details	Inspector

It would be good to merge them and see how we can eventually make a reusable component that can used in other places too. An example would be to show the inspector controls somehow in the entities list that use the new Data Views(pages, patterns, etc..).

The process should be additive and not reductive. We should add whatever is missing from the details view to the inspector controls. Some duplication already exists and it's fine to add a bit more until the changes have completed.

Details view contain a lot of readonly information in contrast to inspector controls. If some item can be made editable(ex Featured Image), it should be added with edit functionality.

The issue is not exhaustive and design can be discussed either here or on the related PRs. It's meant to be an initial break down of tasks to parallelize work and can be updated.

Design

Tasks

• Move the readonly items Editor: Add wordcount and reading time info in post card #60672
• Move the Featured Image
• Consolidate the ellipsis menu currently in details view with the main entity info(page card, etc..). Related to that could be to check the actions we have in Data Views and also consolidate with them.(PR)
• Move revisions info
• Provide a way to make the title editable, either with rich text or a rename action in ellipsis menu(will need design discussions)
• Move excerpt/description Editor: Update post excerpt panel with new designs #60894
• When the complete merge has completed, we should remove/deprecate the details interstitial page for content views. Related issue for this is the advancing site editor index views.

[jameskoster]

Surfacing the Inspector in data views is an exciting idea, it can (in theory) serve as a quick edit interface in data views, replacing this:

It can also potentially function as a bulk edit interface when multiple records are selected.

This could be a good time to refine some design elements of the Page inspector too. There are a lot of panels there, with certain data given outsized prominence (e.g. Page Attributes). We can narrow down the panels, and better define how/when they appear based on context for greater consistency across post types.

Here’s an initial take on how we might do that:

Title panel

Includes the document title, description (optional), and any uneditable meta (also optional).

Any actions associated with the record also live here. They will be contextual and follow a similar convention to data views: primary actions surfaced as single-click quick-actions, ellipsis menu contains all actions. For pages this would be things like renaming, viewing, trashing, etc. For templates and patterns it might be; clearing customisations (for theme-supplied assets), viewing revisions, duplicating, and so on. In most cases these actions already exist.

Summary panel

Contains any editable meta data associated with the selected record. It’s very similar to the existing ‘Summary’ panel in the page inspector.

Content panel

The content panel only appears when the user is able to edit content, IE when they are editing a document.

It lists all the blocks containing content that users can edit. Clicking a block selects it on the canvas. It works the same way as the ‘Content’ panel you find in the page inspector, or when editing a container with "templateLock": "contentOnly".

Design panel

In the Design panel users can modify the appearance of the selected record. That includes actions such as:

• Swapping the template applied to the page
  • Toggling the template visibility
  • Creating a new template
• Applying a theme-supplied pattern to a template
• Changing the block style variation of a section (and potentially page / template too).

This panel will appear when editing a record. In data views we could consider surfacing it when there’s a visible preview (side-by-side layout). This probably requires some further exploration.

Let’s put all of this together in some examples:

Page

When observed from a data view the Design and Content panels are hidden, and a close button is added to the title panel.

Template

In editor	In data view

Pattern / Template part

In editor	In data view

Bulk editing

Obviously this is a bit further down the road, but as a quick demonstration here's how the inspector could theoretically handle multiple records to offer bulk editing in data views:

---

In addition to any other design feedback, it might be interesting to consider whether certain panels should be collapsible or not.

[jorgefilipecosta]

Hi @jameskoster,

The new "Level" option will include all of the current "Page Attributes" section? E.g. when clicked it will open a modal that allows the user to choose both the page parent and the order?

[jorgefilipecosta]

The "Edit exercerpt" is a normal action when clicked it will open a modal where the user can change the exercerpt that will also work on dataviews?

[jameskoster]

@jorgefilipecosta good questions :)

The "Level" option would open a popover where you can select a parent page. "Organization" might be a better label:

The "Edit exercerpt" is a normal action when clicked it will open a modal where the user can change the exercerpt that will also work on dataviews?

I think it's probably okay to start with a modal. But if it's not too much trouble then it might easier if users could simply click to add/edit excerpts. Then we could remove 'Edit excerpt' to make that menu a bit shorter:

What do y'all think?

[SaxonF]

@jameskoster could we just start with two separate attributes in summary panel? "Organisation" may be confused with team/account, and parent seems important enough to be highlighted as its own thing.

Parent: None 
Order: 1

[SaxonF]

Does this issue include the work to remove the existing details views once the gaps are closed or should we spin up a separate issue for that?

[ntsekouras]

Does this issue include the work to remove the existing details views once the gaps are closed or should we spin up a separate issue for that?

It could be a standalone ticket, but I think for now it could be just a task here:

When the complete merge has completed, we should remove/deprecate the details interstitial page for content views.

[jameskoster]

Parent: None

I've seen feedback that this doesn't clearly communicate the page is top level, but seems fine and iterative.

What's the motivation for placing order in a row? It seems a bit prominent for a setting that is potentially confusing, and practically useless in most cases.

[youknowriad]

In terms of tactics to approaching this issue: can we focus on bringing the missing items that exist in "details" but not in "inspector" into "inspector" first and leave the redesigns for later.

The goal is to be in a state where we ready to remove the "details" panels for 6.6 and the polish/design can happen at any time (in 6.6 and further)

[jameskoster]

Yup, good reminder :)

For pages the missing pieces are; excerpt, word-count, and time-to-read.

The latter two can appear alongside the 'last modified' detail, and excerpt can be displayed (uneditable) beneath the featured image (likely with truncation to four or five lines):

---

For templates we're missing settings. These can take the same format as post meta (displayed in rows that open popovers):

---

For patterns / template parts we're missing sync status and description. Description can appear beneath the title. Sync status can be indicated via icon color, and the inclusion of a chip similar to the one found in data views:

[jorgefilipecosta]

The new discussion panel design is proposed at #61357.

[jameskoster]

@ntsekouras I noticed that now that we've added the post title to the Inspector, it gets repeated on mobile:

We can probably remove that mobile-only panel heading now.

[jameskoster]

Yeah, I'm not very fond of actions boolean like, as Jorge describes.

@ntsekouras will this also apply to the "Stick to the top of the blog" option for posts?

[jameskoster]

I updated the OP to include the latest summary panel designs. Details can still change a little but this seems fairly solid now.

The main missing pieces in terms of 6.6 seem to be:

Pages

• Author row.
• Parent row.
• Re-order action (may need to be a row in the summary panel based on technical feedback).

Posts

• Taxonomy rows (e.g. categories / tags).
• Sticky row.
• Author row.
• Remove 'Move to trash' button.

Templates

• Settings for templates like Blog Home.
• Move 'Areas' to dedicated 'Content' panel.

Patterns / Template parts

• Remove 'Revisions' panel.
• Move 'Pattern categories' to a meta row rather than a panel.
• For synced entities the icon should be purple.

Navigation menus

• Remove 'Revisions' panel.

All

• 'View revisions' menu item should include the number of revisions as a suffix.

[ntsekouras]

I've started work for moving the home template details to inspector controls.

[youknowriad]

What's left here? Should we close this issue now?

[ntsekouras]

I think we can close this as its main goal was to move info from details view to inspector controls. There are some small things to polish in inspector controls, but can be tracked separately like in this issue: #60291.

[jorgefilipecosta]

Hi @jameskoster,

Regarding: "Move 'Pattern categories' to a meta row rather than a panel.". It seems like the categories here are like the tags or categories of a post. In a post they are in a panel should the patterns be equal? If we move to a row the issue is that a pattern may have 4 or 5 categories and the row may become huge but I can give it a try.

Regarding "Settings for templates like Blog Home" I guess it was the post per page and discussion settings which is now concluded right?

[jameskoster]

@jorgefilipecosta I think we can hold off on that one until 6.7. There's a dedicated issue and some discussion here: #61852.