Lisa Grimble
(lgrimble@emich.edu)

Portfolio Introduction
Course Overview
The name of this course, "Writing Computer Documentation", is deceiving. Although it states plainly what students will be expected to do (write computer documentation), it doesn't mention "how". The main focus of this class was the "how".
By "how" I don't mean learning and applying a certain structure or using a specific desktop or web publishing program. It goes much deeper than that. The "how" refers to the focus of the documentation itself.
This course taught task oriented, user centered writing. One way was to create manuals that adapt the software to the user's task, not the other way around. If done effectively, a manual written in this manner will explain and show the connections between the users task and the software program. Another way was to create and conduct a usability shootout to see if selected website incorporated this "user first" approach to their writing.
The goal of this class was to help the student view computer documentation (both paper and online) in a nontraditional way. We were asked to focus on the users task (a certain technical communications skill or concept or an actual college technical communication assignment) and frame our work around that task while at the same time teaching software steps and procedures that represent just one means to this end.
The course work and the resulting projects appearing in this portfolio illustrate this goal.

How I fit into this
I am a first year (first term) graduate student in the Professional Writing program. The concepts taught in this class was all new to me. Although they make sense in theory and by example, they were hard to apply. Believe it or not, I have written software documentation before as part of a training program I helped lead at a past job. Reflecting on that manual now and armed with this "new" way of thinking, I see where my coworkers and I could have vastly improved the documentation and (most importantly) it's reception by its intended users us we had used a task oriented approach. We just listed steps for the users to follow and didn't explain how to fit them into day to day job activities and functions. Had we done this, the blank stare, apprehension, and resentment may have been non-existent or at least toned down.

In closing
We learned that effective documentation teaches rather than trains. Fighting against the flow of traditional thinking in this arena was not easy and still won't be when this course is completed. Taking this concept from the classroom to the real world will be even harder. But seeing how in many ways task oriented documentation succeeds where software centered documentation fail should make the struggle worth the effort.

The Team Print Tutorial: Creating Graphics - Illustrating for Purpose

Contextualizing the Print Tutorial Project

Students worked in pairs or groups of three to create a print tutorial. The tutorial was to be task oriented so that it not only taught software steps and features but more importantly taught or reinforced a communication skill. Each group chose their own topic. Students were required to prepare an overview, user scenario, program steps, and a conclusion. Designing the tutorial layout was also part of the assignment..

Reflecting on the Print Tutorial Project

Preparation
Leading up to this first major project, the class was assigned two smaller scale tutorials regarding computer mouse usage. The first mouse assignment was given before any readings in task orientation were assigned. During peer review, we learned that all of us take for granted the users knowledge base and intentions and make assumptions that shape our manuals. After this peer review, class discussion, and related readings, the second mouse manual was assigned. This time we were to use a task oriented approach to teach a defined user how to accomplish a specific task. During peer review and class discussion, I found that framing the tutorial to the task created a more effective tutorial. Having a narrowly defined user and task helped me avoid the assumptions made in the first manual.

Deciding on a topic
The class brainstormed (for what seemed like forever) to come up with good tutorial topics. Common tasks required to complete assignments in other technical communication classes seemed the most applicable. My group chose the idea of creating graphics within a document.

Layout
Each student evaluated layouts from traditional published tutorials in an attempt to see first hand what design elements work well and which don't. We shared this information with each other and then created a layout for our own tutorial based on this information.

Overview and Scenario Development
We collaborated as a team to create a realistic scenario for a student that needed to incorporate graphics in a report. The scenario itself was simple to create. It was the "why", the concept behind using graphics in the first place, that was difficult to explain. I wanted to just say "because it helps the reader and looks good", but that didn't get to the root of the issue. I learned that explaining why a technique is effective is harder than actually teaching the program steps! After much revising and contemplation, I feel we have covered the bases. Within the scenario development, we had to consider two separate sets of tasks - one set strictly for the user and one set for the program itself. User tasks focused on the rhetorical problems. Once these tasks and problems are defined and answered, the program steps almost naturally follow in a way to aid the user in completing their overall task. To me, it seemed that once the agonizing over the scenario and user tasks was complete, the creation of the program steps was a breeze. It almost came as an afterthought when; traditionally this section is the "meat" of any tutorial.

Program Steps
We chose to section/chunk the steps into manageable pieces. We numbered each step and provided computer screen shots where it seemed a graphical representation would reinforce the information given or validate to the user that she was following the steps correctly. I decided that providing "global" uses (signified by a text box proceeded by a globe graphic) would highlight the implicit usefulness of the actions while a plain text box explained the program sections as they pertained to the specific task at hand.

Conclusion
Writing a conclusion made me rethink the purpose of the tutorial and reread the text itself to see if we got our point across. In our original draft, we didn't even include one. The conclusion, though, is a good way to circle back to the overview and reinforces the conceptual method relayed throughout the tutorial and should be included.

Final Thoughts
This was a difficult assignment as I was asked to look at a computer manual and technical communication in general, in a totally different way that I ever had before. It took a good month and a half for the task oriented approach to finally "click" in my head. Once that happened, I finally understood why you (Professor Benninghoff) pushed us to question our scenarios, presumptions, and even topics. I was very frustrated with this process (to say the least) until one day I finally understood. I feel our final tutorial relays this understanding.
This now ingrained task oriented approach has prepared me to look at all forms of technical communication from two perspectives - the writer and the user. Keeping these dual focuses in mind will work together to shape me into a more effective technical writer in the future, both in school and professionally.

