Wow! It's been a long time since I've posted. No wonder some of the others have been so inconsistent making their own blog entries.

A lot has changed since I last posted. We lost a team member, we posted a fantastic doc plan, we first ran into trouble with the tutorials then punched through with some great ideas. Thursday, after our demo for Evelyn (which went well) I gave the lamest introduction to DreamWeaver ever.

I won't whine, but it's obvious I've been distracted by all of the other responisbilities I have this semester (search committee, GITF stuff, etc.). But I'm regrouping, refocusing, and getting ready for the final push.

First things first: this week I'll give a much better intro to DreamWeaver (using actual Word tutorial files) and we'll get the labor issue back on track.

Something to chew over: what if the class broke into three teams of two for the purposes of writing tutorials. Each team of two could write a series of 3-4 related tutorials that centered on a single project. In fact, we could organize the tutorials by project. For instance, one set of tutorials could focus on using transform tools (and maybe throw in text and layers and some filters). It could start off with two beginner tutorials in a sequence, then move to a slightly longer and more difficult intermediate tutorial, and finish with a longer tutorial that showcased a few advanced techniques. Users who stopped at any stage would still learn something. Users who were already advanced could actually open the image created in the last tutorial so that they could skip the intros.

What are you thoughts? James, you're coordinating tutorials, how does this idea strike you?

BTW, if we did adopt this method, I would always have AT LEAST two beginner-level tutorials for every intermediate/advanced tutorial. Beginners are our main audience.

These are some questions that I think we should ask as we "workshop" future tutorials and procedures.

Questions for Sample Tutorial

