Re^2: Better keyboard-driven navigation, any?

[clinton]

The access key shortcut in FF3 on linux is Alt-Shift-KEY (see Access key for info about other browsers), and this is configurable in the about:config keys ui.key.*, (see the mozilla docs for more), so there should be no conflict with browser-specific shortcuts.

Adding access keys is as simple as adding accesskey="$char" (for instance accesskey="Y" or accesskey="&")on any of these elements: A, AREA, BUTTON, INPUT, LABEL, LEGEND, and TEXTAREA.

Update Added example with an entity as suggested by ysth

[tye]

Thank you for pointing out that recent versions of FireFox allow one to change the quite stupid default of having "access" keys conflict with the "menu" access navigation (Alt) that I use very frequently (Win32). I find it funny (in a sad way) that these "ui" settings have such an impressively bad UI (you have to read a separate document to find that the cryptic integer values can be looked up on yet another page where they are in hex so you have to convert the hex to decimal and then type it in).

My personal CSS puts red striped borders around "access key" navigation items just so I'm likely to notice them since they mostly serve to trip up my normal keyboard navigation techniques (so I'm certainly not a fan of their use so far).

I wish I knew a similar trick for IE as I still use IE for PerlMonks even though I use FireFox for most other surfing (IE has key features that make it much nicer for surfing PerlMonks for me than FF, though FF 3 finally caught up on soft hyphen support after a decade of IE following the standard so that is one less key PerlMonks feature once FF 3 stabilizes).

I don't see how your suggested navigation features fit PerlMonks. What is "next post"? You must be navigating via some more specific scheme that you don't explain for "next post" to make sense in your mind. There is no general concept of "next post" at PerlMonks so offering such a navigation option so prominently would most likely just confuse a large fraction of monks who don't or just currently aren't reading PerlMonks in the manner you are assuming.

"Vote ++"? Most places at PerlMonks present more than one node to vote on so a "Vote ++" navigation doesn't make much sense to me.

Perhaps you are thinking of scrolling within a thread, but I don't think access keys can be used that way (without doing a lot of JavaScript...).

For navigating between voting buttons, I've found that several browsers already have decent keyboard navigation for that. The voting buttons are often "adjacent" form elements so "go to next form input control" (etc.) often works well for selecting vote buttons.

I have used Opera and it does define some nice keyboard navigation shortcuts. So I encourage you to try it. You can also configure FireFox to "search when you type" which makes it fast to jump to navigation links via a keyboard.

So, your suggestions for navigation keys reinforces my impression that for them to be useful, people need to be able to customize them (there are only so many keys and there are lots of ways to navigate PerlMonks).

I also think that, with browser defaults mostly stupid with regard to access keys, it is best to have few if any access keys by default (such as only numeric ones, as Corion mentioned). Users who have made the effort to change the stupid defaults should be allowed to make the effort to define where they want access keys (I am disappointed that this isn't just natively supported in browsers -- part of the point of browsers and HTML was supposed to be to give the client control over presentation and navigation, despite so many web "designers" seemingly thinking nearly the opposite these days).

Perhaps the best next step would be to look for places where you want an accesss key and see if the HTML makes it easy or hard to use JavaScript to attach such for your own use. Suggesting specific things like adding a specific id="..." to a specific navigation point would allow such customization to become easier.

[shmem]

"Vote ++"? Most places at PerlMonks present more than one node to vote on so a "Vote ++" navigation doesn't make much sense to me.

That's the key. Why not? if you are reading a specific reply, you know which vote checkbox to press with the mouse to mark a vote, and you don't get confused by the other voting tokens on the page. Mouse navigation allows you to select the appropriate items directly according to the visual context.

Key driven navigation is not so difficult. You can have a keystroke for voing (++, 0, --), but a previous keystroke has to establish the context for it, and that keystroke should scroll the context into view. Not that difficult with javascript.

Browsers do have (customizable) keystrokes for elements, but "they" don't "know" about the layout of a page and about the contexts therein. So, links are stuffed into a single flat list which can be navigated via <Tab> - not a suitable navigation scheme, if you are way down a page reading replies and have to issue oodles of <Tab> strokes to finally get at the checkbox you want to address. There's no way I know of to select items which are not links.

Luckily, PerlMonks pages are organized in a pretty consistent way, so it is easy to define contexts to which to navigate, and with javascript recording the current context, navigation inside that context is easy also. Which brings me back to your question further up:

What is "next post"?

Well, that depends on context ;) PerlMonks pages are divided into a header (links to sections a.k.a monkbar, introductory words to a page or the OP in a thread), a collection of items (links to nodes contained in sections, or actually posts a.k.a. replies to the OP in the header) and nodelets. Inside the collection of items is the "next post", which is a thing that is already on display but not selectable via a link (the "next post" in Newest Nodes would be the next section); and inside that "post" there may be a link collection which can be navigated with default browser keys.

I think you get the idea... I've started to implement key navigation, and currently I'm looking at PM in terms of establishing contexts, sub-contexts and navigation. Viewing things that way might also reveal opportunities to unify and simplify things.

[tye]

The node I replied to was about HTML accesskeys. What you are doing seems quite unrelated to that. Note that I said:

" Perhaps you are thinking of scrolling within a thread, but I don't think access keys can be used that way (without doing a lot of JavaScript...). "

You seem to be doing a lot of javascript, no? And you don't seem to be using HTML accesskeys at all.

but a previous keystroke has to establish the context for it, and that keystroke should scroll the context into view

And does scrolling the content change the context? Is there a visual indicator of what the current context is? You might want to consider those points if you haven't. These are some of the issues that crossed my mind such that I decided to not further discuss the idea beyond my brief mention.

I'm glad you appear to have made something that is useful to blazar. Personally, I scroll a thread when I'm done reading/scanning what currently is displayed not in increments of nodes. But I appreciate the potential improvement for others.