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

Clicking below bottom text block does not defocus it, which can be confusing #5803

Closed
markjaquith opened this issue Mar 26, 2018 · 20 comments · Fixed by #36656
Closed

Clicking below bottom text block does not defocus it, which can be confusing #5803

markjaquith opened this issue Mar 26, 2018 · 20 comments · Fixed by #36656
Labels
[Feature] Writing Flow Block selection, navigation, splitting, merging, deletion... Needs Dev Ready for, and needs developer efforts [Priority] Low Used to indicate that the issue at hand isn't a top priority to address and can be handled later [Type] Enhancement A suggestion for improvement.
Milestone

Comments

@markjaquith
Copy link
Member

If the bottom text block is focused, its UI could be blocking the block above it. Clicking in the vast space below the bottom block does not defocus it. Instead, you have to click somewhere in the "gutter".

kapture 2018-03-26 at 13 32 28

My expectation would be that clicking in a vast empty expanse would deselect a block. I found myself struggling to deselect the block and reveal the hidden block above it. Esc does not work. Clicking in the vast expanse below only works if you click in the GUTTER. Clicking above sometimes inserts a block, if you aren't careful with your click.

@aduth
Copy link
Member

aduth commented Mar 26, 2018

This is the opposite of the expectation proposed by #5541, when this behavior was first introduced. This was based on the assumption that, for consistency with other word processor applications (Google Docs, Word) and to simplify the selection of text in the editable area, clicking below the last text block should direct focus into the text block at a caret X coordinate aligned to the click position.

I do think it speaks to a broader issue of it being difficult to deselect a block. There's been some recent improvements here as in #5543 to make click-to-clear behaviors more reliable. To the point on whether Escape should deselect the block, there was some mention of this in #5513. At the very least, this needs to be consistent and account for some accessible behaviors which occur within a block such as Escape-to-return-focus (#5551).

Flagging for design, cc @jasmussen @karmatosed

@aduth aduth added Design [Feature] Writing Flow Block selection, navigation, splitting, merging, deletion... labels Mar 26, 2018
@markjaquith
Copy link
Member Author

markjaquith commented Mar 26, 2018

The difference, I think, is that a normal word processor does not have as strong a concept of a focused block that you might want to escape (in this case, so I could see what was in the block above). There are not so many "get me out of here" clicks.

I don't think I'd mind if a "below-all-the-blocks" click made my caret go to an X-aligned location in a bottom-most text block, if it got rid of the UI buttons above it.

@aduth
Copy link
Member

aduth commented Mar 26, 2018

It would surely be an option to trigger the isTyping flag when redirecting the click (the value that dismisses toolbar when typing within a paragraph block).

@markjaquith
Copy link
Member Author

If the bottom block is not a paragraph, a below-all-content click starts a new paragraph with isTyping enabled, which feels really nice. Makes me think that just changing isTyping also in the case where the bottom block is a paragraph is the right move here.

@jasmussen
Copy link
Contributor

I do personally really like the ability to click anywhere below the canvas to set a text caret. It's similar in Dropbox Paper and in Medium, and it's a great callback to editors. Although I understand the ticket here, combined with the ability to click left and right to deselect, I'm not sure I would personally put a high priority on addressing this. (Noting here that the leads might have a different opinion, I don't know.)

However if we were to address it, the compromise described above seems like a fine balance.

@markjaquith
Copy link
Member Author

On some screen widths you only have a handful of pixels of gutters in which to click.

screen shot 2018-03-27 at 10 05 09 am

@aduth
Copy link
Member

aduth commented Mar 27, 2018

There may be an interesting tangent discussion on this psychological desire to deselect blocks. Why do we feel this need, and in what way do we feel uncomfortable by having a selected block (and conversely, more comfortable in a state of complete deselection)? Is it heaviness of the UI (should be lighter)? Wanting to step back and view the post as a flow of content (better previewing modes)?

I don't think it's unexpected; I certainly experience it. And perhaps too deep a discussion, but an interesting phenomenon nonetheless.

