Try an alternative way to navigate the inserter + some tweaks

[youknowriad]

[jasmussen]

I dig it. It basically runs with an idea by @karmatosed to have an ellilpsis on the right side of the tabbar, and in turn replaces the tabbar. I like this for a number of reasons:

• It visually lightens the whole UI
• It makes the category group much more scalable, which is important both for translations, and because 3rd parties would likely want to add their own categories
• It makes the inserter menu look like it's made of menu material, same as other popout menus
• It scales better to the incoming Inline Images feature, where we can do something like this, which would be harder with the tabbed interface

Designwise, this looks great. I'm assuming it handles mobile as well? How about the Saved blocks previews?

One thing I don't love is the all-caps small "SUGGESTED" title. Not that it doesn't look good, but because it's the only place we use that heading.

The pattern we should emulate here is that of other menu subheadings:

[youknowriad]

I'm assuming it handles mobile as well?

In mobile the navigation menu take the whole area under the search input.

How about the Saved blocks previews?

These show like today, which means they'll cover the navigation menu but I think it's fine

Tne thing I don't love is the all-caps small "SUGGESTED" title. Not that it doesn't look good, but because it's the only place we use that heading.

Sure, I'll update. Though, do you think we can use it elsewhere in a separate PR. I think for these small titles, it feels a bit better (at least for me).

[jasmussen]

Sure, I'll update. Though, do you think we can use it elsewhere in a separate PR. I think for these small titles, it feels a bit better (at least for me).

We can certainly use it in more places than once, for example replace all menu subheadings with allcaps. However this feels a bit screamy when it reaches the 13px font size that we should ideally never go under. I notice it's 12px here, would you hate to go 13?

[youknowriad]

@jasmussen not at all, it's 13px now :)

[karmatosed]

Thanks for this, good to experiment.

A few things I'd like to get on this, first we really need to get some a11y feedback @afercia can you give any insight into how we make a sidebar like this accessible? It does solve a few things and we totally should explore this as it is a pattern we're using in other areas.

Secondly, I do think it needs some styling improvements like being the full height, feeling more like it slides out would be good. I do wonder if it should be on the left side over the right, I am not sure if this is my bias though.

[afercia]

@karmatosed thanks for asking. Instead of "how we make a sidebar like this accessible" (which can't be made 100% accessible) I think a more proper consideration is what we miss with this new proposed implementation compared to what we have with the tabbed interface implementation.

Not everything can be made accessible if it's not designed since the beginning with accessibility in mind. I'm sorry but this is of fundamental importance for all designers and developers to understand. Designing a new fancy interface without any initial accessibility consideration and then asking other people "now make it accessible", is not a good path if we want this project to be accessible. This must change.

While a tabbed interface is standard because it's part of the ARIA specification and provides an expected, well defined, interaction model that users are used to (it's used also in the operating systems UI), this new fancy panel and the scrolling div are not standard. There's not a defined interaction model users can predict.

I'm a bit surprised a so drastic change is proposed at this point of the project. The current interfaces was developed in several steps with a good collaboration between teams and with a good balance between visuals and accessibility. It was agreed on. It was tested at length. We've involved testers even at WordCamp US and they spend the whole day testing the inserter with keyboard only.

I'll leave out considerations about how much this kind of unexpected changes can cost in terms of time spent in design and implementation.

Moving on to an initial accessibility feedback, far from pretending to cover all the potential critical points:

• the current tabbed interface is better because it has a predictable interaction model
• it gives feedback about the currently selected tab, for example screen readers announce "tab, selected, 2 of 4" and so on
• keyboard users can use arrow keys to switch tabs and then jump directly in the panel using the Tab key: this is one of the main advantages of a tabbed interface because users are not forced to go through all the tabs
• when jumping to a panel, it is correctly announced because it's labeled and it will say users if the panel is about Blocks, or Embeds, etc.
• there are no focus losses, focus works generally well except for Constrain tabbing within popovers and similar components #5242 which is still to implement
• various other details, but overall the important thing is the current interface is rich of information and feedback and that's what users need

About the new proposed UI:

