[HN Gopher] Spatial Keyboard Navigation
___________________________________________________________________
Spatial Keyboard Navigation
Author : danilowoz
Score : 62 points
Date : 2021-10-17 12:25 UTC (1 days ago)
(HTM) web link (danilowoz.com)
(TXT) w3m dump (danilowoz.com)
| whatsapps2020 wrote:
| Looks great. I wish I could use keyboard navigation more because
| my wrist hurts from mouse, and mouse pointer is kinda hard to
| target.
|
| Is it possible to implement this thing as browser extension?
| melling wrote:
| Why not wish for eye tracking so we could simply look at
| something? Then a subtle Soli gesture to select.
|
| https://atap.google.com/soli/
|
| I always think of this blog where the person had to use their
| nose because their hands were in pain.
|
| http://www.looknohands.me/
|
| Discussion from 7 years ago:
|
| https://news.ycombinator.com/item?id=8805053
| Ajedi32 wrote:
| I've been wanting something like that for a long time. Eye
| tracking + a simple keyboard shortcut to trigger a click so I
| can select anything across the entire system instantly
| without having to take my hands off the keyboard. So far
| though I haven't been able to find any decent out-of-the-box
| solutions for that without any major drawbacks.
|
| Eye-tracking is an underrated user input method in my
| opinion. I'm hoping eventually VR/AR will make it mainstream.
| whatsapps2020 wrote:
| Haha, eye only interface would be great. But why do I need
| Soli for it, wouldn't webcam-based eye-tracking with one-eye
| blink for a click be enough?
| melling wrote:
| Until your hands start hurting like the person who I
| mentioned. I was trying to discuss solving the general
| problem. Some people also suffer when using a keyboard
| 58x14 wrote:
| I think you'll find this presentation by Emily Shea on voice
| driven development to be intriguing.
| https://www.youtube.com/watch?v=YKuRkGkf5HU
|
| aside, novel HIDs are IMO a huge market gap that I'd really
| like to invest time in if anyone wants to chat.
| KarlKemp wrote:
| Try vimium, which is probably fast (although I usually still
| prefer the touchpad). This is what it looks like: https://user-
| images.githubusercontent.com/2781117/28320939-f...
|
| It's one keypress to get the hints, then usually two to select
| the element, whereas tab-navigation is 1/4 the number of
| elements on the page (if you do shift+tab whenever it's
| shorter) and this Manhattan-style keyboard navigation is 2 x
| sqrt(# elements), if I'm not mistaken.
|
| Here's what I thought just reading the title: press a key, and
| the elements are spacially mapped onto all keyboard keys
| (except ESC). Then, hit the key in the general vicinity. If
| there's too much and you are likely to miss, zoom into the
| specific area and repeat.
|
| That's really equivalent to the vimium method, but a bit more
| visually intuitive.
| rlili wrote:
| I use Vimium's hint navigation. Works great for most sites.
| svilen_dobrev wrote:
| intesting. btw i tried the preview https://spatial-keyboard-
| navigation.vercel.app/ .. the 3 checkboxes at bottom left don't
| play well with up-down arrows , and dont show the focus when on ;
| and the tab-keyed focus is not shown either..
| Varriount wrote:
| While I do agree with the latter 2 points, (can't multi-jump,
| hard to memorize), the assertion It follows the
| order of the DOM elements and not the visual position of these
| elements on the page, which means that it uses the HTML structure
| (not user-friendly), but it should go after the layout position
| (spatial position);
|
| Isn't quite true - all HTML elements support the "tabindex"
| attribute[0], which can be used to set the tab order of a page's
| HTML elements.
|
| That being said, using "tabindex" (or having an out-of-order page
| structure) can cause accessibility problems for those using
| screen-readers and related programs.
|
| From [0]: Warning: Avoid using tabindex values
| greater than 0. Doing so makes it difficult for people who rely
| on assistive technology to navigate and operate page content.
| Instead, write the document with the elements in a logical
| sequence.
|
| [0] https://developer.mozilla.org/en-
| US/docs/Web/HTML/Global_att...
| rektide wrote:
| Really neat. My biggest gripe is that there's a lot of good,
| neat, interesting semantic data you're marking up the JSX with,
| about Area and Anchor, and none of that information makes it into
| the rendered HTML. I'd love to just see something as basic as
| `data-area` attributes on things that are areas, to make this
| internal context this cool library makes a bit visible, knowable,
| & accessible, to whomever might want to explore it.
|
| In a more WebComponent-ified world, I'd love to see these DOM
| components have left/right/up/down methods, that would return the
| components on it's sides.
| Scene_Cast2 wrote:
| Super cool. As a note, try selecting "Areas" for a hierarchical
| view
|
| I noticed a glitch in the demo. The "options" area, when only
| "animated" is selected, thinks that the three checkboxes are not
| vertically aligned (jumps from "animated" to "strict area",
| skipping "Areas" when pressing up / down, need to press "right"
| to get to "Areas")
| Ajedi32 wrote:
| This is really good! So good that it ought to be implemented in
| browsers in my opinion, probably as a set of additional `aria-*`
| attributes.
|
| In line with other common conventions, I'd also like to see
| Ctrl+Arrow to move between areas, home/end to move to the
| beginning/end of the current area, etc.
___________________________________________________________________
(page generated 2021-10-18 23:01 UTC)