modifier duplicating/swapping (was Re: "A Word of Caution" to all
lex at cc.gatech.edu
lex at cc.gatech.edu
Fri Dec 3 12:57:26 UTC 2004
"Doug Way" <dway at mailcan.com> wrote:
> Of course, now the question is, should the swapControlAndAltKeys or the
> duplicateControlAndAltKeys be the one turned on for Windows? (Remember,
> these both only affect the magic 8 text-editing keys: A, S, F, G, Z, X,
> C, V.) Since it's now just for Windows, I would vote for
> swapControlAndAltKeys. Otherwise, you completely lose the other 8 key
> bindings, such as the old ctrl-V which prints your initials/timestamp.
> Not that I ever use these, but some old-timers might get grumpy if they
> were taken away. ;)
Here's my analysis from the last time this went around. I tried to
incorporate every issue that people have mentioned, including tutorial
writing and power users, in order to find a good compromise. Comments
are welcome! I think my proposal is a real improvement over what we
have, but I'll leave it for the end. If you find this interesting, why
not try tracing this analysis but putting in your own numbers?
At any rate, no one really disagreed with this analysis. So maybe we
should implement the solution if there are still no objections? It's
just a matter of putting one thing or another into the update stream.
Note that my "dupAll" changeset duplicates alt and control for *all*
keys, not just the basic 8 listed here. (or at least according to the
preamble it does. I don't remember any longer!) If the current image
does something different, then it may be worth pulling the dupAll
changeset back out again after all.
==== http://lists.squeakfoundation.org/pipermail/squeak-dev/2003-October/068898.html ====
Okay, to try and prevent a huge flame war and never seeing anything
happen, let me try to analyze this objectively. I will list out the
issues and the proposals, score each proposal on each issue, and then
compute an overall score. The numbers are of course debatable, but this
analysis should at least let us see the overall breakdown.
The issues are as follows:
1.Users, especially new users, expect cut-and-paste to work the same in
Squeak as with the rest of their OS.
2. Tutorials need to be as simple as possible to understand.
3. Experienced users want to have more power available.
What other issues are there to consider?
Anyway, the proposals so far for dealing with this are:
autoSwap: Swap the "control" and "alt/command" keys automatically on
prefSwap: Swap the "control" and "alt/command" keys according to a
dupMain: Duplicate the cut and paste keys for control and alt, and
leave the other bindings alone.
prefDupMain: same as above, but it's a manual preference.
dupAll: duplicate all the control and alt keys. Make the original
control keys available under something like control-shift or
Have I missed any?
Okay, let's score the proposals on each issue:
On Issue #1, I would say:
10 dupMain, dupAll
2 prefSwap, prefDupMain
The duplicating options are as good as it gets on Issue #1. autoSwap is
just as good when it works, but there is a non-zero possibility that
auto-swapping will get it wrong for a particular user. The
preference-based swaps seem worst on this particular issue, because it
doesn't really help brand new Squeak users.
On Issue #2, here's my ordering:
These are the most tentative of my scorings. I may well simply be
uncreative here on how to document something, or on what problems may
arise. But here goes an initial attempt.
dupAll is cake to document -- just talk about "command-X" all the time
and have a few sentences at the beginning say that this means any of
control, alt, meta, or command. You could even leave out the sentences,
and most users (though not all) will experiment and figure out what you
dupMain requires different keys to be documented in different ways.
However, the advantage is that the author could write as if one mapping
or the other is being used, and simply ignore the duplication on the
other keys. prefDupMain is slightly better, because a tutorial writer
can assume the preference is off and thus that the keys are in
autoSwap is very problematic for documentation, especially for
tutorials: there are two possible keys for users to press, and one of
them is very wrong. If a user experiments to try and figure out what
you mean, they can put their Squeak session into a very confusing state
-- e.g., they open up a comparison window instead of doing a cut
operation. This is especially bad when it's a very basic hotkey like
cut or paste, because the user is usually concentrating on a
higher-level goal when it happens. It has been proposed that we make up
two new pseudo-keys such as "mod" and "command", but now new users have
consult a lookup table every time they want to use a hotkey.
prefSwap has the same issues as autoSwap, except that tutorial writers
in particular can assume the keys are in the original location.
However, there are still problems for non-tutorial documentation, so I
only give it a 7.
On Issue #3:
The differences are not that large here, assuming each proposal is well
implemented. All features would still be available to experts under all
proposals, but under some they would require more difficult key
prefSwap is at the top because it allows all the hotkeys *and* it is
configurable. autoSwap also has all the power, but it's at fixed
keybindings for a particular platform. prefDupMain removes some
convenient hotkeys when it is turned on, but it can easily be turned off
by an expert. dupMain cannot be turned off. Finally, dupAll removes a
lot of hotkeys from the simple control-key to the more complex
Would anyone like to modify these scorings? Please be honest, and try
it out before you read the overall scores below.
Okay, here's the overall scores:
autoSwap: 8+4+9 = 21
prefSwap: 2+7+10 = 19
dupMain: 10+8+7 = 25
prefDupMain: 2+9+8 = 19
dupAll: 10+10+6 = 26
There you have it. dupAll and dupMain are the winners, and prefSwap,
autoSwap, and prefDupMain are approximately tied for second place.
We should do one of dupAll or dupMain. dupAll won by a point, but even
though I like dupAll I suppose one point is too close for this kind of
Preferences and swapping are both losers: they help with one issue and
suffer on another.
And you know this is all correct because it has numbers and it is
computed on a computer. If there are any holdouts who disagree, I
suppose I will post a graph to really nail it down.
More information about the Squeak-dev