Re: Framemaker, Word and Robohelp

["Chuck Martin" <twriter -at- sonic -dot- net>]

"Blaine, Karen L." <karen -dot- blaine -at- unisys -dot- com> wrote in message
news:87094 -at- techwr-l -dot-  -dot-  -dot- 
>
> Chuck Martin wrote:
> |It distresses me to see, time and time again, that "taking a course" is
> seen as a solution to |learning about a software package.
>
> Among the positive aspects of taking "taking a course" is that for a new
> product, I can get up to speed a lot faster than I could if I'm exploring
on
> my own.

True, But I think a lot of courses are little more than boosters for the
products, emphasizing the bells and whistles and the things that work right.
Still, I have seen some instructors admit that things are designed in a
convoluted way and apologize to the class members.

>
> One of the most valuable things I get out of a course is the interaction
> with other people, who often will be using a product very differently than
I
> expect to use it. This gives me ideas about how I can use it more
> efficiently. From the UI and the documentation, I may understand how to do
> something, but a course gives me ideas about how to apply the tool to the
> best advantage, how to make it work for me.

Most training courses I've been in, the material is packed into a few days,
with little time for interaction. The interaction you describe is what I
more often get when I take a class at my local college (which I do nearly
every semester), where there is the time to have that interaction over the
course of the semester.

>
> |While in some cases it may be needed, training more often is about
> explaining how to use what
> |should have been obvious, if the software had been designed with its
users
> in mind.
>
> I find that sometimes the practical use of an option isn't clear because
the
> option was designed for use in a specific industry, and uses terminology
not
> commonly used in my industry. Without someone (an instructor) to help me
> "make the connection", using these options doesn't make sense, therefore I
> avoid them even though they have the potential to make my job easier.

Ah, but we were talking here about software designed for *our* indistry.

>
> |Using FrameMaker as an example, it is essentially one of many word
> processors. Many of the |tasks that users would want to do in FrameMaker,
> many of the goals that users would want to |reach, are no different than
the
> ones that would be there if they were using a different package. |And if
> users are reasonably familiar with other packages (as I would hope
technical
> writers with |any amount of experience would be), then the product design
> should be such that it lends itself to |communicating its important and
> useful functionality. In addition, the documentation, both the
> |online Help and the printed materials, should be easily accessible and
> should have clear |information bout how users can reach their goals when
> they run into difficulty.

> |
> Having made the transition between products a number of times, part of the
> transition required is one of accepting the philosophy of the assumptions
> made at product design. Often the product was targeted at a particular
> industry, then expanded for general use. Understanding product philosophy
> often clarifies all kinds of options, methods, and procedures that
otherwise
> leave you thinking "What a stupid way to do that!" or "Why ever would I
WANT
> to do that?"
>
There are, at times, good reasons to do things. Way back when I was still in
school, one of my classes went to Aldus (remember Aldus, creators of
PageMaker, in a wonderful Pioneer Square office). I remember not
understanding, along with most of the other people in my class, the icon
used for one function. It was explained that the development team had
struggled mightily with tyring to come up with an icon that would
communicate the fucntion to more people. But they came to realize that it
was for a very industry-specific function, and that the people who were in
that industry would understand at a glance, and that the best course of
action would be to educate others (not from the industry) of its function.

But this is different from simple poor design, where basic functionality is
hidden behind geegaws and obscure terminology. As Alan Coooper would say
(see the sig), the philosophy of the assumptions made at design time are
typically not those focused on user needs, but programmer needs. Why should
users have to understand product philosophy? Users want to get their work
done and go home! Why shouldn't it be the other way around: programmers
understandding users philosopyh? Well, the answer is: it should, but it
usually isn't.

--
"[Programmers] cannot successfully be asked to design for users
because...inevitably, they will make judgments based on the
difficulty of coding and not on the user's real needs."
        - Alan Cooper
        "About Face: The Essentials of User Interface Design"

Chuck Martin
twriter "at" sonic "dot" net      www.writeforyou.com



^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Develop HTML-Based Help with Macromedia Dreamweaver 4 ($100 STC Discount)
**WEST COAST LOCATIONS** San Jose (Mar 1-2), San Francisco (Apr 16-17)
http://www.weisner.com/training/dreamweaver_help.htm or 800-646-9989.

Sponsored by DigiPub Solutions Corp, producers of PDF 2001 
Conference East, June 4-5, Baltimore/Washington D.C. area.
http://www.pdfconference.com or toll-free 877/278-2131. 

---
You are currently subscribed to techwr-l as: archive -at- raycomm -dot- com
To unsubscribe send a blank email to leave-techwr-l-obscured -at- lists -dot- raycomm -dot- com
Send administrative questions to ejray -at- raycomm -dot- com -dot-  Visit 
http://www.raycomm.com/techwhirl/ for more resources and info.