Make colorpicker keyboard-friendly

[teleclimber]

Now that we can open with Ctrl-K it would be nice if the whole component could be usable with just the keyboard.

I suggest:

• make it possible to tab between inputs. (currently, if I'm in RGB mode and press tab, it changes the mode and blurs the input :(
• make the sliders focusable and use arrow keys to change value. Maybe even shift+arrow for fine adjustment
• make the gradient focusable and editable with keyboard.
• listen for Esc and Enter and use those to close dialog and return focus to CM.

Thanks. :)

[easylogic]

@teleclimber

Good ideas!!

• Main Color Select -> left, right, top, bottom keys
• Hue Color select -> shift + left, right keys
• Transparent select -> ctrl + left(or bottom), right(or top) keys
• Mode Select -> Tab key
• Close Color Picker -> Esc or Enter keys

I'll implement this function.

[teleclimber]

Glad to hear you're interested in implementing this. However I am not sure that shift+left/right for Hue and ctrl+left/right for alpha is the way that offers the best UX.

Main reasons:

• Users like to have fine-grain and coarse-grain adjustment abilities (see DevTools for examples). This is usually done with shift+arrows for example. If shift+arrows is used for something else then you can't offer that, or it has to be a complicated key combination
• it's not discoverable. Users would have to read the instructions to know that shift+arrows and ctrl+arrows. And they have to remember it too. But the tab key is the standard way of going from one input to another so they don't need to know or remember. Once a slider has the focused "blue highlight" they can probably guess that it's arrows that will move the slider.
• If you use tab to change mode, user can't use tab to go from input to input in RGB mode. How do I focus Green input if I am in Red input using the keyboard?

Anyways, just my two cents, but I think using standard keyboard actions is far easier on the user.

[easylogic]

I'm testing some keyboard features, but it's hard to get it right now. I think we need to do more research on the UX side.

I found some facts while testing.

1. The colorpicker must have the focus unconditionally and be able to receive key events. When you click with a mouse click, the focus does not go out.

2. When changing the mode through the tab, only the mode will be cycled. Finally, there is no way to get the focus back to the colorpicker.

3. When keystrokes are input, all events are passed to the colorpicker event handler. So, when you use the key defined in the colorpicker in the input, it behaves unintentionally. For example, when you press the right arrow, the input is the cursor movement, but the colorpicker is the act of changing the main color. This will cause the color at the current input to change.

4. As you say, you need to know in advance what keystrokes are. This is the most realistic way to switch to Tab mode.

[easylogic]

I made feature/keyboard branch.

https://github.com/easylogic/codemirror-colorpicker/tree/feature/keyboard

I am going to update continues about keyboard feature

[easylogic]

https://store.jui.io/v2/view.php?id=58f8d68594976c182b7b23c7

This is a sample page.

Place your cursor on the code mirror and hit ctrl + K to open the colorpicker popup.

• Move the arrows at this time.
• Press shift + arrow to change the hue color.
• Press ctrl + arrow to change the opacity.
• Press the tab to change the mode.

But I still have a lot of problems.

[teleclimber]

On a Mac Ctrl+arrow changes the desktop! So I think using Ctrl+arrow is not going to work.

I agree that doing this in a branch is a good idea.

[easylogic]

@teleclimber

I also added a metakey check.

Now Ctrl + arrow is equals to Cmd + arrow

[teleclimber]

cmd + left is the "back" button in Chrome, Cmd + right is "forward in history".

Have a look at the dev tools keyboard shortcuts to see which ones are likely "safe"

https://developers.google.com/web/tools/chrome-devtools/shortcuts

[easylogic]

CMD + > or CMD + <

How is this?

[teleclimber]

CMD + < opens settings in Chrome.

This is a losing battle IMO. I would use tab key only to navigate to inputs within colorpicker (including sliders and the gradient). And only arrow keys to change the value, with maybe fine grain and coarse grained modifier keys modeled on what detools does.

That way no weird surprises, and easily discoverable for user.

[easylogic]

The tab only specifies the data region and the remainder defines the value with an arrow.

• MainColor
• Hue Color
• Opacity
• Hex Mode
• RGB Mode
• HSL Mode

The current focus area should be expressed a little differently.

Good!

[easylogic]

@teleclimber

https://store.jui.io/v2/view.php?id=58f8d68594976c182b7b23c7

I am refactoring for keyboard features.

Tab key is change selection area. Arrow keys is change real value for selection area.

[easylogic]

This is a sample move patterns.

[Mottie]

The "HEX" mode works great if you have the outer wrapper focused, but if you focus the hex input, the movement and color selection is awkward.