Size Change: +2.19 kB (0%)

Total Size: 1.17 MB

_{compressed-size-action}

Thanks for this PR! I spent some time working with the previous design explorations and wanted to present my further iterations here. While this isn't direct feedback on the PR (yet), I thought it best to share on this PR for a discussion as to what path works best.

Option 1 - Add labels under icons

• Reduce the active state of the Settings icon from 36px to 32px. This allows more room for text and aligns it to the same size as the Inserter.

Option 2 - Expand height of topbar

• Height has been expanded from 60px to 76px to allow more room for text.
• The "W", at this size, feels too big to be full bleed. I dropped it down a bit and pulled it away from edges.
• The right side buttons feel a little out of alignment and would need further iterations.

Option 3 - Smaller icons

Mobile

• I resized the icons from 36px to 28px. This doesn't align with our standard icon size, but does allow for more breathing room when icon labels are visible.
• With the smaller icons, the positioning of the Publish button doesn't feel so bad.
• Again, the Settings icon active size matches the Inserter size.

Option 4 - Text only

Mobile

• Eliminate all icons (as this PR does already).
• I've explored several iterations with the Mover text.
• As shown in the Mobile view, it would be better to display the block's name in the toolbar rather than just "block".

Feedback

I wanted to get these early iterations up for discussion. Is there an option that feels better than the others? What else would you like to see iterated? If you're interested in more, check out my Figma file.

Here's my feedback on the current state of this PR:

Text only

I love the text only mode because it's so clean. But once the Top Toolbar option is introduced, it feels a little wonky. This PR chooses to keep the block toolbar on a second row, which could work, but would need updating to text only as well. (I think that's reserved for another PR)

Top Toolbar mode

The bottom border is missing in the second level toolbar here:

Site icon

I don't think we need to add text here. It just gets very out of place and messy.

Text edits

• "Add block" should just be "Add"
• "Block navigation" should just be "List view"

Settings button

This looks more like a button now than a toggle now. Should keep this pattern?

Button sizes

When both menu dropdowns are triggered, the "Add block" and "Publish" btns sizes are more visibly unequal and look like a mistake. I think they should all match sizes with this option.

Dropdown menus should not overlap

These dropdowns should appear next to their parent level menu.

Example 1

Example 2

Settings item when in dropdown

I think we should drop the "active" state of the Settings item when it's in the dropdown. More like this:

Dropdowns

I think we have a standard min-width on dropdowns like 258px. Let's apply that to these as well.

After these changes, I'm happy to provide another review. 😄

I've left this in labels-only mode for now, we can always change it later if we decide it doesn't work. Or we could have three options: icons only, icons and labels, and labels only 😄

I've addressed most of @mapk 's feedback; all but the dropdown positioning as I'm still tussling with the Popover component on that front. Hopefully will have it fixed soon!

The e2e tests are failing because of the changes I made to the label text on some of the buttons. I'd appreciate any feedback on those changes, so that I can fix the tests once they're sorted.

Thanks for the quick turnaround, @tellthemachines! As you're working through this, I hope providing a bit more feedback is okay. If you'd like me to hold off until a certain point, just let me know.

Top Toolbar mode

I noticed that when selecting Top Toolbar mode, when I don't have a block selected the topbar bottom border doubles up.

Text buttons

When switching to a text only mode, I really think all the button interactions should work the same. It always felt odd to me to have icon buttons (ie. hover and pressed states) display differently than the text buttons, and now that these are all text buttons, it's even more obvious.

An open question: Should the text only buttons reflect the same interactions that the Preview button has. These are no longer icon buttons, and should probably now reflect the interactions of our standard button states.

Settings and Options

I just noticed that when both Settings and Options are in a dropdown, and activated, they both show blue. This doesn't feel right to me even though technically it is. Maybe fixing the whole button interaction thing will help this?

Icon dropdown

In text only mode, when the screen size is reduced, the buttons all move to a dropdown that is represented only with an icon. Does this make sense in the text only mode? Should we have a label for this icon?

There are so many small nuances that come to light as this gets developed, so I really appreciate your time with it all.

If we converted all the topbar text-only buttons to the default button instance as outlined in our Figma libraries, they would interact similarly to the Preview button. Check out this prototype below: (please ignore the black background)

