Two distinct features now labeled "Tools"

[0aveRyan]

Describe the bug Originally the new header mode toggle @youknowriad added in #18624 was labeled Navigation Tools, but that heading was removed. The remaining description prominently labels them as Tools, while Tools already exists under the Main Menu for a disparate set of features.

Additionally, adding this item to the header means there are now six items users viewing the interface need to parse, which moves from the top-end of the perceptual subitizing scale into conceptual subitizing that requires additional cycles to subdivide. Depending on age and cognitive function, humans can identify up to five like items without counting, with six or more like items almost every brain must sub-divide items into smaller groups to compute the whole.

Expected behavior At minimum the confusing double-use of Tools should be addressed. This could be as simple as relabeling or adjusting the descriptive text.

A few ideas...

• New Control Type - It appears the two Modes are intended to be a binary, similar to Visual/Code Editor. One way to address the clustering of buttons could be to use a Toggle Control with edit as the active state and select as the inactive state. Tooltips and Snackbars could explain the mode switch to users.
• Combine Outline/Inspector - The Content Outline and Block Inspector could be combined under a unified button with a tree icon, the counts could be at the top and the bottom section could use a TabPanel to toggle between the Outline and Block Inspector.
• Relocate Outline/Inspector - The Outline/Inspector could relocate into the Editor Footer region, prefixing the Block Breadcrumbs. This would keep Header buttons to be tools that take actions like the Block Inserter, Undo/Redo and Edit/Select toggle, where the footer could be tools that define context and aid in navigating a document.

Screenshots

[jasmussen]

Thanks for the ticket! I would definitely agree we need to try and reduce the amount of tools up there, and to combine and simplify where possible.

It's a larger effort, and the reason it exists as it is today is because the ability to easily select the layers of a block with complex nesting, is an important issue to solve, and the selection tools (perhaps that's what they should be called?) are key to making that easier. Specifically, with the default edit tool, you click any text field to edit it directly. With the select tool, you click any block to select the block. Just like in Figma or Photoshop or other desktop apps so to speak.

In #18667 there are efforts underway to simplify the general block editor UI. Based on that work you can see in https://github.com/WordPress/gutenberg/pull/19082#issuecomment-567508590 a screenshot that removes the document outline from the top toolbar, and puts in in the bottom right corner under a word count. Another option ticketed in #4287 is to make the document outline live in the ellipsis menu on the right.

[mapk]

It's good to note that "Manage All Reusable Blocks" will be going away from this section with https://github.com/WordPress/gutenberg/pull/19400#issuecomment-570742294.

We can also move the "Welcome Guide" under the Options modal dialog in the "General" section. I think it works well in relation to the "Inserter help panel" there.

This would leave the Menu Group looking like this:

I wonder if these items are independent enough that they can exist on their own like "Options" does? And then we can just drop the section title. So it would look like this:

[0aveRyan]

@jasmussen I love the selection toggle, I totally get why it's needed -- this ticket is definitely more about the labels than the functionality itself. I personally prefer the approach in #19082 over tucking the outline behind an additional click in the Menu in #4287, or having the approach in #19082 act as a trigger for the tucked approach in #4287.

Right now, there are three significant ways to modify the editor experience that are all loosely-related in nomenclature (at least in English).

There's choosing an Editor [Visual/Code], choosing View [Top Toolbar/Spotlight Mode/Fullscreen Mode] (which can be combined despite the singular View) and now choosing (Navigation) Tool [Edit/Select].

While I like the simplicity and parallelism of having View, Editor (Plugins) and Tools under the Editor Main Menu, View used in the singular somewhat suggests only one can be active at a time. I'm not proposing this as a new name, but really these are different experiences... visual options/modifiers/configuration for how the editor displays. I'm not crazy about View alone (or Mode) for a top-level label for these, but I'm struggling to find another one-word label to really address what they do.

While it's beyond the scope of the main issue of having two features labeled Tools, part of the confusion stems from all of these semi-related labels getting applied across the UI.

To me, Mode for Edit/Select makes more sense than Tools, which better applies to features that perform an action like it's used in the menu for copying content, showing keyboard shortcuts, etc. Mode would also be an interesting place for features like Annotation/Approval/Per-Block Revisions, etc, so perhaps making it a binary toggle like Editor doesn't make sense.

So if Mode was dropped from Spotlight + Fullscreen view labels that would simultaneously make Top Toolbar (or Unified) feel less bespoke from the other two view labels and free up the Mode keyword to be used for Edit/Select.

