Friday, November 9, 2012

Reading Reponse #11


I think the reason this article bothered me so much is that it just seemed as though the authors were a little sensitive towards gendered views of technology. There are so many women in technical fields (and in technical writing) that at this point in time the point Gurak and Bayer seemed to be trying to make seems a little moot. I honestly thought the article was a little too opinionated, but maybe that’s because I’m still having a little bit of a hard time trying to get my head around the idea that technology isn’t as neutral as I thought.

The keyboards were a good example of this. I hadn’t really thought that they were geared towards a specific, Arabic-alphabet using audience, but they definitely are. Keyboards are just one of those things you think of as being pretty standard worldwide. But if that’s not the case, then there is a lot of room to argue that technology can also pander to gender—either for good or bad.

That’s not to say I can entirely dismiss the article, either. It does raise some interesting points, especially when it looks at technology through different feminist lenses. Because there is a huge difference between, say, radical feminism and liberal feminism, ideas about femininity and technology in these two camps are going to be very diverse.

When compared to the book, I don’t really see a lot of room for feminism. As was said in class, the textbook is really just meant to be an overview of what technical communication is, what it encompasses, and how to approach while being both socially and culturally sensitive. In the case of this last element, though, there might be room for feminism. I’m also taking a grammar class this semester, and during one class it was mentioned that it’s more appropriate now to use “he/she” rather than the historically used “he” to be more gender-neutral and all-encompassing; it’s a common thing to see in most textbooks now.

It all seems to hinge on knowing your audience. If you know your audience, it usually isn’t too hard to figure out how to word things specifically for them, or how to write something so that it’s easy to understand.

Thursday, October 18, 2012

Reading Response #8

 
For Project 3, I originally planned to use an A3 report format for my topic because I thought it would be an efficient way of displaying all my information. However, after I started doing the research, I realized that a white paper would be better because of all the medical information involved. Because I figured a lot would go into the makings of a cure for the zombie plague, the length of a white paper would benefit the project more by being able to offer more than an A3 report could.

Because of the way a white paper can be divided up, I can neatly display all my information (such as how to implement the cure, how it works, etc) and set it up in chapter-like sections that are informative but brief. It was also easier to work in pictures and maps in the white paper than it would have been with an A3 report, which has a limited amount of space that can be taken up.

Overall, I think switching to a white paper format was a good decision.  Information, while there is more than I could have fit onto an A3 report, is still easy to find despite the fact that there is more detail. I think the project turned out well!

Thursday, October 4, 2012

Reading Response #7


When it comes to writing an informal white paper, there are some conflicts. White papers are meant to be a little longer than a typical informal report, which often involve a lot of summarizing and focusing on the general picture. White papers tend to look more at the specific aspects of a product, government policy, etc. In order for me to write a white paper that deals with an informal subject, I will need to find some kind of balance between summarization and providing enough detail to my audience.

On the subject of audience, white papers have a very technical audience—in my case, I’ll be writing to people who want to cure the zombie virus and are looking for a feasible medical cure that my company can provide. However, informal reports are, as I said previously, very general, and it can be hard to determine who exactly the reports are aimed at. However, I think in terms of my project, I’ll have to bypass generalization entirely because my topic is too specific.

Beyond these, though, I feel that the list we made comparing informal reports with white papers complement each other fairly well. Providing a clear subject line will be no problem! Focusing on a solution is easy, too—that’s what my project is all about. A division of strategy in terms of what will be done in a treatment for the virus will likely involve several steps, as will a strategy to implement the treatment.

White papers also focus on feasibility, and I’ll be able to work on that as well. I’m also looking forward to working with visual rhetoric in my white paper, because it’s not really something that’s a part of informal reports (which are usually just plain documents).  Using pictures is a good way of attempting to keep the audience’s interest while at the same time making sure they stay informed about what’s happening in the white paper.

Overall, I am fairly confident that I will be able to write a white paper on an informal subject because the two categories we looked at in class today fit together with relatively few problems. Those problems we did run into are easily taken care of in terms of my project topic, and I feel good about starting my project.

Friday, September 28, 2012

Reading Response #6



Being able to communicate well is essential in technical writing. Ornatowski argues that writers who can’t effectively communicate to others could perhaps end their careers—it’s that important! Writing is vital to pretty much every type of organization on the planet—it allows people to talk with one another, get ideas across, and everything in between. Even if only a handful of people in a particular organization do not know how to write and communicate with others, there are going to be problems.

Similarly, ethics play an extremely important role in communicating in technical writing. It can be hard finding a balance between giving information to people (clients, bosses, etc) that is practical, but is also ethical in that it carries the proper warnings, alerts, and whatever else might be needed to ensure that these people can carry out the practical aspect of the technical writing while at the same time staying safe and adhering to those safety rules.

