> 1. It's not just that people aren't familiar with flowcharts; many > people simply can't follow them at all... And of those who CAN follow > them, only a few can LEARN from them. The same can be said for written documentation. It seems that a bad flowchart would be as effective as a bad procedure and a good flowchart would be as effective as a good procedure. Written words don't guarentee anything. Now, not be familiar with it could be a serious problem. So, perhaps this becomes a question of the target audience.
> 2. Numbered steps can be typed up and emailed, or easily read over the > phone. It's hard to communicate the structure of a flowchart without > either translating it into a list of numbered steps or finding a way to > send the picture. All very valid points. There is certainly a benefit from typed steps as far as quick transmission in email goes. But the same objection can be raised about any image, not just a flowchart. I don't, however, see any difference between reading the steps from a flowchart and reading written text over the phone. > 3. A flowchart's thin lines and tiny arrowheads are likely to be > obliterated the first time it's faxed anywhere. The same could be said for doucmentation that uses a small font size. This is just a formatting issue that can be taken care of with good planning. > 4. People with poor vision may not be able to see the arrowheads > anyway. Blind people can't use flowcharts at all. Small arrows is a formatting issue that can be easily avoided all together. Blind, on the otherhand, is a very valid point. > 5. If I have a list of numbered steps, I can call Tech Support and > unambiguously tell them, "I'm on Step 5." Formatting issue that can be easily avoided by numbering the boxes. > 6. Similarly, it's hard for you to write about a flowchart, so you > won't easily be able to explain in a companion paragraph anything about > specific steps in the flowchart. I don't know about this. In the software designs that i've done, it was very easy to write about steps. It's a matter of format and presentation made all the easier if those steps are numbered as mentioned in #5. > 7. Words can convey SO much more than flowcharts... With words, you can > explain WHY the reader's doing something; flowcharts generally can't > even explain WHAT to do in any sort of detail, since everything has to > fit in those little boxes. This gets into the meat of what the procedure is for.....very basic "this is what you do" steps or more in depth steps that explain what's going on. Still, this issue seems to be related to #6 and so a similar solution should work, right? And, to be a little evil (hehehe), do we really need to convey SO much more? What about conveying only what is needed and then picking the correct tool to convey that information? Words are not always the best way to do this. > 8. The text in your flowchart might not be visible to computer search > engines, so Google won't find it if you publish your document on the > web, and readers might not even be able to use the search tools in their > PDF readers or help systems or whatever to find it. Hmm. Now that's a very interesting point. I hadn't even thought of that. It sounds like I'll have to try a little experiment. But, this point is only valid if you are publishing electronically and over the Web. Don't the same problem arise with graphics, diagrams, schematics, and so forth? How do you avoid the problems you mentioned with other image-based information? Would not those solutions then apply to the flowchart? > 9. If you DO decide to draw flowcharts, keep the structure rigorously > consistent and as simple as possible, Of course. :-) This all goes to good flowchart design in much the same way that one would have to exercise the same rigor for a good document. I'm not talking about slapping together a bunch of shapes and lines all whilly-nilly. The flowcharts would be documentation and as such would be held to same standards of clarity, concision, and accuracy as the written word. > 0. Have your readers already complained that it's difficult to follow > your complicated procedures? I am not even a technical writer any more, I'm a business analyst. So this entire discussion is theoretical. The readers of the documents that I produce, however, expect diagrams like flowcharts, activity diagrams, dialog maps, and so forth. Which is what got me thinking about this in the first place. I do like Jon's point about using the flowchart to understand a complex process and to discover possible routes that could not be seen before. For example, if you must document the results of every decision, you're likely to find results that you would not have thought about if you were simply writing out the steps. The chart itself forces you to think through all outcomes. Thanks for the very detailed response. I'll have to mull over some of these points. Cheers. ******************************************** Sean Hower - communications specialist http://www.seanhower.com _____________________________________________________________ Create your own web site for FREE at http://www.freehomepage.com _______________________________________________ Are you a Help Authoring Trainer or Consultant? Let clients find you at www.HAT.Matrix.com, the searchable HAT database based on Char James-Tanny's HAT Comparison Matrix. Contact [EMAIL PROTECTED] for details. Interested in Interactive 3D Documentation? Get the scoop at http://www.doc-u-motion.com -- your 3D documentation community. _______________________________________________ Technical Communication Professionals To post a message to the list, send an email to [email protected] To subscribe or unsubscribe via the World Wide Web, visit http://techcommpros.com/mailman/listinfo/tcp_techcommpros.com or, via email, send a blank message [EMAIL PROTECTED] Visit the TCP site at http://www.techcommpros.com To find out more about the list, including archives and your account options, visit http://techcommpros.com/mailman/listinfo/tcp_techcommpros.com If you need assistance with the list, write to [EMAIL PROTECTED]
