Widget Editor: relationship between the Edit and Preview toggle buttons is not obvious

[enriquesanchez]

Describe the bug
It took me a while to figure out how the 'Edit' and 'Preview' toggle buttons work. At first, I thought this was a bug, where I was able to activate the 'Preview' toggle but not turn it off.

I think that part of my confusion comes from two things:

1. We are used to toggle buttons working differently in the block editor. We usually only have one button that toggles between the two states.
2. Because this is communicated as a toggle button to assistive technology, I was expecting it to be a two-state button.

Instead, the toggle action uses two separate buttons, and I think this can lead to confusion, as it did for me.

Expected behavior
I'd recommend sticking to the toggle button pattern we already use in the block editor and use only one button to switch between 'Edit' and 'Preview' modes.

[mapk]

This is a pattern used on other blocks as well. I suggest we keep the existing pattern for now unless someone has an idea on an improvement. :)

HTML block

[paaljoachim]

I am going to add an idea that just came off the top of my head....(I am not saying it is a good or bad idea, and maybe I am just adding it to create some inspiration/brain storming session...)
What if we add edit - preview buttons directly into the Widget title area.

Why?
Pros
One could click overall Edit/Preview buttons to affect all of the widgets.
I think the discoverability would be easier to understand for the general user.

Cons
Adds clutter to the widget title bar.

Perhaps the question that ends up is should we add any icons/features directly into the widget title bar to show something that affects all the widgets in a specific widget area? Or perhaps are there any features that should be added into the sidebar widget area settings?

[mapk]

One could click overall Edit/Preview buttons to affect all of the widgets.

Would that also affect the HTML block or any other block that may not be a widget but uses this switch as a pattern?

Also having an "Edit" and "Preview" option in the area bar seems to state that it would affect everything in the area, not just widgets. As a user would I expect to see a change in regular blocks that I've added there too?

My goal with the Legacy Widget is to have that block automatically switch to a Preview state when unselected as long as it has the necessary amount of info filled out to render the frontend version of the widget in the widget area. This should help alleviate this problem.

[paaljoachim]

Here is an associated/duplicate issue: #26182

[paaljoachim]

Btw @annezazu has a very good idea in issue #26182 of adding the preview button to the Widget screen. Clicking it would then show a preview of all the widgets. It is a nice and easy way that also brings in the general Preview button from the Gutenberg screen.

[garretthyder]

I'll flag I had the same confusion with the Edit/Preview thinking it was a button I needed to click to be able to edit the widget. The ticket I had opened #26229, if being handled here can possibly be closed.

[mapk]

Clicking it would then show a preview of all the widgets.

Because of the location of that Preview btn, I would expect it to work just like in the Post Editor and push me to a frontend preview of the site. At that point how does it know which page to push the user to? Not all pages would show all the widget areas from the widget screen. For this reason, I think a Preview btn needs to be tied to the widget itself, or an easier way as I suggested above to automatically switch the widget to preview mode.

[paaljoachim]

This is how I understand your suggestion, Mark.

1. Add a widget to a widget location.
2. Modify the widget and notice that deselecting the widget automatically switches it over to the preview mode. So the user would right away be able to see what it looks like.

That sounds like a good and simple approach.

[mapk]

Also recorded in the feedback on the Call for Testing post: https://make.wordpress.org/core/2020/09/30/call-for-testing-the-widgets-screen-in-gutenberg-9-1/

If you Preview your widget, you cannot leave Preview mode if you wan to make more changes for your widget. Only reload of the page set Preview to off. (video)

This feedback is great! It's obvious this is an issue for users, so reaching a solution here would be very beneficial.

[mapk]

As indicated here: #11952 there were issues when we were using icons only. The Edit icon (ie. pencil) didn't translate well for people in some 10up usability tests.

I ran through several iterations to try some ideas out. None of them feel solid. But in an effort to keep the toggle interaction, Iteration 1 felt the most intuitive. I'm still preferable to the Edit and Preview buttons though... I'll keep iterating.

[garretthyder]

Nice I like those @mapk
Is the toggled pretty fixed in size? I wonder if we could make it larger and place the Eye/Pencil inside the dot and as you click the icon changes? Thoughts

[mapk]

I worked on another toggle idea that still indicates a toggle, but also communicates the purpose clearly. Having both buttons grouped together makes them a single unit. This implies a toggle instead of active and unselected individual buttons.

[garretthyder]

I worked on another toggle idea that still indicates a toggle, but also communicates the purpose clearly. Having both buttons grouped together makes them a single unit. This implies a toggle instead of active and unselected individual buttons.

I love it @mapk that embodies the feeling of a toggle exactly without losing much of the design or going into a vastly new direction. It has my vote out of all of them.

[mapk]

@ItsJonQ is this something you'd be able to take a look at?

[ItsJonQ]

is this something you'd be able to take a look at?

@mapk I could help with this.

The UI/interaction you folks have designed is similar to Apple's Segmented Control.

The grouping of [Button | Button] isn't the tricky part.
I believe Gutenberg uses this pattern in several parts of it's UI (although I'm not entirely sure of the code implementation).

🍬 Tricky

The tricky part is the auto-expanding width animation. For reference, I've created a SegmentedControl modelled after iOS in G2 Components.

Although we technically have Button components and a ButtonGroup pattern, to achieve this effect, I advise that we need a brand new component.

⚙️ Mechanics

Diving into the mechanics a bit... How it works is the background (in the case of your design, the "black" part), needs to be it's own layer. Let's call it "Backdrop". The text content float on top of it. The "Backdrop" would then need to calculate it's width/position based on the current selection, as well as the next selection on change (e.g. going from Edit -> Preview).

I'm not sure how the Figma was mocked for this. But I suspect something similar had to be done (with a dedicated rectangle shape for the background).

I'm just leaving these notes for design/dev awareness.

🔨 Building it

If you folks feel like this is the way to go, then we can build it 💪 . I believe a good component library should have some form of SegmentedControl anyway.

If the effort I described is out of scope (for animation handling, etc...), one path we can take is to use the existing Button/ButtonGroup implementation and introduce a SegmentedControl component later.

Would love to hear your thoughts!

[mapk]

Thanks @ItsJonQ!

I took a look at the Button Group which I believe is this control here from the Cover block:

This might do as long as it can be resized to work well within the block toolbar. While I'd love the addition of the animation on a Segmented Control component, I'm willing to try a Button Group as an MVP right now. Basically, we need to solve the problem which is that these two buttons, "Edit" and "Preview" don't appear to work together as a toggle.

A side note: the Button Group isn't looking right in Story Book.

BTW, you're correct on the Figma implementation of the prototype. It's a background that resizes and animates after click.

[mapk]

The reason I'm concerned about the resizing of the Button Group is because it looks a wee bit small in the toolbar.

[noisysocks]

If you folks feel like this is the way to go, then we can build it 💪 . I believe a good component library should have some form of SegmentedControl anyway.

If the effort I described is out of scope (for animation handling, etc...), one path we can take is to use the existing Button/ButtonGroup implementation and introduce a SegmentedControl component later.

This sounds like a good approach to me.

[noisysocks]

#30889 removes this interaction altogether.