-
Notifications
You must be signed in to change notification settings - Fork 4.3k
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
Consider arrow key navigation between text blocks, faint outlines, or both #1091
Comments
Here are my thoughts... Always present boundaries and tab navigation Yeah, the frustration here is that there's no indication that the bit of text you're in is a self contained thing that you can't navigate out of using the same keys that you use to navigate inside it. Perhaps if the current block was highlighted like we do for form fields, to give it a stronger boundary? Although (total opinion time) I think it's ugly, because I love how clean the editor looks 😄 And... how would the user know that the key to press is tab, unless we make an active block look like it's a form field? The discoverability of that concerns me. Arrow key navigation I don't think it's too much of an assumption to say that we have millions of users who are very used to moving between sections of text with arrow keys. I can go from headings, to paragraphs, to lists, all using arrow keys. You could almost call those sections... blocks? 😉 If you're at the top of a block of text, and there's a block of text above it, and you press up, you move up into the block above.
I would say that makes sense. Perhaps a future enhancement could be skipping blocks that weren't text-based, and going into the next one that is? Freeform block This does so many things for us (breaking out of a list into a new paragraph... navigating around the document...) but I think it loses so much of the niceness of specific blocks that it makes me feel a bit icky. |
+1
Perhaps even better: further refine the concept of a text selection (focus is inside a block) vs whole-block selection (this is the only kind of selection permitted in a non-text-based block, but it's currently not very clear when this is happening). Then the natural arrow key behavior would be to move from the text inside of a text block to selecting an entire non-text block.
I suspect these will not be visible on a lot of screens. I also like the current visual design much better, and suspect that improving navigation would be sufficient to solve this. Finally I am not sure if these outlines would be subject to WCAG contrast guidelines ala #587 but either way it does seem sub-optimal to try to use such a subtle cue to solve this issue. |
If not arrow keys then maybe tabs? I keep trying to tab and shift-tab to jump between blocks because it feels like that should work. |
I agree, tabs should also work but shift tab currently opens the quick toolbar. We are exploring an alternative in #552. |
Yeah, I was expecting to be able to navigate between blocks with arrow keys. |
We added faint outlines as the hover styles for blocks. This is working reasonably well. Let's also add arrow keys. Closing this in favor of #1723. |
Currently in master, text blocks are small units. ⌘A selects everything inside the block, and arrow keys navigate only inside this block.
However when you have not selected a block, all outlines fade out. They also fade out when you are typing. This seems to set the visual expectation that you are looking at a text editor where blocks aren't limited by their boundaries. Let's discuss how to best address this.
Arrow key navigation
Would it help to re-introduce arrow key navigation between blocks? This worked in the prototype, and was also discussed in #520 but ultimately closed for now, due to technical challenges.
Is there a way we can reintroduce it without making too many technical sacrifices? Does it make sense for this to work only between text-based blocks?
Always-present boundaries
Should boundaries always be visible in some form? Quick and dirty inspector mockup:
What would be a good design here?
Let the user pick a default text block?
See also #798: perhaps setting a default text block lets you pick between the per-paragraph text block and the freeform block?
Other ideas? Let's discuss.
The text was updated successfully, but these errors were encountered: