From: shebs@apple.com (Stan Shebs)
Newsgroups: comp.sys.mac.advocacy
Subject: Re: Macintosh bigots (actually Help)
Date: 17 Nov 92 17:54:29 GMT
Article-I.D.: delos.shebs-171192091809
Followup-To: comp.sys.mac.advocacy,comp.os.ms-windows.advocacy
Organization: Apple Computer Inc.

In article <BxvAzp.2nE@news.cso.uiuc.edu>, rvenkate@ih-nxt07 (R A
Venkateswar) wrote:
> >Balloon help *is* the standard Help facility.  If applications don't use
> >it, that's not Apple's or the Mac's fault.
> 
> I don't believe that Apple couldn't improve the help on applications if
> they really wanted to. To put it in the words of someone who posted to
> comp.os.ms-windows.advocacy, balloon help is certainly "drool-proof".
> Disclaiming responsibility is not what I would expect from a company like
> Apple - the only reason that Apple is successful now is because they've
> listened to and acted on peoples' complaints. When (and if) they stop
> doing that, they're finished.

Apple is not alone in the computer business.  We have a whole group of
people who do nothing but tell independent developers what our customers
are saying, but we can't force the developers to listen, and if we publicly
excoriate developers who are making unfriendly applications, then they cry
foul and say that we're driving them away.  So it's a no-win situation.
(I suppose we could be like Microsoft, write the applications ourselves,
and just let the developers scream...)

Ah, but why not embed Help into the API so applications have to go out of
their way to avoid it, as we do with standard windows and dialog and scroll
bars?  This is a deeper question, and the answer is that users need higher
level explanations of what is going on, and only the application writer
knows what info is meaningful and how to display it usefully.  Suppose,
for example, that we insisted that application developers provide a
glossary in the 'glos' resource, and that every word in menu and dialog
resources have a glossary entry.  Then we're 1) requiring every developer
to provide global entries for words like "cut" and "copy", when many of
those words will have context-specific meanings, and 2) we're not doing
anything for the part of the program that is primarily gesture-based (or
should we add glossary entries like "shift-drag downwards".  I could go
on, maybe design a whole new help architecture, but I personally prefer
applications that just work "right", without needing to spend hours
cruising Help dialogs.  (For more discussion of these points, see any of
Don Norman's books.)

Don't be snobbish about "drooling users"!  They're the customers!
Remember "computer for the rest of us" and all that?

Now it *does* seem to be the case that a certain class of user prefers
more elaborate online help, and certainly I like to have it there as a
backup.  Given that many developers have implemented their own version
of this mechanism, yet have effectively settled on some common behavior
(accessible from vicinity of About box, single dialog that looks kind of
like Hypercard, has table of contents, etc), it seems to me that this
would be a good candidate for adding to the Toolbox, alongside Balloon
Help.  I would still be concerned that developers would slack off on
their interface design work because "the online help explains how it
works".  As is the case with other Toolbox support, there would lots
of support for one style of Help, and if any developers wanted to do
something much different, they would be on their own.

Of course, I'm just speaking for myself here.  For all I know, this kind
of Toolbox extension may already be in the works...

Stan Shebs
shebs@apple.com
Newsgroups: comp.sys.mac.advocacy