• there's a general lack of feedback
• pressing the toggle button doesn't give any audible feedback about what just happened
• the expanding panel uses the roles menu and menuitem but that's not appropriate: menus should be used exclusively for "desktop-like" menus, i.e. menus with items that are actionable controls that "do something" /Cc @aardrian
• the panel items are more links for navigation, i.e. links to in-page anchors in the scrollable div, so semantically this is more a navigation menu and should be implemented accordingly
• once a menu item in the panel gets activated, there's no feedback at all about what happened other than the visual feedback (the div scrolls)
• closing the panel clicking on the X button produces a focus loss (focus is not moved anywhere)
• users are forced to tab through all the items in the panel to finally get to the block types
• the scrollable div now lists all the block types together: when exploring the content with a screen reader this is overwhelming information because there are dozens of block types announced all together
• most importantly, the scrolling is pointless when using a keyboard: yes the div scrolls and brings into view the related block types but then keyboard users have to tab into the block types panel and, of course, they are forced to start from the first block type at the top

Have you tested it using a keyboard, at least? Besides the scrolling, there should be a mechanism for keyboard users to jump directly to the group of block types related to the choice they've made: e.g.

• press "Embeds"
• the panel scrolls and sighted keyboard users can see the related block types
• we shouldn't assume they want to directly jump there
• maybe they want to press "Shared" to see the following group
• they should be offered an option to jump to the related group, if they want
• how to communicate all this to non-sighted screen reader users would be a challenge (and this is one of the main reasons that make me think it can't be made accessible)

Overall, I think the new proposed interface offers a reduced level of accessibility and not all the issues can be fully solved. I'm afraid it would be a regression compared to the current UI.

[aardrian]

I was tagged by @afercia , so I am looking. Is there a code version of this?

I am at WCLDN contributor day and had the chance to ask a couple people what problem this is trying to solve. I understand it is related to the growing number of tabs in that interface element, coupled with text expansion from localization.

This challenge is not new, and to borrow from Bruce Tognazzini a bit, I think the underlying concept in this image is viable but can better lean on existing UI patterns.

Immediate changes I would make:

• Instead of tabs in the current UI (not the example above), have a list on the left (instead of the right as this example shows).
• That list is visible by default with an option to collapse it.
• It can still use the ARIA tab model for screen readers, to a point.
• Chunking them first may be more valuable than a very long list, particularly for users running large fonts, using a screen magnifier, or using a screen reader. Users who rely on a keyboard will benefit as well from being able to jump into groups instead of navigate 20 distinct tab things.

These modifications can mitigate some of the issues Andrea raises above. Again, code unseen.

[karmatosed]

My thoughts on this are pretty much 100% what @aardrian says. I think we can make this work and balance the accessibility concerns.

[afercia]

Thanks everyone.

• That list is visible by default with an option to collapse it.
• It can still use the ARIA tab model for screen readers, to a point.

I'd definitely agree. Tabs in an ARIA tabbed interface can also have a vertical orientation. Reference: https://www.w3.org/TR/wai-aria-practices/#tabpanel

[shaunandrews]

I think the drawer looks a little complicated for what is already a pretty complex piece of UI. I wonder if we can simplify the lines a bit and make the drawer feel a little more like a part of the popover, and not another piece sticking off the side. Here's a quick mockup:

Along that same idea, I wonder if we could simplify even more and just some form of dropdown to navigate between groups of blocks:

[karmatosed]

@shaunandrews I really like the first option, that feels like it takes this idea and builds nicely on it. I'm slightly less keen on the drop down, although I could be convinced. I am wondering if it scales as we add more categories and I think it could cause issues with accessibility (I may also be wrong). I do feel the top option has a solid, strong style I'd like to see us take into code. To me, that solves some of the previous issues we have we have already with the library.

[iamthomasbishop]

Just my 2 cents on the latest proposals, from the mobile angle:

I really like that top variation that @shaunandrews proposed, specifically for desktop context - although I might remove the hamburger icon altogether and force expand the right side.

With that said, I'm not sure if it'd translate well to smaller screens. For mobile I think the current horizontal tabs UI is more familiar and discoverable than the proposals (again, for mobile specifically), so my opinion is we should keep that in mind.

The biggest issue I have with horizontal tabs is future scalability when we have 10000000 block types, but I'm also not loving the idea of tucking the options behind a hamburger menu, or even worse a dropdown.

[afercia]

From an accessibility perspective, the "dropdown" could be a better solution depending on the implementation... if it's a native select, that would be 100% accessible because... it's native! However, it would need a button i.e. no action triggered onChange.

As per the "side panel" I can only repeat the a11y recommendation previousl expressed by @aardrian and myself: move it to the left and still use an ARIA tabbed interface (vertically positioned):

• have a list on the left (instead of the right as this example shows): this is important for content linearization: navigation should come first and visual order should match DOM order
• That list is visible by default with an option to collapse it: having a tabbed interface, we can't hide tabs by default
• It can still use the ARIA tab model for screen readers, to a point.
• Chunking them first may be more valuable than a very long list, particularly for users running large fonts, using a screen magnifier, or using a screen reader. Users who rely on a keyboard will benefit as well from being able to jump into groups instead of navigate 20 distinct tab things.

Again, the great advantage of ARIA tabs is that they don't force users to press tab to navigate all the tabs. Tabs are navigated with arrows, pressing the Tab key brings users directly inside the tab panel. This is even more important with 20 or more tabs.

The biggest issue I have with horizontal tabs is future scalability when we have 10000000 block types

Sure but with 10000000 block types also the tabs on a side or a dropdown would be an issue as well.

Is there any design of how this (see below) should look when there are 20 or more block types? (Please move the panel on the left 🙂)

[jasmussen]

The biggest issue I have with horizontal tabs is future scalability when we have 10000000 block types, but I'm also not loving the idea of tucking the options behind a hamburger menu, or even worse a dropdown.

Good observation, and this is why we added tabs in the first place. A thought, though: having used Gutenberg for a year now, I've increasingly found myself not using the tabs a single time. Either the block I need is available directly as a suggested block, or I search. I say this not to project my behavior on to everyone — that would be making assumptions about how other people use Gutenberg — but purely as an observation: are people actually using the tabs, and if they aren't, would a filter mechanism, whether through popout menu, popover, dropdown or otherwise, be sufficient?

[hedgefield]

I would say so, I've never used the tabs either. I like @shaunandrews first mockup a lot too. I would also prefer it if it's always visible, and shown on the left. Good stuff! Looks much better than it did before already.

On the matter of scalability, I wonder if it wouldn't make sense to stretch the inserter to something like browser height. That would give plenty more space, and it's not like there's anything below it that you need to interact with at the same time.

And whatever the case, if the categories list gets too long you can always use the search field or scroll down. It feels like a backup.

[youknowriad]

Thanks all for your feedback, highly appreciated.

The fact that it feels like a backup (and seems that most of us agree on that point) is exactly why I think it should be closed by default. You don't need it unless you really want it.

Also, it opens on the right because this is the natural flow due to the position of the inserter at the moment: most inserters we have opens on the right and there's not enough space on the left (if you close the WP sidebar for instance). We also use this space to show previews of saved blocks which means we're not losing place by adding this to the right.

Regarding accessibility, it has already been updated to follow the guidelines:

• Return focus on close
• Tab aria model
• Filtering instead of scrolling.

I'll update to match the proposed design.

[youknowriad]

About the suggested tab names. Not certain the proposed reorganisation make sense. It remplaces "blocks" by "All" but the thing is "blocks" doesn't really show all the blocks: The saved and embed blocks are not shown. The "All" is what we show when no filter is selected, I believe we can add a tab for this but how to we name the current "blocks" tab, should we leave it as is?

[chrisvanpatten]

A few random brainstormy ideas… (feel free to disregard!):

I think the "there's more to scroll" would be a bit clearer if that subtle gradient at the bottom of the scroll window was a bit taller, maybe?

Resizable…? What if the bottom was draggable to make it taller or shorter?

Might also be helpful to have some kind of message for new users indicating it's scrollable that fades after you scroll (and never shows again)…

Just some random thoughts :)

