“Today, effective “information management” is one of the great challenges to communicating effectively in the technical workplace.” – This quote really conveys the meaning behind why we are reading these chapters and why we are even taking this course. I wanted to mention how important I thought this quote was, as it really gives me reason to appreciate what we are learning throughout this course. I also found it interesting that technical documents should be approached as basically any other document; it should contain an introduction, a body, and an end. This makes sense to follow the same procedure that one would for any other document, so it even easier for our intended readers to comprehend our potentially confusing topics.
Many of different Genre’s discussed should most definitely seem familiar to most of us. We are all confronted with instructions, resumes, websites and many other reports almost daily. I have never considered that the purpose of the document would actually be the identifier of that particular documents genre. In my major we learn to organize reports using many different forms of output including pulling information from databases and reporting information via web pages, among other possibilities. Certain software, such as Microsoft Access, can be used to generate these reports in a consistent format that will most benefit the reader.
The patterns of arrangement discussed in this chapter are applicable to many of the technological documents that we will write. The Problems/Needs/Solution pattern seems the most familiar to me, as we are often asked to identify the problem in a given situation. We are then asked to identify the needs of the users and then obviously we must provide a solution. The identification of the problem is stressed as being highly important, and with good reason. Many technological problems are incorrectly identified, thus they are incorrectly solved or possibly temporarily resolved only to return in another form. This way of thinking is taught to in the Computer and Information Technology classes as root cause analysis.
Thanks!
Jason Flittner
Problems/Needs/Solution
I definitely agree with you that the Problems/Needs/Solution is probably most familiar. Not could it be something as a simple how to document explaining a fix for a problem but it could also be viewed as a budget request to fix a problem or create a project. Both of these documents are common in the IT field. Especially the budget request. What better way to convince someone to give you or your department money than to outline the problem, tell them what you need, and then tell them how you will use that money to fix a problem or even create a new project.
Andy
Agreed on the budget request
Agreed on the budget request possibilities for this type of writing, I could most definitely see how this type would be used for budget requests. The most important information for us to make sure that we include in these documents would be all of the technical information in a “simple” manner. There certainly wouldn’t be any convincing if these technical documents aren’t written correctly so that their intended reader can understand them. Interesting how these different concepts we are learning are all coming together to actually improve our abilities. It’s nice to see that in a class!
Thanks!
JFlitt
www.JFlitt.com
I Agree
Being in the same major as you, I must say that I agree with your statement that, even technical documents should consist of an introduction, body, and conclusion. It is important to emphasize that all of these be related however. Too many times I have read a paper that is discussing various routing protocols, only to randomly hear a statement to the effect of "You’re supposed to put the cheese in the quesadilla". While the concept of introduction, body, and conclusion might seem elementary to most, there are still many students who have not grasped the concept of a relevant introduction, body and conclusion.