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

Provide tools for selecting vs. editing blocks #17088

Open
jasmussen opened this issue Aug 19, 2019 · 9 comments

Comments

@jasmussen
Copy link
Contributor

commented Aug 19, 2019

The goal of this ticket is to keep the benefit of the recently-shipped "clickthrough" interface, without negatively affecting the editing experience:

  • In the version of the block editor shipping with WordPress, it's easy to set the caret in text and edit blocks, but it is fiddly to select parent blocks with the mouse.
  • In the shipping version of the plugin, on the other hand, it is very easy to select parent blocks with the mouse, as they are selected using a "clickthrough" interface, where nested blocks are selected parent first. The flipside is that when you just mean to edit text, having to click through layers first can be cumbersome.

As is, we probably can't ship that clickthrough interface to WordPress without further refinement (see also #16888).

Suggested Solution

Instead of providing a once size fits all interface for editing and manipulating blocks, this ticket suggests splitting the two, using tools:

tools

The idea is:

  1. The Edit tool is selected by default. With this tool, you select blocks as usual: child first, i.e. click any text to edit it directly.
  2. The Selection tool is optional. With this selected, click any block to select the block, parent first, i.e. click a group block to select it and make the child blocks available for selecting afterwards.

1. The Edit Tool

edit tool

The Edit tool is selected by default, and the selection tool is optional.

2. The Selection Tool

selection tool

Choose the selection tool from the dropdown in the editor bar, or press v when you're not editing text. With this tool selected, you can now:

  • Hover any block to show a continuous 2px bold blue outline.
  • Click any block to select the topmost layer. This results in a 1px blue outline.
  • For blocks with nesting, you click through each layer. Columns > Column > Paragraph.

As such, this Selection tool absorbs the "clickthrough" interface as it exists today.

Content in the sidebar is unchanged, you can manipulate block properties as usual on any selected block.

To exit the selection tool:

  • You can choose the Edit tool from the toolbar.
  • If you click twice on any block, at its deepest nesting level, you change to editing that block.
    • I.e. click a paragraph to select it, click it again to exit selection tool and edit it.
    • Click a group block to select it. Click a paragraph inside to select it. Click the paragraph again to edit it.
  • You can press Escape, or Enter. This lets you change to edit mode for the block selected.

What problem does this solve?

The block editor aims to be both an editor for writing, but it increasingly offers layout options through more complex blocks. By doing both in the same interface, we end up with an often heavy UI that gets in the way.

By splitting this behavior into two tools, we can open up the editing tool to be optimized towards just that: writing and editing. And similarly, we can optimize the selection tool towards layout. This gets especially important as page designs grow in complexity.

Near term, this lets us keep the simplicity of editing text by clicking it directly, while adding a new selection tool for when you need to work with layers of nesting.

Longer term, by splitting into edit and layout tools, we can potentially focus both interactions. Ideas include:

  • The selection tool absorbs drag and drop entirely. It can in turn use the entire block hit area as the draggable area.
  • Remove the hover style & block label from the edit tool entirely. This lightens the UI when editing, and implies the way you select parent blocks is not by "hunting pixels".
  • For very complex blocks that feature off-screen layers, such as slideshows, the Selection tool can provide an appropriate place to surface such layers.

Perhaps the focusing of the edit tool can even open up additional ways to select across blocks.

Questions & Next Steps

The minimal version of the solution outlined here boils down to creating a new tool which absorbs what we have so far referred to as the "clickthrough" interface for selecting blocks.

An open question is whether the Escape button is an appropriate keyboard shortcut to revert to the default Edit tool, given that it is also the interface for invoking navigation mode. The current working idea is that nothing needs to change here:

  • If you have the Edit tool selected, pressing Escape enters navigation mode as usual.
  • If you have the Selection tool selected, pressing Escape selects the Edit tool, pressing Escape again enters navigation mode.

The obvious alternative is to find a different keyboard shortcut for selecting the Edit tool.

Your thoughts are most welcome.

@tomjn

This comment has been minimized.

Copy link
Contributor

commented Aug 19, 2019

I'm concerned this introduces mode errors into Gutenberg:

Modes are often frowned upon in interface design because they are likely to produce mode errors when the user forgets what state the interface is in, performs an action that is appropriate to a different mode, and gets an unexpected and undesired response.[4][5] A mode error can be quite startling and disorienting as the user copes with the sudden violation of his or her user expectations.

https://en.wikipedia.org/wiki/Mode_(user_interface)#Mode_errors

vim is a good example of recurrent mode errors. Tools are an interesting concept ( e.g. a format painter from spreadsheets might be interesting ), but something like this changes how the block UI works across the entire editor on a fundamental level

