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.
Subject:Re: What would be the best approach? From:Debbie Warren <dwarren -at- DTECHS -dot- COM> Date:Fri, 5 Feb 1999 15:05:58 -0600
Suzette,
I would have a chapter about Creating Reports.
Creating Reports
To create a report:
List the major steps.
1.
2.
3.
Expand a step into another topic if needed. For example: 5. Add fields.
Your next topic could be Adding fields to your report definition.
You can have a section on field values.
I would try to stick to the "User Task perspective".
>Should I approach this in a linear fashion? Just going through the
>application, showing users how to select different values and explaining
what
>those values mean? Or should I break it down into every possible variation
of
>a report? For example, one report might be How many gift certificates were
sold
>by store within a time span, another - How many gift certificates were
redeemed
>by store within a time span, How many discounted sales took place within a
time
>span, How many times and for how long an employee opened the cash drawer
within
>a given date range, etc. The list would be extremely lengthy and would be
very
>repetitious.
>
>I tend to always like to approach a project from a User Task perspective,
but
>with an ad hoc reporting system, I suspect this might not be the best
method.
> Any thoughts?
>