Wednesday, January 28, 2009

Reading #3

Norman talks about the necessity of simplicity in writing and designing. I think that he has many valid points that should be heeded. It is better for a writer to make things easier to understand, less complex and not so difficult to grasp the concepts and ideas in his/her writing(or program). He argues that it is for the greater good for an author/designer to go to the trouble of making their writings/programs easier to understand because many people have to read or use their writing/program. If they do the work then the reader/user won't have to work so hard. This will eliminate a lot of wasted time, effort and misinterpretations if ideas are not easily interpreted.

Norman goes on to discuss the fact that many writers/designers think that unless something is not complex then it is not profound. If the readers/users do not take the time to understand something then they don't reserve the right to understand/use the writings/programs. I agree with Norman that simiplicity is the answer. I have read a few books that explain complex ideas in understandable terms and I think that just because you make something easy to understand doesn't make you loose the value of the idea, in fact it helps you to appreciate it even more.

A perfect example of how beneficial simplicity of writings/programs can be is the Ipod. The Ipod is the best selling mp3 player out there. Many people don't even know too much about the other options. True, there are a few other mp3 players that are getting a little more attention now, but overall the Ipod rules. And why does it rule? It's because of it's user-friendliness. The designers of the Ipod had the users in mind while designing, and it shows. If every desinger/writer took as much time in making things more simple, then their programs/writings would gain more appreciation.

Wednesday, January 21, 2009

Users as Designers

The reading for this past week was interesting. It basically focused on how technical communicators (writers) should view their audience/users when writing/designing. The audience should be viewed more as part of the work, by asking "how would the user see this?" or "is this easy to understand?" or "would I know what this terminology means if I was an average joe?"

In fact the readings suggest that technical communicators should not only try to see things like the users would but actually involve the users in the writing/desing of their projects. In the readings many examples were used to show that this idea is beneficial. When the students at UM involved users by creating surveys and trial programs for the users the feedback was very helpful in deteriming what should and should not be added to/taken away from/changed to in the product.

The reading also talks about how difficult it can be to stress the value to coworkers about using users feedback in the actual design or modification of a product. Many designers, engineers, managers cannot see the importance or necessity for "dumming down" what they see as easy to understand. This is a roadblock that technical communicators often face but it is also something that many technical writers today are willing to fight for since the results of using users to help modify products has been so positive.

Wednesday, January 14, 2009

Reading Journal Entry #1

In the reading 'Technically it's all Communication...' the topic of why technical communication has no formal definition, or at least no definition that seems to encompass everything included in technical communication, is hashed out. When the writer of this article tries to explain to others outside her field what her major includes, they look at her confused or ask more questions such as, what are you going to do with that degree. The writer points out that this is a problem, not only for academe but also for those who become professional technical communicators.

The writer shows that without a specific definition, technical communicators may have issues with the amount of respect they recieve at the work place. They also could be given odd jobs that have nothing to do with technical communication, simply because no one is sure what technical communicators are supposed to do. The problem springs from the fact that technical communicator's jobs change and evolve with the progression of technology, so the definition must also evole. Also, technical communicators do many different things so it is hard to pinpoint in a short, clear definition all the different areas of technical communication.

However, despite these problems it seems necessary, and in the best interest of technical communicators, to agree upon a defintion for their field. The definition must be broad not vague and easily understood. It must also be updated as technology progresses, but as the writer points out, who would be better to continuously update the defintion of a technical communicator other than technical communicators themselves.