The selection tool absorbs drag and drop entirely. It can in turn use the entire block hit area as the draggable area.

Users will always expect to be able to drag and drop images or select a paragraph with a click and drag then drag that elsewhere, regardless of the tool used.

Some questions:

  • if I select a paragraph block when using the select tool, then hit cmd+v with an image in my clipboard, does it append or replace?
  • If I have several blocks selected that are not adjacent, and hit cmd+v, what happens?
  • If I select a paragraph block while using the selection tool, and begin typing, what happens?
  • If there are only going to be 2 options, does it make sense to use a dropdown and force the user to click twice? Or is something closer to a more appropriate?
  • Should this have the same visual hierarchy as the inserter and edit/undo if it controls the fundamental interaction of the entire editor?
  • How does this work with the new navigation mode?
  • When in selection mode, will it be possible to drag a selection box to select multiple items?
@jasmussen

This comment has been minimized.

Copy link
Contributor Author

commented Aug 20, 2019

Thanks for your thoughts. It's interesting that you mention vim — I encounter such errors all the time in vim, and have learned to press Ctrl + C to escape whatever trouble I got myself in at that time. So the example is great, yet ironically vim is also a very much loved productivity tool for so many. I'm not making a point here, just meandering on a delightful example.

To your point, though, I would suggest your concern is very much valid, and it has already been the driving force for many aspects of the mockup shown above, the Escape key suggestion being one example, the visual distinction suggested for hover styles applied by the two tools being another example. I will share some additional ideas in a minute, but just wanted to acknowledge the thought and note that I'll add the "needs design feedback" label to expand the review range.

The mode thing is not a new concern for this issue, it is one we deal with in virtually every app we use. The block editor and slack both have "navigation modes". In Slack, set focus in the chat, press tab, now the arrow keys navigate at the chat item level rather than scrolling the scrollbar. In the block editor, set the cursor in text, press Escape to enter navigation mode, now the arrow keys navigate at the block level, rather than moving the caret.

Key to both of those is that it's easy to "escape" those modes. In slack, press tab, or click anywhere with the cursor. In the block editor, press Enter, tab out of the editing canvas, or click anywhere with the cursor. In Figma when you have the comment tool selected, press Escape to select the default tool, or click it from the toolbar. In Docs when you are in viewing mode, you have to press a dropdown to choose another mode to exit it.

Those are a variety of different use cases for entering and exiting modes. In the best of them, entering and exiting these interfaces is virtually invisible because it doesn't get in the way. Without any prototype of the suggested interaction, it's very hard to make a proper judgement call to say with confidence that your concern is going to result in a problem. That's not to dismiss it, that is to keep the concern in mind as we do prototype it.

Which brings me to so some of the other ideas I explored as I mocked these things up:

  1. Separate tool shortcuts side by side, instead of in a dropdown. The benefit being that we can visually highlight which tool is selected of the two. The reason for suggesting the dropdown is that it allows a description in the dropdown, clearer labels with shortcuts, but also it emphasizes the default tool as the one you use most of the time, and makes the act of choosing the selection tool intentional.

  2. Show a new "Done" button in the toolbar, when the selection tool is chosen, which provides an additional affordance for exiting the selection tool.

  3. Drastically visually change the toolbar when using the selection tool, say give it a different background color. Perhaps combine with 2.

Those three all emphasize that the selection tool would be an optional interface that you can live without. Throw in #17089 and you could go about your day without using the layout affordance.

if I select a paragraph block when using the select tool, then hit cmd+v with an image in my clipboard, does it append or replace?

I would suggest this is an editing action, which means it exits the selection tool and appends the image after the paragraph. Same as today, in other words.

If I have several blocks selected that are not adjacent, and hit cmd+v, what happens?

