Re: Design for Keyboard Shortcut Behaviour: Quasimode Command System

First up, thanks to all for the brilliant feedback. Loads of 
interesting points have been raised. I've decided to reply to each 
email individually, hoping to keep the threading alive (not sure if 
this is perfect etiquette, I'm sure some one can email me if there is a 
nicer way). If I get a chance I'll update the wiki to cover everyone's 
points.

*** That was the initial idea, unfortunately time constraints (the need 
to go out for beer) means I've only been able to reply to this single 
email. But I believe it covers a bunch of major points anyway ***

I have plans for most of a desktop environment, if I have time tomorrow 
I'll do a quick write up of my "vision" :P Otherwise I'm afraid you'll 
have to wait another week before you get to see all the crazy ideas I'm 
brewing up.

Anyway, on with the discussion:


On May 22, 2004, at 10:10 pm, Thorsten Wilms wrote:

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

The aim is to create a Desktop Environment that is better than Windows, 
rather than just an imitation. I know this is a very difficult task, 
but I really want to try something different rather than make a poor 
windows copy like KDE/Gnome (thats just my opinion of them, by the 
way).

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

This is a good point. I am working from the perspective that X 
applications should be portable to Y with relative ease. Thus we must 
use applications, windows, menus, dialogs, widgets, etc. Other than 
that we are free to go wild.

Although as you point out we have to make the initial transition easy 
enough that users wither bother to switch.

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

I assume that a standard sticky keys implementation would take care of 
this problem for disabled users.

A valid point about people with RSI. It might be possible to find a 
quasimode key which does not aggravate RSI, or reduce the length of 
commands and thus the amount of time spent holding the key. Hopefully a 
little testing will show us the way.

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

I'm not sure that forgetting about modes is only a problem for long 
term modes, but I don't have any data to back that up, so can't really 
argue :)

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

Very tempting :) My current vague unsubstantiated idea was to treat the 
mouse and keyboard as separate, but equally valid modes of entering 
commands. So we have one efficient keyboard close command, and one 
efficient mouse close command (possibly using the venerable old pie 
menu).

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

Usually, but since I hope to have an integrated DE this shouldn't be a 
problem. I was hoping to be able to implement the QCS as a module. If a 
WM wished to use it, it would be allowed use whatever meta key it 
wished.

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

It may be disorientating, but I would hope that it would not really be 
a problem. One very important point which I somehow left out of the 
draft is that the prompt and command list would only appear after a 
delay. So expert users would not see any display, while novices are 
shown the list of commands. As novices become experts, and thus faster 
the prompt and list automatically begin to not appear, no need to set a 
novice/expert preference.

If testing shows that the command list is very disorientating, an 
alternative approach would be to only show the list after the user 
presses a certain key (e.g. the ALT key).

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

Indeed colour change on its own might be a bad idea, especially for 
colour blind users :) I just haven't had the time to think of a better 
approach yet. Someone else want to do the work for me? :P

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

I am moving away from the show command until a key pressed behaviour, 
that would probably just lead to users immediately hitting the COMMAND 
key again to get rid of the feedback. Maybe move to the Win 2000 style 
behaviour as mentioned by Mikko Rantalainen.

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

Not sure what you mean by this. If you mean that novice users won't 
know to press and hold the COMMAND key, I was making the assumption 
that new users of Y would be told (when it first loads?) that the 
COMMAND key is the standard way to issue commands to the system, then 
they can go and discover the commands for themselves using the command 
list. (that's how it would work in an ideal world anyway).

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

Indeed, I was hoping to put some more thought into replacing menus with 
QCS, but to ensure that apps can be ported to Y, this new menu 
interface would have to support everything your standard Windows and 
Mac menus do. Haven't had enough time to look into this yet.

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

I didn't mention my idea that the COMMAND key would be used for system 
and WM commands, and the Ctrl key would be used for application 
specific commands. This way I was hoping to provide and easy 
distinction for the user as to which commands are global (and using the 
COMMAND key) and which will change depending on the application (any 
using the Ctrl key).

I haven't decided how this would work for Copy/Paste for example, which 
affect applications, but are/should be global shortcuts. Anyone got any 
fancy ideas?

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

You are 100% right, my go to window example was horrible (as I worked 
out when I thought it through in more depth the next day). The problem 
is I was trying to remove the 'relative' effect of alt-tab, i.e. the 
fact that the window you go to depends on the z-order of windows, which 
changes rapidly. But I was unable to come up with a way of selecting a 
window absolutely which wasn't ridiculously inefficient. If anyone 
comes up with an efficient way of always selecting a required window 
when titles may change, and order that windows are created may change, 
please do let me know :) Anyway, I apologise for the stupid example.

Everyone is right that we should just stick to the Alt-Tab behaviour. 
It works better than anything else right now.

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

Hopefully habituation will turn what is initially increased cognitive 
work into almost no cognitive work. For example do you find using 
Ctrl-C/Ctrl-V requires any conscious thought? For me using a menu 
item/icon to copy and paste requires a lot more cognitive effort 
(moving mouse, reading menu items, etc) than the shortcuts.

OK, I've covered most of the points you mentioned. What do you reckon 
now? :P

Karl