Consolidate "page actions" on details layout pattern

[johanstromqvist]

The Resource detail layout pattern needs a dedicated place for common page actions such as duplicate, archive and delete, but common details pages in the admin currently lacks consistency in where such actions are placed. Many pages also have a save action, which is not necessary.

Audit

Products

## Products Products has no page actions in "More actions", but `duplicate` in common actions, and `archive`, `delete` and `save` in footer actions.

Orders

## Orders Orders has `cancel order` and `archive` in "More actions", and no footer actions

Customers

## Customers Customers has TWO `delete` actions, one in "More actions" and one in the footer. Plus the destructive button has wrong styling.

Discounts

## Discounts Discounts has no "More actions", but `duplicate` among common actions and `delete` in footer actions

Suggested pattern/guidelines

v0.4

Previous suggestions

v0.3

v0.2

v0.1

It must be very easy and intuitive to find recurring page actions on pages that looks similar. Pages may vary to some degree depending on its purpose, but page actions must default to being consistent and any exceptions should be made with great caution.

• No footer actions
• No save action
• Default to including a "More actions" and place all page actions there
• Surface a single page action, such as duplicate, if that action is a main use case and extremely common on the page.

TODOs

• Visualize the suggested default pattern in Figma
• Talk to various SMEs from Products, Orders, etc, to see if there are any concerns and insight
  • Link to Admin UX post in Workplace
• Consider feedback, set minimal scope, create issues
• Update the content and assets on the pattern page

[nickpresta]

Another example - page actions on Custom Reports:

Things I noticed:

• No icons for any actions
• No "More actions" overflow menu -- all actions are visible at all times
• Destructive action ("Delete") isn't styled any differently

[designrichly]

This likely sits outside scope but as a place to consolidate issues with More actions: currently app actions can't be translated. E.g. Translate & Adapt says 'Localize', regardless of what language your admin is in.

[jakemoves]

@tatianau would be able to articulate this more completely, but there are a11y issues with page actions. When a page action opens a modal, I think it's currently impossible to return focus to the correct element on modal close. If we're standardizing on page actions, let's add a requirement to pass an activator or activatorRef in, so keyboard users don't have their focus sent back to the top left every time they use a page action that involves a modal.

[jakemoves]

Leaving separate comments for different topics: this work would be an excellent candidate for Fable testing, when we have a prototype or PR. #accessibility can help get that organized!

[jakemoves]

Is there a limit to the number of 'common actions', or is it driven by breakpoints? It would make sense to me to support more than two 'common actions' being exposed as buttons (rather than actionlist items that require a drill-down).

[tatianau]

there are a11y issues with page actions

(cc @oksanashopify @maxariss for context)

I second @jakemoves's point - the issues with focus not returning to the activator are prevalent across the Admin, the Products section alone has at least three occurrences (1, 2, 3), and all the issues across Admin sections have the same root cause:

• In many places they can be easily fixed by providing an activator ref to the modals they open.
• However, in case of the Page component's secondary actions, there is currently no way to do that other than creating a custom version of More actions component to pass to Page's secondaryActions which as a workaround has its own implications.
  • Adding a requirement to pass an activator or activatorRef to the secondaryActions as @jakemoves suggested could be the way to provide the ability to fix it system-wide.

Is there a limit to the number of 'common actions', or is it driven by breakpoints? It would make sense to me to support more than two 'common actions' being exposed as buttons (rather than actionlist items that require a drill-down).

@jakemoves AFAIK, there is no fixed limit - the number of secondary actions that are shown to the left of the More actions dropdown is dictated by the available real estate on the page and it changes on window resize or across different screens / page zoom levels, the actions that didn't fit into the available space get collapsed into the dropdown.

---

@johanstromqvist would the problem benefit from creating a GH discussion where folks can share opinions and thread the feedback to each proposal / question individually?

[johanstromqvist]

Great input, friends! Much appreciated.

Regarding the layout pattern itself

• Our priority is to document a details layout pattern with recommendations that are most beneficial to merchants
• The general direction of how and where page actions are grouped seems supported by core
• We can continue our plans to promote this pattern and fix the broken interactions in parallel
• Product teams can update their respective details pages at their own discretion to the degree that it's feasible
• We'll continue to incorporate future improvements to the pattern once it's published

Issues

• App actions in "More actions" can't be translated. @designrichly would you mind creating an issue for that?
• Focus not returning to the activator in "More actions". @tatianau would you mind creating an issue for that one?

Feel free to create any discussions that you think are helpful. I will use this issue for what concerns the pattern documentation, but I'm happy to contribute and pick up insights in other issues and discussions too.

[ry5n]

I’ve always wanted to do something like this (I think Jesse BC did too), so I’m generally 👍

Howver, there’s a risk that many merchants won’t know where to look for the actions once they’ve moved. What’s currently in that “More actions” menu is often just app actions. If a merchant doesn’t use apps, or isn’t used to using this menu, the support impact of this change could be significant.

This is the kind of thing where I’d be tempted to do some kind of usability testing and/or try some kind of change management intervention. We don’t have good patterns for this kind of thing, but maybe putting something discrete where page actions used to be (not a banner!) to help guide users through the change.

[ry5n]

(Also, I’d suggest putting the core actions like duplicate and delete above any app actions in the menu)

[LA1CH3]

I want to second @ry5n 's comment. As an example, anecdotally I have heard some merchants frustrated with the new index table filtering UI, because it significantly changed their mental modal of the index table and how they could perform searching/filtering. I think we'd want to avoid the same here.

Is there any mechanism in place to signify these new updates to the user? Maybe leveraging a local storage key or similar, and the first time they view this new experience, pop up some notification/modal banner with "Hey! Just FYI, we moved all the page actions under "More actions" now.", instead of merchants having to search once they realize the buttons aren't there anymore.

Anyways, thats a bit unrelated to this specific topic but just something I wanted to agree with. In general I am in favor of this change, but one thing I wanted to bring up for the products page: on small viewport sizes, we collapse the "share" action (along with our other secondary actions) all into the "More actions" dropdown.

Adding additional menu items here could make this menu quite long. Maybe its not too much of an issue, but figured I would bring it up.

[johanstromqvist]

Great points!

Agree on recurring page actions in the top of the list. ✅

there’s a risk that many merchants won’t know where to look for the actions once they’ve moved. What’s currently in that “More actions” menu is often just app actions.

1. Our primary goal right now is to make sure that 1P and 3P build new pages according to this pattern. In this pursuit, the suggested pattern feels safe.
2. Any new merchant joining Shopify would benefit from the consolidated pattern, so that's another incentive to proceed imo.
3. I agree that there's a risk for existing merchants to be confused on existing pages. However, I perceive this risk as low, that it's reasonably easy to fix when it occurs, and that merchants would benefit over time. But please check my assessment of that:
   a. Common places like "Orders" and "Customers" already keep actions like duplicate, archive and delete in "More actions", so for resource management in general and for this layout specifically this placement is already familiar. We are not introducing something new, rather consolidating unhelpful variation into the best established solution.
   b. The placement on the page and type of overflow menu is familiar from both the admin and other software. It also gathers all page actions in one sensible place. It would be a reasonable place to look, an unsurprising place to find these actions, and an easy adjustment to make.
   c. Compared to the current inconsistency, I think it's fair to assume that the suggested pattern would reduce cognitive load in the long term despite temporary confusion.