Re: [Usability] Which shortcut keys? (was: sft+ctl+w v. ctl+q)

[Ernst De Ridder <hnridder informatik uni-rostock de>]

On Fri, Feb 14, 2003 at 01:01:48PM +0000, Alan Horkan wrote:

I changed the title because this message is more a discourse on shortcuts in
general than just on the close/quit issue.

> I think the current defaults based on the HIG are the best answer for the
> most people.

I don't agree. Shortcuts are, as the name implies, a shorter than 'standard'
way to invoke some functionality. As such they are not required to make good
use of the program. But when the HIG prescribes a certain shortcut, programs
will implement it, users will come to rely on it, and it will become
impossible to change even when that would be a good idea. The HIG should
only prescribe a shortcut when 1) absence of that shortcut would severely
shock the user's expectations and 2) this shortcut should function in
practically every program. Anything else will be an obstacle to both the
user's freedom to configure his own working environment and Gnome's ability
to adapt to new ideas. Example: F1 for help. Another example: Page Down for
next page (for Page Down the HIG might also prescribe whether this key
travels to the next logical page, or to the next window full).
Note that similar reasoning applies to programs: Don't predefine shortcuts,
but let your user choose them himself.

I can see two ways:

1)
Create stock items (as you have said, as well) for the standard key
combinations, [Interestingly enough, gtk has the ability to create stock
menu items, but neither are there currently any defined, nor can the gtkrc
commands edit them -- only stock icons.] and split the shortcut keys in the
HIG in two categories:

Required:

If you supply this function, you MUST use the stock shortcut key.  If you do
not supply this function, do NOT use the default shortcut key.  Default is
what is described in the HIG, stock is what the user has actually
configured.

Recommended:

If you supply this function, consider using the stock shortcut key. If you
do not supply this function, you may use the default key.

Advantage: the user can configure stock shortcuts centrally.
Disadvantage: how do you solve clashes between user-configured stock
shortcuts and program defined shortcuts? Ask the user on startup? Silently
remove program defined shortcuts that clash? Or maybe programs shouldn't
define any shortcuts besides the Required/Recommended ones?

2)
Define a minimal set of required shortcut keys. Do not use stock items for
them. The user will have to get used to them.

My preference goes to the first option, with programs not defining any
shortcut keys besides the stock ones.

The HIG v1.0 defines 20 (!) alphabetical shortcuts - only Ctrl- J, K, L, M,
T, and Y are unused. My opinion on these are:

New (^N). Delete it. Users spend far more time editing existing documents
than creating new ones. The possible exception is using ^N to open a new
browser window, but I think it's more regular to use Open + URL for that.

Open (^O). Required. Can we move this to a function key? They sit around
being useless most of the time. Only Alt/ctrl combos are used by the window
manager.

Save (^S). Required. Function key?

Print (^P). Delete it. Even an avid printer is not going to press this
dozens of times a day.

Send-To (^E). Delete it - already done in the latest draft of the HIG. 

Close (^W). Delete it. There's a window manager shortcut for it.

Quit (^Q). Delete it. It's too destructive for a shortcut.

Undo/Redo (^Z,shift-^Z). Required. Can we put these on two functions keys,
e.g. F8 and F9? These are easier accesible than the (double) chorded
shift-ctrl-Z, and they don't conflict with the standard
suspend-to-background key, which is important when a user wants to learn the
commandline. (I know F8 is already taken, but when F6=next pane, shift-F6=
previous pane, *why* put pane separator not on ^F6 but on F8?)

Cut/Copy/Paste (^X,^C,^V). Required. I have mixed feelings about those
particular keys though. On the positive side, almost everybody is used to
them, so there's nothing to explain, and they're easy to type with one hand.
On the negative side, it's easy to press the wrong key (esp. ^C instead of
^V can be unpleasant) and once drag-and-drop becomes generally used it's
more logical when Copy means create-a-copy-here (Duplicate) instead of
copy-to-clipboard. Maybe the CUA shift/ctrl Insert/Delete keys? I don't
know.

Duplicate (^U). Recommended, but put it on another key (shift-^C?). On most
commandlines ^U means delete-line, which is an almost diametrical opposite
to duplicate.  Thus users will become very upset when they try to learn the
commandline after having spend some time becoming good at the GUI.
Irritating users who try to learn is never a good idea.

Select all (^A). Recommended.

Invert selection (^I). Delete it. How many users will habitually select the
things they DON'T want and then invert? Seems like a tool for the pro's.

Delete (Del). Required.

Find/Search (^F). Recommended. 

Find Next (^G). Delete it. Find should provide a dialogue box with a 'Next'
button. If there must be a shortcut, use ^F: When there's no search box
open, one will be opened, the user enters a search string, and the first
match is searched for. Once a box is open, ^F search for the next match.
Search in most editors works like this.

Replace (^H). Delete it. The Find dialogue can provide an optional
replace-with field. Besides, binding Replace to Backspace is almost as
contemptuous of the user as Emacs's binding of Help to Backspace. (And no,
Backspace cannot always be distinguished from ^H). Alternatively, make it
Recommended on shifti-^F.

Rename (F2). Delete it. This operation is only useful in filers.

Zoom In/Out (^+/-). Recommended.

Refresh (^R). Required. Maybe use ^L, which is an established unix key?

Add bookmark (^D). Required. Users will normally not check whether the
bookmark was really added, so it's important that the key they expect to do
this actually does do it.

Edit bookmarks (^B). Delete it. When did you last edit your bookmarks?

Bold (^B). Delete it. It's only useful in layout software (and even here
it's IMHO better if the user can define shortcuts for arbitrary,
user-defined styles). In word processing software users shouldn't say bold
but 'paragraph header style' :-). In other software they don't need it.

Underline (^U). Delete it. See Bold (^B) and Duplicate (^U).

Italic (^B). Delete it. See Bold (^B).


Ernst