Re: .net and Help

["Chuck Martin" <cm -at- writeforyou -dot- com>]

"John Posada" <JPosada -at- isogon -dot- com> wrote in message news:230413 -at- techwr-l -dot-  -dot-  -dot- 

<snip>
>"I had a chance to speak with XXX today about the design of the XXX
>product as it regards the HELP function. She told me that an ON-LINE
>HELP feature should definitely be part of the functional specification
>for XX X.X."

I gotta ask: How is it a healthy development envoironment where online help
*isn't* part of the functional spec from the git go?

>This is designed under .net and it's our/my first one as .net.  What do
>I need to keep in mind? A particular form of help?  This will be the
>first document set written in FM around here (yeah!) and I'll be using
>RoboHelp for FrameMaker.

>For anyone who's done this before, what are the general rules?

Bottom line: from your perspective, there will be little difference. You'll
design and write the same content, create content access in the same way.
Your output will probably be HTML-based and probably be hosted in a form
that's familiar to users.

The difference will probably be the underlying API. And although that is
going to be different, the differnce is in the details, not in the way it
will work.

Right now, though, you'll be using existing help technologies, ones that
you're probably used to using. Microsoft Help 2.0 never became a public
product, instead being used pretty much only to document products that work
with Visual Studio .NET. Longhorn Help is still at least 2 years away (but
you can read about it at
http://winwriters.com/articles/longhorn/index.html).

A .NET application offers the same types of user assistance: separate help
windows, embedded content, What's This-style help, etc. For context
sensitivity, you'll still have a map file; it's only the format that might
change.

Oh yeah, my condolences about having to use RH.

>Just yesterday, I was in one and they were discussing how a series of
>check boxes were going to function on an application just being
>developed. Out of nowhere, I toss up the comment..."I'll explain it in
>the help".

See, my comment would be to find out if this new feature could be designed
so that its use was inherently understandable. Failing that, embedded
just-in-time content is preferable to content that user have to take an
extra step or two to read.

If the application can explain itself, you don't have to write as much in
explanation and users will likely not need to call technical support so
often.

-- 
--
Chuck Martin
User Assistance & Experience Engineer
twriter "at" sonic "dot" net      www.writeforyou.com

"I see in your eyes the same fear that would take the heart of me. The day
may come when the courage of Men fail,  when we forsake our friends and
break all bonds of fellowship. But it is not this day! This day, we fight!"
                    - Aragorn

"All you have to decide is what to do with the time that is given you."
                    - Gandalf