Dr Karl Stolley

This semester, I’m again teaching my course in Online Design (really a web design and development course, but I enjoy the nostalgia of the “online” name) and a new (to me) course in Publication Management, which I’ve created using content management as a broader guiding concept along with single-sourcing. Students will be working with Drupal in that course.

I’m continuing to use the WikkaWiki to power my course websites. MediaWiki was a big hit with students in a seminar on Knowledge Management a year ago, but I’ve used the lighter-weight (and easily customizable and standards-compliant) WikkaWiki software since then.

There are a few big things I’ve done in terms of the structure of the courses that are different from past courses of taught. Specifically:

• Putting the major project in the middle of the semester, rather than the end. My students tend to get a weird sense of panic when I’ve had the major project as the final one. They tend to have learned and become capable of much more than they realize around the second- or third-from-last weeks of class, so I’m curious as to how and whether shifting the major project to the middle changes things.
• Adding milestones to the projects, to give students a better sense, week-to-week, of where they should be. I’m a firm believer in large projects that are impressive enough in scope to be significant parts of student portfolios. Large projects also, however, tend to unfold differently for different students. But, in response to evaluations and comments from students, I’ve added some suggestions to help students gauge their week-to-week progress.
• Having in-progress project presentations every week. I don’t know why this hadn’t occurred to me earlier. Most students appear to enjoy the final project presentations. And yet the real benefit of presentations comes earlier than the projecct due date: students are inspired by one another’s work. So this semester, every week a few students will present their in-progress projects.
• Recording my lectures and demonstrations and posting the audio on the course wiki. I did a test run of this in the Information Structure and Retrieval course last semester, although I never posted the audio: running the recorder for three straight hours was a silly choice, and required too much time to listen and edit. I learned my lesson, and stop and start my little R-09 digital recorder more frequently, which breaks the audio up into individual files that are easier to review. And the recordings are meant to work hand in hand with the wiki. Wikis are great for in-class demonstrations of code, as students can go back through the page’s revision history (see, e.g., the list from my demo on XML namepaces from the info structure course). Coupled with audio, which can be played right in the wiki using the Yahoo! Media Player, students can walk back through these pages and pick up points that they might have missed.

I’m always grateful for feedback on my courses. And if anything looks appealing, please feel free to use or link to my materials: As with last semester’s Information Structure and Retrieval and Open Source classes, I’ve licensed all of the material on the course websites under Creative Commons licenses.

Write the first comment.

Sometimes, the most difficult thing about teaching digital writing and communication is the problem of choosing (or not) software, particularly those software packages believed by students and/or faculty to be industry standards.

Even without unpacking the loaded label of “industry-standard,” a no-win situation develops for instructors planning courses that necessarily involve software: On the one hand, students typically expect to learn about brand-name, industry-standard software. In tech comm, some students believe brand-name software proficiency to be the hallmark of a marketable technical communicator. Employers seem to think this, too, as suggested by the now long-standing practice of specifying software in job ads, and job applicants listing software skills on their resumes; or rather, listing software titles on resumes.

On the other hand, students also expect to be able to work from home, and to work cheaply. Tuition is costly enough without tossing a thousand-dollar piece of software onto a syllabus’s “Required Materials” list–particularly for software that has little or no use value outside the enterprise. That, of course, is precisely the problem with expensive, proprietary enterprise-level software.

My position is that using a particular software package ought to be about as big of a concern to technical communicators (and their employers) as learning to drive a particular make and model of a car is to driver education. Learning to drive in a Buick doesn’t mean one cannot safely drive a Toyota or a Bentley. The controls may be in slightly different locations; the vehicle may even handle very differently. But the driver’s ability to drive, after a period of relatively painless adjustment, remains constant.
Read the rest of this entry.

2 comments.