From: bcoleman@hayes.com (Bill Coleman)
Newsgroups: comp.sys.mac.advocacy
Subject: Re: IBM Funny
Date: 14 Oct 92 16:08:05 EDT
Followup-To: f@hayes.com>references:  <strobl.718999205@gmd.de>

Organization: Hayes Microcomputer Products, Norcross, GA

In article <strobl.718999205@gmd.de>, strobl@gmd.de (Wolfgang Strobl) writes:
> 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. 
>>> 
>>> 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. 
> 
>>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. 

You are attempting to obfuscate the issue.

The dialog box I was speaking of is Modal. Since it is modal, you cannot switch
back to the application. Since the application doesn't have the focus, you
can't use the ALT- shortcuts.

If the dialog were not modal, you still can't use the ALT- shortcuts to
do a paste from the application, even though the "real" shortcuts will work.
You CAN, however, click on the application window, and then use the ALT-
shortcuts to do a paste. However, this will perform a paste into the 
application window (which is now the focus) and not the dialog window (which
was what was originally intended.

The point here is that it isn't obvious how to get the interface to do what
you want. The ALT shortcuts fail to work for no good reason. 

Regardless of how any other types of windows might work under Windows, this
is still a raging inconsistancy within Windows, and part of the reason it
isn't as good as using a Mac. End of debate.

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

But so do do the Ctrl-V (or Shift-Ins, take your pick) shortcuts! Yet they
work! INCONSISTANT!

Wolfgang, you continue to repeatedly overlook the fact that this facility
works in Windows, but only if you use the correct shortcuts. You can't
rationalise the existance of ALT- shortcuts not working by saying, "you
can't do that." Because you CAN!

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

Not at all. I expect Windows to show the same behavior within itself. If I
try the Shift-Ins shortcut, it works, ALT-EP doesn't.

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

Unless he tries to do a Paste with ALT-EP. That doesn't work from a dialog.
He's got to do Shift-Ins (or maybe it was Ctrl-V).

> You try to build a straw-man.

No straw men here.

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

Not at all.

How do you explain that the Shift-Ins (or Ctrl-V) shortcuts work, then?

Of course, if they didn't work, I'd be complaining that I can't even do
a doggone paste in a dialog box. That would be really stupid.

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

Switching applications on the Mac is certainly not a "major act" 
Nominally, you click on the window of the application you want to work
with. If the window isn't visible for some reason, you go to the
application icon at the top right of the display.

Windows works similarly. If you want to access an application, you click
on its window (or icon -- that works on the Mac, too). If the window
isn't visible, you click on the desktop to get the task manager list.

Extremely similar.

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

I don't find the Windows model to different from the Mac. See above.
The techniques are slightly different. The model is the same.

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

While true, you can only access the menu bar of the current focus. 
(Clicking on a menu changes the focus in addition to accessing the
menu)

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

Macintoshes support multiple applications and don't have this complication.
QED.

> Some assumptions learned when using single-applications systems break when 
> you try to move them over to a multi-application system. 

The Macintosh is not a single application system.

Indeed, the Lisa (on which the Macintosh interface is based) had a single
menu bar at the top, yet it is a multiapplication system.

You are proceeding from a false assumption -- that the problem I'm citing
has something to do with the Macintosh UI differences from Windows. It
doesn't. It is an inconsistancy within Windows itself.

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

Your analysis of my problem is faulty, therefore your point of view is
flawed, therefore you did change 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.

Ah. So you finally concede that Windows is Inconsistant. QED.

Thank you. So long.

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

You didn't follow the posting very well.

I stated that I would feel better if there wasn't this inconsistancy (that
you could actually use ALT- shortcuts in a dialog). However, there are
still things I don't like about the ALT-shortcuts:

a) they are cumbersome (lengthy)
b) they are modal

I changed the subject slightly, but certainly with sufficient warning.

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

Press the ALT key and released. The application control menu changes
highlight ever so slightly. If you don't realise where to look (like
you didn't realise you pressed this key), the change is invisible.

A dialog opening up on you is certainly conspicuous. This ALT navigation
stuff is much more subtle, almost stealthy.

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

EXACTLY!

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

It is inconsistant from the Windows side. ALT-EP shortcut doesn't work. But
the Ctrl-V (or Shift-Ins) shortcut does. 

>>Yup, and that is EXACTLY the problem. There's two different types of shortcuts.
> 
> Well, now I finally seem to start to understand. 

Sure took long enough.

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

Nope. You missed it.

If you could use both ways interchangably in all cases, it wouldn't be 
inconsistant. I stated so much in previous postings.

The problem (and the inconsistancy) arises where one method works in all
cases, and the other one fails in certain special cases. That's inconsistancy.

If you can use both ways interchangably in all cases, you'd have redundancy,
not inconsistancy. Sometimes redundant methods are useful in an interface.

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

That doesn't explain why the accelerator shortcut works, and the ALT-
shortcut doesn't.

You are correct that something is flawed here, and it certainly isn't my
mental model. Its WINDOWS!

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

Except the keyboard layout isn't from IBM. It is an ISO standard.

IBM followed the ISO standard. So did Apple. That's good for both of them.

You'll also note that DEC follows the same standard. That's good for
them, too.

But don't be lulled into thinking that Apple somehow copied IBM. That's
false.

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

Well, Wolfgang, you must be some kind of computer-robot then. Read "Tog on
the Interface." They tried some tests with humans. Their results indicated
something quite different.

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

Again, read "Tog on the Interface."

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

You again are mis-attributing intent. The experiments performed by Apple
weren't some marketing ploy, where the results are defined before the
experiment is written.

No, these were scientific experiments, where the object is to determine
the truth, even if the truth isn't consistant with your beliefs.

The results were quite remarkably. The users would insist that using the
keyboard was faster, yet measurements with the stopwatch on these
same users showed that the mouse was faster. 

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

This is pointless.

You keep going back to finger distance as a measure of cognitive load. It
isn't. Unless you have some grossly misshappen anatomy, cognition takes
place in the brain, not the fingers.

Oh, I forgot, you are a computer-robot.

Goodbye Wolfgang. It has been distinctly unpleasurably trying to discuss
this matter with you. 

I've reserved a nice cozy place for you in my killfile.

-- 
Bill Coleman, AA4LR                ! CIS: 76067,2327    AppleLink: D1958
Principal Software Engineer        ! Packet Radio: AA4LR @ W4QO
Hayes Microcomputer Products, Inc. ! UUCP: uunet!hayes!bcoleman
POB 105203 Atlanta, GA 30348 USA   ! Internet: bcoleman%hayes@uunet.uu.net
Disclaimer: "My employer doesn't pay me to have opinions."
Quote: "The same light shines on vineyards that makes deserts." -Steve Hackett.