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.