This fits into project three because we’re producing A3 charts, white papers, and quad charts. All of these are means of communicating with people, each with its set of advantages and disadvantages, depending on the project. For an example to bring to class, I printed off a template for an A3 chart that’s divided into several different sections. These include things like “Theme”, “Problem Situation”, “Target/Goal”, “Cause Analysis”, “Countermeasures”, and “Implementation”. All of these categories are important, and at the same time allow the user to communicate effectively with the people who will be reading the A3 chart. Since an A3 chart is divided up into these different sections on one page, it’s easier to see warnings, potential problems, etc, than if the writer was using a white paper or a quad chart to convey the messages.

Thursday, September 20, 2012

Reading Response #5

What did I learn from usability testing, beyond how to make a grilled cheese with an iron? Well, I learned that it’s extremely helpful! By doing usability testing, it becomes much easier to iron out (no pun intended) any kinks in your instructions. By sitting with someone and watching them while they run through your manual, you can see where things go wrong or have the potential to go wrong.

Because we weren’t doing anything particularly dangerous in class, there wasn’t really any chance that things could go drastically wrong, but when applying usability testing in the real world, it becomes extremely important to write instructions that are clear and simple to use. If you’re trying to fix, say, some kind of farm equipment, especially anything with blades, there’s a real potential for serious injury.

Or, in another example, if you’re writing instructions for children, it might be necessary to write instructions that are oversimplified. Because adults can understand something doesn’t mean children necessarily will. If it’s a recipe that involves baking or something that needs a little more care to be done, then the audience (children) really need to be kept in mind. Warnings also become significant in this case, if knives or ovens or any number of kitchen tools come into play—adult supervision or help becomes part of those instructions, because, again, injuries could occur.

I also learned that pictures go a long way in helping to detail how to put something together. They’re not always needed, but they do come in handy when putting together a lengthier project or if something’s a little more difficult. This way, you can check your work against someone else’s and determine whether or not you’re doing it right.

Thursday, September 13, 2012

Reading Response #4

In terms of writing for instructions as opposed to a brochure, the language needs to be clearer. There need to be warnings, precautions, etc, that basically protect the writer of the instructions in the case of injury on the part of the person carrying out the instructions. Instructions also need to be accurate. All technical writing needs to be precise, but instructions all the more so, especially if they detail something that could be potentially dangerous.

The manuals that people brought into class were interesting, especially the one for wearing the bike helmet properly. All that information, just for a helmet! It’s funny, in a way, the lengths to which writers need to go in order to ensure they won’t be sued.

Instructions also need to be written with design in mind. A lot of manuals—in particular those from IKEA—seem to consist of nothing but pictures. At least, this seems to be the case to me. When I moved into my apartment a few weeks ago, all the furniture I brought with me needed to be put together, and all the instructions were written in diagrams. If there were words, they were only to explain what part was what or what number to call if I was having problems putting something together. They weren’t always clear, and they were sometimes hard to understand. If instructions aren’t designed with flow and clarity in mind, then no one will be able to understand them.

On another note, it’s interesting watching Helvetica from a technical writing standpoint. I first watched part of the film in a graphic design history class, and I loved it. Now, though, applying it to technical writing makes it even better. We studied type a little bit as a part of graphic design history, and it was probably one of my favorite topics. It’s amazing the difference a typeface can make on a project—there were a few times when it was the difference between a great project and a mediocre one. Typeface has an influence on instructions in particular because being able to easily read what you’re supposed to do is as important as being able to understand the diagrams that accompany the words.

Thursday, September 6, 2012

Reading Reponse #3

After working on the brochure project this week, I’ve learned a little more about visual design. Because I’ve taken a few graphic design classes, a lot of what I’ve already learned goes along with the newer things that cropped up this week.

 I knew about typeface vs. font, the importance of color, and other visual elements of design. I’ve done dozens of projects that focus on these particular aspects, but the interesting part this week was applying those concepts to a more technical design. I’ve done websites, DVD covers, maps, and even food containers, but those have always been geared more towards graphic design. A brochure can easily be considered graphic design as much as technical design, but for the purpose of this class I know that it was to help us familiarize ourselves with what technical communication is, and how design can sort of insinuate itself into it.

 Because so far, it seems to me that technical communication and graphic design can often be one and the same. Visual design is as important as writing when it comes to technical communication—if you don’t have an eye-catching design, it’s pretty likely that no one’s going to want to look at your work. It needs to be well-done, appropriate to your topic, and clearly geared towards a specific audience. The same goes for writing: if an instruction manual, for example, is written all over the place with no rhyme or reason (or if it doesn’t have pictures to illustrate), it can be confusing and off-putting. No one wants to look at it, and, well, that could spell disaster for your furniture.

I feel like I’m already getting a lot out of this class because now I’m going to start looking at these projects with a technical eye as well as a graphic one. In graphic design, we always had to do research before we started a project to make sure we knew what we were doing, and we had to write up a fake memo each project that explained who our audience was and how we were going to market our product. Beyond that, time was usually spent making things look as graphically eye-catching as possible. Writing was never quite as big a deal. In this class, it’s easy to see that the writing is at least as important, if not more, than the graphic elements.