Email burnout -- or Length Matters in Love Letters -- or sab-BAD-ical attitude #1 -- or confronting the reverse transmission-composition proportionality paradigm

This is how my friend Ruby reacted when I did not reply to her email within 24 hours:


I sometimes get the same vibe from my students, colleagues, and family. Since an email "arrives" nearly instantaneously, I think we have come to expect a response in minutes or hours rather than days. If we don't get an email response from someone in that amount of time we assume that either their computer is broken or they have had a stroke. If another day passes, they clearly hate us / disrespect us / are incompetent.

When I was fourteen, I had my first and only girlfriend-via-correspondence. Her name was Rena and we met at a matinee showing of "Ghostbusters." My family didn't have air conditioning, so I used my allowance and haying money as often as I could to go to the movies in the hottest part of the day. I was a film buff, I guess. Anyway, Rena and I made eye contact during the opening credits while I was slurping my coke and in an uncharacteristic act of bravery I leaned over the two rows of seats 20 minutes into the movie and asked for her phone number. Or I got my brother to do it, I'm not sure. Turns out she lived in Grant City, MO. When you're from Agency, MO, (population 900, but just five miles from St. Joe) there aren't many places you can describe as even more of a hick town than your own. So I guess she was attracted to my urbane sophistication. Since our love was star-crossed by 105 miles of rolling missoura prairie, and since neither of our parents' would allow us unfettered access to the long-distance phone lines, we had no choice but to correspond through the US postal service.

Imagine this: while the windows steam up from the humidity outside, you labor all morning over your 16th letter in five weeks, carefully sculpting an image of yourself, "I've been lifting wates and practicing with my marshal arts a lot. That's not flowers on the back of this paper. I traced my 2 favorite throwing stars. They're called shurikens. I've got 4 of them. I'll probly get some more this summer." Since she doesn't know any of your friends, you pretty much portray yourself as a sort of teen-aged Territorial Governor--a leader in your community, respected for your fairness, wit, and fearsome roundhouse kicks (oh yeah, I was Napoleon Dynamite..and so was EVERY one of my friends). And since your devotion is best calculated in page count, rather than action or clear sentiment, you can ramble on for pages about your parents, your friend's dad's truck that you "rutinely" drive in the pasture, your favorite shows, your hunting conquests, your complete collection of the Conan, Tarzan, and The Horseclans book series'. And since you're also sensitive, you can confide that you still almost cry when they play the Ghostbusters theme song on the radio every 10 minutes. Then you tell her about all of the money you've saved from haying and urge her to arrange a visit to her cousin in St. Joe in a few weeks... all the while DYING to reveal to her that you bought her what just may be a gold bracelet at Montgomery Wards for $20.

At 12:15, you put on a $.19 stamp and stumble out into the heat, put the letter in the mailbox and flip up the red metal flag. At 12:35 the mail-lady pulls up in her station wagon and takes your letter, leaving a wad of mail behind. There's one from her (in response to your 14th letter)! You leave the rest of the mail in the mailbox and tear into her envelope before you even get to the door. She doesn't waste much time: "Scott, I think we have to be just friends, Scott. I've been really confuse because I [heart] you soooooo much but I also love the other Scott too [here, she was referring to her ex-...well, suddenly CURRENT (again) boyfriend with the same name] and he's here and he knows all of my frens. He has a lisense too..."

You see what I'm getting at? If she had waited two days to send that letter--and to make up her mind between that hillbilly Scott and this cultured Scott--she would have seen that I had THROWING STARS and SAVINGS (i.e. I could protect and provide) and BOOKS (i.e. I was going to be an English Professor someday and earn big \(\) and the respect and adulation of my community). I'm not bitter all these years later. I'll bet she is, though.

Has email made us more patient? Has it made us consider what is worthwhile to communicate? Duh. As frenzied and ridiculous as my correspondence with Rena was, is it really sillier than the many times YOU have sent out a brilliant email then put off all meaningful work to hit the Send/Receive button every 15 seconds for an entire afternoon waiting for replies? What about the times you've labored over an indignant response to a colleague's email--pointing out the unprofessional tone, the errors, the miscalculations--only to hit send and see in the meantime that they had already sent out a heartfelt apology and explained that their wife's heart attack that morning had left them "out of sorts"?

But none of this gets at the real reason I started writing this post. My students understand email better than my colleagues and my family and myself. They realize that there is now (and always has been) a transmission-composition proportionality paradigm. Simply explained, they spend time writing an email or letter in proportion to the time it will take for it to travel from them to its recipient. It took two days for my letters to get to Rena. I spent hours on each letter. They were always several pages. It takes 3.52 seconds for my email to reach someone on the other side of the planet. Therefore, I should spend no more than 2 seconds composing it. Less if I'm replying to something whiny.

Instead, we professionals too often succumb to the reverse transmission-composition proportionality paradigm which posits that all of the time our correspondents save in waiting for the postal service should now be spent composing a three paragraph response to our query about borrowing their scotch tape.

I'm therefore compiling a list of my future email responses (with an ear for tone, as demonstrated by the carefully placed exclamation points) starting with some of the standard responses in a magic 8-ball. Feel free to suggest additions:

  • Ask again later
  • As I see it, yes
  • Better not tell you now
  • Concentrate and ask again
  • Don't count on it
  • It is decidedly so
  • Most likely
  • My sources say no
  • Outlook good
  • Outlook not so good
  • Reply hazy, try again
  • Signs point to yes
  • My bad.
  • I'll get right on that, honey.
  • Ha!
  • Here ya go!
  • thin mints, 4 boxes
  • I'll get right on that, Liz.
  • Sorry about that 🙂
  • No, thank you.
  • Okee-dokee.
  • I'll get right on that, President Steen.
  • Is this student-centered?
  • LOL!!!
  • whatever
  • Why yes, I DO have some expertise with shuriken.

Back in the Saddle

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.

Sequenced/Themed Tutorials

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.

Standards for tutorials/procedures

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)?

ATC: Help Compiler, writing teams

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.

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.


Advanced Tech Comm - The Client Interview

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.

ATC2006 Begins!

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.

Wrapping up Fall 2005 EN3090

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...