TechWhirl (TECHWR-L) is a resource for technical writing and technical communications professionals of all experience levels and in all industries to share their experiences and acquire information.
For two decades, technical communicators have turned to TechWhirl to ask and answer questions about the always-changing world of technical communications, such as tools, skills, career paths, methodologies, and emerging industries. The TechWhirl Archives and magazine, created for, by and about technical writers, offer a wealth of knowledge to everyone with an interest in any aspect of technical communications.
Geesh! Ya go and take a couple of vacation days and the minute
your back is turned... ;-)
At 03:31 PM 8/30/96 +0800, Stuart Burnfield wrote:
>14 months as a techwhirler and I finally get to disagree with Sue
>Gallagher about something!
>David (the idiot) Ibbetson said:
>>And this has the result that the types who use the toolbar all the time
>>won't know about the facilities that have been hidden from them!
>Sue (the usually infallible) Gallagher replied:
>>. . . The user isn't there to play with the computer, but to get a
>>job done. If the toolbar button accomplishes the result *and* does so
>>faster and easier than the menu option, that's the way many users will
>>choose to go.
So I read the rest of the message and couldn't figure out where Stuart
and I disagree! Then I found this (also from Stuart) in another post...
>However, I took Sue Gallagher's comments to mean that toolbars can or
>should be the primary means of interaction for new users. I just think
>there's a danger of overprotecting users and not encouraging them to
>continue learning by exploring the product. It's good to lower the first
>rung on the ladder, but not if it makes it that much further to get to
>the second rung.
Well, I hate to disappoint you Stuart. But I'm not totally sure that
we disagree. If I remember correctly, I answered sumbuddy's question
about a "standard use" for toolbars, then answered sumbuddy else by
saying that users, after all, just wanted to get the job done and
prob'ly don't care about the options that're available on the dialog.
I never said that the docs or the interface shouldn't try to encourage
exploration and learning. I definitely think they should.
What I was trying to say, I think--and this is where our conversations
just miss each other--is that there are lots of users out there who just
plain ol' don't want to learn any more about the software than what they
need to get the job done. And they are just as much our customers and our
audience as the users who want to explore and learn and figure out how
it all works.
Sure, if we had more of the explorers in our target audience, our jobs
would be a lot easier. We wouldn't have to worry about making information
instantly accessible or about sevenplusorminustwo. We'd have a bunch of
users who wouldn't rest until they figured everything out -- who'd read
a 24-step procedure in online help.
But we do have to worry about those disinterested users. They're the
reason we try to put information in a single online help panel. They're
the reason that we chunk information down to the smallest units
imaginable and do everything but draw circles and arrows on the page
to point that info out.
And, oddly enough, those are the users that will seldom use the toolbar.
See, toolbars take investigating (unless someone else tells you about
them). The disinterested user will *usually *take the most obvious path
to the finish line -- usually the menu to the dialog box. It's the advanced
user who'll sprint to the finish using the toolbar. And the advanced user
prob'ly knows all about the options on the dialog box, but at the moment,
So, there you have it, Stuart.
I'm sorry to disagree with you, but I really don't think we disagree. ;-)
TECHWR-L List Information
To send a message about technical communication to 2500+ list readers,
E-mail to TECHWR-L -at- LISTSERV -dot- OKSTATE -dot- EDU -dot- Send administrative commands
ALL other questions or problems concerning the list
should go to the listowner, Eric Ray, at ejray -at- ionet -dot- net -dot-