Re: Branching procedures
I'm stuck, and I can't figure a good way out.
I'm doc'ing mainframe (ISPF) procedures that can include a number of runtime options. The user specifies input data sets and runtime options on the initial screen. Depending on the runtime options the user selects, various other screens might appear, one per option.
For example, a typical flow is:
1. Component screen, for input data sets and options (filter statements, report titles, report parameters)
2. Possible screen for filters.
3. Possible screen for report titles.
4. Possible screen for report parameters.
5. Back to the regular flow, for print options, job cards, jcl review, and submitting the job.
At first, I'd want to break out each of these possibilities into a subsection. But each of these possibilities is a stage in the process, a means to an end, not an end inandofthemselves (although that might be the best way to go).
But if I keep to one procedure flow, I get all these "if" conditions: "If you selected option X way back 12 screens ago, then this panel displays now. Otherwise the next panel appears, unless you didn't select option Y way back 12 screens ago..."
You get the idea. It's just nasty.
Off the top of my head, how about the following:
Have one long procedure flow.
Where the possible screens depend on the configuration (items 2, 3, and 4 in your list), use a table instead of prose.
Intro paragraph for table could be along the lines of "The filter screen differs depending on the options you selected in step 1. See Table X. "
Table X. Possible Filter Screens
Configuration Option Filter Screen Description
X Screen X Blah blah blah
Y Screen Y blah blah blah
The first column of the table would be the option chosen in step 1.
The second column would be the screen displayed (either a picture of the screen or the title of the screen).
The third column would either be an explanation of the panel or, if the descriptions are too cumbersome, a cross reference to a subsection where it is described.
Visit TechWhirl's Other Sites