💾 Archived View for gbryant.co.uk › gemlog › 2024-06-16_hhmu-keyboard.gmi captured on 2024-08-25 at 00:04:12. Gemini links have been rewritten to link to archived content
⬅️ Previous capture (2024-06-20)
-=-=-=-=-=-=-
For my Gemini Hand-Held Maneuvering Unit I've been thinking about how to type on it. One option of course is to add a physical keyboard, but I don't like the idea of having to make a tiny keyboard. I'm wondering if you can type using only a scroll wheel.
Original post about HHMU - "Thinking about a Gemini reader"
A scroll wheel gives us three actions - scroll up, scroll down and click. Depending on which side of the device it's on, scrolling up could also be translated into scrolling left or right. Having only 3 options for interacting with the device is a big constraint, but it's one I'd like to run with for now.
So far I've come up with 4 categories of keyboard that you could use with a scroll wheel:
This categorisation is based on how it works - each could be visually presented in different ways.
A scroll wheel is naturally suited for scrolling through a one-dimensional list. So the obvious thing to do is put all your keys in a one-dimensional list. It's very intuitive to use - you scroll to the letter you want and click to type it. However it also gets tedious as you add more letters/keys - more letters means a longer list to scroll through. They also can't all appear on screen at once, so it can be hard to know which direction is a shorter path to scroll.
Demo video of inline keyboard (116KB) made with p5.js
As the list of possible keys lengthens it starts making sense to group them up. You scroll through groups first and then choose your letter within the selected group. There are a lot of ways to present this - the way that occurred to me first was just a QWERTY keyboard. You scroll through the columns and then select a key within the column.
Demo video of QWERTY group keyboard (254KB) made with p5.js
Sandra at Idiomdrottning suggested an alternative - keep it visually presented as an inline keyboard, but group the keys together for faster scrolling through. I think this combats the disadvantages of the inline keyboard quite well, but I haven't yet tried making it.
This was a bit of a silly idea, but I wanted to try a completely different category of keyboard. The keys are arranged in a binary tree. You scroll one way to choose one child of the current node, the other way to choose the other and click to type the current node.
Demo video of tree keyboard (158KB) made with p5.js
In the video above I make a mistake after typing the first letter and scroll past "e". This shows the big problem with this keyboard - it's not forgiving of mistakes. When you select the wrong branch you have to scroll all the way off the bottom and start again. For this reason I'm not gonna take this keyboard any further.
A thought just occurred to me though - what if rather than having a binary tree represented on screen, you displayed a QWERTY keyboard. Scrolling narrows down which half of the keyboard you want to select, so first you select the half of the keyboard, then a quarter, then an eighth, etc. I'm not sure how you would signify which half is selected by which scroll direction, but it's an interesting idea.
Now the ideas get even sillier - I haven't even bothered making this one. Imagine a QWERTY layout on screen with a cursor that moves across it over time from left to right. It can be moved up or down a row by scrolling, and you click to type the letter under the cursor.
It would be very unpleasant to type on because if you miss your key you have to wait until the cursor goes all the way round to type the next one. And that includes backspace! So you can't type faster or slower than the designed speed. Horrible!
Of course I'm leaning towards a group keyboard or an inline keyboard, since those are the options that aren't silly. My initial preference is a group keyboard with a full QWERTY layout on screen, since it means the e-paper display will need to update less. I'm concerned that the inline keyboard's scrolling would make the screen muddy quickly and require frequent full refreshes. Then again, an alternative way to present the inline keyboard would be to show a QWERTY layout but only scroll through it in a single list, wrapping at the end of each row.
If you have any other ideas that you think would be fun to try, contact me on the Fediverse!