Re: Design for Keyboard Shortcut Behaviour: Quasimode Command System

On May 26, 2004, at 8:28 PM, Karl O'Keeffe wrote:

> <snip>
> Ideally the system would somehow encourage the user to use the 
> keyboard shortcuts over mouse commands (where they are more 
> efficient). Anyone with any bright ideas as to how to do this let me 
> know.

I'm not opposed to having a shortcut system at all, but I think that 
users shouldn't be encouraged to use one method over another. Many of 
the new users I help out eschew keyboard shortcuts entirely. Long term, 
very few non-technical users pick up the shortcuts, even if I encourage 
them to try it out. Many users seem to remember the sequence of events 
better if they use the mouse.

> <snip>
> Not sure I understand what you are on about with the changing labels 
> of controls. Do you mean the behaviour in newer versions of Windows 
> where holding down the ALT key displays the underline indicating the 
> ALT-key combination to move focus to that control?

First example I can remember is Appleworks, since at least when it was 
ClarisWorks 4. The delay feels like about 500ms, but I'm not sure on 
that. Here are links to before and after the delay pictures:
http://tuxserver.ath.cx/~durin/tmp/after.jpg
http://tuxserver.ath.cx/~durin/tmp/before.jpg
The advantage to this over the Windows system is twofold: the letter 
used needn't be in the control label, and the existence of such a 
letter is more easily noticed because of the shift in position of the 
lettering.

> If you do, I think I would prefer it if the underline was always 
> displayed, it's not very distracting and adds some visibility to the 
> commands. I was hoping that Y would behave similarly to Windows with 
> respect to moving focus between controls, maybe making it a little 
> more obvious for novice users (because I hardly ever see anyone taking 
> advantage of the ALT-key shortcuts, including me).

I was personally hoping that the list of controls that could be tabbed 
through would be user configurable to prevent tabability holy wars.

> <snip>
> I'd like to avoid dialog boxes wherever possible. For Find I'd like to 
> implement a LEAP style system as detailed by Jef Raskin in the 
> Technical Specification for The Humane Environment 
> (http://humane.sourceforge.net/the/spec.html - its a long read, so 
> maybe do a Find for LEAP).

After numerous reads through the spec, I think that LEAP is just a 
method of moving to a specific point in a document. Is that correct? I 
think this could be done as a plugin to a standard text entry widget.

> <snip>
> Hopefully we could avoid locking the user in to a single behaviour (I 
> know how Linux users love to use diverse weird and wonderful 
> interfaces/window managers). Provide a good default interface, but 
> still allow people to use something else if they feel the need.

I think you need to pick here: Diversity or THE, they are mutually 
exclusive as far as I can tell. I think that if Y ever wants to be more 
than a niche market, THE is pretty much out of the question.

> <snip>
> Indeed, my idea for having a go to window command instead just turned 
> out to be way to complex and almost impossible to make efficient. I'm 
> still not entirely happy with the way alt-tab behaviour works (have to 
> keep looking to see where in the list the window we want is), but I 
> can't come up with anything better :)

I like expose, and I learned today that you can pick windows from the 
keyboard. Works in both F9 and F10 expose modes. I think expose could 
be effectively done as a plugin after the rest of the system is 
functional.

AF
---
main(){char ch[7];ch[1]=(ch[4]=((ch[3]=(ch[2]=103)^14)^12))^16;
ch[5]=(ch[6]=(ch[0]=(ch[1]>>1)+7)&42)+10;printf(ch);}