Re: Design for Keyboard Shortcut Behaviour: Quasimode Command System

On Sat, May 22, 2004 at 08:00:39PM +1000, Karl O'Keeffe wrote:
> Hi All,
> 
> I've been lurking on the list for a while, and I think I'm finally up 
> to date on the goings on in Y. I am interested in working on the user 
> interface for Y. I will hopefully be able to work on it in my spare 
> time for approximately the next 6 months (June to Nov).

I've been lurking here for a while too, and my interests are interaction 
and interface design. I've read Raskin's The Humane Interface and have 
been thinking about concepts like you propose for quite a while now. 


Firts of all there's the question, if Y should have its own Desktop 
Environment. Running Gnome or KDE might restrict freedom for things 
like you propose.

Even if the long term goal is a new and totaly consistent interface 
environment, there's still the need of a migration path. At least for 
Y to have a chance of mass adoption.


> http://y-win-wiki.jciteassist.org/y-win-wiki/QuasimodeCommandSystem


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

Quasimodes might sound like a nice idea. But they're a problem for 
people with disabilities. It's generaly not very comfortable to have 
to hold down a key for a while. It might be painful for people with RSI.

And the problem of forgetting about an active mode is rather one of 
long time modes, where holding down a key all the time is not an option.

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

So should windows come without close buttons, if there's a quasimode  
command?


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

The Windows key is usualy free in defaults of various WMs and DEs,  
I think. But I'm not sure about the Apple key. Isn't it normlay used 
like Ctrl?

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

Having a large command window springing up might be somewhat 
disorientating. Better make it compact, for not having to drastic changes 
on the screen. Long list are not helpful, but scary.
 

> As the user types the prompt changes colour* to indicate the validity 
> of the command (e.g. green for valid, red for invalid, yellow for 
> partially entered command). If the user enters the text for a valid 
> command, the description for that command is displayed below the users 
> text.

Just the prompt should change colour? Too small, but text should not 
chnage to bright colours. Also taking olour vision deficiencies into 
account, other means of indication should be used (icons?).
 

> After the executing of a command, the prompt remains on the screen in a 
> non-focusable translucent state to allow the user to see the last 
> command they entered. The prompt disapears on the next keypress or 
> mouse click*.

I'm pretty sure I would hate that behaviour with simple and often used 
commands like window operations. In most cases the action taking place  
should be all feedback that is needed.


> The QCS attempts to provide a system which is efficient for expert 
> users, while still being easily accessibly to novice users. Most 
> importantly it tries to provide a smooth transition from novice to 
> expert, a feature missing in many of todays interfaces.

It's not realy discoverable. That's a problem for novice users.
 
> It does this by using monotony and habituation. Providing a novice 
> method of doing something (e.g. toolbar), and a seperate expert method 
> (e.g. keyboard shortcut) makes it difficult to transition to being an 
> expert. QCS avoids this by only providing the most efficient way to 
> accomplish a task (usually keyboard shortcut), and attempts to make 
> this as easy to find and understand as a toolbar button or menu item.

Now replacing all menus would be interesting. Such Unification is good 
for learnability and removes clutter from the screen. But having one 
'command space' for everything makes it hard to explore. A fragmented 
'command space' helps by being somewhat like a pre-selection.


> Commands are made easy to understand and find by displaying the list of 
> possible commands. This allows a user to decide which one is most 
> appropriate for them. Listing all the commands allows the user to 
> quickly scan all actions to discover if the one they want is available.

Hardly, if you list all commands available on system, wm and app level 
at once.

 
> Commands in the QCS are designed to be as modeless as possible. This 
> means that, where feasible, the same command should have the same 
> 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'm sorry, but that's a bad example. Having generalized commands would 
be a good thing. But do you ever select or recognize a window by name? 
Typing in a command and parameter to switch windows takes too much time 
and requires quite some mental work. Window cycling works quite well, 
especialy if the windows are taken to the front 'live' instead of 
going through a list of icons (Kahakai does it right!). But there 
should be Exposé like functionality anyway.


> The effect of these modeless commands is increased habitutation. The 
> user learns to issue the command unconciously without first pausing to 
> determine the state the system is in.

If you ask Tog, keyboard shortcuts (and full commands can only be worse) 
always require high level cognitive work, whereas point and click actions 
do not. But that's a topic I need to read up about.
 

---
Thorsten Wilms