@markjaquith
Copy link
Member Author

Yes! I've been thinking about that a lot since opening this ticket. It reminds me of many other experiences:

  • The experience of being physically stuck (in a deep chair, or in a tight space).
  • The experience of trying to get a tight sweater or shirt off, and struggling.
  • The experience of having something undesired (but not frightening) like an insect, upon my person.
  • The experience of having something that isn't relevant stuck in my field of vision. (Desktop clutter, unwashed or unfolded laundry).
  • The experience of having my vision obscured (dirty sunglasses, a dirty windshield or window, someone blocking my view of something I want to look at).

It also represents a loss of control. When I'm using a computing device and the UI is responding quickly and intuitively, I get into this state of flow, where I am master of the machine. When something gets stuck and I'm trying... so... many... things... and... failing, the illusion falls apart and I realize I'm actually losing a wrestling match with an unruly maze of electrons.

Also, the block-selected state seems to be a prelude to action. I've tapped it on the shoulder. I have its attention. And now I'll ask something of it. When it is stuck in this state, and I'm concerned with my content as a whole or perhaps specifically with content that is partially obscured by the selected block, I get annoyed by it being in my face asking me "hey, what do you want me to do? What's up? Look at what I can do. Stop ignoring me—YOU called ME, buddy. Hey. Hey. Hi."

This does seem related to both the heaviness of the UI, and the content-blocking nature of it. I find that I am MUCH less bothered when I have Fix Toolbar to Top enabled.

@karmatosed
Copy link
Member

@jasmussen:

I do personally really like the ability to click anywhere below the canvas to set a text caret. It's similar in Dropbox Paper and in Medium, and it's a great callback to editors.

I also like this ability. @markjaquith you make some excellent observations, thank you.

My expectation would be that clicking in a vast empty expanse would deselect a block.

I think this is a valid expectation by some and I think #5541 is also valid by some. That's kind of the interesting bit here for me as feels like which side you fall on this is from past experience brought to Gutenberg. Both are valid.

On some screen widths you only have a handful of pixels of gutters in which to click.

I agree this is a problem on smaller screens and should be something we iterate on.

It also represents a loss of control. When I'm using a computing device and the UI is responding quickly and intuitively, I get into this state of flow, where I am master of the machine. When something gets stuck and I'm trying... so... many... things... and... failing, the illusion falls apart and I realize I'm actually losing a wrestling match with an unruly maze of electrons.

This is a really important behaviour to notice and design to ease. Anytime someone feels loss of control that's when their bond with the experience is taking a hit.

This does seem related to both the heaviness of the UI, and the content-blocking nature of it. I find that I am MUCH less bothered when I have Fix Toolbar to Top enabled.

That's super interesting an observation. The toolbar position is turning out from feedback to be such a personal preference. We've gone back and forth with it's placing, even having tests go both ways in feedback. The entire thing is interesting from a design challenge view. Thanks for adding feedback there.

@markjaquith
Copy link
Member Author

That's super interesting an observation. The toolbar position is turning out from feedback to be such a personal preference. We've gone back and forth with it's placing, even having tests go both ways in feedback. The entire thing is interesting from a design challenge view. Thanks for adding feedback there.

Yeah, I get that this is a personal preference. I find myself toggling it even based on screen size or what I'm editing.

I think the obscuring nature of the on-the-block editing bar bothers me more than the clutter factor. The first paragraph block obscures the title (partially) and subsequent paragraph blocks obscure the last line of the paragraph block above them. When you're trying to do that lean-back in-your-chair thing and observe your content, you want to be able to see all of it.

@bahia0019
Copy link

I was actually searching for a similar topic when I ran across this, and figured I'd add my observation too.
Like Mark, I too feel trapped when I can't intuitively escape out of something like a focused field.
I think using the ESC key is the most natural method for un-focusing.

In addition, I too have the desire to click into the vast blank area below each block.
I think that it would work to focus the lowest block, AND also unfocus any block when in a block.

