From: strobl@gmd.de (Wolfgang Strobl)
Subject: Re: IBM Funny
Organization: GMD, Sankt Augustin, Germany
Date: Tue, 13 Oct 1992 18:00:05 GMT

In <6191.2ad9bc3f@hayes.com> bcoleman@hayes.com (Bill Coleman) writes:

>In article <strobl.718757688@gmd.de>, strobl@gmd.de (Wolfgang Strobl) writes:
>> In <6170.2ad5a35b@hayes.com> bcoleman@hayes.com (Bill Coleman) writes:
>> 
>>>In article <strobl.718461278@gmd.de>, strobl@gmd.de (Wolfgang Strobl) writes:
>>>[I wrote:]
>>>While it may be obvious to a PROGRAMMER when the keyboard focus changes,
>>>it certainly isn't ovious to the USER. When I bring up a dialog box within
>>>the same application, it may TECHNICALLY be a different window, but to me,
>>>the user, it is the same application.
>> 
>> This depends a lot on the characteristics of the system. If there is
>> a big, visible difference between the look and feel of an application
>> window and a dialog box, the user probably won't recognize the 
>> dialog box as just another window. But if the dialog box looks
>> and works like a window, it's different. In addition, it is
>> always visible which window the focus has. 

>A dialog box is part of the application. If it has completely different
>looks, then this breeds more inconsistancy. The user will think the dialog
>is a separate application, or something entirely different. He will fail
>to recognize the association between an application action and the resulting
>dialog. He will subsequently become more confused when he attempts to switch
>back to his application (which he can't do, since the dialog is the application)

Why shouldn't the user think that the dialog box is a separate
application? Perhaps it is - applications *can* have more than one
main window. Dialog boxes don't have to be modal, in addition, so
perhaps the user *can* switch back to his application. Dividing
the world in application windows and dialog boxes with nothing
inbetween is quite artificial, IMHO, just like the separation
between desktop accessories and applications.

In another thread you said that proficient mouse usage has to
be learned. Well, the same applies to how to talk to windows
in a multi-application environment. 

>> For me, its much more obvious that my keyboard actions apply
>> to the active window and it's menu (if it has one) and its
>> buttons et al, that that some remote menu bar works on one
>> of many visible windows.

>Ah then looks are deceiving. Indeed, you can Paste into the dialog box! But
>only if you use the CORRECT shortcuts. If you use the ALT-shortcuts, you
>can't!

Of course you can't, because the Alt shortcuts you are obviously 
talking about BELONG TO ANOTHER WINDOW, not to the dialog box
in question. This dialog box can have - and most probably has - 
its very own ALt-shortcuts. These don't have to be learned, be-
cause the are always *visible*.

You expect Windows to show exactly the same behaviour that 
you are accustomed to from you Macintosh experience and
training, and get confused if it doesn't. So do I when I
sit in front of a Macintosh. But I don't blame the Macintosh
for that. 

>That's even worse for Windows then. The user can't even recognise the
>facilities the application can perform, since he is blocked by his previous
>learning. Shame.

A Windows user usually learns quite fast that he can operate the
active window, whether a dialog box or not, using the keyboard, if
he likes to do so. 

You try to build a straw-man.

>>>> This is just what I would expect in a system with more than a 
>>>> single window. 
>> 
>>>But not what you would expect in a system with a single APPLICATION. That's
>>>my beef.
>> 
>> Indeed. It's not what I would expect in a system with a SINGLE application.
>> 
>> The Macintoshs user interface design (as far as I know about, which isn't
>> that much) is better than the Windows one, as long as there is only
>> one, single application in use. For multiple applications, its worse.

>I disagree. 

>But, you are changing the subject. The objection I raised wasn't about
>multiple applications, but inconsistancy within a single application.

The objection you raised was - and still is - a misunderstanding
on your side. Windows doesn't work how you would expect it to work:
you expect to have a global menu bar which applies to everything on
the screen. On the Macintosh, this is more or less true. On Windows,
it isn't. This is because on the Macintosh, switching between
applications is a major act, because it makes the menu bar of the
activated application accessible and the menue bar of all other
applications completely inaccessible (and invisible!). In addition,
there is a lot of work going on behind the scenes - clibboard
rendering, for example - which makes it an even bigger hurdle.
The menu exchange is - intentionally - perceived as a slight change
of the global menu bar.  Because of that, users start to understand 
the menu bar as some kind of application-independent worktool,
which is always visible and offers actions (commands, operations)
which are always accessible.

Windows has a different model: here switching between applications
is nothing more than giving another window the keyboard focus.

There is no global menu bar or anything similar concept. Usually,
applications have one window with a menu bar, and these menu often
have the usual set of basic entries "file", "edit" ... "help".

Some applications have more than one window, some don't have 
a menu bar at all. But as a rule, if a window has a menu or contains
controls, these controls and the menu operate on the window
they belong to.

This model is indeed a bit more complicated than the simple
single-application model of the Macintosh, and may look
inconsistent to somebody accustomed to the simpler Macintosh
UI model. 

But my point is: that complication (i.e. to give up the model
of the global application menu bar) is necessary to really
support the concurrent use of multiple applications. 

Some assumptions learned when using single-applications
systems break when you try to move them over to a multi-application
system. You problem with Alt-EP in dialog boxes is one of
these assumptions, IMHO, so,  from my point of view, I haven't
changed the subject.


>You windows types keep dancing around to avoid the subject at hand --
>inconsistancy!

With that little word, you can evade the need to argue about
almost anything. Cute.

>>>> But as long as the window which has the menu bar we are talking
>>>> about *has* the keyboard focus, you can use all available menu navigation
>>>> methods given by the standard menu keyboard interface. 
>> 
>>>You can. It is quite modal, and requires a bit more cognitive effort than
>>>using a mouse, but you can.
>> 
>> Of course it's modal. If you just have launched the 'open document' dialog,
>> you are in the mode of opening a document. It doesn't make much sense to
>> reenter that dialog a second time, from within the first dialog.

>No, I was saying that the menu navigation was modal. Press ALT and release,
>and you are stuck in menu mode. It may or may not be obvious to you. That's
>pretty awful behavior for an interface. Modes are to be avoided, hidden
>modes shunned. 

I get the impression that now *you* try to change the subject. 
Your original statement was that you can't use shortcuts to 
access the menu bar of an application while in a dialog box.

>As for the open document -- it is modal, but it is a visible mode. It is
>also necessary coming from an application -- a necessary evil of flexibility.

You seem to imply that there is an invisible mode if you have a
similar situation in Windows. WHere?  I don't think there is one.

>> I can imagine a fully recursive user interface, where you could
>> use a secondary file dialog to paste the content of a file into the name
>> field of the first dialog, just by using the very same menu bar,
>> but I can't imagine myself explaining *that* to a user. 

>Wolfgang, I didn't want to do anything complicated. I just wanted to paste
>a name into a dialog. Just that. I couldn't using the ALT-EP shortcut. Don't
>make it out like this is something that is too complicated to accomidate.

>Windows can do it. It just does it inconsistantly.

No. It does it different from your expectations. This is inconsistency,
but it isn't necessarily on Windows side. :-)

>>>Funny. As a long-time Mac user, I can recite all the standard shortcuts 
>>>from memory. And my fingers know them quite well. 
>> 
>> That's because "standard shortcuts", as implemented by the Mac
>> and the keyboard interface to menu bars and dialog boxes on
>> Windows a two different things. Windows has "standard" shortcuts
>> (called "accelerators"), in addition.   I.e. Alt d f and Ctrl+v
>> are two different things. 

>Yup, and that is EXACTLY the problem. There's two different types of shortcuts.

Well, now I finally seem to start to understand. 

Every time you find more than one way to do something on or to a 
system, you call that an inconsistency. 

>One type works in all cases. The other type only works some of the time. If
>you learn the wrong type, you end up thinking the program can't do things at
>certain times that you CAN do with the other shortcuts.

The error in this argumentation is that you have the wrong mental
model of how the keyboard interface works on WIndows, and insist
that every difference between your expectation and the actual behaviour
is an inconsistency. It isn't. Your mental model is flawed; it doesn't
apply to Windows. 

This proves that you have learned how to use a Macintosh, and that
you don't have learned how to use WIndows. There is nothing wrong
with that, and I even concede that Windows is more difficult to
learn - there is more to learn. But just because "shortcuts",
as defined by the Macintosh don't have an exact counterpart 
on Windows dosn't make it inconsistent.

>> I too rememember the standard shortcuts
>> like Ins, Del, PgUp and so on, mostly because they are separate
>> keys on the standard PC keyboard (the one just recently adapted
>> on the Macintosh, if I'm not mistaken). 

>You are mistaken. The extended keyboard has offered these keys since 1987.
>That's not recently adopted.

Well, I'm using keyboards a bit longer than since 87, and remember
the toy keyboard of the original Macintosh quite vividly. I was 
very surprised to find that Apple adopted IBMs MF-II keyboard
layout. Not a bad move, IMHO.

>>>Which is exactly the point. If you have to think about the shortcuts, then
>>>you might as well use the mouse -- its faster. If you can't remember them
>>>instantly, game over.
>> 
>> Not so. My fingers reside on the keyboard. Even if I have to do a short
>> look at the menu bar (I'm looking at window, anyway), it is much simpler to
>> just type one letter than to remove the right hand from the keyboard, to
>> locate the mouse, to look back to the screen, to find the cursor, to move
>> it to the menu entry (which I've lost while looking for the mouse) and to
>> click at that entry.

>You are WRONG. You are forgetting the time it takes to think about all these
>things. You are concentrating only on the time it takes to move your hand
>or fingers and aren't taking into consideration the time it takes to move
>your brain. 

I am forgetting the time it takes to think about all these things, 
because I don't do that - it's completely automatic, quite similar to
how I don't think about how to move the mouse to point to a certain
menu item - if my hand already sits on the mouse.

>There's a greater cognitive load trying to recall or synthesize the keyboard
>shortcuts. Because of this, it APPEARS that the keyboard shortcut is
>faster, because your brain is so busy trying to compute the right key
>to press. With the mouse, you don't have to think about it, you just have
>to move the mouse. This is such an easy operation that your brain gets
>bored, and you PERCEIVE that it takes forever.

I don't believe that because I use mouse *and* keyboard regularily,
and am quite proficient with the mouse. But there are as many situations
where the *mouse* produces more - unnecessary - cognitive load than
the keyboard, if not more.

>The stopwatch tells a different story. Read "Tog on the Interface."

I trust my stomach more than a stopwatch. I can think about so
many way to manipulate experiments, even unintentionally, which
try to compare mousing with keyboarding. My own desire isn't
to get some stupid repetetive task done as fast as possible, but
to get my work - which varies quite heavily - done. I use
graphical programming environments whenever available, and truely
prefer modern, visual source level debugers and really appreciate
the advance they represent over the older, command oriented ones.
   ... But. I try to avoid debuggers at all, visual or not, and
prefer my programs to work from the very beginning. More than
once I made the experience that after long tinkering with a
visual debugger a short look into a linear trace output solved
the problem. I use all sorts of visual editors with syntax directed
editing, class trees and the like. But if I have to 
write something really difficult, I still use my old-fashioned
character-based text- and program-editor, which is very modal,
but not very powerfull. But it has one advantage: it doesn't
get in the way. There is nothing visible but my text or my
program, and there is not much to think about the interface,
there hardly is one. 

>(BTW, why do you look away from the screen? Why do you have to find the 
> mouse cursor? I grab my mouse without looking at it. I find the mouse
> cursor instantly (sometimes I make a small circular motion to find it).
> I move my hand back to the keyboard without looking. It only takes about
> two months of practice to learn these skills. Compared to typing, that's
> a very short time to become proficient.)

Well, it took me about one year to learn typing, but I'm using mice
much much longer than that. I still can move my finger much faster -
and with less cognitive load - a few centimeters than performing
the ritual you describe above.

>>>And what's the use of training your fingers to type something, if it can't
>>>be used in all cases. I started working with Windows, and I got used to
>>>ALT-EP for paste. I didn't like it, but I got used to it. Then I brought up
>>>a dialog box. WHAMMO. ALT-EP didn't work. So much for saving time with
>>>shortcuts.
>> 
>> Why didn't you use the Ins key? I use it all the time, it is easily
>> reachable, and it works everywhere.

>Because I fell into the trap. I thought that the ALT-stuff was more 
>mnemonic. To use the Ins keys, I had to look away from the screen and find
>the INS key. And I never could remember if paste was Ctrl-Ins or Shift-Ins.
>(I've now learned that it is Shift-Ins) More time wasted.

I wouldn't consider that a waste of time.

>Of course, now that I've learned this, MS has changed the rules, and
>some applications are going to be using Ctrl-V. INCONSISTANT!

Yes, in a way, and I don't like it. On the other hand, I understand
that they try to get a bit more consistency between applications
on the Mac and applications on Windows, at the expense of intro-
ducing a bit of inconsistency in the WIndows interface.

>> ;-) :-) Got you. I'm using a German version of Windows. 

>That's certainly unfair of you.... <grin>

Perhaps unfair, but I think it proves my point that the 
keyboard interface to menus isn't just a redundant variant
of keyboard shortcuts.

>>>> Why not? I've learned them automatically, while I used the system, and
>>>> I know a lot of people who learned them while they used the system.
>> 
>>>Except they don't work. So you learn them one way, then you have to go
>>>back and learn the REAL shortcuts.
>> 
>> Hm. To me, the Ctrl+C shortcut is very nonintuitive.

>It doesn't have to be intuitive. Just consistant. Once you've learned the
>non-intuitive lesson, you've learned it for all applications.

Then please apply the same rule to Windows keyboard navigation
for menus and dialog boxes. It is very consistent - and powerfull,
too.

>However, an interface element that is both non-intuitive and inconsistant
>is practically unlearnable.

Just a question: you apply the work "inconsistent" to single objects,
quite often. As I understand it, this attribute is usually applied
to a multitude of things or to a relation between things or the 
multiple useage of something, just like "compatible" or "equal".
How can a single interface element be "inconsistent"?

>>>> Perhaps there *are* people unable to memorize short (i.e. one
>>>> or two) key sequences they use all the time, but I doubt  
>>>> very much that they are in a majority.
>> 
>>>There's actually a large difference between a two and three key sequence. 
>>>That's why I find Windows menu navigation to be cumbersome.
>> 
>> Where did you find three key sequences? 

><ALT> <E> <P> That's three keys.

Oh, I see. But you don't have to memorize the first key, it's
always the same.

>>>On the Mac, I don't care where the Open menu is. I just hit Command-O and
>>>I've got it. Under Windows, I can't be sure exactly where this menu is.
>>>Is it under the File menu, where it should be? Or perhaps I'm using 
>>>Write, where it falls under a different menu.
>> 
>> Write has it under the File menu. But you're right, shortcuts
>> (those equivalent to Command-O, not the keyboard/menu interface)
>> could be more standard between Windows applications. 

>AH! Vindication!

Not at all. I just try not to fall into the "right or wrong, my
country!" trap.

>> Many don't have any shortcuts, and if they have, they aren't always identical.

>EXACTLY!

So what. Bad or illdesigned applications don't make an interface
illdesigned, automatically.

>> Microsoft seems to have standardized on Ctrl+F12 for File Open
>> (the use it in Word and Excel), but it isn't standardized enough
>> to be usefull. I don't use them often. On the other hand, people
>> are different - I know others who like them: Ctrl+F12, Ins,
>> Shift+F3, Enter ..., so I'm not so fast to condem that feature.

>I HATE F-key shortcuts. The F-keys are never in the same place on two
>keyboards, and one-handed manipulations with some of the modifier keys
>are next to impossible.

You hate F-key shortcuts. So do I. But I don't try to enforce my
preferences on others.

>>>>>And as soon as you try to use one of those ALT- shortcuts in a dialog,
>>>>>WHAMMO -- all that learning goes out the window.

>>>Nope. You can't do a Paste using the ALT+ shortcuts. You have to do 
>>><taking deep breath> Ctrl-Ins. 
>> 
>> If the window you are typing to has an Edit menu which has a Paste
>> entry, you can do a Paste using the Alt+letter shortcuts. If it
>> hasn't, you can't. 

>But you can always paste with the Shift-Ins or Ctrl-V shortcut.

Yes. But this doesn't have anything to do with the menu bar. It
is not part of the functionality of the apps menu bar which happens
to have an Edit menu. It's a function of the edit control (a 
child window) you are typing into. 

>>>Or if the application is more progressive, Ctrl-V.
>> 
>> Why is this more progressive? Just because MS decided to
>> support a handfull of Macintosh shortcuts in their applications,
>> in addition?

>It is more progressive because MS changed the standard. The standard
>used to be Shift-Ins. MS changed it this year. So, if your application
>keeps up with the latest standards, it is more progressive.

>> Using the clearly labeled "insert" key for an insert operation
>> is more progressive, IMHO.

>It is undeniably cumbersom, IMHO.

I disagree. But we should leave it there; I think we have both said what
we intended to say.

>>>From using it. ARGH!
>> 
>> It is my impression that you use Windows just enough to be able
>> to complain about its shortcomings, and the Macintosh so much
>> that you can't see its shortcomings, anymore.

>That may be true. I have a lot of coworkers who feel the same way,
>and they use Windows a lot more than I do.

But do you have anybody who uses Windows more than the Mac, without
being forced to do that?

>Windows is tons better than DOS. I had to do a bunch of DOS related
>stuff recently. Going to Windows the next week was like a breath of
>fresh air. I felt much more at ease. 

>Windows is better than DOS, but it ain't no Macintosh, that's for
>sure.

Agreed. That WIndows is better than DOS, and that it doesn't
approach the Macintosh. But doesn't make Windows inferior, in my
(not your, I understand that) opinion, it just makes
it different.

>>>I disagree. The pointing device is a natural extension of real-world learning.
>> 
>> Sorry, I'm lost here. Care to explain 
>>  - what that means, and
>>  - how it applies to my above statement?

>You learn how to reach out and grab things from when you were just a dozen
>months old. Using a mouse is an application of that learning.

Well, I learned that it may be quite dangerous to reach out and 
grab something, so I wouldn't apply that without further study. :-)

>Using a mouse is easier than using a keyboard, just for that reason. Given
>the choice between a computer with and without a mouse, I'd choose the one
>with a mouse (or other pointing device). So, I can't see how using an
>interface without the mouse is a benefit.

Neither the keyboard nor the mouse resemble the direct interaction
by which a child reaches out and grabs something. In both cases
you don't interact with an object directly, but use a tool to act
on your object. In a way, ineracting using a mouse is one level more
indirect, because you use one tool (the mouse) to operate a secondary
tool (the pointer), which finally acts on the object. 

>> Pointing at things is used in real-world learning. Mostly it's the
>> teacher, who does the pointing ("look, boy, that is a horse"). Most
>> of the time, there is no device necessary to do the pointing, because
>> it's either implicit, or unnecessary, because a finger or an arm
>> is sufficient. 

>You continue to grasp things in the real world every day of your life. Using
>the mouse is just an extension of that experience. You don't have to speak
>to do that. That's the advantage.

Perhaps. But is an extension of a very stupid and not much productive
way of grasping things in the real world. Using a stick do dig in 
the mud comes to mind. We can do better with our hands. And I 
*can* speak. :-) 

Sorry about the last joke; I think I understand your point. But
I don't agree that an user interface of a computer has to be
so simple that you don't have to use your capability to speak or
to write in order to interact with it. Or worse: that you
*can't* use your capability to speak or to write.

>> In addition, many people have bad memories about pointing
>> devices in real-world learning context (cane), so it isn't that
>> good an idea to force that upon them. 1/2 ;-)

