WordPress
Tracking issue: Normalize `details` view with inspector controls in site editor
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.
Tasks
- [x] Move the readonly items https://github.com/WordPress/gutenberg/pull/60672
- [x] 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
- [x] Provide a way to make the
titleeditable, either with rich text or arenameaction in ellipsis menu(will need design discussions) - [x] Move excerpt/description https://github.com/WordPress/gutenberg/pull/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.
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.
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?
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?
@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?
@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
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?
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.
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.
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)
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:
I've started working on the excerpt/description. @jameskoster from the designs I get that the excerpt/description should be readonly and we should have an action in the ellipsis menu to edit it. Is this correct?
Sprinted on some visual/compositional details around the summary panel with @jasmussen:
- Less prominent "Add featured image" button
- Move uneditable meta (e.g. word count) beneath excerpt/featured image/description
- Move status chip into editable meta and add label
- Tweak some spacing / type styles
I'll open PR's for these adjustments as time allows.
Posted some initial a11y feedback specific to the excerpt UI hre: https://github.com/WordPress/gutenberg/pull/60894#issuecomment-2082448458
Hi @jameskoster, regarding the new discussion panel design. The modal only refers to the comments part and not the pingbacks/trackbacks. There is an option for pingbacks and trackbacks on the actions menu, but the actions menu right now only supports button where an action happens on click. Would it make sense to have the modal control comments and trackbacks and the description text be something like "Comments and pingbacks enabled", "Comments and pingbacks disabled", "Comments enabled and pingbacks disabled"? The issue is that it may be much text? Maybe two models one for comments and the other for pings backs would also work? Would that be ok? Which option you prefer.
If we want to go with the actions menu possibility, I guess we could try to implement a new type of boolean actions. But boolean actions are almost like a field where on click we change the field value. So boolean actions as a concept may not make sense. We could try to implement something custom on the menu for posts but I guess in that case it would not be available on the action menu in dataviews ( the menus would be slightly different) but I guess that's ok.
On the details panel for template parts with navigation include a navigation editor. Should we also include that navigation editor on the inspector for template parts.
The synced status I think it is not needed given that template parts are always synced. But we can use the proposal for patterns in template parts too.
but the actions menu right now only supports button where an action happens on click
@jorgefilipecosta can't we use DropdownMenuCheckboxItem DropdownMenu V2?
If not, then two separate rows/popovers (one for discussion, one for pingbacks/trackbacks) might be better.
Should we also include that navigation editor on the inspector for template parts.
Good question. I think it would be nice to include. As a start, could we reuse this panel from the Navigation block?
A quick mockup:
but the actions menu right now only supports button where an action happens on click
@jorgefilipecosta can't we use DropdownMenuCheckboxItem DropdownMenu V2?
Hi @jameskoster, yes we could use the DropdownMenuCheckboxItem. The issue is that that menu only shows "Actions" and right now an action is either:
- A button that when clicked executes something on a set of data.
- A button that when clicked shows a modal that allows to execute something on a set of data.
One option to have the pingbacks in that menu would be to implement a new type of action which is essentially a checkbox. But I am not sure if an action with a boolean checkbox makes sense as a concept because what would differentiate an action like that from a field that is a boolean? "Move to Trash" is also essentially just switching the status field of a post. We could also consider "Allow trackbacks/pingbacks" as an action "switch pingbacks/tracksbacks" state. We would still require an expansion in the actions API to allow something like isChecked( item ) which decides if the checkbox is checked. @ntsekouras and/or @youknowriad would something like that for the actions make sense?
Yeah, I'm not very fond of actions boolean like, as Jorge describes.
The alternatives I see are:
- Two panel rows for them. Although if we separate them I'm not sure we could keep the
discussionlabel to show one item, where we used to show two items. - One
discussionpanel that open a dialog with both, and in the row panel we show a text for both values. Ex.comments on/trackbacks. This could be big though and maybe an icon for trackbacks could be enough? 🤔
Should we also include that navigation editor on the inspector for template parts.
Good question. I think it would be nice to include. As a start, could we reuse this panel from the Navigation block?
Hi @jameskoster,
We could not reuse the panel from the navigation block as is because it is implemented inside the block and they have block inspector-specific logic. But we can reuse the components used below and make the following simplified navigation editor:
- When an item is clicked we select that block and move to the blocks tab.
- The options available for an item are move up, down, and remove.
- Options like adding a submenu or append items would not be available as that would mean almost a new off-canvas editor.
When there is more than one menu in a template part, we would follow the template approach:
Show a "menus" area with the menu names. When clicked a menu would be selected and we would switch to the block tab. Similar behavior to the left sidebar right now that shows a list of menus.
We could also follow this approach when there is only a single menu. Show a "Menus" area with a single menu. When clicked it would navigate to the block tab with the full editor for that menu. Let me know which option would you prefer for the single-item case:
- Show a simplified editor for that single menu directly.
- Show a "Menus" area with a single item that when clicked goes to the blocks tab and allows full editing capabilities for that menu.
Re the Discussion panel, here are visuals for the options as described:
There are trade-offs both ways. The long button label in the first option looks a bit clunky. In the second option I'm wary we're giving too much prominence to pingbacks and trackbacks, and the long label looks clunky.
To be honest I don't have a strong feeling either way, and would lean towards which is most straight-forward to implement. I think it's a detail we can revisit later.
cc @jasmussen in case he has any ideas or strong feelings.
Re the Discussion panel, here are visuals for the options as described:
There are trade-offs both ways. The long button label in the first option looks a bit clunky. In the second option I'm wary we're giving too much prominence to pingbacks and trackbacks, and the long _label_ looks clunky.
To be honest I don't have a strong feeling either way, and would lean towards which is most straight-forward to implement. I think it's a detail we can revisit later.
cc @jasmussen in case he has any ideas or strong feelings.
Thank you a lot for the mockups, I'm working on an initial implementation of this.
@jorgefilipecosta thank you for the information on navigation options. I think we may need to mock up the options here before making a decision. Leave it with me :)
To be honest I don't have a strong feeling either way, and would lean towards which is most straight-forward to implement. I think it's a detail we can revisit later.
Pingbacks and trackbacks provide a nice way for one blog to notify another that it's quoting it. As a feature, it's probably not broadly used today, but I still have fondness for it. But it's also one of those features where you set the default in your discussion settings, and then often forgetting about it. In other words, the main use case for the availability of this control in context of posts and pages is to change that default, locally.
For that reason, and because it's grouped with other commenting/discussion settings in the general settings section, I'd suggest putting trackbacks inside the Comments popover. If need be, the "Comments" label can be renamed "Discussion" to match its settings counterpart.
@jorgefilipecosta for the navigation menus... assuming the Inspector will only be accessible in the full-screen editor for 6.6 (with access in data views coming later), I think this approach is probably the way to go for now, both for single-menu and multi-menu scenarios:
When an item is clicked we select that block and move to the blocks tab.
So, when editing a Header template part, the Inspector would include the following panels:
(I appreciate the "Site Logo" and "Site Title" items would come later).
The new discussion panel design is proposed at https://github.com/WordPress/gutenberg/pull/61357.
@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.
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?
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.
I've started work for moving the home template details to inspector controls.