[Y-devel] Design for Keyboard Shortcut Behaviour: Quasimode Command System

[Augie Fackler]

>> 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.
>
> The fact that very few non technical users pick up keyboard shortcuts 
> is the reason that I want to encourage their use. They are by in large 
> a lot more efficient that using the mouse. But because mouse commands 
> are currently much easier to discover users never bother trying 
> keyboard shortcuts.

How so? Using a menu item shows you the keyboard shortcut. Windows < XP 
shows the accelerator key all the time, and people didn't pick up on 
it, so now it is hidden to reduce clutter. That doesn't seem any less 
discoverable than a normal menu item. I think that people tend to learn 
one method and then lean on it until it becomes cumbersome. I tried for 
years to get people to use keyboard shortcuts over buttons and other 
systems, but the respose is always something like 'but what I do now 
works, even if it's slower.' Also, a system can be too discoverable. 
KDE has many easily discovered features, but ends up feeling very 
cluttered.

> You may have a point that sequences of events using the mouse are 
> easier to remember, I'll just hope that the difference isn't too 
> severe.
> <snip>
> The advantage of not requiring the letter to be in the label is nice, 
> but I think it is outweighed by the disadvantage of the shortcut being 
> hidden until the user takes some action.

True, perhaps this should be implemented only where the shortcut isn't 
in the label. I don't like the fact that the label must contain the 
shortcut key, it can be limiting.

>> I was personally hoping that the list of controls that could be 
>> tabbed through would be user configurable to prevent tabability holy 
>> wars.
>
> I was hoping to follow the windows method of having every control 
> accessible from the keyboard. I don't really see any advantage in the 
> mac way of forcing you to use the mouse to access some controls but 
> not others.

The advantage shows up on a website like slashdot where they have 
several hundred links, I can be in the username/password field in under 
3 tabs(5 if I am in the address bar of Safari). All I ask is that we 
leave this as a user choice, not a hardcoded system. I don't want to 
debate the merits of the different systems.

>
>> 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.
>
> Yup, LEAP does move you to a point in the document, just like Find. 
> Ideally it would be part of the standard text entry widgets, if a 
> plugin could do it that would be perfect.

Similar things have been done on the OS X input field widget. 
TextExtras, as an example, adds things like the emacs pipe command to 
every cocoa text field. A well implemented system could be made so that 
plugins would effect all textfields. Perhaps we could after a time have 
a bunch of standard plugins, and do the KDE interview thing and make 
users as comfortable as possible, regardless of background(tabability 
settings, menu location(I feel at the top of a window is wrong for 
efficiency, but if somebody wants the slow way, so be it), command key, 
etc).

>
>> 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.
>
> I was hoping to have the advantages of The Humane Interface while 
> still allowing diversity by have all the THE elements as default, so 
> new users would get their advantages. While still allowing the 
> elements to be unloaded and replaced by others (so if the user doesn't 
> like using QCS for shortcuts, another modules could be used).

You end up with the problem that lazy app writers will prefer one 
shortcut system over another, and you end up with a shortcut system 
soup as is present on most *nix environments now. <idea> Maybe the QCS 
could use the menu item name for the command? Thoughts on that 
concept?</idea>

<snip expose talk>

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);}