Solvedgutenberg Block Transforms should be more discoverable/obvious

I was writing a block, added a line of text I wanted to convert to a heading, and couldn't work out how to convert it to a heading.

I think this is a discoverability/ usability issue. I eventually found it in the toolbar, but it was not obvious. There's no indicator showing clicking the option will offer more options. Something as simple as a small down arrow next to the block type icon would have helped considerably.

I am used to typing and then changing the styling the content after the fact. I don't want to have to leave my flow to add a header/ whatever. But finding the transforms took much longer than it should have, and I was swearing to myself since I know it used to be available but wasn't in any of the places I remembered.

I'd like to propose an alternative as I think there is already an over-reliance on iconography in Gutenberg. Icons like gears and dots hide much of the editor's functionality behind ambiguous glyphs that can only be learned through experimentation. This is tolerable for advanced or little-used functionality, but something as simple as transforming text should be one of the clearest functions in the editor. We don't need to invent a new icon to make transforming text at least as obvious as it is in word processing apps like Word, Pages, or Google Docs with which new users will be familiar.

I saw that @jasmussen already reverted the paragraph icon back to its more traditional form (the pilcrow) in the latest master branch. This is an improvement, but I think we can do more. Below is a proposal to clarify the block transformation workflow through a text-based control already familiar to users. I've left the actual behavior of the block selection untouched while hopefully improving discoverability.

The proposed control offers the following improvements:

• Clarity - Text reduces ambiguity, especially in unconventional icons like Preformatted or Verse.
• Contrast - The control is obviously different than its neighbors and won't be confused with alignment.
• Affordance - The dropdown arrow suggests a menu reveal, which is what happens when it is selected.
• Freedom - We can design the block icons based on clarity and not worry about their proximity to related icons in the toolbar. For example, H is the obvious icon to represent a heading, but it appears to have been changed to T just so that it wouldn't blend in with the H2/H3/H4 icons next to it. With the proposed control, that's not a problem.
• Familiarity - WP users know this control from the TinyMCE editor or have used a similar control in other word processors.

Familiarity with one of the most important functions of an editor is a good thing. In the midst of a paradigm shift like Gutenberg, conventions can ease the transition, especially for such a common user action like text transforms.

Just wanted to say thanks for all the constructive voices here and willingness to find better solutions. If there's anything that is fairly clear is that the current "block switching" interaction is not as obvious as it could be.

I think using the paragraph icon instead of the one that is easily confused as aligment, @jasmussen's update in #9310, plus the addition of the drop-down arrow are a good baseline to check on the next release and see if we need something more involved. @kevinwhoffman it'd be great to expand on your proposal and see how it might look across more blocks and nested contexts.

I note that I was working on an iPad when I was finding it difficult. This should be an interface that does not depend on hover. It should be discoverable on touch-only devices too!

Hi @kevinwhoffman, nice mockups, thanks for joining us in the fray!

Back in the day we explored something similar, to figure out the pros and cons to each approach:

There are many aspects to consider, though

• The need for the editor to be responsive (see also #7479 (comment))
• The need for the block toolbar to scale to editors with thin main columns through editor styles, as well as nested contexts (see also #9075)
• The need to make transforms plug-in friendly. For example you can't only transform paragraphs, headings, quotes and text blocks. You can transform a heading to a cover image. You can select multiple images and transform to a gallery. One goal is to allow a plugin to register itself as a compatible transform, for example a ToDo list block might register itself as compatible with the List block.
• Because we dock the toolbar to the block so as to be contextual, it essentially covers preceeding text. Although there is an option to fix the toolbar to the top of the screen, this is something to be mindful of when making the toolbar wider.
• The need to accommodate very long block names including translations.
• Accessibility — we have 13px as the minimum font size.

One of the kickoff goals of this editor project was to unify multiple disparate interfaces into one. Instead of you having to learn how to use widgets, shortcodes, oembeds, custom HTML and TinyMCE in order to accomplish a rich layout, we wanted you to only have to learn a single interface, and once you knew that, you could do anything. This has been the driving force behind unifying everything under the block metaphor. You may have to learn how to use the block, but once you know it, you know all of WordPress.

It's all a delicate balancing act, but we're definitely open to finding solutions that thread the needle!

As I shared over on #9228 I wonder if a simple dropdown indicator is enough here?

It doesn't indicate the specific purpose of the icon, but it does promote discoverability.