From: tomster@bigwpi.WPI.EDU (Thomas Richard Dibble)
Newsgroups: comp.sys.mac.advocacy
Subject: Re: Macintosh advocacy (really!)
Date: 15 Dec 92 20:22:28
Organization: ZikZak Corporation
	<1992Oct23.211012.20812@javelin.sim.es.com>
	<bmccnnll.720056834@unix1.tcd.ie>
	<1992Oct28.041251.118883@watson.ibm.com>
	<1992Oct29.051139.11315@cs.uow.edu.au> <6281.2af56fde@hayes.com>
	<1992Nov6.085209.2682 references: <tomster.92dec6154303@bigwpi.wpi.edu>
	<6539.2b2d1c03@hayes.com>
NNTP-Posting-Host: bigwpi.wpi.edu
In-reply-to: bcoleman@hayes.com's message of 14 Dec 92 23:42:59 EDT

>>>>> On 14 Dec 92 23:42:59 EDT, bcoleman@hayes.com (Bill Coleman) said:

  BC> Organization: Hayes Microcomputer Products, Norcross, GA Lines:
  BC> 232

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

And you pull down menus hundreds, if not thousands of times in that
same period ( not quite as much as you click the mouse, but around
half).  The delay in the computer drawing and redrawing the menus is
far greater than the delay due to "cognitive load" of me choosing
which button to press.  So why not get rid of all those useless
things?  All they do is cost us time!
 
>   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).

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

