re: externalizing help customization

Subject: re: externalizing help customization
From: Sean Hower <hokumhome -at- freehomepage -dot- com>
To: "TECHWR-L" <techwr-l -at- lists -dot- raycomm -dot- com>
Date: Fri, 23 Jul 2004 06:46:42 -0700 (PDT)



--------------------------------
Hannah Gilberg wrote:
Our company is creating a web-based application that will interface with
any customer's data model. How fields and pages are named, basic
business rule, field behaviour, etc. will be configured by editing a
handful of XML files. Some basic workflows will remain constant,
regardless of configuration, but it is possible that every procedure
will need to look different from one customer to the next.
Any thoughts??
--------------------------------

We're dealing with a similar situation. I would focus your documentation on only those things that will always be present or needed or done. I don't know what kind of application you are dealing with, but if it has required fields or required settings, focus your procedures on those and then explain, somewhere, that depending on the client's config there may be additional steps.

I would provide field-level (context-sensitive, bubble, or embedded), "page-level", and very high-level information. You would tie the field-level and "page-level" information directly into the application, that way if your client doesn't have some piece of interface, they won't get the help for it. The very high-level information should be general enough so that it is still applicable to a client's config, but not so general that its usefulness. Where the balance is will be up to your docs team to decide, but it's an important balance to make.

None of this requires XML. Any HAT will allow you to create context-sensitive help. It does require a lot of planning and understanding of both the GUI and how teh application actually functions (behind the scenes). If you understand when, where, and how the applicaiton is configured and performs its tasks, you'll be in a better position to understand when, where, and how to break up your information for delivery.

If you go the XML route, how will you ultimately display it? If you're looking to do client side transformations, you just limited yourself to two browsers. This may or may not be an issue for you, but it's something to keep in mind.

I think I've rambled enough.... :-)

********************************************
Sean Hower - tech writer
http://hokum.freehomepage.com


_____________________________________________________________
Create your own web site for FREE at http://www.freehomepage.com

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

ROBOHELP X5: Featuring Word 2003 support, Content Management, Multi-Author
support, PDF and XML support and much more!
TRY IT TODAY at http://www.macromedia.com/go/techwrl

WEBWORKS FINALDRAFT: New! Document review system for Word and FrameMaker
authors. Automatic browser-based drafts with unlimited reviewers. Full
online discussions -- no Web server needed! http://www.webworks.com/techwr-l

---
You are currently subscribed to techwr-l as:
archiver -at- techwr-l -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.



Previous by Author: Re: administrate vs. administer
Next by Author: OT - British English question
Previous by Thread: RE: externalizing help customization
Next by Thread: Re: externalizing help customization


What this post helpful? Share it with friends and colleagues:


Sponsored Ads