Tagged: Jargon

Technical Communicators and Diagrams

Last week, when we discussed methodological practices, and their value in fields like Technical Writing/Communication, I came out of our class meeting skeptical about quantitative methods. Though I thought it was (and is) important for technical communicators to understand scientific language, I didn’t think they necessarily needed to throw engineering jargon, or anything like it, at the audiences reading their technical documents; worrying too much about quantitative methods, then, when discussing technical communicative practices – which I’d hoped would focus on removing the scientific and anything jargon-like as often as possible – seemed like more effort than it was worth.

It didn’t help, either, that when I began this week’s readings, I found that we were reading Flower’s and Hayes’ “A Cognitive Process Theory of Writing”, a piece that’s maligned amongst much of the pedagogy literature (Berlin, for example) I have read in ENGL 609. I myself don’t mind reading criticisms of cognitive rhetoric, or of anything that has to do with cognitive psychology. As Faigley reminded me:

“The idea that thinking and language can be represented by computers underlies much research in cognitive science in several camps, including artificial intelligence, computational linguistics, and cognitive psychology” (533).

Each of these “camps” would fall under the “Computational Cognitive Science” umbrella I learned about in classes at a previous program, and the limitations of that area of cog sci (“computational models are relatively rarely used to make new predictions” about behaviors since they can only mimic human ones [Fundamentals of Cognition 11]; computational models don’t account for humans’ “conflicting motivational and emotional forces” [Fundamentals of Cognition 12]) are items I’m always fond of mentioning.

There is something to be said, though, for having, as Charney advocated, some uniformity in research. As Slattery writes, in “Undistributing Work through Writing”, “a research methodology grounded in the study of writing can be a fruitful way to examine individual workers’ practices” (312). The idea of grounding (or couching – I like that word because it reminds me of days, before graduate school, when I had free time) any research in something recognizable, like a methodological framework, aids those who sincerely wish to test that research so they can either refine it or rip it to shreds. And Flower and Hayes, as Faigley mentions, helped to make research about the writing process more scientific, applying the conventions of another field to the field of composition in an effort to “springboard for further research” by others through “testable hypotheses” (Flower and Hayes 366).

That Hart-Davidson, Spinuzzi, and Zachry would write that Flower and Hayes’ work, which not only provides testable hypotheses but argues that the act of writing is driven by goals (366), would be rejected by practitioners blew my mind. When I refer to practitioners, I mean writers that “might have [questions] like: ‘what kinds of things have I done that lead to a successful outcome?’” (Hart-Davidson, Spinuzzi, Zachry 73). I would assume that such writers would appreciate Flower’s and Hayes’ work. The comment in the paper by Hart-Davidson, Spinuzzi, and Zachry about the need for visual conventions left me a little dumbfounded, too. Those authors call diagrams like the one based on Flowers’ and Hayes’ theory “high-level, abstracted views of writing processes” (Hart-Davidson, Spinuzzi, and Zachry 72), but diagrams like that seem fairly common to fields like engineering and information science – fields in which, from what I understand, there are two things:

  1. Lots of cognitive theory (I came across “information architecture” and “knowledge management” a few times as I was reviewing my assigned journal for Tuesday’s presentation), and
  2. Lots of technical writers.

I found a few examples of similar diagrams online through Google:

Some conventions I can point out amongst these visuals are: Arrows, boxes, characters denoting words that look a lot like jargon, and a lack of color.

How do some technical communicators succeed in their field if they can’t handle those visuals? I’m not saying that it’s easy to understand those diagrams for me or anything, but shouldn’t technical communicators be better about handling these diagrams than the average writer?

 Works Cited

Faigley reading

Flower and Hayes

Hart-Davidson, Spinuzzi, and Zachry