Design for Keyboard Shortcut Behaviour: Quasimode Command System

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 have first set my sights on designing and implementing a standard for 
keyboard shortcut behaviour in Y. To this end I have posted a first 
draft of my design document (currently missing the gritty details of 
the design and behaviour) to the wiki:

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

Let me know what you think, I expect some controversy from my ideas but 
hopefully I'll be able to convince you of their merits (or you can show 
me where I have actually gone crazy).

Karl



Quasimode Command System (QCS)
==============================


Abstract
--------

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.


Introduction
------------

Throughout this page I will use a number of usability terms, which I 
introduce below for those who have not heard them before.

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

The behaviour of a quasimode based editor is described in great detail 
in the technical specification[2] for Jef Raskin's Humane Environment.

Quasimodes avoid the problem of users forgetting the current mode by 
leveraging the physiological principal that the muscular exertion of 
pressing a key is continuously reinforcing. Therefore users never 
forget that they have entered a qausimode.

Habituation is the development of 'muscle memory' and the ability to 
execute gestures without conscious thought. An example of this is 
driving a car or riding a bike, initially it requires a lot of effort 
to balance a bike while pedaling and steering, after enough practice we 
can ride a bike without thinking about it.

This principal can be used for increased efficiency in the user 
interface. Unconcious use of commands is faster and allows us to focus 
our attention on the task we wish to accomplish rather than how we 
issue the command to accomplish that task.

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


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.

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.

The command list greys out commands that could not match the text the 
user is typing.

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.

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

If an invalid command is entered, the prompt exhibits the same 
translucent behaviour, as well as the text 'Invalid Command'.


Mock Up
-------

              +----------------------------------------------- Icon 
displaying
              |                                                character 
on
+------------|----------------------------------------+       [command] 
key
|            v                                        |
|        +-----------------------------------+        |   +-- Prompt
|        | [CMD] : n yCalc                   |  <---------+
|        |         /start new application/ <----------------- 
Description of
|        +-----------------------------------+        |       currently 
typed
|                                                     |       command
|   +---------------------------------------------+   |
|   |     r    : Start Application >              | <-------- Command 
List
|   |     w    : Close Window                     |   |       cmd : 
description
|   |     #    : Go to window number #            |   |
|   |                                             |   |
|   | shutdown : Shut down computer               |   |
|   |  restart : Restart computer                 |   |
|   |  logout  : Logout Karl O'Keeffe             |   |
|   +---------------------------------------------+   |
|                                                     |
|                                                     |
|                                                     |
+-----------------------------------------------------+


A mock up of the prompt and command list of the Quasimode Command 
System.


Justification of QCS
--------------------

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

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.

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.

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.

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

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.


Detail of QCS Behaviour/Implementation
--------------------------------------

...Coming Soon...

  Commands in Initial Version
  ---------------------------

   * r : Start application >
    * X : X is name of application to start
   * w : Close window
   * # : Go to window number #

   * p : Focus pane >
    * # : Number of pane to go to
   * | : Vertical panes
   * - : Horizontal panes
   * + : Quad panes
   * . : Single pane

   * shutdown : Shut down computer
   * restart : restart computer


Roadmap
-------

  0.1
  ---
  * QCS implemented with *no* visual feedback
  * Simple commands implemented (close window)

  0.2
  ---
  * Prompt displaying text user enters
  * Command list displaying commands and descriptions
  * More commands implemented

  0.3
  ---
  * Prompt displaying valid/invalid feedback
  * Prompt displaying descriptions for valid commands
  * Command list greying out items that can no longer complete users text

  0.4
  ---
  * Support for commands with simple parameters
  * Parameter list displayed for commands with parameters

  0.5
  ---
  * Support for commands with complex parameters (new task)

  0.6
  ---
  * Persistant translucent prompt (for both valid + invalid commands)

  0.7
  ---
  * Good API for using QCS with window manager/widgets/applications

  0.8
  ---
  * Eye-candy prompt and command list (translucency/shadows/anitmations 
etc)

  1.0
  ---
  * Everything working
  * No bugs
  * Documentation


Dependancies
------------

The QCS requires certain other elements of the Y project to be 
implemented before it can be completed:

  * Hidable windows
  * Always on top windows
  * No titlebar windows
  * Not in taskbar windows
  * Not focusable windows
  * Access to input system for clearing persistent prompt

  * Drop shadows on text
  * Font with Windows/Apple key glyphs
  * Font with Tab/Arrow key glyphs
  * Control over resize behaviour of labels
  * Strikethough text/bold text
  * Widget background transparency


Areas of Design Requiring Further Study
---------------------------------------

There are still many areas of the design of the QCS that have not been 
worked out yet. They include:

  * Autocompletion
  * Displaying modifier keys next to prompt
  * Accessibility (especially in use of colour to show validity)
  * Display effect of command before command is executed
  * Keyboards without Windows or Apple keys
  * Best way to dismiss persistent prompt (any key/timer/special key 
combo)
  * Replacing 'Alt-Tab' behaviour with go to window behaviour, which is 
better
  * Architecture for parameters and application callbacks
  * How to deal with more commands than will fit on the screen
  * How to deal with lots of text entered into prompt
  * Icons for commands


Extensions
----------

  * Implement QCS for widgets
  * Textbox widget behaves like The Humane Interface
  * QCS takes place of application shortcuts
  * QCS takes place of application menu
  * Integration with the rest of my interface designs


References
----------

	 	1 Jef Raskin: http://humane.sourceforge.net/home/
	 	2 THE Technical Specification: 
http://humane.sourceforge.net/the/spec.html
	 	3 Hick's Law: http://www.usabilityfirst.com/glossary/term_266.txl