• Is the title appropriate? Does it announce the topic in task-oriented terms? Is it inviting?
• Is there any context or overview? Does it preview the types of skills learned in this tutorial? Does it explain any knowledge the user must already have or any steps the user must have already taken? Does it clue them in on the likely duration of the tutorial?
• Is the first step appropriate (i.e. Is it too basic – unrelated – or does it assume too much knowledge)?
• Do the steps of the tutorial adhere to a “pattern of exposition”?
• Is the look of the tutorial intimidating (how many pages is it)? If so, how can we fix that?
• Is the tutorial appropriately paced? I.e. is it too long, does it maintain a more-or-less constant level of detail? Does it distract with too many alternatives?
• Is there appropriate emphasis given to warnings, tips, notes, etc.? Is there a consistent and obvious style mechanism for explaining the interface (for instance, bolding or italicizing the names of buttons, menu commands, and other official interface names? Are we using the correct names (according to the interface) and are we using likely user synonyms?
• Are illustrations effective? I.e. is the emphasis of the illustration clear and obvious? Are there distractions in the illustrations? Are there enough/too many illustrations?
• Is the structure of the tutorial easy to follow? Is there one sequence of steps or several? Why?
• Is the technical level of the tutorial appropriate (and for whom)? Does the tutorial help the user to find other assistance? Does the tutorial invite users to explore on their own?

Questions for Sample Procedure

• Is the title appropriate? Does it announce the topic in task-oriented terms? Is it consistent with other procedure titles?
• Is there any context or overview? Does it preview the types of skills learned in this tutorial? Does it explain any knowledge the user must already have or any steps the user must have already taken? Does it preview any notes or cautions that the user should be aware of?
• Is the first step appropriate to this task (i.e. Is it too basic – unrelated – or does it assume too much knowledge)?
• Do the steps of the Procedure adhere to a “pattern of exposition”?
• Does it distract with too many alternatives?
• Is there appropriate emphasis given to warnings, tips, notes, etc.? Is there a consistent and obvious style mechanism for explaining the interface (for instance, bolding or italicizing the names of buttons, menu commands, and other official interface names? Are we using the correct names (according to the interface) and are we using likely user synonyms?
• Are illustrations effective? I.e. is the emphasis of the illustration clear and obvious? Are there distractions in the illustrations? Are there enough/too many illustrations?
• Is the structure of the procedure easy to follow? Is there one sequence of steps or several? Why?
• Is the technical level of the procedure appropriate (and for whom)?

I'm beginning to wonder if the wiki tool will be robust enough to support our needs. I'm disappointed that there is no history function so that we can look at old versions. But I'm bothered even more by how clumsy the navigation and file management tools are.

One partial solution (at least to the navigation issue) is to create compiled Help. This is a system that can take dozens (or thousands) of web pages (and their referenced files such as graphics or video/sound clips)Â and compile them into a single compressed file that can be accessed from a desktop or over a network.That would still leave us with a serious file management problem (echos of ATC 04), but at least the finished product would be compact and potentially easy to use.

http://www.microsoft.com/downloads/details.aspx?familyid=00535334-c8a6-452f-9aa0-d597d16580cc&displaylang=en

I'm also taking the iniative to create the following positions in the class. Please choose one role and proceed into the Documentation Plan (see the wiki) accordingly:

Writing Team
Areas of Responsibility:

Tutorials writing leader: leads class discussion on number and scope of tutorials, assigns tutorials to various members, tracks progress.
Procedures writing leader: leads class discussion on number and scope of procedure topics, assigns procedures to various members, tracks progress.
Writing Style leader: leads class discussion on style guide issues, records and gradually compiles style guide (or at least list of style do’s and don’ts)
Design & Navigation leader: leads class discussion on individual page layout and overall organization of Help system. Works with Tutorial and procedure leaders to create site-map.
Copy Editing & Graphics leader: leads class discussion on developing peer editing and individual editing practices. Assigns editors and tracks progress. Also works with Writing Style Manager to develop standards for screen shots and other graphics, then checks all topics for compliance.
Tools and Testing leader: leads class discussion on authoring tools, file management, and similar issues. Responsible for overseeing final testing and corrections of all links/functionality.

Use your blogs as the ongoing repository of information for your area of expertise. Be sure to check other blogs VERY frequently for updates.

If anyone is interested in watching this project unfold, we are currently using a wiki to collaborate. You can look, but you can't touch (unless you have one of the double-super-secret password-encryption rings that my class and I forged during the last new moon). This isn't the most robust wiki platform in the world (no history of documents, for example) but it seems to get the job done.

http://en4090psuadvancedtechcomm.pbwiki.com/

Whew! That went extremely well. Without getting into specifics, when I taught ATC in 2004, the client interview was the Pearl Harbor of my teaching career. My students left having been stripped of motivation and more confused about their project than ever.

THIS time, the energy in the room crackled and anyone could see that Dr. Stiller (her department is our "client" this year) and the class had an immediate rapport. My students asked insightful questions and followed up very well. Not only were they able to glean a lot of important information from Dr. Stiller's answers, I think they did an admirable job of communicating their own professionalism.

As always, I don't want to slide into the driver's seat (though I have to restrain myself from doing so), but here are some of the important take-aways I think we have to consider:

• Our users are expressing themselves creatively. Supporting those creative expressions will be our job and we should adjust our tone appropriately.
• Tutorials, and to a lesser degree Procedural help, are probably going to be the main emphasis for this document. We should certainly focus those tutorials around acclimating students to suites of tools and we should not be afraid to have the same tools appear in multiple tutorials (eg. layers & selection tools).
• While Dr. Stiller's assignments are excellent sources for us to consider as we look at tutorials, we should use those assignments to build a list of important skills, THEN design the tutorials to teach those skills. This allows us to account for individual instructors who may design very different assignments to assess those same skills.

On a different note, I met with my reflective practice teaching group last Friday. Our discussion centered on ways to get at what our students know, as opposed to what they can parrot back from the readings/lectures/etc. Then, today, I was talking to my Dep't Chair about my excitement/anxiety over this class. I was telling her that--as much as I want to shove the class aside some times and start doling out tasks and organizing the project--it's critical to the success of the class for those decisions to be deliberated and arrived at by the class itself--the ultimate means of determining what your student's know. Discovering the best approach, through trial and error, is a much more valuable experience than having it prescribed in a text...or even by a well-meaning professor. She asked me to consider writing about this course and my approach for WAC next year. We'll see what happens.

I couldn't be more psyched about this semester. The Clock has an incredible staff and great leadership from Sam Kenney and Brooke Thornton. The work we've begun on faculty governance is now in the hands of a very capable group of faculty, PATs, and OS. My Twice Told Tales class is very engaged in the readings and the course. My Technical Communication classes (complete with several re-tooled assignments/structures) are coming along very well.

But more than anything else, I'm excited to be a part of another semester of Advanced Technical Communication. Anyone who's talked to me for more than two minutes in the last two years knows that the first offering of that course was the peak of my teaching career to date. My current class of six was hand-picked from among the best students I've worked with in the past two years. And they're ready to go--they've even suggested blogging (why else would I be blowing the dust off of this ancient blog?) as a way to track the project over time. More than a seminar, the class is a lab. I'm there to guide them when necessary, but for the most part, they "discover" their path and they set many of their own goals. I'm not basing my high expectations solely on the Fall 04 experience, I'm basing it largely on my confidence in these six remarkable students.

This year, we're working with Evelyn Stiller from the Computer Science Department to develop a web site that will help students in the Web Expressions course learn to use PhotoShop Elements. Together, we'll be learning to use PhotoShop Elements (our subject and one of our tools) as well as DreamWeaver, pbWiki, and any other tools we need. We'll be meeting regularly with Dr. Stiller to get background, receive feedback, and apprise our "client" of our progress.

For now, we're still forming as a team. We're relying on the text to give us some background knowledge and points of reference for later on, we're exploring our own roles, we're investigating tools and the client application, we're branding our group and generally getting to know each other in this new context. If experience is a predictor, we will be a solid team by this time in two weeks and that team will become more skillful and tightly-knit even as the deadlines begin to loom large.

To top it all off, three students from the former class have agreed to visit the class this year to participate in discussions, talk about their current role as technical communicators, and generally cheer the current group on.

I love this job.

What a semester. For the first time ever--and I hope for the last time--I taught three sections of Tech Comm. I had to make changes to the course, and I'll talk about those in a moment, but I was very pleased with some of the results.

First, the success stories. Among other changes to the course, I made everyone collaborate with a partner so that cut the number of projects to 38. Of those, there were many that displayed excellence of one sort or another, but the seven "A" projects stood out in quality of research, quality of argument, quality of writing, and quality of design. They all shared one characteristic--their authors were very passionate about the topics.

Here's the rundown:

• A project that analyzed the crisis in text book prices. Not surprisingly, honest research revealed that it was very difficult to point the finger at one source. After 15+ pages explaining the problem and examining data from sources such as the GAO, the authors recommended a multi-faceted approach including asking profs to post information on their texts well ahead of the beginning of the semester (I immediately sent an email to all of my Spring students giving them the title, author, isbn, etc. for my texts). I suggested that this report be repurposed for the campus bookstore committee and (potentially) for the general faculty.
• A project proposing a quarterly magazine devoted to healthy body images for PSU women. Again, a thorough discussion of the problem followed by an equally thorough description of the proposed magazine. I'm 100% behind this idea -- though I do wonder if they could start with a webzine.
• A proposal to create a Geology Minor at PSU. Their most shocking finding: after examining the courses that comprise other schools' Geology minors, we already have the courses/faculty in place, we only need to create the minor program! Wow.
• A report that examined the mosquito problem in Plymouth in light of last fall's discovery of birds infected with EEE and WNV. One of the writers had actually worked in mosquito control in the past. Instead of relying on their own experience, they went to great pains to find and cite excellent sources. Acknowledging their own student status and seeking cover under the credibility of "expert" increased their own credibility.
• A report that examined the dangerous crosswalks on Highland by the library. Great research, great documentation of their sources, very direct and compelling writing. They actually made the idea of a pedestrian bridge seem reasonable (until the price came up). Dream big!
• A proposal seeking to address the outrageously long wait at the coffee shop in the HUB. This one was close to my heart. They proposed simple coffee carts in the outlying buildings (Hyde, Boyd, Rounds) that could be supplied by a van. I don't know if it makes $ense, but it would make me less grumpy in the morning.
• And finally, a proposal by the weather guys to purchase a system called WSI for the meteorology department. This is the software that makes all of the space-aged illustrations and fly-throughs during a weather forecast. More than anything else, they made compelling arguments that PSU grads hoping to break into broadcast meteorology were not competetive because they have not trained (and cannot make demo tapes) on WSI.

Now for the changes this semester. The big change: everyone had to have a partner for their projects. Many students HATED this. The common complaint--my partner can't write so I'm stuck doing all of the hard work. There are ways that a partner can be a good collaborator even if they're not doing an equal amount of writing. But, in a few cases, both sides agreed that one partner did ALL--or nearly all--of the writing. Unacceptable. I'll work on mechanisms to ensure each partner is doing a considerable portion of the writing.

I dropped my old technical description assignment, but the instructions assignment suffered because of that.

I also added another conference. Since I had THREE sections, these conferences were too short. But they were so worth it. If I could swing it, I would add a third. Instead, I'm thinking of adding a research presentation--an informal presentation where the students stand up in front of the class and discuss the sources they are using for their project and the lines of questioning they are pursuing approximately two weeks before the due dates.

Another change I'm considering: HTML journals may be replaced with blogs...