Exploring beyond a sidebar for exposing styling tools

[karmatosed]

I am starting a new issue to not distract from the flow of the work in #19255. In that issue, I have looked at what if we stayed with the sidebar. I consider that the baseline as what is being done in prototype right now. However, the more I work on this the more limiting this feels. I took some time to explore what could be beyond this and want to say this will be much later in my mind, maybe as an iteration over having to be done in v1.

I am going to share some earlier ideas here but they are all worth sharing, sometimes when you share an early mock it sparks something, so let's do that.

In these let's put to one side how you get to the styling tools, it's about where they appear and look like.

I have for now explored the following variations:

• Toolbar with dropdowns
• Toolbar inline
• Style library: using the block library pattern

Let's dive into those!

Toolbar with dropdowns

These explorations have 3 variations to share and all work around the same premise of the toolbar having styling tools appear. There are 2 variations on those tools:

• Group under styling types
• Split into individual tools

In the mocks, you will see a few variations on those explored.

Toolbar with basic dropdown

This version has sizing tools under one section, splitting out alignment and colors.

Toolbar by type

This toolbar splits into types, for example, typography and color. This uses sub-menus to show tools. Potentially this is a little clumsy for extra interactions but that can be worked out.

Toolbar with split out tools

Here every single tool is split out and has its own drop-down the interface. This is a simpler version and very aligned to the block toolbar.

Toolbar inline

I did a few other explorations as to where this could go inline. These are varied but show some options.

Style library

What if it looked like the block library?

What if you could dock it? This image shows potentially moving to the side to 'dock' so you can interact.

What about mobile?

The great thing is that a more toolbar approach really brings easier versions on mobile:

Next steps

As I worked on this for me creating a proper toolbar with each tool as in the split out tools makes a lot of sense, but that's my own feelings. I really want to get other insights here.

I have some particular feedback I am looking for, along with wider thoughts.

• Is there one version for you feels strongest?
• If you agree with the toolbar being the way to go, should this respond to the option setting of 'in top' or 'by block' for toolbars?
• What else not explored would you like to see?

It's worth noting that iterating like this could come after we get the basic version live, this is why I am moving this out into another issue.

[karmatosed]

As an additional for the toolbar approach, it could be that the tools apply based on where they are.

• Top toolbar: for everything not just block.
• By block: just for that block.

This could take the tools beyond a single global mode and into a wider one if we also looked at by block offering option of just single instance. A long way off but worth considering. There is a danger of confirmation dialogues and options we should be careful about if we have a variety here. This is where we really get into needing to explore this beyond an idea and test.

Here is a speed visual of that in action:

[enriquesanchez]

These explorations are fantastic @karmatosed!

I like the idea of having block-specific styling option in the block toolbar and global or document-level options in the top toolbar. I know it has been mentioned in the past that we need to be careful of adding too many options in both places, but I feel that your explorations of using dropdowns provides a new perspective here.

Your exploration of the 'Style library' is resonating with me. I feel that it's a clever way of keeping all of those controls tidy in one dropdown and being mindful of space.

[johnstonphilip]

Context-based toolbars (global vs block specific) seems like a pretty solid idea to me! Visual separation like that is probably going to be important for helping users understand what-controls-what.

[mapk]

Top toolbar: for everything not just block.

This feels good as it's located at a "global" level. When I make a global change here, it makes sense to see everything (all blocks) get updated on the page that relate to the change.

By block: just for that block.

This one I have a harder time with. If I make a global change while interacting with one single block, and I see all other similar blocks update, there's a disconnect for me. When manipulating a single block using the block's toolbar, I only expect to see that one block change.

Great work! ❤️
I do like that when I'm in the Global Style mode (I think that's what this is), I am presented with my global style tools. It helps me visually orient myself to the tasks I am able to do in this mode.

[karmatosed]

This one I have a harder time with. If I make a global change while interacting with one single block, and I see all other similar blocks update, there's a disconnect for me. When manipulating a single block using the block's toolbar, I only expect to see that one block change.

It's a trade-off, but by doing things like this example where we highlight all blocks of that type we can perhaps soothe that hitch.

This is all worth exploring as it's deeper dived in and has a lot of implications for full site editing. There's some great working out going on there that can be iterated on. I see the toolbar as an iteration, so good to see where that all takes us.

[karmatosed]

I have distilled down to 2 options here:

Top with dropdown

