Issues:
Summer 2004
|
Sharing Examples of
Information Design Awareness
from Various Fields & Experiences
This journal is an effort to showcase and share the learning of
students taking
Principles of Technical Communication
at Eastern Michigan University. The articles
presented here are from a multi-genre project, and are repurposed versions
of either a technical definition or a genre analysis, designed to detail
an aspect or document from a particular field, in context inside the field,
but also to suggest/explain the relevance of the topic for an
audience outside the field.
Technical Communication is
Information Design, and Most of Us
Never Understand We're Already Doing This, or How Important it is to Our
Future Success
As we've learned in class, Technical
Communication means much more than knowing some basic formats (genres)
of common documents. It means understanding that all forms of communication
are designed (or at least once were) -- they are, in effect, tools --
for use by specific
audiences for particular purposes. The fact that they are relative
to particular situations points out their
rhetorical nature. In
this class we've learned to become much more conscious of our own
processes of development in "writing" documents. In fact we now
realize there are whole phases of development we never counted as
part of "writing". We now understand there is a process of: 1) analyzing
the "rhetorical situation," 2) "inventing" ideas of how the text can
do what the reader needs it to do, and 3) "testing" the resulting design
with readers/users. Further, this is a
recursive
process, meaning we go
through it over and over again (Lather, Rinse, Repeat),
building improvement almost in layers.
Sharing Our Learning: Showing our TC Awareness
Our articles in this webzine attempt to do two broad things: 1) explain
the function of a concept or genre in a field we're in (insider view), and then
to 2) analyze or explain how or why they work the way they do (outsider view). The latter
is of course what we've been realizing in 324, that documents are
designed, and that they actually "function" for or with people, helping
them to do particular tasks. But how or how well they work is a function
of the match between the particular circumstances of use and the design
of the document. That is, a hammer does or doesn't work so well at
putting in screws because particular design decisions, or expectations
of how the tool would be used. The goal for our articles is to first
describe the hammer and the situation, so to speak, and then to discuss/analyze
how or why it gets used in this situation. We're showing both our knowledge
of our particular field, and how TC allows us to share and make sense of
the practices of that field.
|