When I first began reading Solving Problems in Technical Communication, I was immediately struck by Johnson-Eilola and Selber’s comment that “[t]echnical communication is no longer simply communication about technology; it is also often communication as and in technology” (1). This statement concisely shows that the field’s focus has changed over time, or rather it has expanded to include additional dynamics in the relationship between technology and communication. Dynamic, I think, is an important word to describe that rapidly evolving relationship to which technical communicators must adapt. If “the only constant in the field is change,” then adaptability is the most valuable skill a technical communicator can have outside of his/her expertise (2).
Like writing (and research), technical communication is messy and recursive, and there are a number of problem situations to which technical communicators must return and revise their heuristic before trying again. A great deal of thinking about the problem situation is involved, which is why heuristics makes so much sense as a framework for going back and forth between theory and practice. I haven’t had much experience with heuristics (other than washing clothes, perhaps), but the heuristic used to organize the book forced me to frame my own understanding of technical communication through the answering of questions in each quadrant, which was very helpful to me.
The text cloud heuristic described by Selfe and Selfe in Chapter 1 was, well, quite fun to work through. Knowing that this chapter was written by technical communicators made me even more conscious of the creative choices used to present the heuristic. The first three steps are concerned with identification, which leads me to think that much of the front-end work is largely constructed by thinking rhetorically about context, purpose, and audience. In other words, the first few steps involve thoroughly understanding your goal and the process you will use to arrive there (or rather the problem you will attempt to solve). With research, the interpretive part is, I think, the most fun, and the text cloud is a great example of visualizing the frequency of and relationships between particular terms and the patterns they reveal. Selfe and Selfe observe that the text cloud and other visual presentations help technical communicators (and their “user” audiences) to make sense of large datasets (41). Infographics are one example that has become increasingly popular (and creative) over the years, and there are now a number of free, web-based tools for creating them with ease, using a simple UI. I assume that text cloud generators are probably easy to find and use as well.
Hart-Davidson describes three work patterns of technical communicators: they “work as information designers,” “user advocates,” and as “stewards of writing activity in organizations” (51). I liked the author’s heuristic for technical communicators to become better user advocates. They should constantly reevaluate their work based on the intended users/audience, and if possible, get them involved in the process and listen to them closely (62). This kind of close involvement, however, does require strong curating/organizational skills, but what are common methods for keeping such content collections organized? The user forum mentioned in the example (62) provides little context for how this might work, so perhaps this is something we can revisit in class. But I am definitely adopting Elena’s user-advocacy work patterns as my new office pin-up poster: “listen, participate, curate, create” (66).