While selecting non adjacent blocks is not part of this issue (see #16811), I agree this tool would be an obvious interface for hosting that feature. And I would expect it to work same as today. Append.

If I select a paragraph block while using the selection tool, and begin typing, what happens?

Given it's an edit action, I would expect you to exit the selection mode and start typing. As a new paragraph block below the one you selected, like the aforementioned append actions.

If there are only going to be 2 options, does it make sense to use a dropdown and force the user to click twice? Or is something closer to a more appropriate?

As noted, I did explore showing the two tools side by side, which has the benefit of being able to show a selection highlight of the tool selected. But to address the very reason for your question, it should be easier to exit this tool than enter it, and the dropdown provides valuable context to what the tool offers.

It may be worth expanding again on the goal here — there is no limit to how deeply a block can nest, and we're already seeing delighfully complex blocks that offer completely bonkers lovely layouts. This new market of premium blocks is one that is not gracefully handled by the current editor. The goal of providing the selection tool is to improve those layout affordances, and avoid the fiddly nature of what we have now, without breaking the direct manipulation of the current default interface: click text to edit it.

Should this have the same visual hierarchy as the inserter and edit/undo if it controls the fundamental interaction of the entire editor?

The idea of grouping these together is that they are global tools. Undo and redo still work if you are using the selection tool, and inserting a block I would imagine exits that tool immediately.

How does this work with the new navigation mode?

As suggested in the ticket, no real change here. If you never pick the selection tool, everything is like it is in master (only with child first block selection). The part of the open question that we need more suggestions and input on, is whether Escape is an appropriate key to exit the selection tool, given it is also the button that invokes the navigation mode. My working theory is that it is not an issue: press escape to exit the selection tool and get back to editing. Press escape again to enter navigation mode.

When in selection mode, will it be possible to drag a selection box to select multiple items?

That's not covered by this issue. I would imagine if this becomes a requested feature and some concensus emerges that this is necessary, then the selection should start from outside the blocks. Simply making a drag action on a block in the selection mode would drag that block to rearrange it.

@tomjn

This comment has been minimized.

Copy link
Contributor

commented Aug 20, 2019

Thanks for the feedback! 🙂

Simply making a drag action on a block in the selection mode would drag that block to rearrange it.

Once there's a prototype I shall open a new ticket if it still makes sense for this feature request. Here's an example for reference, it would be especially useful once people start experimenting with how blocks are arranged spatially


Since this is a new mode, we can introduce other affordances into the block UI that wouldn't normally make sense, such as showing block hierarchy next to the blocks visually in the margins, padding/margin adjustments, borders, etc that would normally get in the way of the editing experience. Perhaps even the mobile UI selection design pattern of checkboxes for selection


This might also be a means of implementing other modes, such as a view only, or an editor commenting/commentary/markup mode

@jasmussen

This comment has been minimized.

Copy link
Contributor Author

commented Aug 20, 2019

such as showing block hierarchy next to the blocks visually in the margins, padding/margin adjustments, borders, etc that would normally get in the way of the editing experience. Perhaps even the mobile UI selection design pattern of checkboxes for selection

I've had some similar thoughts along these lines indeed. There is a great deal of potential. But I didn't want to get ahead of myself. But yes, I do hope that this opens up a way to both simplify and focus various editing experiences.

This might also be a means of implementing other modes, such as a view only, or an editor commenting/commentary/markup mode

I did think of a History tool, that would surface the revision history in a sidebar, and in the editing canvas show, using ins and del markup the changes from the most recent revision. But again, those are ideas to explore in a bit!

@tomjn

This comment has been minimized.

Copy link
Contributor

commented Aug 20, 2019

hmmm, does this overlap with the visual vs code editing modes? It might well be we already have modes in the editor:

Screenshot 2019-08-20 at 12 06 38

@jasmussen

This comment has been minimized.

Copy link
Contributor Author

commented Aug 20, 2019

hmmm, does this overlap with the visual vs code editing modes

If you're referring to the history tool idea I briefly surfaced, then yes maybe. But to be clear that idea is not fully formed at all, so probably should not be considered at this point.

If you're referring to the tools, I would suggest no. I consider the code editor an entirely different editor to the block editor. They may save to the same point in the database, and you can definitely jump into the code editor to debug or fix things. But the transition to and from the code editor is not always as smooth as it would need to be, in order to be comparable, I would say.

@shaunandrews

This comment has been minimized.

Copy link

commented Aug 29, 2019

This is just lovely.

By splitting this behavior into two tools, we can open up the editing tool to be optimized towards just that: writing and editing. And similarly, we can optimize the selection tool towards layout. This gets especially important as page designs grow in complexity.

I really love this. It might be my past experience with design software biasing my opinion, but this separation of modes makes so much sense.

@SchneiderSam

This comment has been minimized.

Copy link

commented Aug 29, 2019

This is just lovely.

I really love this. It might be my past experience with design software biasing my opinion, but this separation of modes makes so much sense.

absolutly! So cool!!

In this context I wanted to say that I really liked to use the Clickthrough. I think it's sad that the team took out the PR #17239 again. But your @jasmussen suggestion would help all of us!

@jasmussen

This comment has been minimized.

Copy link
Contributor Author

commented Aug 29, 2019

Thanks, @SchneiderSam, appreciat your thoughts.

I do think that the clickthrough interface solved a problem, it just solved it also when you didn't want that particular problem solved, so to speak! I do believe, and it is good to get generally positive thoughts to the same, that by splitting in these two tools we can keep the best of the clickthrough, when you want it and not when you don't!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
4 participants
You can’t perform that action at this time.