As you're working through this, I hope providing a bit more feedback is okay.

Absolutely, all feedback helps!

I noticed that when selecting Top Toolbar mode, when I don't have a block selected the topbar bottom border doubles up.

Hmm, I can't reproduce this. Have you checked out my latest changes?

In text only mode, when the screen size is reduced, the buttons all move to a dropdown that is represented only with an icon. Does this make sense in the text only mode? Should we have a label for this icon?

Very good question 😅
I'm happy to try out a text label here, just not sure what to call it (we don't currently have an aria-label on this button, so I guess that'll need addressing either way). "More settings" seems a bit weird/redundant?

I've switched all the text buttons to behave like the Preview button in my latest commit, let me know if it works!

Regarding the dropdown positioning issues, it's trickier than I thought initially. The Popover component that we use in dropdowns has very limited positioning capabilities. We have #21275 to address that, and from the looks of it it's going to require rewriting the whole component. I repositioned the Outline dropdown the best I could, but haven't been able to improve any of the others. Can we leave it as is for now, and revisit once Popover is rebuilt?

I've switched all the text buttons to behave like the Preview button in my latest commit, let me know if it works!

After sitting on this one for a few days, I'm not fond of how our default button state looks for each of these topbar items. I iterated further with something more reminiscent of our Icon Button styles. It's not perfect, but the other direction felt overwhelming.

• The gray pressed state is replaced with a simple 1.5 pixel blue border.
• I aligned with the recent PR to make the text links in the topbar blue instead of black.
• Hovered states are identified with a border as are the active states.

Next steps

• Iterate when the Top Toolbar mode is "on". How do the toolbar buttons look when there are gray dividers?
• Explore other interaction designs.

I got some feedback yesterday that moving to "text only" might be too much. The text only version loses hierarchy and grouping which can cause usability issues.

I'm exploring a couple icon + text solutions to see how else we might be able to retain some sense of hierarchy and relationship once we introduce text into the topbar.

cc @kellychoffman

Caught some spacing issues on smaller screens.

Generally, the spacing in between these buttons all feels a bit off.

These all feel too close.

These feel too far from one another.

Is there a way to make this more consistent across all the buttons in text-only mode? In this Figma mockup, I have them spaced 10px apart.

Figma mockup

10px isn't aligned to our grid system, but yeah, something close to that would make sense.

Noting that #24965 has been created to discuss improvements to the "Options" modal, which should help solve some of the overly-similar labels currently present.

See also these other issues relating to the top toolbar:

• G2: Apply 12px grid to top toolbar more consistently #21870 G2: Apply 12px grid to top toolbar more consistently
• Rethinking the "Current Document" display and settings #20877 Rethinking the "Current Document" display and settings
• G2 block top toolbar #20592 G2 block top toolbar
• Two distinct features now labeled "Tools" #19409 Two distinct features now labeled "Tools"
• Exploration: moving options #19128 Exploration: moving options

@mapk Was wondering why 'Outline' was used for the button text that opens the List View, instead of 'List View'?

Looking back through the designs in the comments, it looks like at one point it said 'List View' (#24304 (comment)) but then changed in the more recent designs.

edit: Oh, I notice the tooltip currently says 'Outline' for the icon button, so that's probably why. I was wondering if we want to stick with List View in both places.

@ZebulanStanphill, changing the spacing to 12px is totally fine.

@talldan, No problem changing it to "List View". Let's make that happen. :)

Glad to see this merged! Thanks everyone for the perseverance and I'd like to thank @nicolad who started the first attempt to build this in #15830 ❤️ (deserves props).

Regarding this point by @ZebulanStanphill:

Really, the block inspector shouldn't even be accessed from the top toolbar in the first place; it should be accessed from the block toolbar, and it should act like a modal, to better fit accessibility guidelines.

Ah! That's what the accessibility team has been asking in the last... years? Considering all the troubles for keyboard navigation to go from the selected block to the inspector and back, the teams asked several times to have the inspector "in place" close to the block instead of in the sidebar. Hopefully there will be new explorations in this direction.

I'd like to propose props also for @tomjn who created the original issue, together with @nicolad who, as mentioned above, worked hard on the first PR.

I actually raised the issue during a user group after a discussion with @mikelittle, he deserves the props :)