It does not take extensive coaching.  In fact, it takes none at all.
My experience (with the ten or so people I have witnessed starting to
use this feature) has been that it is quite easy to "get".  All I have
to do is take the mouse in hand and click the right button *once* on a
portion of the Excel spreadsheet, the new user's eyes light up, maybe
he asks something like "how'd you do that" in which case I again click
with the right mouse button.  Within five minutes on his or her own,
this person has made himself familiar with the concept and has tried
it on the objects on the screen.  It's actually quite fun to watch,
kinda like a kid a Christmas ...  Anyways, what I'm trying to say is
that the learning curve for this is almost nonexistant.  If you would
take the time to step into Excel (with a two-button mouse ... though
I'm sure the Mac version has a modifier kludge in it.) for five
minutes I'm sure you would see what I mean.

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

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

Well, yes it is.  They change where the objects on the screen change.
The button bar is clearly different from the spreadsheet itself; a
chart is quite different in appearance than the button bar.

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

The thing is, you see, that he doesn't need any knowledge other than
that they're there.  If he wants to do something to a spreadsheet
cell, he right-clicks on the cell and the menu pops up.  If he wants
to do something with the 'x' axis of a chart, he right-clicks on the
'x' axis of the chart.  It's called object orientation.  Get used to
the idea.

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

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

Because he wanted to do something to the object he was clicking on.

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

I can see why you are "uneasy" about it.  It's still quite obvious you
haven't actually gone out and tried using it.

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

  BC> YES!

[Webster - _Webster's_New_World_Dictionary_, 1988 printing:]
	"feature -- [...] 3. a distinct or outstanding part, quality,
or characteristic of something."

Please correct me if the definition has changed in the past four years.

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

Excel is easier to use than Lotus-123.  Excel has almost twice as many
features as Lotus.  Go figure.

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

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

No, it's not black-and-white "either he can figure them out instantly
or he can never use them."  Every feature takes a small or large
ammount of time to use.  If that ammount of time is greater than the
ammount of time saved over the lifetime of the user's usage of the
feature, the feature was not worth learning.  On the other hand, if
the feature saves the user more time than it takes for the user to
start using the feature, that feature was quite useful.

Ever take economics?  The user will continue to learn new features as
long as he feels the time he is going to save will outweigh the time
he is spending learning the feature.  True, his feelings are not
always accurate, but they sure are a hell of a lot more accurate for
his specific condition than those of the guy who wrote the program.
Therefore, features are a good thing ... or at least not a bad thing
... in and of themselves.

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

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

No, no no.  I said it was a *feature* of the NeXT.  Oh, yeah ...
features are flaws, right?

What I was talking about was the click-the-right-button-to-make-the-menu-
stay trick NeXT-ers have been talking about.  Or was that the Amiga?
I don't remember any more.  The point is, I have often found Windows
would run better if it had a mechanism like that (even before I knew
the Amiga/NeXT had it).  To me, that says it is a good feature.

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

  BC> What?
You deleted too much of the post for me to remember ... :->

  BC> That there is no need for keyboard qualifiers?

No, that was definitely not it ...

> Thank-you for articulating it so well.

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

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

No, no, no.  You are again under the impression that all users are the
same.  This is simply not true.  Even though *you* may not need it,
*I* may ... by the way, what is it that we're talking about here?

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

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

Ah ... so either you fall into a temporary coma while the menus are
redrawn or you are running a much, much, much faster Mac than I've
ever seen.

The menus on all the Macs take much longer in drawing and re-drawing
than any time I have ever spent on the timeless dilemna of "which
mouse button do I press".

  BC> (much)

That's better.

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

(Oops ... I guess that should be "(a) follows naturally from (b)",
which it does.)

  BC> He did not offer proof of (a). He offered up an artificial user
  BC> interface item which doesn't even appear on the Mac. He didn't
                     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Exactly.

  BC> look at the problem of solving a user task. If you use different
  BC> methods which are OPTIMIZED for the one-button interface, there
  BC> is no lost time.

But I'm afraid he *did* bring up a real user-task problem.  Wasn't this
the one about menus?  I think so.  As I've said before, that has been
a *real user problem* for me.

(NOTE: just because Apple has not come up with a solution for it does
not mean that it doesn't exist!)

And of course, if you take a task which is "OPTIMIZED" for the Mac
then you will obviously tend to favor the Mac for that task.  This
task was not invented *after* the solution, Bill.  This task was a
real problem -- and still is in Windows and, I would assume, since the
Mac has no solution to it, on the Mac -- and is not "OPTIMIZED" for
any specific user interface.  Just because the two-button mouse excels
in this task does not mean that the task was "OPTIMIZED" for the
two-button mouse.

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

No, I disagree.  I'm surprised to hear this from you, in fact.  What
about all the time to learn this difficult interface?  That brings
down the average task speed.

Anyways, it should be that (a) follows from (b) ... actually, I guess
that's how you took it anyway ... but I just thought I should clear it
up, just for the record ...

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

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

Just because your argument was reduced to nothing doesn't mean he was
making fun of it.  But now we can make fun of *you* !!!
Neener-neener-neeeneer ...  :->

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

Well, I xor'ed it with itself and anded it with zero and still came up
with nothing ...

Argumental logic does justify his assertation as a completely
reasonable one.  Why don't *you* go back and read your logic manuals?
It was not ad hominum.  It did not attack you or your motives.  It
might have hurt your feelings, but that means nothing to me or anyone
else besides you.  Taking the argument of the opponent "one step
further" (or several) is both a common and accepted means of making a
point.  It washes quite well.

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

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

No, I should *conduct* the same research as Apple did.  Give me a
grant and I'll do just that :->

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

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

Research does not rot; it just becomes irrelevant.  *People* change.
If you gave a VCR to the average person ten years ago they would not
have a clue how to work it.  Now most of them can even set the clock
on it.  Society has made the VCR's interface more common to more
people.  Hypothetically, go back ten years and give people the
interface to the VCR and the dash board of a car.  Most would find the
car (standard transmission, et al) easier to use than the VCR.  Do the
same to a group of people today (I mean people who live in an area
which has reasonable access to the modern world; no Pennsylvania
Quakers), give them the choice, and they would choose the VCR.  By
quite a bit.  Why?  Because they are used to it.

People ten years ago were not used to two buttons on a mouse -- heck,
they weren't even used to mice.  Things change.

> 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*?

  BC> Yes, Yes, Yes.

I'm sorry, but I don't believe you.  Let's see some proof of that,
especially the latter two (as the first would be hard if not
impossible to proove).

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

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

Well, let's see:

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

Hmm ... no, sorry ... doesn't happen.  When you move from one button
to two the one button still works.  If you are used to using the right
button to do all your clicking then you just need to flop the
definitions of the two buttons (in windows, Control Panel, Mouse).  No
re-learning, because none of what you learned before is lost.

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

Except when things are more easily accessible with the second button.
We have given you several examples, all of which you have just ignored.

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

  BC> Good. We're in agreement. Next thread.

(and when you're looking up the argument logic look up satire as well
... :-> )

		---- tomster@wpi.wpi.edu

--
/****************************************************************************\
| "I sometimes used to try to catch her, :	FROM:   tomster@wpi.wpi.edu  |
| but never even caught her name."	 :	TO:	who(m)ever reads it  |
|	---- the cure			 :	CC:	programming language |
\vvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvv/
Newsgroups: comp.sys.mac.advocacy