This has 2 variations:

Global at top, local by block

Always at top

Toolbar at top

It's worth noting in each what shows changes as a global styling is different than a selected block. Along with this, if you select one type of block, all of that type highlight.

[enriquesanchez]

To me, the always at top option feels the strongest, in my mind it works well with the mental model of "global", and I like that the options are contextual based on what I have selected.

I however wonder how keyboard navigation will work. If I'm in a block, and I want to edit the block' global styles, how would I get there?

I also wonder if having labels that clarify what is happening could help here?

[mapk]

Either one of the "always at top" feel more global-minded to me as well.

I'd really like to figure out a way that allows the selection of a block type without adding a border to the blocks in the page. When adjusting global styles, I really want to see how these styles fit with the rest of the content, and the block borders get in my way of that.

This could be a bad idea, but how about a way to select a block-type from the global styles tools? In the prototype below, I added a dropdown that would display the blocks in the page. (it reminds me of the Block Navigation). Like I said, not the best, but at least it allows me to see the changes as a whole.

[karmatosed]

This could be a bad idea, but how about a way to select a block-type from the global styles tools?

I feel this falls into the issue of knowing a type and adds extra UI. I am not against exploring a way to 'see all' though, which feels like a different issue. There was some talk about having a 'browse' mode which would lead you to see all in art direction. This feels better to me than adding a drop-down. I'll explore that a bit more, however, that's distant exploring.

[ZebulanStanphill]

You know how we have Storybook for components? What if there was something kind of like that, but user-facing and for blocks?

The user could browse through the block library (probably using a similar UI as the block inserter), and after selecting a block, it would be inserted onto a canvas, pre-filled with the block's inserter preview content. You could then adjust the global styles for that block while seeing its effects on the example block in the canvas, without actually having to insert the block anywhere on your website.

[oandregal]

We've just landed #24250 the first step for users to be able to edit styles globally. I've created #25139 as a follow-up to iterate on the current sidebar. I also now there was this issue to look beyond the sidebar, so wanted to ping folks about this. Perhaps now that the pieces are into place is a good time to revisit and iterate?

[ZebulanStanphill]

Pinging @afercia to check this out.

[afercia]

Thanks for the ping.

Considering all the accessibility issues with sidebars discussed in various issues, any exploration that moves away from the concept of sidebar is very welcome and appreciated ❤️

The most experienced WordPress contributors may also remember that sidebars in core, for example the Media modal sidebar and the Customizer sidebar, have always been problematic, for many reasons. I'm also guessing that, from a design perspective, one of the wills for FSE is to have a user interface that's as clean as possible with no "big", intrusive, UIs like the sidebars. Sounds like a win-win.

I also share the idea mentioned a few times in this thread that "modes" seem to solve some problems. By switching the whole UI to a different, well scoped and well communicated "mode", there's the opportunity to free up space and remove controls that don't belong to that mode. This seems a much better approach than trying to "squeeze" many controls in a limited space or replacing "on the fly" parts of the toolbars with extraneous UIs (see #24766, #24676, #24021, #24805).

Thinking at the future, as more functionalities will be introduced, more controls will be necessary. Gutenberg has always had two different needs: on one hand, provide a rich set of features and on the other hand, strive for a clean UI. Modes could be the answer and I'd suggest to further explore how to expand the concept of "modes".

A couple point more specific to this thread:

the idea of having block-specific styling option in the block toolbar and global or document-level options in the top toolbar. I know it has been mentioned in the past that we need to be careful of adding too many options in both places

From an accessibility perspective, two separate toolbars would be a concern for keyboard accessibility. Also, discoverability for screen reader users would be one more concern. I'd lean towards the simplest option: a single toolbar.

I however wonder how keyboard navigation will work. If I'm in a block, and I want to edit the block' global styles, how would I get there?

Yep, that's a concern. Gutenberg still needs to provide a solid, reliable, mechanism to move from the selected object to its toolbar. Not sure what the correct English term for this is, I think it's "create affordance"? For example: when editing a block or a caption or whatever editable "thing" that displays a toolbar above it, Shift+Tab should move focus to the toolbar. Same for Alt+F10 which is the legacy keyboard shortcut for the Classic Editor users are used to. Also, Alt+F10 should always move focus to the relevant toolbar based on the specific workflow at a time. A single toolbar would greatly help with this.

[mtias]

Closing as not planned for now.