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

Designs for the Keyboard configurator #10

Open
maria-komarova opened this issue Sep 25, 2020 · 5 comments
Open

Designs for the Keyboard configurator #10

maria-komarova opened this issue Sep 25, 2020 · 5 comments
Assignees

Comments

@maria-komarova
Copy link

I am not sure where else to put those designs so I am posting them here. I can move them if there is a better place for them.
Here is the link to the partially clickable prototype: https://www.figma.com/proto/YzqrbohHAbPUR5w26d6ton/Keyboard-Configurator?node-id=191%3A32666&scaling=scale-down
In this prototype you can see the dropdowns and some of the dialogs. R and Y keys can be clicked. R can be changed to P. If you click on Enter that should show the multiple select state. The idea is that the section with keys that show functions should be scrollable below the keymap. Mostly to account for the possibility that the list can get larger and to keep the keymap above in view. Green is the color that can be edited or removed to better see this functionality.

The first view is the page that should be shown if there are multiple keyboards connected. If a user has only one keyboard the app can open on the configurator view right away and show the current layout.
When the current layout is deleted show the confirmation dialog and then change the view to the next layout. The last layout can not be deleted and the Delete functionality in the menu should be disabled.
"Save without Applying" should be disabled if the user is changing the current layout. One can either Save & apply Changes or Save as at this point.

Use Ctrl + 1, Ctrl + 2, Ctrl + 3, Ctrl + 4 to switch between layers. Include those shortcuts and the shortcuts from the hamburger menu in the Keyboard Shortcuts dialog that should follow regular GNOME shortcut app dialog styling.

Share button should allow users to share the link to the Github where the configuration is stored. Sync changes button should save the configuration on Github. I am not yet quite sure what the process for this should be. This is something we would need to figure out.

The LEDs are shown with the 3px border on the inside of the key. The idea is to use this border to show the chosen pattern. The prototype has "Select layer LED pattern" dropdown but there will probably be a pattern by default for the keyboards that would have it.
If the keyboard doesn't allow any patterns the dropdown should be disabled. The same is true for the per key LED settings. If the keyboard doesn't allow per key LED settings, those controls should be disabled. Or potentially shouldn't even be displayed.

The keys in the section that shows the functions are grouped. If we add more functions we should see either what existing group they belong to or put them in a new group. Controls like Brightness can be shown with symbols to save space if we think it would still be clear to users what they mean.
The keycaps here have two sizes: 36x36px and 60x36px. Assuming the 3px border can be used to indicate selected state, there might be an additional 1px padding between this border and text.

To show the selected state of the keys on the keymap above: set background color to white, use checkmark in the left bottom corner and darken all deselected keys (I merely used the overlay. I can give exact details for what color I used and at what opacity if needed).

I am including separate mockups here below as well.
Keyboards
conf-layer1
conf-layer-key-selected-1
conf-layer1-key-pattern
conf-layer-layer-color
conf-layer1 (1)
dialog-delete
new-layout
new-layout (1)
conf-layer1-applied

@jackpot51 jackpot51 self-assigned this Sep 25, 2020
@jackpot51
Copy link
Member

jackpot51 commented Sep 25, 2020

A single key will not be able to do a pattern different from a layer, in reference to the Use layer LED pattern next to Key LED color. The keyboard may be constrained to either doing a pattern or having each individual LED set

@maria-komarova
Copy link
Author

maria-komarova commented Sep 25, 2020

I was looking at the Spec doc that @WatchMkr put together for that.
Would it be possible to set the keys that the user is trying to change to whatever they choose and then treat the rest of the keys as if they were individually set to whatever was chosen for the layer?

@jackpot51
Copy link
Member

jackpot51 commented Sep 25, 2020

Each effect may have different rules for different keyboards. For Launch, we have complete control over the LEDs. But for laptops (with per-key RGB), it may be constrained to one of two items:

  • Per-key color and per-keyboard brightness. This can be abstracted in software into per-keyboard color.
  • An effect such as breathe, which has a per-keyboard brightness and may or may not have a per-keyboard color

Also, laptops with per-key RGB will not be able to set colors per layer.

@maria-komarova
Copy link
Author

It is fine if we disable the functionality for the keyboards where not all of those functions would be possible. I tried to account for the maximum case but I thought we can either disable or do not display some of the functions for the keyboards that won't support it.

@jackpot51
Copy link
Member

What are the font sizes used?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants