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.
--------------------------------
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.
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.
