Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Show "ellipses dropdown options" in select mode #25275

Open
mariohamann opened this issue Sep 13, 2020 · 4 comments
Open

Show "ellipses dropdown options" in select mode #25275

mariohamann opened this issue Sep 13, 2020 · 4 comments
Labels
Needs Design Feedback Needs general design feedback. [Type] Enhancement A suggestion for improvement.

Comments

@mariohamann
Copy link

Problem

It appears we already have a way to move blocks with a keyboard. AND in Select mode, the ellipses dropdown options are still relevant, IMO. Maybe we should explore adding the ellipses options back to the toolbar in this mode too?

Originally posted by @mapk in #24092 (comment)

Idea

Although there was a wider discussion if it would be compatible with current keyboard actions, I want to bring up this idea in a single issue.

image

Thoughts

To preserve the possibility to tab through the blocks: What do you think about adding a "second layer" in select mode?

Using keyboard:

  1. Focusing a block (while tabbing) still shows the name.
  2. Pressing return for the first time displays the options of the dropdown like shown above. (Still being in select mode and making it easy to move etc.)
  3. Pressing return for the second time enters "Edit mode".

Using the mouse:

  1. Hovering a block shows the name.
  2. Clicking on a block shows the options...
  3. ...and clicking for the second time enters "edit mode".

I have the feeling that this could especially work very fine with #25133 and #24751

@jasmussen
Copy link
Contributor

From the same thread, I don't believe we can add the ellipsis button here.

In select mode, you press tab to select blocks forwards, and you press shift tab to select backwards.

Shift tab would conflict with selecting the ellipsis option in the toolbar, therefore if we had the ellipsis button in select mode, you could only tab forwards to select blocks.

@mariohamann
Copy link
Author

Thank you for your feedback. What do you think adding a "second layer" in select mode, as described above? Or should I explain this more clearly? :)

@jasmussen
Copy link
Contributor

I missed the bit with an additional layer! I blame Monday :)

Pressing return for the first time displays the options of the dropdown like shown above. (Still being in select mode and making it easy to move etc.)

I like to refer to the modes as "tools", because even though each tool comes with a mode (just like they do in Photoshop, Illustrator, Figma, Google Docs, etc), they really are tools you use for the interaction. In that vein I could see additional tools. I'd love an annotation tool, and a "Browse" tool where you click a link to go there in the editor.

But key to all of those tools is that it needs to be intuitive not only how to use them with keyboard and mouse, but also flow naturally in and out. Right now the select and edit mode tools are tied together very tightly:

  • Click any block to edit it
  • Press Escape to select it (bonus tip, press Delete to delete the block)
  • Press Enter to edit it again

Here's a GIF:

nav select

Using Escape and Enter as keyboard shortcuts to organically flow in and out of these modes works really smoothly, and it's only two keyboard shortcuts to learn. As it is, I'm not sure what benefit there is to adding additional steps to switching between those flows, or what is the primary problem being solved for.

Is it to better surface the options in the ellipsis menu? We could add more keyboard shortcuts for those.

@afercia
Copy link
Contributor

afercia commented Sep 24, 2020

As mentioned here and in #24092, the "Select" mode was originally designed to allow quick, easy, keyboard navigation between blocks as in, for example: 20 blocks -> 20 Tab key presses to navigate through them all. The main purpose is to drastically reduce the amount of Ta key presses to navigate the blocks list.

Adding more controls in Select mode defeats its original purpose as it would inevitably add more tab stops.

Also, I'm not sure the "second layer" would help: such a switching mechanism isn't that intuitive compare to the current one. Right now:

  • in Select mode, the Tab key moves through blocks: more accurately, it moves focus to a button element labelled with the block type and other info about the block content
  • Enter switches to Edit mode: this is the most intuitive interaction on a button element
  • the Escape key switches back to Select mode: again, this is the most intuitive interaction

The above interaction is simple and it works pretty well.

Adding a new step between the two modes as in: first Enter key press switches to a new mode where a toolbar appears with all the "block actions" available isn't that intuitive (and adds a lot of tab stops):
A button element should have only one available action. Why users would ever have a clue that the available button action actually changes depending on the number of times the button was pressed. IMO, this would be totally unexpected an very confusing.

While I'd agree there should be a new "mode" to make block-level actions easier, I'm not sure this proposed interaction would be ideal. The separation between the modes should be clearer and the switching mechanism way simpler and better communicated by the UI itself. Noting that part of the discussion related to this issue is happening also on this other issue starting from #25133 (comment)

I'd be totally in favor of exploring a new mode that doesn't even try to be WYSIWYG as proposed by @ZebulanStanphill. This new mode could display a simplified blocks hierarchy and make the block-actions available. As mentioned in that discussion, such a mode could maybe also make other UIs no more relevant e.g. the current List View, the breadcrumb bar, etc.

@jordesign jordesign added the [Type] Enhancement A suggestion for improvement. label Aug 17, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Needs Design Feedback Needs general design feedback. [Type] Enhancement A suggestion for improvement.
Projects
None yet
Development

No branches or pull requests

5 participants