Re: Design for Keyboard Shortcut Behaviour: Quasimode Command System

Disclaimer: These are just my opinions. If I come off a flamey or 
anything, please don't take it as such. Any flamishness most likely 
stems from trying to keep my comments really short and to the point, 
and I apologize for it in advance.

Summary: I personally dislike the idea at first glance, but am still 
very open to it. I really need to know more about the whole thing to 
make a fair judgment. I really like my two key commands. It feels like 
a step backwards, but then so did moving to an RPN calculator, and I 
use one of those every day.

On May 22, 2004, at 5:00 AM, Karl O'Keeffe wrote:
> <snip>
> Knowing that we are all lazy programmers, I've also appended the 
> document to this email :)

Being lazy, I didn't notice that until *after* I read it on the web....

> <snip>
> Jef Raskin[1] coined the term 'quasimode' to describe an input where 
> the user must hold down a modifier key in order to enter commands. He 
> argues that mode errors are a significant problem in existing user 
> interfaces. vi is a modal editor, the result of pressing a key depends 
> on the current mode, forgetting the current mode can lead to errors 
> (such as text being entered as commands).

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.

> <snip>
> Monotony is idea that there should only be a single method for 
> accomplishing each task. Hick's Law[3] tells us that as we give a user 
> more ways of accomplishing a single task they will take longer to 
> decide which method to use. Therefore efficiency can be improved by 
> only ever having a single method for accomplishing each task (just 
> make sure it is the most efficient method!).
>
> Monotony inceases the power of habitutation by ensuring the user 
> always accomplishes the same task the same way, thus becoming 
> habituated faster.
>
> Efficiency of an interface could be measured by calculating the 
> minimum amount of information required to perform a task divided by 
> the amount of information the interface requires the user to provide. 
> For example the editor vi can be considered very efficient as most 
> commands are only one or two characters long, whereas using the file | 
> print menu with the mouse is very inefficient as it requires multiple 
> mouse movements and clicks to impart a single element of information 
> (that the document should be printed).

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

> Description of Quasimode Command System (QCS)
> ---------------------------------------------
>
> Initially the Quasimode Command System will be used for issuing 
> system, and window manager commands (for example start an application, 
> or go to a specific window). Later it can be used for issuing commands 
> to widgets and applications.
>
> To issue a command (to the system or window manager) the user holds 
> down the [command] key (either the Windows key, or the Apple key*). 
> This brings up a prompt and a list of commands and their associated 
> descriptions, on top of all the other windows and filling most of the 
> screen. As the user types a command the prompt updates with the text 
> entered. The user releases [command] to execute the specified command. 
> If the users text does not correspond to a valid command nothing is 
> executed, allowing a user to mash the keyboard and release the 
> [command] key to exit the quasimode.

Might I suggest using ALT on Windows keyboards and Apple on Macs? Those 
are kinesthetic equivalents. 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.

> <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?

> <snip>
> The QCS is different from most implementations of keyboard shortcuts, 
> in that the command only takes effect once the [command] key is 
> released. In existing interfaces pressing [ctrl]-x to cut takes effect 
> immediately the x key is depressed, and new commands can now be 
> entered without first releasing the [ctrl] key (although 'alt-tab' 
> behavious in existing systems breaks this rule, only taking effect 
> when [alt] is released)

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.

>
> The requirement to release the [command] key before executing a 
> command makes QCS slightly less efficient than existing keyboard 
> shortcut behaviour. In exchange it brings some advantages, including 
> the ability for commands to take parameters, commands with multiple 
> characters, and improved consistency. Multiple character commands 
> allows us to have more commands than individual keys, without 
> resorting to multiple modifier keys.

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.

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

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

> <snip>

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