Selfe and Selfe's article is perhaps the strangest we've had to read. Written in 1994, I found it woefully outdatedand in some cases, unfounded. Computers only undersatnd things in terms of 1 and 0 - on or off. Therefore, of course DOS works like a hierarchy based information structure. Did it have to? I always thought so. The technology to support bricolage-style interfaces wasn't around or too expensive (I assume, I can't really remember when Windows really caught on). Besides, the argument is irrelevant now. Nobody uses DOS anymore! We have our bricolage interface and it probably oppresses and marginalizes logocentric thinkers. Coincidently, we are now learning CSS - an interface of extreme logocentric privilege. Should we also be allowed to design our zen garden in MSPaint so students that prefer a bricolage interface are placated? Is refusing to do so undemocratic or oppressive? In any case, I think the purpose of this article is to remember to try and reach the widest possible audience when performing technical writing and Web design - you must think beyond your personal preferences and you cannot assume people are privy to the same knowledge and experience that you are.

Barton and Barton’s article is not very accessible. However, I did learn that maps are not necessarily faithful reproductions. They can be subjective. They can make people want to visit someplace, or avoid it entirely. They can also promote nationalism, superiority, and hierarchal structures. I suppose that the map we need to make for class could go all sorts of ways. I had never even considered that…

Week 8

Doheny-Farina’s article demonstrates the problems and benefits of writing as a group. Technical writers must be aware of the viewpoints and rhetoric of other members of the group and respect and accommodate them. Although these viewpoints may clash, compromise can yield a better document. Doheny-Farina goes on to emphasize this in his section on implications for teaching.

The Writing for Publication article actually iterates a lot of what I learned in WRIT 5500. I also think it was useful for TC to talk about exactly what sort of articles they look for. I imagine that it is very helpful for professionals.

Week 5

I can see myself coming back to Rude’s article in the future. So far, I think it presents the most practical and applicable theories of all the articles assigned. Just because a project is doable, doesn’t necessarily mean that it should be done. Rude brings several issues to light, including pro/con arguments versus feasibility arguments, hypothesis versus question based proposals, addressing all conceivable issues in a report, and a list of criteria for decision making. It’s an article that covers, what I think, are several important aspects of writing effective reports and proposals.

Selzer wrote a rather interesting article, but I think it is of limited applicability. Everyone’s composing process is different, so what works for Nelson may not work for everyone. Even Selzer concedes this point. However, I did think that the section on Nelson’s invention process deserves attention. Once again, we have another article that really drives home the importance of the audience in technical writing.

Allen et. al had something really interesting as well. It was pretty neat to hear different composing processes from groups of people. Although, I feel that the article is far to old and needs to be updated. I am certain that technology has introduced vast changes to the way groups collaborate on a writing project. Unfortunately, I feel that I have never been a part of a decent group project, as they have often been disorganized messes of members who cannot write well or contribute equitably. Because of that, I normally prefer to work on my own, but I am looking forward to working members of a graduate writing program.

Week 4

Driskell writes about how it is important to understand how the skills learned in other
fields apply to technical communication. One must understand the differences between the
reasoning of different groups of professionals
within a company or organization. It can serve as a primary key to anticipating the
organizations needs and use of evidence in documents produced by that group or person.
Likewise, understanding what kind of rhetorical approach to use with different audiences
is important, as members of different departments read documents differently; they read
with their experience and needs in mind.

The Rydeski article really reminded me of my days at the newspaper. Essentially, I
had to deal with two style guides: the Associated Press Style guide and the staff
manual created by the Editor in Chief before me. The format of the AP guide was
pretty good. It did a lot of the things mentioned in Rydeski’s article, including
giving one answer, not including everything, and a section on copyright protection
and anti-plagiarism policies. However, sometimes, information was difficult to find.
The part of the manual which discussed the proper way to refer to certain things
(i.e. Web sites) was well organized, but the rest of manual made information
difficult to find. It once took me entirely too long to figure out how to refer to
two different people that happened to share the same last name in a news article.
The staff manual was also really well done, and I had the pleasure of revising and
adding to it from time to time. Although it was very comprehensive, it was organized and sectioned off in such a way that made most information easy to find.