[chrisvanpatten]

Oh shoot, and the thought that inspired that brainstorm session and I promptly forgot to mock up…

On scroll, maybe the currently in-view accordion header could be pinned to the top so you don't forget where you are?

[chrisvanpatten]

Sorry for the commentspam, and potentially dumb question, but something else occurred to me… has there been any consideration of positioning the inserter to the right of the inserter button?

In the current inserter, on smaller screens (like iPads or my 11" MacBook Air) you get this issue:

But if you insert it to the right (sorry this is a kinda hacky mockup but you get the idea!)…

You have the freedom to position it in the middle, and a user can expand it and keep it in view a lot easier.

[shaunandrews]

that it's not necessarily clear from looking at it that there's a scroll (especially in your animated example… until you actually do scroll)

Take these mockups for what they are: Approximations of a real UI. A real UI would have scrollbars dictated by the OS (I assume, I don't think wp-admin/Gute do any custom scrollbars). This means for Windows users with a mouse, there would be visible scrollbars; For Mac users scrollbars would appear briefly (by default) and then fade away about the mouse is moved over the scrollable area.

I think the scroll + accordion could get cumbersome very quickly.

I kinda of agree with you here, but I'm willing to try it and see what actual problems we run into.

he search at the top maybe is a good idea over right at the bottom

My motivation for moving the search to the bottom was to put the focus on the blocks; The blocks are the star here, the search is just on way to find a block. I still see the search being given focus immediately when you open the picker, so the workflow should remain mostly unchanged.

I am less keen on the pill shapes

I stole the shape from the iOS keyboard apps. I don't love it either, but its always fun to try new things. :)

The same goes with the colors, I can see them as being a distraction to some but really useful and cheery to others

I think we need to add something to block listing to let them standout from each other. Right now Dashicons or Gridicons aren't unique enough for everyone. Some more custom illustrations (by letting people use SVG's) would go a long way, but I think when paired with a color — it really allows developers to let their brand shine through. Without color, I worry that all blocks just blend together in the picker.

[chrisvanpatten]

@shaunandrews I went back and struck through my original comment up there because on reflection my concerns weren’t as bad as I first thought :) sorry about that! Excited to see this evolve.

