From: bcoleman@hayes.com (Bill Coleman)
Newsgroups: comp.sys.mac.advocacy
Subject: Re: Macintosh advocacy (really!)
Date: 14 Dec 92 23:42:59 EDT
Followup-To: 085209.2682 references:  <tomster.92dec6154303@bigwpi.wpi.edu>

Organization: Hayes Microcomputer Products, Norcross, GA

In article <TOMSTER.92Dec6154303@bigwpi.WPI.EDU>, tomster@bigwpi.WPI.EDU (Thomas Richard Dibble) writes:
>>>>>> On 4 Dec 92 13:12:09 EDT, bcoleman@hayes.com (Bill Coleman) said:
> 
>> Look: let's not be silly about this. The time spent by the
>> unconscious part of your mind deciding which mouse button to press
>> is so tiny, that no matter how often you have to make that decision
>> during your lifetime, it is insignificant to the time you just spent
>> posting that it does take time... ;-)
> 
>   BC> If you clicked the mouse only once a day, that tiny delay
>   BC> wouldn't matter.  But in the course of using a computer of an
>   BC> hour, you may click the mouse hundreds, if not thousands of
>   BC> times. That tiny delay adds up in a hurry.
> 
>   BC> Furthermore, the two-button mouse is more complicated to master.
>   BC> There's also a dilemma of hidden user interface items popping up
>   BC> from below the screen with no visible indication (as in Windows
>   BC> or OS/2).
> 
> It is quite obvious that you just don't 'get' the idea of
> context-based menus, as applied in Windows (and, I think, in os/2).

It isn't a question of "getting" them at all. It is a question of what is
easier to use. If a user interface metaphor requires extensive training and
coaching to "get" then it must be defective. It should be replaced with
something simpler and intuitive.

> They are not 'hidden' in that you must click all over the screen to
> find them.  If you are in Excel, everywhere on the spreadsheet has a
> context-based menu which will pop up if you click the second mouse
> button on it.  

And that, in my mind, is the problem. It isn't VISUALLY OBVIOUS where these
"context" menus change. 

There should be visual cues where the user can find these menus. He shouldn't
require a priori knowledge of where to find them.

> If you made a mistake, simply click *either* button
> outside the menu to make it go away.  

How does this help the user? If he clicks to bring up a menu, and gets the
wrong one, how does he complete his task? How did he even know to click there
(or somewhere) in the first place with the right mouse button.

I surely hope you can see why I'm uneasy about these "context-based" menus.
The "context" is certainly non-obvious. The magical nature of the "pop-up"
menus is certainly unsettling. 

>   BC> This thread started when someone suggested that the Mac was
>   BC> inferior because it only had a one-button mouse. I'm just trying
>   BC> to point out that just because the Mac has fewer mouse buttons,
>   BC> that doesn't make it inferior. The use of one mouse button is
>   BC> actually a design feature, and there's a basis for showing how
>   BC> it may actually be a SUPERIOR design.
> 
>>>> Look at the Archimedes; they have *three* buttons, and still sometimes 
>>>> wish there were more! :-)
>> 
>>>I'm not familiar with Archimedes. Sounds like they are perpetuating
>>>a bad user interface.
>> 
>> No, it has a very nice UI actually. Lots and lots of features; not 
>> necessarily designed for the novice. 
> 
>   BC> Sounds like a bad user interface. That's two strikes: 1 - too
>   BC> many features, 2 - difficult to learn.
> 
> How is too many features, in and of itself, a bad point?  

YES! 

Too many features shows that little thought has been given to the design and
use of the product. Extra features do little to help the user get the job
done. (Although they do may for impressing power-users and certain targeted
market groups) When you actually get down to USING a product, rather than
just comparing the number of features, having lots of features is a sure
sign that the product is harder to use.

> I submit
> that it is only a strike against it if the usefullness of the features
> does not outweigh the increased complexity of the interface.

Of what use are additional features if the user cannot figure out how to use
them? They are of no use at all.

>   BC> Really, do you look at this process of opening one window while
>   BC> closing another is a real stumbling block to productivity?
> 
> It is merely an *example*, Bill.  Calm down.  The menuing example
> given for the NeXT's definitely *is* a stumbling block to
> productivity, as far as I'm concerned, because Windows does not
> support this feature, and I have often found myself in need of it.