>I don't understand this reference. Are you saying that people don't like
>pointing devices because they are spanked?

No. I just try to point out that the matter isn't as simple as 
you try to present it. There isn't a single, clear inheritence
path from the child grabing a toy to a Macintosh user pushing
his mouse. 

>>>Keyboarding is not. I do not agree that being able to use a visual interface
>>>from the keyboard is a benefit when the mechanisms to do this get in the way 
>>>of other interface elements through inconsistant usage.
>> 
>> For computers which don't have a keyboard at all, I aggree.

>Even for computers which have a keyboard.

Here I disagree.

>>>If ALT-EP worked even from a dialog box, I'd feel better. I'd still think of
>>>the three key shortcuts as cumbersome, but they wouldn't be so awful. They 
>>>don't.
>> 
>> You're barking before the wrong tree (I hope I got that picture right :-).

>No I'm not. Paste will work from a dialog, but not if you use the ALT 
>shortcuts. If they would, then I'd be happier. That's all I'm saying.

If they would, that would be an inconsistency, because this would
imply that two different things - the selected one, the dialog box
you are typing into - and another window - your main application
window, here, react to your attempt to do keyboard navigation.

>> Menus are attached to windows on Windows, so you can't expect the 
>> keyboard navigation to work on some global menu. 

>That's not what I'm saying. Go back and look at what I wrote. I'm not asking
>Windows to do anything it can't already do. I'm asking that it do it 
>consistantly.

No. You ask it to introduce an inconsistency.

>> This concept doesn't exist there. Alt e p is local to a windows. Many 
>> shortcuts, including the insert key interpretation, are - more or less - 
>> global, because they are a feature of certain standard child windows, 
>> which are used almost everywhere.

>If this is your reasoning, than I submit that this is radically piss-poor
>user interface design. The user doesn't care about the internal architecture
>of keyboard interpretation. He just wants an interface that works cleanly
>and consistantly. Windows doesn't give you that.

You repeat to say that, but I haven't seen a proof. Of course the usesr
doesn't care about the internal architecture. But if you insist on 
a behaviour which is inconsistent with the architecture - both the
internal and the visible one -, this doesn't prove anything.

>>>> Do you really think that it is as simple as that? There is no reason
>>>> to remember two letter shortcuts much longer than you actually use
>>>> them. 
>> 
>>>This assertion is exactly contrary to my experience as a Macintosh user.
>> 
>> YOu can't have experience in that area as a Macintosh user, because
>> that feature doesn't exist on a Macintosh.

>See the next sentense.

>>>I remember all the standard shortcuts BECAUSE I use them. Either the
>>>longer Windows shortcuts aren't used (and hence aren't learned), or the
>>>complexity of the cumbersome nature of the interfaces bars learning.
>> 
>> No. As a experienced Macintosh user, you have a blind spot, here.
>> If I where a experienced Macintosh user, I would have that blind spot,
>> too, probably.

>I don't think so. I asked three experienced Windows users what the shortcut
>for a certain common menu was, THe response I get back is that they don't
>know, or they give me the wrong answer. I could ask three experienced mac
>users the same question, and they would all give me the right answer.

THis only shows that Macintosh users have to superfluous burden to
memorize shortcuts, whereas the WIndows user don't have to do that,
because everything is visible if they need it.

>That's that the consistancy of the interface does. It simplifies learning,
>not compound it.

>>>The beauty of a visual user interface is that YOU DON'T HAVE TO. You
>>>don't have to READ just RECOGNIZE.
>> 
>>>In a CONSISTANT visual user interface, it is even better, because recognition
>>>is faster since you already know what to expect!
>> 
>> Indeed. But all this is a feature of the visual interface, not of
>> the pointing device. The pointing device isn't necessary.

>Once you transition to the keyboard, you lose the connection to your basic
>real-world experience. If you can't reach out and grab it, you have to
>recall or synthesize some sonomic sequence of keys to use it. That's
>where it breaks down.

See above. This is a much to simplified view, IMHO. The mouse is as
artificial as the keyboard. By that I don't imply that it isn't 
better for many human-computer-interaction task, than the keyboard.
But this has to be tried (and proven) on a case to case base. My
own experience shows that this therory - it looks simple, so it
is simple - fails sometimes.

>To complete the visual interface, you must have direct interaction. You can't
>(yet) get that without a pointing device. And a keyboard isn't the answer.

Sure. But what was the question? ;-)

IF you must have direct interaction, the mouse isn't the answer, either.

>>>> You read it once, or twice and remember it by its various attributes 
>>>> (mostly: position) and use it blindly, later.
>> 
>>>Yup. And this is exactly why mousing is faster than keyboard shortcuts.
>> 
>> Exactly why?

>Because you don't have to recall anything. You reach out and grab it with
>the mouse. Just like you reach out an grab your coffee cup. You don't
>have to remember to type "<ALT>-"C"offee-"G"rab.

I don't remember to type <ALT>-"C"offee-"G"rab, I remember 
"push left tiny finger (sorry, my dictionary fails here) on the left hand",
underlined letter, next underlined letter, release.

>>>If you and Peter are actually trying to tell me that you use Windows by
>>>pressing Alt, then thumbing through the menus by pressing the arrow keys,
>>>or by looking at the menu items and typing the appropriate shortcut, then you
>>>are TONS slower than users using the mouse. The comparative cognitive load
>>>is immense.
>> 
>> I can't speak for Peter. 
>> 
>> A few comments. Windows has - and this is indeed different from the Mac -
>> more than one method to interact with menus and dialog boxes. 

>This is true. And having more than one method to do things isn't necessarily
>a good thing.

Agreed. But it isn't necessarily a bad thing, either.

>> There are 
>>  - the mouse interface,
>>  - cursor navigation,
>>  - the Alt+character navigation and
>>  - the shortcuts (called accelerators).
>> 
>> The fact that there are four instead of two methods may increase
>> the cognitive load. On the other hand, one could argue that
>> the confusion is already there, even on the Macintosh, because
>> there are *two* different ways to do the same thing. If you 
>> can ignore one way, why shouldn't you be able to ignore the others?

>It isn't the number of methods that increase cognitive load, it is the methods
>themselves. Cursor navigation, ALT keys, and even the accelerators are probably
>all slower than using the mouse.

I didn't mention it up to now, because I didn't know where to apply
it. I don't agree whith the theory that there is a positive linear
relationship between cognitive load and speed, and that you just
have to measure the speed in order to measure the cognitive load.

IN addition, I know that the tools you have change what and how
you do something, so just the attempt to measure mousing and
keyboarding with all other things equal invalidate the whole experiment,
IMHO. What if I can write a text twice as fast when using the mouse,
if, for some reason or another, I write another - and perhaps 
less usefull or good - text, that way?

>Now, if you restrict yourself to the accelerators, then you almost have it
>as good as the Mac. Unfortunately, since there's no consistancy, your learning
>isn't as complete as on the Mac. 

>Worse, you end up learning to use the ALT navigation, and your life is even
>slower, and you end up doing things the "wrong" way at times.

But it doesn't end up that way. I'm using all the various interaction
methods together, and consider it as a big advantage that this
is indeed possible - that I can switch from "expert mode" to
"exploring mode" and back after an interuption, so to speak.

>> Personally, I use all four methods, often interleaved, i.e.
>> I click at some menue entry, read the pop-up menu, and continue
>> with the cursor keys or a letter. Or I start with the Alt+letter
>> and continue with the mouse. It depends on how crowded the
>> menus are, whether I've already memorized them, where my
>> fingers are and what I try to do. I seems to be quite fast
>> to me, but this is purely subjective. 

>If I were to sit down and time you, I believe I'd find that using the 
>mouse is much faster. And that's the entire issue. You PERCEIVE the
>keyboard shortcuts are faster because of their higher cognitive load.

Simply not true. I had to sit down - and indeed did it - and to
think about whether I'm using the shortcuts and the keyboard 
navigation at all! I remember that I'm constantly using the mouse
for various things - selecting a remote piece of text, double clicking
a word, resizing a window, operating a menu and so on. But did I use
the keyboard? Introspection gave the result: yes, I do. Not often and
certainly not as often as the mouse, and obviously completely 
automatic. FOr example to scroll through the menu bar in order to 
check a few flags: alt, a few cursor keys, esc. Very often in
dialog boxes, to push the buttons directly, instead of going through
the mouse indirection. Or in combination - I already told that: 
click at a menu entry to pull down a menu, but then use the cursor keys to 
move the selection up and down. This requires much less thinking
that moving the mouse pointer - no need to play ballistic pingpong
with your pointer on the screen to move the selection down two lines. 
Just two simple keystrokes <down><down>. And so on..