Norman’s article iterates a lot of what I’ve read about writing. Keep it simple and clear, etc. I was really intrigued by his comparison of writing and design – claiming that they are one and the same. I’ve never thought of them like that before. I’m often told that I am good at both writing and designing, so perhaps I’ve subconsciously understood Norman’s concept all along.

Week 3

Johnson advocates what he calls an “involved audience” which is exactly what it sounds like. Through examples of real world projects, Johnson shows the benefits of bringing the audience in during the development of the intended product. Even without examples, the theory seems to make a lot of sense. The technical communicator must produce a product for the audience, so it is logical that a better product would be made by consulting with the audience to determine their needs and expectations. This shows that technical communicators should be able to communicate across an expanse of mediums (writing, speaking, coding, etc.).

Johnson-Eilola takes issue with the thought technical writers as the people who merely transcribe the work of others. It was a bit difficult to understand exactly what Johnson-Eilola is getting at, but basically, he seems to be saying that learning only the basic and practical skills in technical writing is useful in getting and keeping a job, but having such sparse instruction really limits the field as a whole. He uses the example of third party technical manuals, showing how technical writers can use abstraction and collaboration to write a more complete and encompassing manual for a product. The moral here is that the good technical writers are also strong analysts. They must not only understand the technology, but they must know how to best interpret it and fit it to the needs of an audience.

Coming from a practitioner, the article by Casady is provides perhaps the most useful moral of all: no one wants to read your technical writing. In fact, they probably hate the very idea of having to read a manual or report. Therefore, the good technical writer should accommodate the user by being as clear and concise as possible. Having to read technical writing is a big enough job for the audience. They should not have to decode it as well. However, I think this is really true of any writing. This article seemed to show that engineers and developers sometime perform technical writing and transcribe everything they know in relations to their primary job function – leaving the needs of the audience behind.

These articles really remind me of Dobrin’s definition of technical writing. It really is more than just writing about technology. It is accommodating technology to the user.

All of the readings for this week are about defining technical writing. Because they all deal so similarly with the same topic, I thought it would be best to combine my writings into one piece.

I find it rather remarkable that these articles take a seemingly simple task (define technical writing and/or technical communication) and beat around the topic. Miller is mostly concerned with examining scientific rhetoric, the positivist view of science, and the role of instructors in technical communication. Her article seems to me to be less about a proper definition of the field and more of a defense of technical writing as a respectable field.

Dobrin’s forward for his article actually apologizes for the article being so awful. The article is just 30+ pages seemingly devoid of meaning or relevance. Dobrin’s discussion of universalist views, monadist views, and alternity seem to reveal way too much thinking about technical writing. However, I do appreciate Dobrin’s much anticipated definition: “Technical writing is writing that accommodates technology to the user.” In much the same vein that he manages to poke holes in other definitions, he thoroughly examines his own definition. However, in doing so he claims that his definition is not “ultimately accurate.” But, for the purposes of even the most discerning everyman, I think he got it.

This brings me to the third article by Bemer, which acts as an overview of the whole definition dilemma. Bemer makes the comment, “the academy [of technical communication], many scholars say, focuses more on theory than application. The opposite is perhaps true for the workplace.” To me, this statement is very important. Articles that are so roundabout, confusing and generally unhelpful (like Dobrin’s article) don’t help the practitioner. It seems that they are more helpful for the teacher of technical writing. The academy is supposed to train students to enter the workplace, where theory has little relevance.

I never ever imagined that technical writing had so much theory abounding in it. I really figured it to be a rather straightforward field. I hope I haven’t missed any dire points, but I feel as though there isn’t any practical use in these theories. I don’t think I could get a job as a technical writer because I could hold an in-depth discussion on the many subtleties of the definition of the fields and schisms between it and more traditional fields in the humanities. Articles like these may even be harmful. Most people (according the examples given throughout these articles) claim that technical writing is supposed to clear and objective, but Dobrin and Miller refute these claims, asserting that it’s impossible to remove all rhetoric from writing and constant use of impersonal tone is something of a paradox, etc. It seems to imply that there is no right or wrong way to be a technical writer if nearly everything about the field can be refuted back and forth. If anyone can perform technical writing any way they want, then what is purpose of teaching it?

Taking these readings into account, along with class discussion, I think that technical writers are defined by their products (manuals, walkthroughs, Web sites, reports, etc.), the products of the technical writer are created to, “accommodate technology to the user,” and technical writing courses teach students how to best produce these products.