The Individual Online Tutorial: Project Title

Contextualizing the Online Tutorial Project

Students were assigned the task of creating an online tutorial. The students were to use HTML to layout, write and post their tutorials on the internet. The tutorial had to be task oriented with a defined user class.

Reflecting on the Online Tutorial Project

Preparation
The class brainstormed for ideas and during this process it was decided that the tutorial should involve a task that must be completed online. A lot of ideas were thrown about. I chose utilizing styles in HTML using a typical English 424 student as my user and an actual English 424 assignment as my task.

Layout
We mocked up layouts on paper to get a feel for how we wanted the online tutorial to look and function. I found that my layout resembled the layout of my paper tutorial but with added (and necessary ) web navigation link on the left. I knew from previous review, in class and on my own, that this layout should be clear and understandable to my users. Creating the layout using HTML was a challenge. Having a preset layout on paper helped, but applying the table tags correctly was difficult, although eventually doable.

Scenario Development
Writing a good user scenario by now was not hard. I found that it was easier for me with this project to include important information in my fist draft. (Did I actually learn something?) I was able to pair the communication concept with the task with much less pain than before.

Program Steps and Tutorial Review
Here too, writing the program steps was not difficult. I kept in mind the specific task and global applications as well in order to provide a useful description before each section of steps. The review just summed it all up. I also decided to provide links to CSS sites to help users find additional information on the subject. If I did my job right, they would see the usefulness of applying styles and actually desire to learn more. This information was included in the review as well.

Final Thoughts
The hardest part of this project was the "online" aspect. I had already had my fight with task orientation during the previous tutorial project. I was intimidated by HTML (and still am to a lesser extent). Once I got past my initial fears, consulted a few guides, received some assistance in class, and went through a lot of trial and error, I succeeded in creating a functional, though not beautiful, website. I find the dynamics of "web publishing" interesting and given enough free time in my personal life would love to learn more. I'd like my tutorial to have a more professional air, but for now it will have to look like a student project.

The Focused Usability Test Project: Usability Shootout

Contextualizing the Focused Usability Test Project

Students were assigned the task of creating a usability shootout and a subsequent usability report to compare the websites of two colleges that offer technical communications programs. The student specifically defined a user class and at least one user in this class ( or a user assuming this role) was tested. The study, if written effectively, should determine which program website did a better job of creating a link between their program and the defined user class need and issues.

Reflecting on the Focused Usability Project:

Preparation
To prepare for this project, students completed two tasks. The first task was to create a list of features that we, as technical communication students, would like to see on a program website. This assignment put me in the mindset of a student much like myself before I started this program at EMU and made me ask what information would be most beneficial to a new or potential student with an undeclared major. we also looked at websites for college level "Ultimate" teams to see basically how sites can fail at providing information to outsiders. Our users in the study we would be creating are essentially "outsiders". They are not associated with the college and/or technical communications in any way. This task helped remind me to be aware of any assumptions the sites may make and I myself may make when creating my test questions.

Deciding on program websites to compare
A list of college with technical communication degree programs was distributed to the class. The list was broken down for students to evaluate. These evaluations helped pare down the number of colleges to evaluate and also showed us which colleges had enough similarities to make their comparison worthwhile. After this exercise, I chose Michigan State University and Michigan Technological University.

Scenario Development
I created a scenario much like the user scenario for the traditional tutorial. The preparation we did before beginning the project (listing what we'd like to see in a program site, experiencing a site that forgot about the user) helped.

Creating Test Questions
I had to go through a few revisions in this section. At first, my questions were just looking for the "do you see a definition and what is it" type of answers. My post-test survey was only asking for a regurgitation of these facts. Through peer review and class discussions, I was reminded what the real issue was that we were testing. We were looking not only for sufficient information was present, but also for some kind of clue that this information created a connection between the users interest and abilities and the program itself. Once I got that through my thick head, I found writing the post test survey simple. When I did resort to yes or no questions, I included a why or why not in order to uncover the root level causes for these user responses.

Analyzing the Test
Argh!!! This is where it got difficult. I had all of this wonderful data but it wasn't doing any good in its pure form. Class discussions helped me pinpoint some key issues that my particular study found. With this basis, I was able to review my data asking myself, "What surprises me?", "What assumptions were made?", etc. to analyze my results further. Reviewing my user's responses to the background questions also helped me zero in on user tasks.

Writing the Usability Report
As I have never written a usability report nor found a good example of one similar to ours, I struggled with this last step. Even given a basic report structure to use and knowing the definition of what information to include in each section only helped to a small extent. The nature of the test information itself caused a blurring of these section lines. I was also afraid of sounding too repetitive from section to section and of boring my reader during the Data section. I benefited from class discussions immensely in drafting and redrafting my report. Seeing and hearing other students' interpretations and layouts made me rethink some of my assumptions and gave me enough of a desire to revise (and revise again).

Final Thoughts
This project has taught me a lot about planning documents for users - not only in reviewing the websites but also in structuring my usability test and writing my report. It brings home the fact that in order to reach users effectively technical communications should not be an afterthought but rather an integral part of information design.