Closed algernon closed 5 years ago
The fullscreen dialog is supposedly "mobile only", and we're supposed to use modals on tablets & desktop. I think we can deviate from the guidelines in this case.
This is roughly what I'm thinking of. A slightly bigger preview perhaps, with the type selector and modifiers checkboxes below the preview, main selection right from there. Clicking an item in the main selection would close the window with the clicked thing used. Clicking the type selector or the modifier checkboxes don't, would need an explicit save for those. Should close on Enter and Esc too (cancelling in the latter case).
I think this is the best of our options, but will explore putting the selector below the keyboard too. I do want to avoid scrolling though, so might have to tweak stuff a little there.
This also gives us much more space on the layout editor screen:
Looks nicer already. Still need to make the ErgoDox buttons wider, but at least we have the space to do so.
Another idea: pull up the selector on the other side of the screen. Key selected on left -> selector on right, and vice versa. This is less distracting than a fullscreen one, but still allows us to have a nice big keymap, and easily scale to all kinds of resolutions.
Having spent a few cycles on this... I'm back to the popup idea. We can just pop up a bigger thing at the selected key, and let the JS libs we use position it correctly.
This page has a playground where the idea can be seen. Using "right-start" as placement, with "flip" and "arrow" enabled is roughly what I had in mind.
With this, we still have a full-screen keymap, but no distracting full-screen or modal dialog, no half-screen sidebar (which would interfere with the main menu too, btw), and no need for an extra preview either.
Current iteration:
This is not as convenient as I first imagined. First, it covers nearby keys, which makes it awkward to use it. It's hard to implement click-away properly (we'd need a clickaway for every key, pretty much), and the positioning isn't exactly reliable (it fails miserably on the ErgoDox). It also really needs an arrow pointing to the selected key, but that's a huge pain to implement too.
Trying to move the key selector to the bottom:
I had to remove the AppBar
to make even a small selector display. I can rearrange the selector to not waste so much horizontal space (it was set up for vertical use), but we'll still have about 3-4 lines of keys available at ~1600 pixel width, and that's with the appbar gone.
I can make the keymap image smaller, to make more space for the selector, but one of the reasons for this whole exercise is to be able to use a larger keymap, not a smaller one.
I think bottom's not going to work.
this is kind of roughly what I was thinking, but a horrible mockup the current dropdown becomes vertical tabs. keys get spread out across the box. modifiers show up similar to how the are now Styling keys as enclosed key-like shapes makes it a little easier to understand them as buttons the currently selected one, maybe is highlighted as the active button.
If we flow the keys onto 2-3 lines, we could even put the save button to the right.
Right now, we have the key selector to the right of the keyboard image. This works fine for the Model01:
It's not working so well for the ErgoDox:
We could move the selector below the keyboard, which would likely work for the ErgoDox, but fail for the Model01. We could also turn the selector into a full-screen dialog that presents the selector, and a small preview of the keyboard with the selected key highlighted (with color only). This would work for all keyboards, and we'd have all the space for the keyboard image itself. This is also the most responsive solution, and would allow us to lower the minimum resolution requirements of the Chrysalis window.