This might be a flaw in the NeXT, but not the Mac. Depending on how one USES
the Mac interface, there is little need for this specialised shortcut for
closing windows in an open.

>   BC> Pop-up menus always have the same behavior. They always go away
>   BC> (and reduce to their original visual state). Some applications
>   BC> offer tear-off menus, which always stay up. There's no
>   BC> difference in behavior with one button or another. There's no
>   BC> need to use keyboard qualifiers.
> 
> Which was exactly his point.  

What? That there is no need for keyboard qualifiers?

> Thank-you for articulating it so well.

You're welcome.

> This is simply *not an option* on a Mac.  It should be.  Ignore it if
> you will, even disable it, but it *should* be an option.

Why? If something is not needed, why should it be an option?

> BTW, don't tell me there is no wasted time while the Mac erases and
> redraws the menu ...

There is no wasted time while the Mac erases and redraws a menu.


(much)


>>>Nope. You certainly missed my point. While the Macintosh METHODS may
>>>differ, you can certainly accomplish the same task with a slightly
>>>different user interface approach.
>> 
>> Taking considerably longer, and making life more difficult for you. 
> 
>   BC> You've offered no proof that other methods would a) take longer
>   BC> or b) would be more difficult. Indeed, I believe I could easily
>   BC> make a case that the one-button solution is considerably LESS
>   BC> difficult.
> 
> Well, he did offer proof of (a).  Even *you* did.  I'm not sure about
> (b), but I would hasten to conjecture that (b) follows naturally from (a).

He did not offer proof of (a). He offered up an artificial user interface
item which doesn't even appear on the Mac. He didn't look at the problem of
solving a user task. If you use different methods which are OPTIMIZED for
the one-button interface, there is no lost time.

And (b) certainly doesn't follow from (a). Difficult interfaces can often take
less task time, provided the user has the sufficient memory, training and
resourcefulness to make use of them. 

>> Getting silly about it (again), I can do basically anything you can
>> on your Mac with a pen and paper. It might take me years to
>> accomplish tasks that would take you a few minutes, but it can be
>> done...
> 
>   BC> Reducing an argument to an absurd level does not refute it.
> 
> No, it puts it back into perspective.  You have been arguing that
> simplicity is paramount over features; he just gave an example where
> you are obviously wrong.

No, he reduced an argument to an obviously absurd level. He didn't debate the
merits of the argument. He merely made fun of it.

Go back and study logic. This kind of ad hominem argument doesn't wash.

>>>Again, I'd like you to name something you can't do on a Mac that you
>>>can on an Amiga just because the Mac is missing a mouse button.
>> 
>> Abosultely nothing, actually. 
> 
>   BC> QED.
> 
>> The second mouse button is just an aid to the user-interface.
> 
>   BC> Apple doesn't see it that way. They have research which
>   BC> indicates that the second mouse button is a HINDERANCE, not an
>   BC> aide.
> 
> I don't *care* how Apple Corp. sees it.  I care how it *really is*.

Good point. If you really care, then you should study the same research that
Apple did.

> The research they have ... how many years old is that?  

What difference does that make? Unlike computer software, scientific 
research doesn't rot with age.

> Was the
> quality of the interfaces equal?  Was the second mouse button defined
> in any of the afore-mentioned fashions?  Did the tests involve
> situations where the second button was actually *used*?

Yes, Yes, Yes. 

>   BC> The point is, the user interface should permit the user to
>   BC> ignore the features he doesn't really need and get useful work
>   BC> done. As the user becomes more experienced, he should have the
>   BC> opportunity to learn and integrate new system features as HE
>   BC> desires. It shouldn't be something imposed by the programmers or
>   BC> designers of the system.
> 
> Exactly.  So why not give him two buttons on his mouse and a handy
> little toggle to make the second button identical to the first?

Because having the two mouse buttons in this fashion a) presents a learning
problem and b) isn't necessary.

a) when the user reaches the point where he needs to learn the special features
using the "two button" interface, he has to start back at square one. He has
to unlearn the habits he adjusted to when he used the "one button" interface.
This does not make for a smooth learning curve.

b) if every facility is accessible with a one button interface, there's no 
need for the second button.

>   BC> The Mac hasn't reached this goal, but it is a lot closer than
>   BC> anything else on the market. The one-button mouse is one of the
>   BC> vehicles toward that goal.
> 
> Well, sure it is ... :->

Good. We're in agreement. Next thread.

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