How do you prefer to deal with long flowcharts?

["Hart, Geoff" <Geoff-H -at- MTL -dot- FERIC -dot- CA>]

Shauna wonders <<How do you prefer to incorporate long, complex, branching
flowcharts in a document, when they won't fit on a single page, legibly?>>

We used to deal with this all the time in biology (e.g., dichotomous keys
for typing plants) and ecology (e.g., site classification via dichotomous or
higher-order keys). The basic principle is the same in both cases, and
applies equally well to flowcharts of other kinds: analyze the sequence so
that you can identify individual chunks that all belong together in a single
sequence, then present each chunk on its own page. This is, of course, an
iterative process, since your first cut rarely fits elegantly on a single
page, and you have to repeat the analysis to subdivide it. And sometimes,
you can reorder the flow to make it better fit the page, though that's not
commonly the case.

<<In my example, one such flow is describing program logic as part of the
detailed design document; it spans three portrait-oriented pages vertically,
if cut into chunks.>>

Of course, sometimes you really do want "the big picture". In this case,
we've occasionally produced a foldout page that contains the entire diagram
on a single sheet. The page must be large enough for legibility, of course,
and that sometimes means it won't fit into the standard page sizes. In that
case, we've sometimes resorted to adding a "map pocket" to the publication,
and inserting a larger folded sheet at the back of the book.

Now that we can move such things online, it sometimes helps to think
laterally and try an online solution. Something like a zoomable PDF file can
work very well, particularly if the initial stages of the flowchart use
large enough type to be read at "fit in window" size, and zooming in reveals
the progressively smaller type used for subsequent lower-level steps. A
collapsible hierarchy such as the one used in Windows Explorer can also work
in some cases. An HTML hierarchy might also be very effective, provided you
leave a trail of "breadcrumbs" to show users where they are in the
hierarchy. Would these approaches work well for those who will be using your
product day in, day out?

<<Do you just cut them into pieces, cropping the graphic wherever the page
would break it?>>

Never. Crop it based on functional divisions that meet user needs.

<<Do you try to impose a rule on the Developers to make their flows fit on a
standard page>>

Ah, the Procrustean approach. <g> Nope, try to work with the reality as
you've been shown it rather than trying to cut the reality to fit your page
size.

--Geoff Hart, geoff-h -at- mtl -dot- feric -dot- ca
Forest Engineering Research Institute of Canada
580 boul. St-Jean
Pointe-Claire, Que., H9R 3J9 Canada 
"User's advocate" online monthly at
www.raycomm.com/techwhirl/usersadvocate.html
"Science is built up of facts, as a house is built of stones; but  an
accumulation of facts is no more science than a heap of stones is a
house"--Jules Henri Poincaré 


^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Check out RoboDemo for tutorials! It makes creating full-motion software
demonstrations and other onscreen support materials easy and intuitive.
Need RoboHelp? Save $100 on RoboHelp Office in May with our mail-in rebate.
Go to http://www.ehelp.com/techwr-l

Free copy of ARTS PDF Tools when you register for the PDF
Conference by May 15. Leading-Edge Practices for Enterprise
& Government, June 3-5, Bethesda,MD. www.PDFConference.com

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