Panels shall remember their state or else switching between them is a usability nightmare

[porg]

Reproduction

1. In the Site Editor or Block Editor you have the right Side Panel.
2. In this Side Panel you can switch between different panels (block settings, global styles, some 3rd party plugins offer their own preference panels there)
3. Over time those panels get more and more settings (WP 6.2 preview shows this trend!), hence get more structured (tabs, sub-screens with drill down navigation, etc).

Proposal: Each of these panels remembers its state!

• Panel state:
  • Which tab is open?
  • On which sub-screen am I?
  • Where have I scrolled to? (in case of long panels with many expanded sections)
  • Which input field has focus?
• 👉 This is crucial for efficiency/usability!
• ❌ Otherwise this is an interaction efficiency nightmare!

Demo of the usability issue in a screen recording (2m 20s) with audio commentary

Gutenberg.Side.Panels.shall.remember.their.state.when.switching.between.them.mp4

[porg]

CC to: @mtias @getdave @critterverse @ndiego

[skorasaurus]

related with consistency of panel state: #18418
related #27560

[getdave]

@talldan I seem to recall you thinking about maybe having a package to handle UI requirements such as this?

[talldan]

This issue? Consider a generic API for programatically navigating interfaces

In that issue I was thinking about the developer experience of trying to implement a specific kind of feature.

The OPs problem seems like it needs some thought first about how it should work in terms of the user experience.

[porg]

The proposed UX overall is clear

Each panel (1st and 3rd party) shall remember its state (during a running Site Editor session) to avoid clicking/scrolling to your particular UI element of interest, after each toggling and switching.

Implementable UX specs

To work them out technically feasible, please provide me the following infos on the architecture:

1. What's the official generic term for those right hand side panels in the Block/Site Editor?
   • Not knowing better I refer to them as "inspector panels" for now.
2. UX standards or coding/interface standards for 1st/3rd party inspector panels?

• a) UX standards?

  • a1) 1st party: Currently "Page/Block Settings" + "Global Styles": They look & feel consistent. Whether this is by coincidence or governance I do not know. If governed/specced, please provide the links.
  • a2) 3rd party: e.g. Greenshift, (screenshot below): No I assume. E.g. the Greenshift block inspector panels have an entirely different look, wording and structure (information architecture).

• b) Coding/Interface/Event Standards? — Do inspector panels have any standardized event handling and signaling to the parent?

  • b1) Events like saveState and restoreState?
  • b2) Or does the state of a panel anyhow exist all the time (not unloaded when invisible)? And when getting focus again this triggers an init event, which as observable now starts the panel scrolled to top, loads the top hierarchy screen it has, and resets all sub-tabs/panels on their initial state.
    • → Then the solution would be to only trigger the init event at the real panel lifecycle start, and each time later it gets focus again to not trigger the full init again, but instead offer a "gets focus again" event, to which a panel can "react more subtle".

Example of a 3rd party block inspector panel: Greenshift