[ZebulanStanphill]

Woah, there are some really nice-looking mockups here! I especially like the most recent ones that @chrisvanpatten has posted. I think the search bar should probably be moved to the top, though. Additionally, I am not sold on the pill-shapes for the blocks, but I think using colored backgrounds is a good idea that should help with identifying blocks and providing a way for plugin-added blocks to stand out. I think using a square-with-rounded-corners look for the items in the inserter could look better than both the pill shapes and the current square shapes.

[shaunandrews]

Playing some more. I think maybe we could keep the colors for the "official, out-of-the-box" blocks the same (a light gray), and reserve the brighter colors for developers and brands.

[jasmussen]

I was about to suggest that you use colors from Hugo, https://codepen.io/hugobaeta/pen/grJjVp, but I also don't want to put out the wildfire that has captured you. Flame on!

[karmatosed]

@shaunandrews just as a little iteration, what do you think of bringing back the buttons with the text included and combining with the accordion? I am enjoying the exploration but I do wonder which method has better readability - not sure of the answer yet.

I do like how 'app' like this is going with the buttons. We maybe can open up the background color and an icon for developers to give them that option.

[iamthomasbishop]

I must say @shaunandrews - the last iteration is pretty great. I wasn't feeling the color icons initially but this (neutral "official" icons with the potential to customize others) feels like a sweet spot.

I also think this is feeling very native app-like, and while I'm not 100% sold on the treatment, I like where it's heading.

My initial reaction to pulling the labels out if the icon is that it would add for more visual separation, which I like. It's also a more familiar style for native app users. My only concern is how does it look & feel in the grand scheme of things, inside the rest of the UI?

🤘

[iamthomasbishop]

Also fwiw: on mobile/native GB we will be making the button/pill/icon taparea larger for a more spacious tap area and to make drag-n-drop-to-add more discoverable. The sacrifice there is you show less blocks on the picker. Idk if that is applicable to web but I thought it was worth mentioning 🙂

[ianstewart]

@shaunandrews one thing I really like about your last iteration — ignoring the obvious super-cool app-like space for new blocks to bring character and branding — is the use of negative space and colour (the grey) + contrast to separate the blocks. It's easier to "read" than using lines as separators for these elements. And "feels" more like abstracted blocks in the selector.

[shaunandrews]

Worked up a little gif to get a feel for how the accordions could work:

Also, here's a quick comparison of the current blocks and the updates I made above:

[Quick Edit]
Here's another to add to the comparison, with the smaller buttons which let us fit more blocks into view:

[karmatosed]

@shaunandrews thank you for the gif, that's really useful to see it in action. I really do like the feel of this and flow. I have to say I still am not totally sure about the background on icons and lack of larger button including text. That said, I do think we can run with your suggestion and at least see what the feedback is of it in a PR. @youknowriad would you be up for doing that?

[youknowriad]

Sure @karmatosed I'll give a try 👍

[jasmussen]

Love how this discussion has turned out. I went a bit silent when the creativity bloomed because I wanted to see how far this goes, but as things are stabilizing a bit, I'd like to add a few notes:

Although I like the icons next to Most Used and Shared, Gutenberg is already icon heavy. If we can do without them, perhaps that's best, at least for now. Same with the block count — this feels like something we can add in a subsequent PR once we know it's necessary. Otherwise it just adds to the code.

I really love the splash of color that some of the brand specific blocks received. As such, I love the idea that a block author can add these colors. However for a couple of reasons, I feel like maybe for the core offering, none of the out-of-the-box blocks should have color. This echoes @karmatosed's thoughts.

It has in the past been decided to include a whitelist of oembed handlers in WordPress. There are a lot of them. We are surfacing every one of these as a block in Gutenberg, because we want the user to easily know what's intrinsically supported so they don't have to go download a plugin assuming it's not already there. However, maintaining the correct icon and brand color, obeying brand guidelines, for each of these services, will quickly become an onerous task, and is arguably a task WordPress shouldn't even be part of in the first place. This is why we replaced all the whitelisted oembed icons with generic "type" icons, as opposed to using their logo. In other words — the YouTube block should not be red and have the icon, it should be gray and use the "generic video embed" icon.

To be clear — Google can choose to make their own expanded YouTube block, and I would love for them to be able to then use the YouTube logo and add their brand color. But it would be a block coming from Google then, not WordPress. In other words, I'd prefer we keep:

• oembed blocks generic and gray
• allow 3rd party blocks to add color if they like

[youknowriad]

Ok! so I tried this in #6636 As a developer, what I like about this is the code simplification :)

I didn't implement the color API yet.

Let me know what's missing.

[afercia]

what I like about this is the code simplification :)

And if this goes in, I think we should further simplify and remove the roles menu, menuitem, and remove arrows navigation :) The groups wouldn't be "menus" any longer, arrows navigation would be inappropriate and not expected. They would be just accordions with buttons as content.

[shaunandrews]

Gutenberg is already icon heavy. If we can do without them, perhaps that's best, at least for now.

Sure. I was trying to find a way to make the Favorite and Shared accordions stand out from the rest—especially the Shared section, as thats the same icon used to denote shared blocks in the editor.

I feel like maybe for the core offering, none of the out-of-the-box blocks should have color.

Agreed. The last few mockups have been sticking with a single, gray color for "out-of-the-box" blocks.

However, maintaining the correct icon and brand color, obeying brand guidelines, for each of these services, will quickly become an onerous task, and is arguably a task WordPress shouldn't even be part of in the first place.

FWIW, I wasn't suggesting these as replacements for the embeds—you may notice that the Embed blocks are listed in one of the accordions in my latest mockup. I was just showing what a branded block could look like; Those are imaginary blocks from Spotify, YouTube, and WooCommerce.

[jasmussen]

Those are imaginary blocks from Spotify, YouTube, and WooCommerce.

Solid — just wanted to clarify because both Spotify and YouTube have oembed counterparts. But I definitely agree that if those three made their own core blocks, they should totally be able to look like that.

[gravityrail]

I added the ability to style icons using pure CSS in #6636 (comment)

[aardrian]

@gravityrail Please note, CSS alone may be inadequate to meet the WCAG 2.0 AA compliance that Gutenberg needs to hit. The icon will not be announced as that symbol by screen readers (if at all), so if it relies strictly on visuals it needs some other indicator.

[gravityrail]

@aardrian the intention here is not to use CSS to specify the icon or icon title itself (that code is unchanged), but rather for lightweight branding (e.g. background color).

That said, of course people could use CSS to add meaning to the icon that is lost on visually impaired users, so perhaps we should also create a hook for those people to add aria-* properties there too.

[youknowriad]

Thanks all for the feedback, closing in favor of #6636