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

Consider arrow key navigation between text blocks, faint outlines, or both #1091

Closed
jasmussen opened this issue Jun 9, 2017 · 6 comments
Closed
Labels
[Feature] Blocks Overall functionality of blocks [Type] Question Questions about the design or development of the editor.

Comments

@jasmussen
Copy link
Contributor

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:

screen shot 2017-06-09 at 13 42 54

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.

@jasmussen jasmussen added [Feature] Blocks Overall functionality of blocks Design [Type] Question Questions about the design or development of the editor. labels Jun 9, 2017
@notnownikki
Copy link
Member

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.

Does it make sense for this to work only between text-based blocks?

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.

@nylen
Copy link
Member

nylen commented Jun 9, 2017

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.

+1

Perhaps a future enhancement could be skipping blocks that weren't text-based, and going into the next one that is?

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.

faint outlines

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.

@Ipstenu
Copy link
Contributor

Ipstenu commented Jun 28, 2017

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.

@jasmussen
Copy link
Contributor Author

I agree, tabs should also work but shift tab currently opens the quick toolbar. We are exploring an alternative in #552.

@JDGrimes
Copy link
Contributor

JDGrimes commented Jul 2, 2017

Yeah, I was expecting to be able to navigate between blocks with arrow keys.

@jasmussen
Copy link
Contributor Author

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
[Feature] Blocks Overall functionality of blocks [Type] Question Questions about the design or development of the editor.
Projects
None yet
Development

No branches or pull requests

5 participants