Improve Write/Design mode switch discoverability

[annezazu]

In the testing I've done with users, it's not clear how to switch between modes and no one thus far has been able to figure it out in 5+ tests. Meanwhile with zoom out, there's a nice double click to move out of zoom out that allows a more seamless understanding, along with the clear option to invoke it.

In talking with @jasmussen, some ideas were thrown out including a more of a toggle state rather than a dropdown selection. In any case, kicking off this issue to start resolving the problem sooner rather than later. Happy to ask permission from a close friend I had test if we want to see someone trying to go through it in action. cc @WordPress/gutenberg-design

[rabie-elkheir]

Hello @annezazu I can do this job
Would you please send me a link to the design location?

[annezazu]

Hey there! We don’t have a design just yet and this issue is open to start exploring that. Thanks so much for being game to help when the time comes!

[jameskoster]

Here's a couple of rough ideas based around the premise of drawing a little more attention to the mode selection UI.

[annezazu]

In doing more testing around this too, I think we need to consider a way to prompt folks around the modes potentially when they can't do something. Some of that will depend of course on where we end up with auditing blocks that can be edited with content only: #65778

[jasmussen]

Toggle options come with the challenge of stressing already pressed real-estate. Until the tools themselves and the defaults applied have been refined to be more solid than they are in this nascent pre-alpha state, it's unclear that these actually need the prominence. Perhaps more importantly, we know that annotations/inline comments are on the way, and it may be useful to have those as its own tool. Does that become three buttons, or two? So there are lots of variables to consider.

Here's a couple of options that are perhaps a smaller diff between trunk, and if nothing else they can serve as interim stepping stones.

A	B

Figma.

[ntsekouras]

@jasmussen I'm not sure I get the differences in the designs you shared.

How is option A different from trunk?

Is option B only about a dropdown for the tools or in view/preview icon too?

[jameskoster]

We should be careful about adding chevron indicators unless we're prepared to apply that treatment to all menu triggers, else we're introducing unhelpful inconsistencies.

In order to use chevrons like this they would likely need to be buttons themselves, with the mode-icon indicating the active selection, but not being a button itself. E.g. Figma:

This is what I tried to recreate in the first of the three mockups above.

[jasmussen]

The difference is the presence of chevron indicators, like Jay alludes to. I'd agree to be careful there.

[jorgefilipecosta]

@jasmussen, @jameskoster any consensus on the next steps is it worth giving chevrons a try risking some inconsistency or should we go for another option?

[jameskoster]

I don't think we should add a chevron to the existing button unless we're prepared to apply that treatment across. Reflecting further I'm not convinced this would be an effective way to help users Identify how to 'change modes' anyway. It's a relatively abstract concept and a tiny additional icon probably isn't going to help that much if they're already struggling.

Using something like ToggleGroupControl would be better to try imo.

It's probably too heavy-handed, but an alternative idea could be:

1. Update the Editor welcome guide to include a slide explaining modes
2. Conditionally show that slide post upgrade, when the user first opens the editor

[jasmussen]

I'd echo Jay 👍 👍

[richtabor]

Yea, I'm not convinced this is something to solve right now. Let's evolve write mode a bit further before thinking on this front.