Then... Editor - Would remain locked as the Visual/Code Binary View - Would loose Mode and remain locked to Core tools Mode - Would be a good place to allow 3rd party extension

[jasmussen]

Great thoughts here, and a lot to parse.

For starters, I think it's worth for now shelving the conversation around Top Toolbar/Spotlight/Fullscreen Mode, as I suspect those could morph or move or change in entirely separate conversations. For example, I could see spotlight mode potentially going away entirely, made less necessary by work in #18667. Fullscreen mode I personally would love to see default and non-optional, but there's a larger wp-admin discussion to be had here.

The visual/code editor choice also feels like separate to me, as the two can't necessarily coexist as equals. I.e. you can make changes in the code editor that will break/not work when switching back to the visual editor, whereas the items currently in the tools menu do not affect features available.

Finally it's worth noting that #17949 is exploring potentially adding a 3rd tool to the tools/mode/edit dropdown, which would invoke a commenting mode where selecting a block allows you to attach comments/notes to that block, which can then be addressed, just like Word or Google Docs.

All that is preface for the challenge, which I agree, better nomenclature helps a lot here.

---

In discussing the best nomenclature it's worth looking again at what the dropdown, currently labelled "Tools", hopes to accomplish.

Primarily, it serves to provide a visual indicator and click affordance for the tool you have selected. While this is technically a mode — i.e. when you have the Edit tool selected you can click text etc. etc. — it is no different from how Figma attaches modes to tools.

Let's imagine you had a 3rd tool there, for attaching comments or editorial notes to blocks, like say you're reviewing a post from a colleague before it's going live. You'd have three tools there:

• Edit Tool — click any text to edit it, default
• Select Tool — select blocks parent first
• Comment Tool — attach notes to blocks

Each of those has a mode attached, but the mode is secondary to the functionality the tool offers. This is why I'm personally more of a fan of calling these "tools", as they describe an interaction, rather than "modes", which I feel is a little on the technical side.

This is also why I feel the three tools could belong together in a dropdown like this — you would flow in and out of each tool as you are editing, layouting, and annotating a document. This is in contrast to Fullscreen/Spotlight which is "set and forget", and to the code editor, which is also either a set it and forget it preference, OR a place you go when you need to see what's wrong under the hood.

---

In that light, how would these labels sound?

• Dropdown is called "Document Tools"
• First tool is called "Edit Text"
• Second tool is called "Selection Tool"
• Third tool, if it happens to come into being, would be called "Annotation Tool"

Is this better?

[0aveRyan]

@jasmussen circling back to this...

I'll try to keep a few finite thoughts here:

• I think the extra word (i.e. Navigation Tools, Editor Tools, etc) would really add clarity here and is worth the extra pixels/characters :) OR really explore and iron out deviating to the Editor/View/Mode taxonomies suggested above.
• I don't think Fullscreen mode excludes the continued need for Spotlight mode -- it should stay!
• The words definitely matter as we think about all these new tools. Using two words feels more like a stop-gap solution, though perhaps important one. Maybe it's not Editor/View/Mode... but coming up with a framework we can grow into -- that can be extended somewhere -- I think is really important. Also really important is having a shared, teachable vocabulary. Anytime that vocabulary shifts its hard on professionals, novices and everyone in-between. Considering how many features are in the pipeline that require labeling, learning, etc... I lean towards finding a more resilient taxonomy set today as opposed to down the road and re-shifting the vocabulary.

[jasmussen]

I don't think Fullscreen mode excludes the continued need for Spotlight mode -- it should stay!

I'm sort of coming around to that too — though in a different way. I don't personally find it useful at all for editing posts, however there are situations where it might be useful, like when editing a reusable block, the act of doing so might put a spotlight on just that block. Or when editing template parts.

It seems like the next steps here might be to actually take the controls in the top toolbar which is stabilizing, and then plot out a table with verbiage suggestions, and then move to PR. Does that sound about right?

[0aveRyan]

@jasmussen Sounds good, though we can keep hammering away at #19447, which will probably help inform whatever happens here.

[jordesign]

Looping back to this issue - I do note that we still have 'Tools' in 2 areas, but am wondering if other advancements have made this less of an issue? What do you think @0aveRyan @jasmussen ?

[jasmussen]

I tend to think we can close this one and reopen if the concern resurfaces, so much has changed since this one that there's new context which may reframe details here.