Re: Re: Design for Keyboard Shortcut Behaviour

On May 24, 2004, at 10:09 pm, Mikko Rantalainen wrote:

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

Yeah, the find dialog is a mode change. I am hoping to implement a LEAP  
like system for the Find command (in a separate module which uses the  
QCS). See the stupidly long Technical Specification for THE  
(http://humane.sourceforge.net/the/spec.html) for an idea of how LEAP  
would work.

It's not that the find dialog is especially confusing, I just think  
that a LEAP style system would be more efficient (as argued by Jef  
Raskin).

I'm hoping to avoid a vi/emacs style spartan prompt by displaying and  
describing the possible commands in the command list.

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

If we assume that entering text is the most often action, then we (us  
English speakers anyway) are lucky enough to have all those actions  
only take a single keypress. But the lack of dedicated command keys on  
keyboards means that non-typing actions are likely to require more than  
one keypress. (Maybe the F1 - F12 keys could be better utilised, as  
they are dedicated command keys).

Of course you can follow Internet Explorers way of doing things, and  
have backspace behave differently depending on weather the focus is on  
the page or a form element. But this introduces confusing modes (I've  
been caught by it myself numerous times).

You are right that it would be brilliant to be able to have all  
frequently used commands only require a single keypress, but this would  
introduce more modes, and I am currently experimenting with a system  
that is trying to reduce modes.

Requiring two hands to enter the ALT-Left command to go back is  
annoying. Better key selection could solve that one, but the general  
problem is still left. I am making the assumption that the user will  
either have both hands on the keyboard, or is using the mouse. With  
both hands on the keyboard, ALT-Left style shortcuts are not such a  
problem anymore. When using the mouse we just need to provide an  
efficient method of issuing commands. Currently there is no efficient  
method of going back a page using the mouse in IE. Mouse gestures or  
pie menus may be a neat solution to this.

> Have you tried to hold down the windows key and type "shutdown" in the  
> same time? That's far from a good UI!

I have. And your right the combination doesn't exactly flow. Could I  
escape this argument by saying that most commands will only be a single  
letter, and thus avoid this problem? Or that shutdown is an  
infrequently used command, and thus doesn't need to be speedily  
invoked? Or maybe that by making it difficult to type we avoid users  
accidentally shutting down the system?

If long commands do turn out to just be a pain in the ass then we can  
just avoid them.

> 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

Not sure I like the excessive nesting here (but it is just an example).  
It suffers from the problem of 'uninformed consent'.

Quote: "... and then there is what Alan Cooper calls "uninformed  
consent": 'At each step, the user is required to make a choice, the  
scope and consequences of which are not known.'"

I would prefer a more dense structure that allows the user to scan  
possible commands. I envisage the list of all system/WM commands  
displayed on the screen, displayed in organised groups. This way of  
displaying information has been termed 'monocline-grouping'

Quote: "Alan Cooper (again) talks about "monocline grouping" -- "a  
single
layer of information organised into groups" -- as an alternative to
categories. In these, "categories" change from being *choices* to merely
being *helpful attributes*."

(Quotes nabbed from some geezer on a mailing list:  
http://64.233.167.104/search?q=cache:C-6tPg9KLWcJ:www.listserv.acm.org/ 
archives/wa.cgi%3FA2%3Dind0011e%26L%3Dchi- 
web%26F%3D%26S%3D%26P%3D1140+monocline+grouping&hl=en)

> 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

I was hoping that commands that usually require confirmation (such as  
shutdown/restart etc) would be longer text commands, therefore avoiding  
the problem of accidental invocation and thus the need for  
confirmation.

Although some commands (Quit - Do you want to save changes?) will still  
require a confirmation. This could be handled by the system you  
propose.

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

I kind of want to avoid this, it breaks the rule of monotony, and thus  
habituation without seeming to bring any benefits.

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

You have almost suggested a way of browsing the Start menu by keyboard.  
Something like that for launching applications is probably a really  
nice idea. See Mark Pilgrim's method of providing fast application  
launching on Windows for an idea of things we can incorporate  
(http://diveintomark.org/archives/2002/10/07/my_good_easy).

I haven't really had any time to think about the best way to launch  
applications, but I agree that it is something worth including.

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

That was my intention all along, but in a flash of stupidity I forgot  
to mention it anywhere in my draft :)

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

Yup, much better idea than my way of doing things now that I think  
about it.

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

Right again, my go to window command can't really be made more  
efficient than alt-tab, so probably best to stick with something that  
works, even if it's not perfect.

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

Indeed there are major efficiency problems. I'd still like to have some  
way of going directly to a window, but I am having real difficulty  
working out a way to do this that works across title changes/orders  
that windows are opened/ect. If anyone else can figure it out we can go  
with their approach :)

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

I'd like to try having Copy/Paste behave as the QCS specifies. If it is  
a lot less efficient/really annoying, than it may be worth looking at  
the possibility of immediate execute of all commands (although this may  
reduce much of the power/consistency of the quasimode approach).

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

Yeah, I'm shying away from using Autocompletion. It causes problems  
with habituation when menu items can change.

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

That was my intention, but this needs to be looked at in more detail to  
see if it is feasible (I hope it is).

>>   * Replacing 'Alt-Tab' behaviour with go to window behaviour, which  
>> is better
>
> I think this is still under discussion.

And the discussion seems to have proved me wrong :)

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

Any elaboration on 'See "bash"'? Would its way of doing things work  
well in a quasimode situation?

Karl