Meta actions on details view

[mtias]

We need to outline all the contextual functions and map the design elements for the various meta functions that can be performed in the details view, and improve upon the anemic "saved" state.

Section header

Here we have the ellipsis button, the main "edit" (where appropriate) and the beginning of high level status info. Styles can include visualizing style book here, for example — #50393

Ellipsis menu

To include the following actions:

Template

• Reset – for theme templates that have been customised.
• Delete – for any user-generated templates.
• Rename – for user-generated $custom templates.
• Replace – if any patterns associated with the active template can be found.
• Duplicate action would be nice, but may need to be restricted to $custom templates initially. We need to figure out scope selection when duplicating templates such as Category.

Template part

• Reset – for theme template parts that have been customised.
• Delete & Rename – for user-generated template parts.
• Replace – if any patterns associated with the active template part area can be found.
• Duplicate – creates a new template part with the same details / contents. The name could be Current template part (copy). Or we could ask the user to supply one.

Page

• Trash – sends the page to the trash.
• Duplicate – The naming convention should be consistent with template parts.

Status

Mockup

• Add badge to communicate status in page details (Site editor sidebar: add page details #50767).

Footer

This is the save and revisions area.

• Display revised date with access to revisions
  • Page – Site Editor → Page Details: Link 'Last modified' detail to revisions #51343.
  • Template – part of Details View → Templates #49597
  • Template part – part of Details View → Template Part #50392
  • Styles – part of Details view → Styles #50429
• Keep an eye on the future of collaboration (multiple authors, who is currently editing).

Contextual navigation

• Access to themes from Design root
• Access to wp-admin page list from Pages panel
• Access to manage reusable blocks from Library panel

[SaxonF]

I'm a little bit concerned about the scalability of the approach we've taken with the save dock. This is something we've discussed in the past, and we landed where we are to be able to push 6.2, but given how site editor admin is expanding I think it's worth reconsidering.

The issue stems from mixing global changes with local. Make a change to a page (e.g. post excerpt/slug, or posts per page), do you expect the "save" button to save all changes you've made across your site or just the change to the current page? We've received similar feedback like this across the community (e.g. see Saving is SUPER confusing when you start navigating the site editor section here).

The issue is less pronounced in the editor because of the stable toolbar at the top. As soon as you switch to site view / admin the toolbar goes away and you're in a space that allows for navigating in/out of different contexts.

I don't have any proposals other than prompting to save when leading edit mode and ensuring all save actions within site view / admin are localised.

I agree though that the footer of the sidebar is a decent spot for secondary links.

[jasmussen]

Given the save dock is out there, it seems feasible to have something in place for 6.3 that keeps it as is. That doesn't preclude us from further explorations in the future, expanding or changing the save hub based on what we learn both in the plugin and what is able to land.

Taking a stab at what exists, and based on the outline noted, here's a quick take:

• Design root: Access to themes
• Styles: Access to styles outside of the current theme.
• Templates: Access to managing all templates
• Pages: Access to managing all pages
• Navigation: Access to revisions

Of these, I'm the most uncertain about the details of "access to styles outside of the current theme". What could be a flow here? Is it similar to "Browse themes"? Or is it a drilldown to style variations from other themes you have installed?

Figma

[mtias]

We need to be able to display more than one thing. For styles, revisions are very important while more styles is more discovery / theme browsing related. Also, like you mention, we don't have more styles today, so we cannot add it.

I'd also like to see us settle on what belong to the ellipsis menu next to the section title (where we can have delete, duplicate, etc) and what at the save areas. For example, access to history / revisions could work in either.

Can we also include examples of individual resources? (A page, a template.) Where the published date, status (pending review, scheduled) are more important.

[jameskoster]

How do these buttons fit when there are unsaved changes?

It doesn't seem impossible that some panels could demand more than one quick link. Is that a way to allow for scaling?

[mtias]

What's the value of the "1 unsaved change" text?

[jameskoster]

The value isn't that high compared with the quick links, especially as the save modal includes the same information. I wouldn't be opposed to removing it as a part of this work.

[SaxonF]

save-page-detail.mp4

Here's a potential iteration. I don't think the actual "Save dock" should contain any actions/links that aren't related to the act of saving. I'd separate the two more groupings clearly with save dock always fixed to the bottom, and related links/shortcuts stuck above but still pushed down by the section content. Ignore the "manage pages" link, just an example of positioning, I actually don't think we need any for pages right now.

In the example above, showing a page detail, you can start to see how the global saving model we've adopted breaks down. Do we show change info pertaining to the current context? What if there are site changes but not to the page, do we still show a save action? If we do still show a save action, does it still make sense to show info relating to the current context? (e.g. when page was last modified)

Since we can't make any larger changes for 6.3, what I would suggest is the following:

• Keep the save dock / action always signifying global changes for now
• In the save dialog, highlight the current context with other changes deselected by default (e.g. page, styles). This can be done as part of the save dialog refinements work
• Revisions link can open revisions of whatever context you're currently in

I'd also like to see us settle on what belong to the ellipsis menu next to the section title (where we can have delete, duplicate, etc) and what at the save areas. For example, access to history / revisions could work in either.

A general rule might be

• Save dock contains anything relating to the act of saving/revisions and is fixed to bottom
• Secondary actions of the current context are within ellipsis menu
• Related links / shortcuts stuck to bottom but still pushed down by content

[draganescu]

What's the value of the "1 unsaved change" text?

I think the value is that it's a reminder that some work may be lost because it's a change that stays in a background "memory", which the computer has but maybe the user has not. The site editor allows one to quicky move in a sort of multi dimensional "space" of focuses so it's not easy to keep track of all the stuff.

The fact that the save button is active and blue is a good affordance for the same thing, but this text may be reassuring for when say your internet sattleite falls down and you know that the computer knows you made changes and keeps them there, until you get your sattelite back on orbit.

I also like the "Saved" status for the same reason, when autosave works, to tell the user that their stuff is safe.

There may be other better ways rather than crowding the "save dock" for what I am saying above, but there is definitely value in these UI details for an app that runs across the internet in the browser I think.

[SaxonF]

I put together a somewhat experimental PR that makes a couple changes to the save dock. #50567. Note that this only touches saving and does not include changes to the sidebar (adding links, actions etc)

[mtias]

Updated the main description with a more fine grained breakdown of tasks and elements.

[jameskoster]

The ellipsis menu is fairly trivial in terms of visual design, though it would be nice to update the underlying components for the dark context. There's some nuance in terms of which actions should appear, based on the active panel.

Template

• Reset – for theme templates that have been customised.
• Delete – for any user-generated templates.
• Rename – for user-generated $custom templates.
• Replace – if any patterns associated with the active template can be found.
• Duplicate action would be nice, but we probably need to work on Add new Template modal #50395 first as there isn't a clear destination for such an action just yet.

Template part

• Reset – for theme template parts that have been customised.
• Delete & Rename – for user-generated template parts.
• Replace – if any patterns associated with the active template part area can be found.
• Duplicate – creates a new template part with the same details / contents. The name could be Current template part (copy). Or we could ask the user to supply one.

Page

• Trash – sends the page to the trash.
• Duplicate – The naming convention should be consistent with template parts.

---

For pages, we can display the status in the panel header. To begin with this may be read-only, but in the future it could be a button that opens a status-switching UI.

---

The save portion of this work is underway in #50567.

Above the save dock appears the date the active item was last modified, who modified it (via Gravatar), and a link to view revisions. Currently revisions are accessible for Pages, Templates, and Styles.

The revisions button could be a text link as above, or a button:

---

There is already a proposal for the Style Book link in the Styles panel (#50393). In the interest of consistency it could make sense for other contextual links/actions to occupy the same space.

The "Browse themes" button would link to themes.php. We may be able to use an icon button here instead, if we can come up with a good icon for themes.

For the Pages, Templates, and Template Parts panels, a segmented control allows the user to toggle between 'browsing' and 'managing':

The template management panel looks a little empty, but eventually it could be possible to filter by template type here (related: #48651). For template parts, we might already offer filtering options based on area, but it's not high priority.

There is no management view for pages in the site editor yet, so for now the manage button must link to the Pages list in wp-admin.

It's quite tricky to come up with good icons for these buttons, and those above should be considered WIP until we come up with something better.

[jasmussen]

Thanks for the energy on this one!

[jasmussen]

@jameskoster the only thing I've been waffling on is this part:

Especially in some sections we'll have the back button, the title, plus button, and ellipsis already, and we're very likely going to run into space issues with translations.

I wonder, did you have any good alternatives there? If yes, then perhaps we should tentatively update this one and mark it ready for dev, because that contextual link seems like such a small thing that we can always move to another place if need be. What do you think?

[jameskoster]

I think we're ready to move on this one?

• Ellipsis menu design / contents are detailed in this comment.
• Status will be handled in Site editor sidebar: add page details #50767
• Revisions / Save dock elements have come into focus:

All that remains are the "Contextual navigation" items that we've gone back and forth on a bit:

• "Browse themes" at Design root.
• "Manage pages" in Pages panel.
• "Manage templates" in templates panel.

For manage templates (and template parts), this toggle feels solid:

Here are options for the other two:

What do you think @SaxonF @jasmussen?

[SaxonF]

Looks good to me @jameskoster . We will need some indicator the modified row or just value is interactive (like the drill-down and edit icons) but otherwise I think this is a fine starting point to iterate on.

[jasmussen]

I think it can work. Not sure if the 404 and Search are right for this area, but happy to iterate that.

I mentioned in a few otheres, I personally miss a bit of the previous whitespace between site hub and detail title, and don't think we need the border separator. But other than that, this is coming together.

[jameskoster]

I personally miss a bit of the previous whitespace between site hub and detail title, and don't think we need the border separator

Yes we really need to nail down all of these metrics, once and for all. There's some recent discussion in Figma here.

I'll update the OP with the latest designs. It feels like we're at a stage where details can be refined in PRs.

[ntsekouras]

I was thinking of trying this with the new DropdownMenuV2. What do you think? It might take a bit longer because it will reveal things missing or in need of adjustment, but it's something we want, right?

---

edit:
I'll probably implement it with the current DropDown for now because we're close to 6.3 deadlines. I've opened a PR though that uses the new component, to iterate there as well.

[mtias]

I think we are good with this. Follow ups to be treated separately.