Re: Design for Keyboard Shortcut Behaviour

[was: Design for Keyboard Shortcut Behaviour: Quasimode Command System]

Karl O'Keeffe <[email protected]> wrote:
> http://y-win-wiki.jciteassist.org/y-win-wiki/QuasimodeCommandSystem
> 
> Knowing that we are all lazy programmers, I've also appended the 
> document to this email :)

Such information should have been provided before the link, I didn't 
read this far before following it.

> This page describes a command input system (keyboard shortcut system) 
> for Y which uses the principle of habituation and monotony to promote 
> the transition from novice to expert user, quasimodes to reduce mode 
> errors, and a visual list of commands to reduce memory load for new 
> users.

I'm not sure if going totally one way or the another is the right 
thing to do. For example, not a very many people are totally lost 
when a dialog pops up when they press CTRL+F (for Find). That's a 
mode change, IMO, because the target of the action is normally still 
the previous window. On the other hand, I don't agree with vi's way 
to do everything with a spartan prompt. Some ideas below...

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

The UI should be designed so that the most often actions only 
require *one* keypress and the more seldom an action is intended to 
be used, the more keypresses it should require. A backspace (for 
commanding to undo the last keypress) or an enter (for confirming 
the command) are examples for commands that only require one 
keypress. CTRL+C for copy requires *two* keypresses but most people 
think that's good enough. Left ALT+Left Cursor key for browser's 
back isn't good enough, because you need two hands to enter the command.

A command "to rot13 three first letters in selected text" isn't 
often enough used action to require a one or two key shortcut.


> |   | shutdown : Shut down computer               |   |

Have you tried to hold down the windows key and type "shutdown" in 
the same time? That's far from a good UI! I'll call the windows key 
COMMAND key from this on so it can refer to any key one wishes to 
use for that. So, how about something like this:

Press COMMAND -> A tooltip-like window appears that has shortcuts 
listed:

W Commands that operate this window
Q Quit this application
A Commands that operate with applications
S System commands
etc

Pressing W while COMMAND is held would popup a context menu like 
menu where holding the COMMAND down wouldn't be required anymore. 
That menu would have items like:

W Close this window
N Minimize this window
M Move this window
D Move this window to desktop... (would popup an another menu)
etc
ESC Cancel

Some actions would require confirmations but those could be handled 
in similar way. For example, COMMAND-Q wouldn't immediately quit the 
application. Instead, it would popup a menu like

Q Quit application
ESC Cancel

Note that the default action in this menu is Q should any of the key 
combinations would quit an application:

COMMAND-Q COMMAND-Q
COMMAND-Q Q (holding COMMAND would be optional)
COMMAND-Q ENTER ("Quit" menu and confirm first item)

Similarly

COMMAND-A R would popup a "Run Application..." dialog (which would 
be an xterm for me :)
COMMAND-A S B M could start Mozilla (as in Application / Start / 
Browser / Mozilla)

By this, it should be clear that user should be allowed to customize 
this menu. It could be that you start Mozilla once a week (and keep 
it running for the rest of the week) while another user starts and 
stops Mozilla every 15 minutes. For the latter user it's much more 
important to have only a few keypresses for the shortcut.

Perhaps have a 500ms delayt before displaying the menu after the 
keypress have been done. This way experienced users don't have to 
suffer from flickering while they are inputting commands.

Selected menu item could fade out in similar way menu items fade out 
in windows 2000 (if you haven't seen it, the system has on-top 
window without window decorations and the alpha channel is animated 
from opaque to fully transparent during about 1000ms. All events go 
directly through this window). This is enough feedback to see if you 
mistakenly selected a wrong action or to confirm that system is 
doing something. AND it doesn't need an user action to go away.

> effect in every situation. For example, rather than use the 'alt-tab' 
> method of switching windows where the effect of the command is based 
> upon the currently selected window and the order of previously selected 
> windows, QCS uses a go to window switching method where the user 
> specifies exactly which window to bring to the front. The same command 
> brings the same window to the top no matter what order the windows are 
> currently in.

I don't think that this is the only way Y (or any other UI) should 
support. Most of the time I'm using two or three windows and during 
those times I find it pretty efficient to use alt-tab: first I dig 
up the three applications I want to use, the I press alt-tab when I 
want to change to previous application and alt-tab-tab when I want 
to change to the application that I recently used but which wasn't 
the last one. For more that four windows alt-tabbing isn't that smart.

I'd keep alt-tab (or change it to command-tab) pretty much as it is 
and add another menu COMMAND-C (for Change To...) for switching 
directly to another window. The alt-tab action should display a menu 
instead of a line of icons but mostly it's OK for me.

Always using direct access would be fine if there was a nice way to 
differentiate between multiple windows effective. If I need to 
change between Mozilla window #3 and NEdit window #12 every 15 
seconds, how do you think it should be done with direct access? 
COMMAND-C M 3 (for mozilla window #3) and COMMAND-C N M 3 (for 
Nedit, more windows, (#1)3). Major efficiency problem when compared 
to alt-tabbing.

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

I think that the CTRL key should work like it's working right now. 
For copy/paste and such things doing the action immediately is the 
Right Thing to do, IMO. The COMMAND key could work differently and I 
don't see any problem with that.


>   * Autocompletion

This is one of the things that won't work if you need to hold down 
some key while entering the rest. With a good autocompletion system 
I could efficiently enter commands with COMMAND-X to start up 
autocomplete command which would work somewhat like bash: imagine 
that I could enter S TAB (for "system") followed by SPACE (for next 
parameter) and enter S TAB (for "shutdown") and press ENTER. Of I 
could press TAB without anything to see all the choices in *that 
context* (so after having "system" in front, the rest of the choices 
would be similar to "system" menu in GUI).

>   * Display effect of command before command is executed

At least for window manager commands this would be a big bonus: for 
example, while the selection is over "minimize all", all windows 
would be displayed semi-transparent... :D


>   * Replacing 'Alt-Tab' behaviour with go to window behaviour, which is 
> better

I think this is still under discussion.

>   * How to deal with more commands than will fit on the screen

See "bash". I think that something has been wrong when GUI menu has 
more items that it can display without scrolling.

-- 
Mikko