[...]

>>>It is faster to do this with the mouse. With the mouse, you just reach out
>>>and grab the item you see. With the keyboard, you have to recall, then
>>>synthesize the appropriate key, then you have to type it. By the time you've
>>>done all this, the mouse user has already grabbed his mouse, grabbed the
>>>item on the screen and returned to the keyboard for the next thing. Faster.
>> 
>> Yes, faster, if the conditions are right. If you already look at the
>> item. If you have your hand on the mouse. If you know where your pointer
>> is. If you look at the item, but have you hand on the keyboard and 
>> you don't know where the pointer is, it is much faster - and 
>> simpler (less cognitive load) - if you just press the letter which you
>> see underlined in the word you are looking at.

>If you have your hand on the keyboard, you move it to the mouse (without
>looking at it). 

I have pushed my mouse down to the floor more than once during that.

>If you don't know where the cursor is, you move the mouse
>in a tiny circle and find it. As soon as you spot it, you move right
>to your destination. You can do all this without breaking your train of 
>thought.

I can do that without breaking my train of thought, but not
always. I can do the same with the cursor keys and a few other
keys on the MF-II keyboard without, but not always.

>In comparison with the keyboard, you have to actually read the word, find
>the right letter (which requires semantic cognition) and then type it. This
>is a much greater cognitive load. 

I have to (or not to) read the word, whether I use the keyboard or
the mouse. I can find the right letter without semantic cognition,
because there is a simple visual aid: the right letter is underlined.

>Case in point. There are retarted people in the world that can't spell
>anything, and would have a difficult time matching the letter on the
>screen with the letter on the keyboard. These same people can use a mouse
>to grab something on the screen. That's lower cognitive load.

On the other hand, there are people who are visually impared. What
about them?

Anyway. If you - or anybody - cannot or do not like to use the
keyboard interface, there is no need to use it. I don't quite
unterstand why you insist on arguing against that straw-man.
I have stated repeatedly that I believe that a system should
fully implement *both* kinds of interfaces.

>> And if you don't look at the item (i.e. menue entry, command, action
>> to trigger) in question, its even faster, you just repeat the
>> memorized keystroke sequence 

>Except you have to REMEMBER the correct sequence. (And remember, you
>experienced windows users couldn't do this. <grin>)

I think I have already answered that point. :-(

>And the second roadblock is that if you do remember a sequence it may
>not work because a) you are in an application that does things differently,
>or b) you're in the wrong state (dialog box in front)

YOu apply something said about short-time memory to long-time memory.
Doesn't make much sense to do that. Anyway. You don't have to 
remember it. But if you do, you can use it again in that application.
Of course, the fact that you reach [D]raw [L]ine via Alt D L doesn't
help you much in your terminal program, because that means
Drop Line, there. :-)

>>>> Well, indeed. The Macintosh UI is different from PM and Windows, and
>>>> more consistent, often by omission. This doesn't always make it 
>>>> better, imho.
>> 
>>>IMHO, Consistancy is lots more important than feature count.
>> 
>> I don't know how to compare these.
>> 
>> Anyway. I say that I prefer my house to have more than one
>> way out, and you answer that one shouldn't rate a house by
>> its number of doors.

>Only if your house has lots of doors, but floors of different
>heights and slope. I'd rather have level floors of the same 
>height and fewer doors.

My house indeed *has* lots of doors - because it has many
rooms - and floors of different heights. I like it very much. :-)

Wolfgang Strobl
#include <std.disclaimer.hpp>
Newsgroups: comp.sys.mac.advocacy