Re: Design for Keyboard Shortcut Behaviour: Quasimode Command System

On May 23, 2004, at 1:38 am, Augie Fackler wrote:

> [...] Could we make the quasimode entry key configurable, so that the 
> kinesthetic people have built up for a specific location isn't lost? I 
> occasionally get myself in trouble when using Windows, because alt-z 
> is the same kinesthetically as cmd-z on a Mac.

That is an interesting point, something well worth testing out. (I also 
use both Mac and Windows keybaords, and I had the same trouble in the 
beginning. I now find that I seem move between the keyboards with 
little to no trouble. Although I'm not saying that is valid excuse for 
avoiding this issue :)

> Personally, I think this isn't so good. On Macs there has 
> traditionally been a couple of ways to do very common tasks, because 
> what is intuitive is slightly subjective. As an example, right now I 
> can use a menu item, command key, or a toolbar icon to save this note 
> as a draft. Efficiency isn't the only thing we have to look for, it 
> also has to be intuitive(If efficiency were of more value than 
> intuitiveness then we'd all be using RPN calculators, but that won't 
> happen, because use of such a calculator isn't nearly as intuitive).

A good point, my hope is that the QCS can be made *easy enough* for 
novice users. We just need to make it such that the user can find the 
command they are after. Initially this will probably just be done by 
listing the commands and their descriptions. There may be some problems 
with this, like an overload of text. So adding icons/diagrams or 
something may help. Or give important/most used commands some 
differentiation (bigger text/different colour) in order to draw the 
users eye. Any ideas in this vain would be greatly appreciated.

One of the problems of having both the toolbar button and the command 
shortcut is that it is easy to become habituated to using the toolbar, 
which is a lot less efficient that using the shortcut. If we removed 
the menu item and the toolbar button, the user would be forced to use 
the most efficient method. But then we lose the great benefit of the 
toolbar, which is the visibility of the commands. I'm kind of hoping 
that providing visibility using the command list would alleviate this, 
I'm prepared for the fact that it may not, but I want to try it and 
see.

I don't want to imply that I favour removing any mouse access to the 
system at all, or that I want to enforce ultra strict monotony. My 
current feeling is that we should provide single easily discoverable 
and efficient keyboard commands, and single easily discoverable mouse 
commands. Thus I hope to avoid forcing the user to change input methods 
(e.g. so users of a web browser don't have to key moving to the mouse 
to click a link, and the move to the keyboard to go back).

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.

> Might I suggest using ALT on Windows keyboards and Apple on Macs? 
> Those are kinesthetic equivalents.

You may. If that seems to work better than we can use that.

> Also, I agree with the earlier comment about popups being annoying. 
> Why not just show the shortcut items next to menu items like everyone 
> else? For non-menu items, holding down the [command] key could change 
> the label of controls with shortcuts to contain the shortcut as well. 
> I have seen that a couple of times, usually after a few hundred 
> milliseconds.

Hopefully by only showing the pop-up after a delay it will avoid 
annoying people, obviously we'd have to do a few tests to see if this 
is actually true :)

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?

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).

>> <snip>
>> Commands can have parameters, such as the start application command 
>> accepting the name of the application to start. A space following the 
>> command name indicates the intention to enter a parameter. The list 
>> of commands is then replaced by a list of parameters.
>
> Why not use a dialog box of old for this?

I am attempting to reduce the use of modes (most dialog boxes are 
modal).

> The alt-tab does break the old rule, but on macs, at least, it allows 
> key commands to be sent to a backround app without bringing it to the 
> front. I can quit 6 apps just by holding command and hitting tab and q 
> 6 times.

A (very) brief check of this behaviour shows Quit seems to be the only 
command that can be sent to background apps while part way through an 
alt-tab. You'd probably have to convince me of the usefulness of 
sending commands to background windows in general before I'd consider 
this something worth looking into (unfortunately I don't have enough 
time to examine every cool idea).

> I don't see this as necessarily a good thing. Multiple modifiers can 
> be just as easy to hit as a single one(for those on a mac, 
> command-option isn't really harder to hit than just command or just 
> option, once you know where to aim, windows keyboard, same for 
> windows-alt). Commands can already take parameters by bringing up a 
> dialog, like the Find command in most text editors.

A good point about multiple modifiers not always being evil. I am 
beginning to like the Mac behaviour of CMD-R: Reply, CMD-SHIFT-R: Reply 
to All. Where adding an extra modifier changes between related 
commands.

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).

>> If The QCS is integrated with Y applications and widgets, as well as 
>> the window manager, Y can benefit from a better command system than 
>> exisiting GUIs.
>
> I was going to suggest it be implemented alongside a more traditional 
> system, but I think that would be mutually assured destruction. Some 
> apps would favor one system over the other, and we'd have a KDE vs 
> GNOME kind of thing on our hands.

Ideally I'd love for my ideas to be so brilliant that they just become 
the default Y behaviour. I am a big support of the single interface 
behaviour (like on Mac and Windows), rather than the fragmented 
interface design on Linux. I see Y moving in this direction as 
indicated by the single widget set.

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.

>> <snip lots of roadmap things>
>>  * Replacing 'Alt-Tab' behaviour with go to window behaviour, which 
>> is better
>
> That is probably the only command which is kinesthetically the same on 
> all 4 platforms I use(Win32, Mac, KDE, GNOME). That, at least, should 
> remain a holdover.

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 :)

Karl