If the Inserter panel closes the Inspector panel, the inspector should re-open

[folletto]

At a certain screen size, when the Inserter panel opens, the Inspector panel closes (which is fine as maximises visibility). However, once the Inserter panel closes, I'd expect the Inspector panel to re-open if that was the previous state.

To reproduce

1. Open Gutenberg
2. Resize the window to be around 1200px wide
3. Open the Inspector on the right from the toolbar
4. Open the Inserter on the left from the toolbar
5. The Inspector closes (good)
6. Insert something, the Inserter panel should close

Notice that the Inspector panel doesn't re-open.
This is specific to smaller window sizes where the two panels can't co-exist.

WordPress 5.4.2
Gutenberg 8.5.1

Related: #20951 (comment)

[folletto]

Suggested change

If the Inspector right panel is open when the Inserter left panel is opened, the Inspector should reopen.

[youknowriad]

Any time there's a need for a way to remember a previous setup like this issue suggests, I fear that it leads to unexpected behaviors.

For example:

• opening the canvas inserter also closes the global inserter, should we reopen the sidebar at that point?
• What happens when you leave the inserter open for a long time and then you come back and close it? do you expect the sidebar to reopen? I think it's not clear.

I do agree that the current behavior is confusing though. I'd like us to think if there may be another way, a simpler with less conditions and a clear behavior.

[folletto]

opening the canvas inserter also closes the global inserter, should we reopen the sidebar at that point?

In general, yes: the user expressed intent to have the sidebar open, so closing it feels like an unintended consequence against the user desire. If they wanted it close, they would have closed it, right?

What happens when you leave the inserter open for a long time and then you come back and close it? do you expect the sidebar to reopen? I think it's not clear.

Same as above, but maybe I'm missing the problem you're trying to surface here.
Why time would be a variable?

For me the rule is simple: if it was open, reopen.
The reason is that it's more likely to match user intent.

A different way to see this problem: it doesn't close on a wider screen.
So we know it's not what the user wants. :)
We close it just because on smaller screens the size is limited, not because we mean to close it.

[youknowriad]

In general, yes: the user expressed intent to have the sidebar open, so closing it feels like an unintended consequence against the user desire. If they wanted it close, they would have closed it, right?

In this case, the user's intent is not to close the global inserter but to open the canvas inserter though.

[youknowriad]

• What i'm trying to surface is that there are three things opening/closing each other so the user intent is not always tied to the previous state
• Also as time pass, closing something doesn't necessarily mean opening what was open previous for me. The user might have forgot entirely that the panel was open.

--
if I'd have to choose an option, I'd opt for every piece of UI opens and closes separately, but I know this doesn't scale well on small screens.

[folletto]

Ok, I think I understand what you mean.

I agree on your final statement, and that's why it's not easy. That's however where I'd start for the logic. If we think it's the best option on a larger screen, I'd try to have a behaviour as close as that on a smaller one, no?

[afercia]

I'm not sure this behavior is fine in the first place.

There are just too many moving things outside of the user's control. Not sure this is a good experience for users and I'd like to know if this has been user tested and in that case what the tests results are.

Also, not sure the "breakpoint" under which this behavior is triggered is fine. What is the reasoning behind the current "breakpoint" value? Does it adapt to variables like different content widths?

On my macbook (1440x2 retina) the sidebar doesn't close. It stays open and the content area becomes a narrow column with a width of about 650 pixels. Too few to operate comfortably on the content.

Note: to trigger the behavior I have to zoom in at 110% level (with Chrome).

Screenshot: content area too small ~ 650 pixels wide:

[folletto]

If you want to discuss the behaviour you should open a different issue, as this is about how to handle that behaviour on a smaller screen, not a discussion on the behaviour itself.

[afercia]

Thanks for the "lesson". 👎 Again, not an appropriate feedback, tone, and language.

[draganescu]

I've opened a similar issue in #22525, see comment from @jasmussen about the logic behind this behaviour.

[folletto]

Thank you @draganescu, yeah it seems it was an explicit decision, I'm still wondering if it's worth reviewing (there has been now a few mentions that the behaviour doesn't feel "right").

Even if I acknowledge the complexity of this as @youknowriad mentioned: keeping a state adds some maintenance complexity here.

[draganescu]

Indeed @folletto, I agree it should be reviewed. I think sometimes usability tends to get the 80/20 treatment which is wrong. In usability issues, edge cases experienced once a year can completely change a workflow or the perception of how something responds. In my opinion it's far better to have a common sense UX rather than one that implements a perfect set of great rules.

[folletto]

Usability is super important, yes. Nobody can keep every variable in their mind with a project as large as WordPress, and that's why we are more effective together. I always try to be mindful that a change might have been done against a set of variables I wasn't considering, in the end everyone here is trying to do their best, right? Balancing them is a one of the most difficult things we do. And I know you know, you've tons of experience here! :D

I always appreciate people that ask questions more than people that state “this is a terrible UI”. So I try to be that first person too (and I don't always succeed unfortunately...). :)

I know you have already noted it on your issue above, but for clarity, what would be your suggestion for this issue?

[draganescu]

Indeed, it's so true, nobody has all the answers and hindsight is an unearned superpower.

My suggestion was identical to yours above:

If the Inspector right panel is open when the Inserter left panel is opened, the Inspector should reopen.

[jasmussen]

If the Inspector right panel is open when the Inserter left panel is opened, the Inspector should reopen.

If this isn't an ocean of work and complexity, seems fine to try.

[draganescu]

According to feedback from the widgets testing outreach it's also a problem in the new widgets editor

Another usability issue I had at my desktop browser width (1280px) was that opening the picker would hide the document/block sidebar, but after insertion or otherwise closing the picker said other sidebar would not return. I would expect it to do so.

[annezazu]

Sharing feedback from a recent Gutenberg review that relates to this happening:

The number of steps required to create a single article has increased significantly compared to ClassicEditor.
For example, unless you maintain a certain screen width, the sidebar will be forced to close when you add a block.
The user will have to bring back the sidebar every time.
I don’t understand why they are trying to increase the number of steps required to work.

[porg]

• I reported yet another variation where closing the block inserter does not restore the panels as before:
  If Block Inserter Panel closes it should restore Document Overview Pane if it was open #53078

• And your observed usability issue (after closing the Block Inserter, the left/right side panels are not in their states as they were before!) is still persistent in current WordPress 6.2 and Gutenberg 16.3.0, see this video recording:

Inspector.Panel.not.restored.after.Block.Inserter.closed.mp4

[richtabor]

Noting that this does not occur within the Site Editor, only the Post/Page Editor.

It's possible to have both open at the same time in the Site Editor, which I lean towards being an acceptable solution — rather than trying to be too clever with opening, closing, and reopening sidebars.

Relevant due to #41717.