@karmatosed karmatosed added Needs Design Feedback Needs general design feedback. and removed Design labels Jun 25, 2018
@hedgefield
Copy link

I understand both sides, but personally also prefer being able to click anywhere in the whitespace to hide the block UI. For me it's a kind of pre-preview - I want to see the whole text, with nothing obscuring it or pulling more attention to a certain section. Eeverything should be as I intend it so I can review the flow of the text.

@ehti
Copy link

ehti commented Jul 19, 2018

I was wondering why I'm unable to get rid of the editing toolbar (of a block) that was hiding the actual text.

I kept trying until I figured out that it only works if you click on the left/right side, and not below the last block in the vast whitespace.

Personally prefer this so +1 to this issue.

@Clorith
Copy link
Member

Clorith commented Jul 25, 2018

I find my self wanting to have the floating toolbar, it gives context with the block that's selected and I find that very useful, but it does obscure blocks above it, and when there is no clear way to deselect it, it's frustrating and I too feel that loss of control and a bit of hopelessness.

I find my self hitting ESC repeatedly to get out of this, I expect most users to turn to the ESC key to de-select what they are in, as most software today uses it as well (see CAD, accounting software, photo editing and so forth, a lot of the tools many use on a regular basis).

@jasmussen
Copy link
Contributor

It's been good to have this ticket sit open to gather feedback. It seems there's a majority consensus that "click below to set caret in bottom paragraph" (which is inspired by classic editors like Notepad and TextEdit) is not as useful in a block-based editor as initially assumed.

So I'm going to file this for 5.0, but with low priority because it obviously works as it is today, and whether this makes the cut depends on someone having bandwidth to write a pull request. But if they appear, we'll merge them. Thanks everyone!

@jasmussen jasmussen added [Priority] Low Used to indicate that the issue at hand isn't a top priority to address and can be handled later and removed Needs Design Feedback Needs general design feedback. labels Oct 11, 2018
@jasmussen jasmussen added this to the WordPress 5.0 milestone Oct 11, 2018
@mtias mtias modified the milestones: WordPress 5.0 RC, Future: 5.1 Nov 15, 2018
@mtias mtias added the [Type] Enhancement A suggestion for improvement. label Nov 15, 2018
@ellatrix
Copy link
Member

Any change in opinion, especially after the lighter block UI that shipped in WP 5.5?

@markjaquith
Copy link
Member Author

Not really. I do like the lighter UI, but the toolbar for paragraph 2 still obscures paragraph 1, and it's hard to make it go away.

Screen Shot 2020-08-20 at 2 07 53 PM

The red areas are where you can click that will make the toolbar go away but not send your focus to another element. It still seems very strange to me that all the empty space below the bottom paragraph doesn't hide the toolbar for the last item. That area below the paragraph is its bottom-margin. Clicking that works, but just a little bit south of there, you're out of luck.

And pressing Esc throws me into select mode.

@jasmussen
Copy link
Contributor

It's definitely been discussed sufficiently, let's try it!

@paaljoachim
Copy link
Contributor

Can we get a status update on this issue?
Thank you!

@paaljoachim
Copy link
Contributor

paaljoachim commented Feb 16, 2021

Clicking below the bottom block should automatically create a new Empty Paragraph block or atleast deselect the block and bring the attention back to the Page settings. Similar to clicking top right of the Page title area brings attention to the Page settings.

Anyhow here is an update to what it looks like currently in WordPress 5.7 beta 2 and Gutenberg plugin version 10.0

Clicking-below-bottom-block.mp4

@jasmussen Joen. It would be great to get this issue fixed.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
[Feature] Writing Flow Block selection, navigation, splitting, merging, deletion... Needs Dev Ready for, and needs developer efforts [Priority] Low Used to indicate that the issue at hand isn't a top priority to address and can be handled later [Type] Enhancement A suggestion for improvement.
Projects
None yet
Development

Successfully merging a pull request may close this issue.