The Week in Words (August 7)

At the Editor's Desk

After last week's big reveal of my other project, I think it's time to get back to a real focus on what brings us all together here: hating Dan Brown.

Freelance Services

It's a shame that I've never gotten around to preparing a sales page around here, but as some of my blog posts in the last couple weeks have probably hinted, I do have some valuable services to sell. In addition to my own extensive experience with creative and technical writing, I've done writing coaching, document design (fiction and nonfiction), story editing, voice editing, line editing, copy editing, and several types of copy writing.

At the moment, I'm working on breaking into grant writing, and I'm in talks to maybe do a ghost writing gig. It all sounds like a lot of fun.

Incidentally, since I don't have a strong sales process set up at the moment, I've got some open availability, so if you find yourself in need of some of those services, you can feel free to send me an email (or use the site's Contact Form) to ask me for an estimate. I'm not cheap, but I'm terribly good.

The Girl Who Stayed the Same

There's the technical and the creative writing to do, though, and I'm still going strong on my current work-in-progress. This week I finished chapter seven and started chapter eight of The Girl Who Stayed the Same.

Someone finally asked Jonas if he was an angel (and he answered with a qualified no), and we also learned that Jonas is really terrible at chess. He's also pretty emotionally unstable, but what do you expect from a dude who hangs around with artists all the time?

On Unstressed Syllables

This week we covered two major topics: following directions and preparing a document according to the rules (specifically grant applications), and following the rules and writing stories with due respect for your readers.

Sunday I introduced the Technical Writing series on grant applications with a story about my three-year-old daughter learning to read...by memorizing the shapes of words. It's limited in a way phonetic alphabets aren't supposed to be, but it's also advanced in a way three-year-olds aren't supposed to be, so I'm considering the whole thing a wash.

Then on Monday I talked about grant money, selection committees, and how grant writing is just like the slush pile all over again. It's frustrating in ways, but it also gives experienced novelists a leg up on the competition.

Then Tuesday I took it a step further, saying that grant writing is just like writing Shakespearean sonnets. The metaphor isn't perfect, but the application is -- if you can learn to express your ideas well within someone else's strict structure, you're ready to call yourself a professional writer (and start raking in the dough).

On Wednesday, Courtney waxed domestic with a story about sewing up some torn garments, and in the process taught us how to patch up holes in our stories' plots. It can be a lot of work, and it's certainly the sort of thing we're often tempted to let pile up on our To Do lists, but a little extra effort can save a story from becoming scrap, and turn it into a perfectly serviceable Saturday shirt.

Thursday I introduced the Creative Writing series on writing rules with a story about Trish trying to watch The Da Vinci Code in spite of all my lecturing. The lecture's got to go someplace, though! So I spilled it through onto Friday and Saturday, too.

On Friday I talked about respecting your readers, and specifically focused on understanding and deliberately crafting your book's reading experience. When you consider how your story affects your readers (and what they're offering in exchange for your storytelling), it becomes far easier to stick to some of the core rules of writing.

Today's article tied that up with a detailed look at what some of those rules are: premise, verisimilitude, and the unforgivable sin named "Deus Ex." It's been a pretty academic week, and if you've followed along you probably deserve a couple hours of college writing credits for it. Alas, my blog isn't yet accredited.

Around the Web

I also found a couple of good articles around the web this week, that I thought you might find interesting. They're certainly relevant to our most recent discussion.

• Writing this week's aggressive broadside against popular novelist Dan Brown, I couldn't help thinking about literary agent Nathan Bransford's fantastic article last week, The One Question a Writer Should Never Ask.

• Wouldn't you know it, though, Bransford followed up with another excellent post this week on the same topic, Writing vs. Storytelling. Be sure you read both of these -- you'll be a better writer for it.

The OC (Week 16)

This post is part of an ongoing series.

Final Exam

Two weeks ago, I wrapped up my Technical Writing class with a final exam. It was a little experimental (Courtney said more than once, "I've certainly never had a final like that!"), but it went perfectly.

In case I didn't mention it before, Courtney joined us for the final exam period. I asked the class if they were cool with that back in Week 15, and they insisted they had no problem. She wanted to come out of idle curiosity, mainly as a result of reading this blog, and I had no objections.

So she showed up Thursday afternoon, a couple minutes before one o'clock, and the vast majority of my students were already there and in their seats. I was at the front of the class, by the computer station, getting things ready for the class session, and she came timidly into the classroom, crossed in front of the blackboard, and asked me where she should sit that would be unobtrusive and out of the way.

I'm mean sometimes. I sent her to the chair at the teacher's desk, front and center.

Cookie Platter

I wasn't trying to be mean. It was really the only place I had for her. The students were arrayed on the outside of their inverted-U of tables, and though there was a table tucked in the middle of the room (where I'd sat while observing the presentations), I had big plans for the middle of the room, so I couldn't really send her there.

I was also standing at the computer station and not starting class for a very particular reason. I was buying time, waiting for all of my students to arrive, and also deliberately standing so as to conceal a cookie platter T-- had made for my students. I didn't want to spoil the reveal by having someone walk in late and spot a half-hidden cookie platter, y'know?

Anyway, once the classroom was full, I turned on the overhead projector with just the empty desktop of my school-issued laptop showing, and that got everyone's attention. All eyes snapped to the screen, and then I stepped back, brought forth the cookie platter, and headed to the table in the middle of the room to set it down.

I was halfway there when someone said, "Are those cookies?"

I explained that T-- had wanted to send cookies for my students all semester, but I'd kept objecting because I thought it would be too distracting. Then I finally relented on the one day when their participation counted for 10% of their grade. Hardly fair. Nobody complained, though.

I was in the grip of la grippe, so I left the cookies wrapped in their plastic and stepped back to the front of the room. "I need somebody else to unwrap them," I said, and about two heartbeats later Sean -- seated in the middle of the back row, and as far from the cookies as possible -- leaped over the tables to take care of business. He got them unwrapped, then passed the tray around, which was quite calm and orderly.

Chaos and Disorder

The next step was the one that denied Courtney a seat in the middle of the room. I told them I had their graded semester projects ready to return, and I'd call out their names. After they came to retrieve their grade sheets, they were to remain standing in the center of the room instead of returning to their seats. (That was an important step that turned out to be totally useless.)

Once everyone was standing in the middle of the room (and they were sort of packed in like livestock), I explained that we were going to divide up for the day's activity. Unlike previous activities where each group worked on its own version of the assignment, today's activity would require three different groups, working on different aspects of one product. So I explained that the table on the right would be for the Documentation Group, the table on the back would be for the Software Group, and the table on the left would be for the Publishing Group. I told them to take their best guesses which group would most suit them, and go sit down.

Everyone sat down pretty much exactly where they'd been before.

The Assignment

Next, I explained to them the assignment. Just as I've said here before, my goal was to have the students create a wiki to demonstrate their ability to learn a new document type without my guiding hand. So I pointed to the screen at the front of the room, that showed my blank desktop, and told them my goal was for them to have a full-featured wiki including the contents of all of their weekly tutorials up on that monitor by the end of the class period. By that point, it was a little over an hour and a half.

Then...I sat down at the front of the room. And I looked at them. I may have given a little bit of an indication what each group should do, but it certainly wasn't anything that could be described as "directions." I did ask a couple of my students on the back row if they'd completed wikis of their projects for extra credit (Sean and Will, both of whom had asked for permission to do that, and both answered that they had), and that was meant to give them a nudge toward helping the rest of the class figure it out. It worked.

Not right away, though. The next ten minutes were brutal. I had about two minutes of deer-in-the-headlights from the whole classroom, and then my two with experience (both in the Software Group) leaned their heads together and started talking, and got a couple others from the Software Group chiming in before too long. I listened to their chatter for a little while, to get an idea where they were headed, and then gave them a nudge in the right direction, and listened for a little while more.

The Software Group and the Publication Group ended up both being composed primarily of technical people, so by that point the Publication Group was pretty involved in the conversation, too. The Documentation Group (my English Majors) were sitting off on the right still waiting to find out what they were supposed to do.

So I finally addressed that. I explained to them briefly what a wiki was -- a type of simplified markup language -- and that they would need to take the highly-formatted, styled Word documents I'd used for their weekly tutorials, and convert them into flat text files with some simple markup. I suggested they get to work downloading the tutorials from the class website, figure out how they were going to distribute the workload, and then start making guesses as to how they would do the conversion. They wouldn't know for sure until the Software Group settled on a wiki platform, but they could do some prep work while they waited.

In Production

Then I headed back over to the Software Group, and I said, "What you'll probably want to do, first, is choose which wiki platform you're going to use--"

And Will cut me off to say, "We just did that."

I went on, "And then this group is probably going to divide up, half of you going to support the Documentation Group as they convert the existing documents into the right format, and half of you going to support the Publication Group as they figure out how to get those documents up for us to see, within the next hour."

They nodded, then immediately got to their feet. Will went one way, Sean went the other, and they became Management. It was kind of awesome.

After that, I was done. It was their final exam, after all. I sat at the front of the room and chatted with Courtney, eavesdropping on their discussions, but most of the corrections I would have made ended up getting caught by Will or Sean before I had the chance.

It was only a few minutes into that (maybe ten or fifteen), when I asked Will what address they were using, and Courtney was able to pull it up on her laptop. From that point on, while we were discussing writing or Wil Wheaton, or whatever, we were also scrolling through the wiki as it was under construction. I was impressed with the draft version. I was really impressed with the changes they had in place by the half-hour mark. And at the end of the period, while they were still scrambling to get a couple of the more complicated chapters put together, I asked Will to step up to my laptop and present the finished product to me.

He shook his head. "It's not ready yet!"

I said, "That's okay. Show me what you've got." I didn't say it in a menacing way, either. I was prepared to grade them based on what they'd finished, not the page or two that were still undone.

He wasn't satisfied with that, though. He said, "Give us a few more minutes. It's almost done."

As he said that, from one end of the Publication Group table I heard, "Five's done!" and down at the other end, "Seven should be up now." And Will scurried off to oversee the finishing touches.

In the end they all stayed a little bit late, just to present a polished product. It was phenomenal. It was so much better than I'd hoped for, especially given the short time limit.

(If you're curious, you may be able to see a copy of it here. I have no idea how long that site will be live, but it's there for now.)

I'd had some closing words prepped, to finish off the semester, and after seeing their work I wanted to go into detail with praise, but there was no time. All I could tell them is, "Well done! You've earned a one hundred. Thank you guys for being awesome!" And then I sent them on their way.

Retrospective

Knowing what I know now, I could have made the final session go a little more smoothly. I don't think I could have possibly gotten any better results, but I could have left the students a little more comfortable with their role. Then again, that's pretty much true for the whole semester.

And I'm not beating myself up for that. This was my first time teaching. Wow.

Anyway, one thing I experimented with there in the final -- dividing them into purpose-based groups -- is something I think I'd like to do from the start if I ever teach the class again. On day one, I'd divide them into those groups -- with those titles -- and let them rearrange through the course of the semester if they wanted, and sometimes divide them up in support roles and sometimes combine them, based on the project, but give them a chance overall to develop some sort of consistent group identity, apart from "we're sitting within arm's reach."

I do wish I'd had another assignment or two in there, and I wish I'd had in-class activities for nearly every class I didn't have one for. I put that down to limited prep time from being a first-timer, though. Same goes for the uncertainty of their schedule (flip-flopping on due dates), but I think I could be a lot more confident about that on a second go-round.

Apart from that...I'm awesome. I know the class was satisfactory to the powers-that-be, I think the class was useful to the student, and I'm amazed how much I gained from the experience. My students were all amazing people, and I'm glad I got to meet them. And, y'know, I discovered I could do something I never would have thought possible. It was bigger and better than NaNoWriMo. I'd never have guessed.

And that's it. Hope you've enjoyed the updates. Let me know if you have any questions. I'll let you know if they ask me back for more.

The OC (Week 15)

This post is part of an ongoing series.

Season Finale

We have officially left the regular season. Post-season takes place tomorrow. Or something like that. Whatever.

Week 15 marked the last week of regular classes for the semester, and we finished it by finishing up our presentations. Tuesday saw some technical difficulties, and Thursday saw some more, but the brightest minds in OC's IT department are in my class, so we got it all worked out.

A Polite Reminder

We finished up on Tuesday with fifteen minutes to spare, and I just let them out early. As I headed toward the podium to pack up my laptop I said offhand, over my shoulder, "See you Thursday."

Then I stopped, turned to glare them all in the eye (that's right, thirty-two eyes all at once, it's a professor thing), and I said with a dread pronunciation, "See you Thursday."

A chuckle went around the class, but I got numerous affirmations from those who'd missed the previous Thursday, and then they fled the room.

It worked. Thursday we had a full class, and I was able to give some last-minute clarification concerning the Final with the confidence of knowing everyone was there. That was nice.

Semester Projects

Thursday was also the due date for Semester Projects. They'd haggled a midnight deadline earlier in the semester, so that held and they had until the very last seconds of Thursday to get the document turned in for full credit. Someone else (I'll let you guess who) had worn me out with his arguments and convinced me to accept late work, too, but I instituted a 5% per day penalty for it.

There was some discussion whether that should be pro-rated, or lump sum, and the arguments on both sides of the debate were pretty compelling. I ended up pro-rating, because I like my students.

Anyway, I got all the projects over the weekend, and they're now all graded. They turned out awesome. I remember that being one of the things the class was most famous for when I took it, and at the beginning of the semester when I asked my students what they knew about the class they were signed up for, the project was the only bit any of them had any clear ideas on.

I had some concerns that the reputation of the semester project might fade with a new professor at the helm, but for now I think it's safe. They did some really cool stuff, and nearly all of the finished projects are going to be terribly useful. Several of them will even be useful to me.

Homework

I made that all sound like a lot of fun, but those four words up there -- "they're now all graded" -- actually represent a pretty miserable experience. Who knew semester projects could be such work for professors? Both of my parents are teachers, so I've heard grumbling and complaining about having stuff to grade all my life, but I didn't really get it, until I found myself with a mountain of stuff to grade.

It's no fun at all. Just horrible. I really don't recommend it. If you're teaching a class, go all California-hippie on them and don't do grades. Or quantum physicist and assign grades completely at random. That would have to be better than actual analytical numeration. Blech.

(I've also been coming down with a cold in the same days that I've been going through that process, so it could be having an impact on my attitude. Time will tell, I suppose.)

Anyway, it's done. It's done and it's done and it's done. I've got Finals on Thursday, and I'm confident everyone will show up, and the minute that's over, I should be able to turn in final grades and be done with the class. How cool is that?

More next week (or, conceivably, tomorrow).

The OC (Week 14)

This post is part of an ongoing series.

Presentations
I mentioned it in the last post, but we're done with lectures and mostly done with the tutorials (more on that in a minute). That just leaves presentations, and the final.

We started the presentations this week, with four presentations a class period over four periods (in two weeks). Two of my four presenters on Tuesday had skipped the assignment that had them sign up for a presentation spot (on Google Docs), so they found out about it for the first time when I sent out a reminder email on Sunday.

To their credit, they both did surprisingly well.

Honestly, I haven't seen a presentation yet as bad as mine would have been (and, in fact, was, back when I took the class). They're farther along with their semester projects than I really expected, too, which is encouraging. I'm looking forward to seeing their finished products, so I'm glad to see it's not all going to be last-minute stuff.

Empty Seats
Thursday's lectures were a little better, really -- which is to be expected, given that they had more time to prepare, and got to learn from the presentations that went before. Unfortunately for the presenters, though, there weren't nearly as many people around to be impressed. We had right at half of our class show up.

That, too, shouldn't be much of a surprise. After all, it was the first time all semester that we'd met in class on a Thursday. To be fair, I warned them about that on the first day of class, and before Thanksgiving break, and then I sent out an email last Sunday (as I mentioned) reminding them about presentations this week.

I had a brief bout of guilt, worrying that my own attitude about the last couple weeks (being so much easier on me, since I'm just listening to presentations) had been conveyed to my students somehow, and they were slacking off because I was. Then I remembered the Thursday thing, though (and got emails from a couple of my students citing exactly that), and I let myself off the hook.

Textbook Execution
One thing I had been slacking off on was their final tutorial. All of the rest had to be done by specific dates, to match up with their assignments. There was one last one that I'd promised them, though, that didn't really map directly to any work they were doing. Way back in week 9, I did a big presentation showing them how to build an automated Table of Contents and generally take advantage of all the extra work we've been doing to build a powerful, long-form document. I flew through the process in class, though, and gave them no exercises or anything to reinforce it. Instead, I said, "This'll probably end up as a tutorial at some point."

I'd meant to get that to them the week before Thanksgiving, but it was the week before Thanksgiving, so I didn't. I kept thinking about doing it during Thanksgiving break, but I was on break, so I didn't. Whenever I started feeling guilty about that, I reminded myself that my students didn't really care.

Then Monday morning I got an email from one of them asking me how to make a Table of Contents, because she needed it for her semester project, and I immediately felt like a super jerk. I sent her a quick answer, and then got to work writing my tutorial.

It was a complicated one, though, because I had to walk through some of the more advanced tools in Word. Not only that, I had to handle some pretty nit-picky exceptions to make it come out perfect, but I was trying to express how simple the whole process really was, even while explaining why those exceptions were doing what they were doing. Then I needed screenshots to illustrate it, and I needed to put together all the resources they would need to follow along with the tutorial, and make those available on the website.

It was a real task, is what I'm getting at, but I finished it last night. The title for the tutorial was "How to Build a Book," and it took all the tutorials I've made all semester and bound them together in a single textbook. It ends up looking pretty nifty, and it tops 100 pages even without the lecture information and assignment descriptions (that I would definitely include in it, if I were making it a standalone book).

Anyway, I have no idea if that will actually be useful to any of my students (since the one who asked me about it presented her document yesterday, and she'd clearly figured the ToC out using just my quick email), but I'm glad to have it done.

Final Thoughts
The only other issue I've been dealing with this week is their Final Exam. I've been told I need to have a Final Exam period, but that a test isn't really necessary. I told them early in the semester that they would have an option of building a wiki instead of taking the Final Exam, just because a big ugly test doesn't really mesh at all with the way I've been teaching the class.

As I really started thinking through the logistics of it, though, the wiki alternative seemed unrealistically complicated, and any test I would have (for those who didn't want to take the alternative) would be just a huge waste of time. There has been no memorization in this class at all (it doesn't make sense in tech writing), so I would have just made them show up in class to read a bunch of questions, flip through their textbook for answers, write those answers down, and then go home. I wrote their textbook, and it's way too straightforward for any of that to be a useful experience.

So I finally decided to nix the original plan, and instead I told them all to show up for the Final Exam period, and we're going to build a single wiki as a group project. That should be a lot less stressful for those who would have built individual wikis, it should be a lot more useful for those who would have taken the test, and I think it could actually be a fun experience. We'll see.

Between now and then, though, I've got eight more presentations to grade, and about a bajillion pages of papers to grade.

More next week.

The OC (Weeks 12 and 13)

This post is part of an ongoing series.

Week 12
Back in August -- back when I had so much delicious free time on my hands that reactivating my WoW account seemed like a good idea -- I was just a bright-eyed kid all full of ideas. Those were the good old days, before bitter experience taught me the cynicism of reality. (In case you can't tell, I've been noveling.)

Anyway, back then I made up a course schedule to put in the syllabus, which included lecture topics for every week, and assignments for the students along the way. I mentioned the fallacy of that schedule in the week 11 post about technical writers as programmers, where I pretended a topic of actual interest to them was a topic I knew something about.

Week 12 featured a reversal of that, when I pretended a topic I knew something about was a topic of actual interest to them. The title for the lecture was "Writing to a Deadline and the Publication Process." I reversed the order for my presentation.

The Publication Process
By "the publication process" I meant the actual physical process that converts a Word file into a paper book. As a technical writer, that's a process that takes up a lot of my time. After I've finished writing a perfectly-crafted, error-free description of my topic, I then have to spend hours and days and weeks reshaping the beast to make it play nice with paper pages.

This reshaping takes two major forms: page design, and print options. Page design is stuff I can do in Word, like adding page breaks (and "Notes" pages, and "This page intentionally left blank." pages) to make sure new sections start on right-hand (front) pages, and adjusting space between paragraphs and illustration sizes to make nice full pages, and making sure every document's length (in pages) is a multiple of four.

I went to some effort to explain why that last bit matters. It has to do with printing on both sides of a double-wide sheet, and then folding it in half (producing a four-page fold called a "signature," which was a word I totally blanked on during the class). The reasons for this are complicated and partly apocryphal, but mostly they're just uninteresting. I won't bore you with the details.

Then there's print options, such as which print method you want to use. Offset printing (using big acid-etched copper plates and rolling rubber mats) is still far prettier than digital printing (using, y'know, lasers), but it's prohibitively expensive for small press runs (anything less than a hundred thousand copies), and it requires a lot of set-up time. As a technical writer, that's a really difficult balance to hit sometimes. As...anyone else, it doesn't matter. Offset printing is just outside the price range of the housewife putting together a cookbook, and printing contracts at most companies are handled by accounting or documentation departments, not the programmers and engineers who are taking my class.

Still, it's the technical process by which we make real things out of the documents they're building in Word, and I felt like I should go over it.

I also discussed the various binding methods -- from three-ring binders and spiral-bindings to the hardback ("case" binding) and paperback ("perfect" binding) you'll find on the shelves at B&N. I discussed the benefits and drawbacks of each, showed some samples, and then moved on.

Writing to a Deadline
Writing to a deadline is the biggest challenge of the technical writer (whether it's a job title or just a job requirement). The nature of the deadline varies from shop to shop, and I demonstrated that by talking about my personal experience again. At Lowrance, we typically received an assignment with three days to build a hundred-plus-page book. Sometimes we had to turn it overnight. At the FAA...the Maintenance Handbook project I just finished was one of my top priorities for most of the last year. Once it was officially given to me, the deadline was a vague "soon" for months before it became, all of a sudden, "Friday."

There's a commonality in both cases, though. In all technical writing, really, the information you're supposed to be putting into a document comes to you at a trickle -- an agonizingly slow trickle at times. At Lowrance, we knew what products were in the works for months, but it would be three days before packaging before we had a working model to test and grab screenshots on.

Your job as a technical writer is to get as much information on paper as you can, as early as you can, without wasting too much time. That last bit can be the tricky bit, because we could easily have built a bunch of documents at Lowrance using early emulators, and then had to scrap 90% of our work because of a single software change (and we often did).

The other difficulty you'll encounter when you're writing to a deadline, I told them, is that you'll get called into meetings, or have to attend training, or deal with any manner of pompous windbags who monopolize your time to tell you about something incredibly important to them, but that has no relevance to your project (or your life) whatsoever.

The best thing to do in those cases, I've found, is to have your laptop open on the table in front of you and just spend the whole lecture working on your project. (That got a laugh.)

Work Time
That whole lecture took forty minutes or so (as intended), and I left them the rest of the time to work on their projects and ask questions. They did, and some even hung around after the end of the period, so it was 2:30 before I headed home.

I sent out an email later that week to let them know the following Tuesday would be exclusively work time. I promised to be available (in class) if they had any questions or needed advice, but that I wouldn't have a lecture prepared, and I wouldn't be taking attendance. I also sent an email to several of the other professors inviting them to stop by and keep me company, because I didn't expect any of my students to actually show up.

Week 13
Some of them did. Three, actually, which doesn't sound very impressive, but it amounts to 20% of my class, so it's not too shabby. I barely broke 50% on Week 12, and I did take attendance that week. (That was my only low week, though, and they did know it was going to be partly a work period.)

Anyway, I had some great questions from the students who showed up, and I'm pretty confident they're going to have great projects to turn in. I also got to chat with one of my students about Google Wave for half an hour, which was both fun and educational.

Oh, and I got all my dailies done. So it was a productive period all around.

All I've got left now is presentations, evaluations, and the final exam. Oh, and the grading. I tremble at the thought of all the grading to be done. Still, the semester is mostly survived, and I think I've done some real good. Yay me.

More next week.

The OC (Week 11)

This post is part of an ongoing series.

Scary Professor Guy
I brought back Scary Professor Guy to open the class this week when, two or three minutes into our class period, one of my Juniors was still trying to get one of my Seniors to help her with her programming homework.

I barked, "Okay, okay, go sit down. We're not here to talk about programming, we're here to talk about technical writing." She blushed a little and went back to her seat, I had all eyes on me, and said, "Right. Today's class topic is 'Programming as a Technical Writer.'" That got a laugh.

Talking Points
Before we got to the lecture, though, I had them go around the room and everyone described his or her semester project. Briefly. I had a couple goals in mind with this, but the main one was just to force them to think about their semester projects. They did that three weeks ago when they wrote up their proposal, and probably not a moment since then. So I sent out an email last weekend letting them know they'd be responsible for talking about their projects during class on Tuesday.

Their assignment today (due next Tuesday) is a progress report, but I was hoping the threat of public speaking would drive them to get started a little sooner, so they'd actually have some progress to report.

I imagined it could take as much as half an hour to go around the room (leaving me forty-five minutes for my lecture) but I went ahead and prepared an hour's worth of material just in case. In reality, it took fifty minutes to go around the room, so I not only cut the disposable fifteen minutes, I had to do some major compression on my core lesson.

The presentations were useful, though. I'm sure the students were bored of it about halfway through, but most of them were encountering (or will encounter) similar problems and frustrations. Most of those problems are inherent aspects of technical writing, so it's not like I could give them advice to get around them, but at least they'll know they're not alone.

Programming as a Technical Writer
I'd sort of looked forward to this lecture ever since I found out just how many programmers I had in my class -- my opportunity to show them how useful programming can be in tech writing and (just in passing) how incredibly cool I am, as I've done all these things.

The better I got to know them, though, the more I realized that the stuff I had to tell them didn't merit a class (or two -- I'd originally scheduled another lecture on "HTML, XML, and Structured Documentation," in addition to this one). I've got three English majors who could all really benefit from a course in each of those topics, but I wasn't going to be able to teach them Python in seventy-five minutes, and I couldn't justify making all my programmers sit quietly while I tried.

So, instead, I adjust my focus. Instead of trying to teach when and how to use which tools, I converted my case studies into object lessons. That may seem like a pretty narrow distinction, but it's a matter of scale. I only had twenty minutes, anyway, so I briefly described several of my big projects (in terms of efficiency improvement), and then I leaned heavy on the take-away lesson.

The take-away lesson is this: automating tasks can be difficult to set up, but it makes those tasks easier every time you have to perform them afterward. Your job is to determine (and it's a matter of constant re-evaluation) if the set-up expense is worth the efficiency reward.

If you're a programmer, that expense is often just the amount of time it takes to make and refine your program. I have half a dozen examples ready to hand where I was able to save hours and hours off of every document we produced with just a couple hours of research and coding. If you're not a technical person, though, that expense can require weeks or months learning a new skillset, or days refreshing your understanding of one you haven't used in a while. Still, there are some projects large enough that a semester of training is worthwhile to write a script to process the thousands of pages of data you'll be dealing with.

I didn't try to teach them how to do anything specific. I would have, if the projector had worked like it's supposed to. I would have probably kept them late so I could show them how to put together a quick VBA macro in Word, but now I'll just save that for a Thursday tutorial later in the month. As it was, I just told them about a couple times in my experience where quick Python scripts or clumsy VBA macros made my life much, much easier.

Progress Report
Their assignment today, as I mentioned, is to write a progress report on their Semester Projects. I had them create Google Docs account last week, so I decided to make this week's assignment be a new Google Doc. In their tutorial I showed them how to set up and format a Google Doc from scratch, and then how to load and modify a Google Docs template to achieve a similar (but prettier) effect. Now they're supposed to fill in one of those two documents with the information required by their assignment, and then share it out to me.

I'm anxious to see how that goes. I'll let you know.

More next week.

The OC (Week 10)

This post is part of an ongoing series.

Pulling My Punchlines
Last week's class was disappointing. I think, of all the classes I've prepared this semester, the only one I was more excited about (beforehand) was the one with the band flyers. That time I was excited about the in-class activity, though. This time I was excited about the lecture.

Because I had good material. Dad told me before Week 2 that I had to focus on how I could make their lives better, and this class was all about that. I had so much good information to impart, I just knew it would be a great class.

And it was not, by any means, a bad class. The information was good, the students paid attention, I filled an hour but didn't keep them late. It was a good class, but it lacked punch. None of my excitement really got through, because (for the first time) I felt comfortable enough before class that I didn't invest much preparation in the presentation. Turns out, I'm still not a natural. I didn't have any punchlines, so I'd spend ten minutes telling them how cool this feature was, or how that program worked, but I failed to drive home how it would impact them. I guess a good activity could have served that purpose, but I had so much I wanted to cover that I didn't really have time for one.

Or...well, I did. It just wasn't in-class. I'll talk about that more later.

Markup
The class covered "Collaborative Writing and Editing Tools," and the most basic of those is markup. Markup, as I told them, is the process of providing feedback on a documentation product using a consistent, somewhat standard set of marks and symbols. You're probably familiar with the paragraph mark, which can be penned into the middle of a long paragraph to recommend a good spot to break it up. You might be familiar with the strikethrough line ending in a little swirl to indicate text that should be removed. If you don't do a lot of markup, you're more likely to just cross out text you think should go.

There are a bunch of standard marks, but there's also a bunch of standards, so it's hard to find one reliable set. Because of that, I stressed "consistent" more heavily than "standard," and showed them (very quickly) how to look up a set of editing marks online.

Before I got to that, I had a little slideshow ready, and I flashed hand-drawn samples of my personal markup on the screen, and asked them to identify the meaning. They've been getting markup from me all semester, so they had no trouble with that process.

The problem with markup is that it's slow. A document's author has to create a baseline document, get it to an editor, wait for the editor to suggest changes, and then incorporate those changes into his baseline. If the author tries to continue working while that's going on, he risks invalidating much of the feedback he'll get from the editor. If he wants several different people to review his document (without a lot of wasted effort) he has to go through the whole process separately (in order) with each editor.

Track Changes
Word makes things a little easier by allowing direct modification within documents. Instead of printing out a copy for my boss to mark up, I can email her a copy of a document I'm working on and she can make any recommended changes directly. To preserve author control, she can activate a tool called "Track Changes," which allows Word to keep track of every modification she makes to the document.

When I get that document back from her, I can change some view settings to see what the original looked like (my document), what the final looks like (her suggested version), or "Final with Markup." Turning on that last option shows me a visual record of every change she made, and I can right-click any one of those and choose "Accept Change" or "Reject Change." Once I do that, the markup goes away, and I'm left with the text I want, as the document's author.

That only eliminates one step in the markup process, but it speeds things up a lot, and it allows the editor to make much more detailed suggestions (in the form of actual changes). Word also offers a Comment which allows an editor to attach a note to a document he's reviewing without actually modifying the text any. Something like "Should we say more here?" maybe, or "Check this figure number."

The nice thing about all of this is that I can keep all of the markup available when I need it, but just change my viewing option to "Final" when I need to see (or print) a clean document.

Collaborative Writing
Still (you all knew this was coming), markup is just a clumsy process given the tools we have available now. After talking through the ways we can do markup, and get the most out of it, I opened up my Google Docs folder on the screen and started really preaching.

With tools like Google Docs, it's easy for multiple authors to work on a single document. By way of example, I opened some of the (many) documents in my folder. I showed them my Class Topics document, which I keep on Google Docs so I can update it from anywhere, whenever I have a moment and an idea. I showed them a spreadsheet I use to track some stuff I'm working on in WoW, just as a sort of virtual Post-It Note (to stress the simplicity of creating and maintaining documents). I showed them our NaNoWriMo spreadsheet, as an example of one that has a lot of editors viewing and modifying all the time.

When that one went up, I launched into my little speech. "This makes it easy for any of us to open it up at any time and update our word count--"

And someone said, "Yeah, and you can see just how bad you're doing." At that point I had about 1,100 words, which put me dead last among the people on that list, and around 1/5 of my target, so I didn't disagree.

Someone else said, "Wow, Courtney's really smoking!" She was a hair shy of 6,000 words.

So I came out from behind my podium, shaking a finger at them, and said, "Oh, yeah, sure. But she's a full time novelist. That's what she does. And me? I've got a day job. I've got two kids. Oh, and I've got to teach you guys." I put some venom in that, and they all laughed.

Real-time Feedback
Then I opened a couple more documents, copies of Gods Tomorrow that I'd shared with Carlos and Courtney, and showed them how they'd provided feedback right in the document -- Courtney with color-coded comments between paragraphs, and Carlos with footnotes, that behave just like the Comments in Word.

That's really my favorite use of Google Docs, because it lets me watch a reader reading my books. That has got to be the greatest thrill for a writer.

Change History
Of course, giving them the ability to change my documents creates a little bit of a security concern. Both of those documents were copies of my original, but to get the most out of collaborative writing, you're eventually going to have to relinquish some control, and that creates the possibility for a reckless editor to really mess up a document.

Google Docs (and, really, any modern collaborative writing software) handles that by tracking changes. I can open any of my Google Docs and view a list of every change that has ever been made to it, all the way back to the original blank page. Not only that, but I can see who made each change, I can compare versions, I can revert to an old copy. It's incredibly powerful.

So I talked through that process, and (really like everything I'd shown them in Google Docs) it was mostly showing how Google had implemented useful collaboration tools available elsewhere, because I'd started the class talking about version control software, and how to make the most of it. The real key is to keep on top of the changes being made to a document you're responsible for -- know who's working on it, what they're doing to it, and be sure to catch any serious problems early. As long as you're paying attention, it's easy enough to protect the quality of your document in a system like that.

The Punchline
To close the class, I opened a final document on the screen -- the instruction sheet from an AirSoft gun (which is to say, really terribly translated English with some cheap illustrations). You can see the original here, if you're curious. For the Google Doc, I just copied all the text over verbatim, and put it in a plain text document.

Then I told them that their assignment for the week was to fix that document. On Thursday, when they got their tutorial, I walked them through the process of setting up a Google Docs account, and then required them to send me a copy of the email they'd used. Once I had that, I invited each of them to collaborate on that document. I also set up a spreadsheet to use for presentation sign-up, instead of passing around a sheet of paper at the next class.

That, I think, will do more to sell them on the usefulness of this information than anything I did in class on Tuesday. They'll be able to see collaborative editing in action, they'll see their classmates modifying a document they have open in real-time, and at the end of the day they'll have a Google Docs account set up. It's another weapon in their arsenal. They're better able to handle real-world writing challenges this week than they were last week, and that's really all I was ever going for.

More next week.

The OC (Week 9)

This post is part of an ongoing series.

Life is Funny
I started class today with story time. See, one of my students mentioned a couple weeks ago that he didn't need to do the Employment Packet assignments because he already had a job. The Employment Packet assignments require them to research job openings, and develop a resume (and practice their business letter writing skills a couple more times). While I'm at it I'm teaching them some advanced styling techniques in Word, but that's just an added bonus.

Anyway, today I started out by asking how many of them already had professional-level jobs or internships, and nearly all the hands went up. I wasn't surprised by that -- I've been getting information about their career status from them since the first assignment. Next I asked them how many really believed that would be the last job they ever needed, and only three or four left their hands up.

And, y'know, I've read their company profiles, and it's quite possible. Still, I said, life is funny.

See, when I took that class in my senior year, I had no idea I would be a technical writer. In fact, just a few weeks before I was a technical writer I had no idea I would be a technical writer. I'd spent college killing time in the emptiest of the computer labs as a lab technician, and then supplementing my income by playing Asheron's Call.

I told them that story, which was fun. I told them how I'd played AC and harvested singularity keys and sold them on eBay. Then, one day, Toby said he could probably write a program to handle that process for me, and we made the Damion bot. By the time it was done, I spent a few months making a couple hundred bucks a week off that.

Then I graduated, and a couple hundred bucks a week wasn't going to cut it, so I had to get a real job. I got lucky there, because our department chair put me in touch with Mark Lee at Lowrance, who was looking for a new technical writer. He needed a resume, though.

What was I going to put on my resume? I had the writing degree, but all my writing samples were poetry and chapters from a dragon-rider novel. I put down the lab tech job, and my only other work experience before that was as an assistant at a private elementary school. I probably included that. I didn't list "Professional video game player" as an occupation, but I'm sure I put video games under interests....

Then I went for the interview, and Mark listed all those things. Eyebrows raised in a question, "Says here you're interested in...video games?" And I nodded, feeling stupid, and he said, "Y'know, the problem with posting a technical writing job opening is that you get all these applicants who know how to write, but don't know anything about operating the devices. You sound like the kind of guy who could play with the gadgets we make, figure them out, and then explain them in a manual. That's exactly what we need."

Life is funny.

A little while later, Toby applied for a job there, too, and it happened to come just as our company was adding a new product to our development -- turn-by-turn GPS devices. In Toby's interview, he told them the story of designing the software that guided my character through dungeons to gather singularity keys for me while I slept, and that pretty much got him the job. Half a year later, he was in charge of developing the turn-by-turn software.

Life is funny.

Auto-generated Text
That whole bit was more mentoring than Tech Writing teaching, but it made a great introduction to my class lecture, which was on auto-generated text in Microsoft Word. I told them that when I got to Lowrance, Mark was still building Tables of Contents for the manuals by hand. It was dozens of hours of work tacked on to the end of every single project, and it was a huge source of errors (because it's so easy to leave in a mistake and never notice).

That same spirit of poking around and figuring stuff out that Mark had thought would serve me well with the product documentation came into play with our documentation process, too. I got irritated trying to correct a broken ToC one time, and decided to see what sort of tools existed.

Turns out, Word has a pretty impressive ToC generator built right in. The trick is that you've got to use consistent, well-designed heading styles. That's some of the "advanced styling techniques" I talked about earlier. I've spent the last month telling them how to develop these styles, and requiring them to use section headings in all of their homework assignments just to get them ready for this.

All of those assignments have been accompanied with tutorials I developed -- six, so far -- and each of those tutorials has been structured using a single set of custom styles (chapter heading, section heading, paragraph heading, body text, bullets, block quote, image, and caption). By now the students know well enough how I made those styles that they were able to grasp the significance of each of them.

So I pulled up all six of their tutorials on the overhead, and copied and pasted them together into one big long document, the chapter heading style automatically separating the different tutorials into chapters. I had to make a couple little adjustments (give the heading styles appropriate Outline levels, and make a clone of the chapter heading for the ToC title), and I explained what I was doing as I did it, but about ten minutes into the presentation I was able to scroll to the top of the document, choose Insert | Quick Parts | Field | TOC, and hit OK.

A fully formatted, populated, beautiful Table of Contents appeared on the page. Someone in the back said, "That's awesome!" Somebody else said, "You cheated!"

Exactly the response I was looking for.

I showed them some more stuff along the same lines. We added automatic chapter numbers, and figure numbering in the captions, and then we built a Table of Illustrations to go with the ToC. We fixed the page numbering so the front matter had little roman numerals and the first page of chapter 1 was labeled 1 (instead of 5).

Then we went to the header and put in a field that shows the chapter title on the top of every page (so if you're in the middle of chapter 4, you know it's chapter 4). All of that took about forty minutes. Maybe a little less, and when we were done we had turned a handful of documents into a real book.

It was easy...but only because we'd done our work beforehand. Everything I did relied on the consistent use of well-designed styles. Because all of my chapters used Tutorial Chapter style, and every single section heading was Tutorial Section, and every caption was Tutorial Caption, I was able to do these things. That was really the main point of my lesson for the day. I don't expect any of them to be able to build a ToC or add a StyleRef field to a document on command. I do expect them to be able to build a document that could support those, though. And if they ever have to work with one that does, I expect them to be able to recognize what's going on, and use the built-in styles appropriately.

It was a pretty straightforward lecture day, divided evenly between story time and presentation, and when I got to the end of the presentation I let them go. I'd thought about having them build an Index as their in-class activity, but I'm pretty sure that would have taken hours. I filled fifty minutes as it was, and the lingerers and hangers-on kept me in the classroom, talking, until well past 2:15.

More next week.

The OC (Week 8)

This post is part of an ongoing series.

The Anxiety Persists
So, I've been through this often enough now that I can make a pretty good analysis of the situation. Early on it seemed like my pre-class anxiety was getting less and less as it moved from a weeklong problem to one that only took up a couple hours.

With only really one exception, though, I've realized that the total severity of the anxiety remains constant, regardless of the duration. That is to say, as my downtime has decreased, it has gotten worse and worse. I spent two hours before class today confident that I was about to die.

Then one o'clock rolled around, I cut off their chatter with a relatively quiet, "Okay," and I felt fine. Really every week since the first has gone like that. I don't have any trouble talking to them anymore, it's just waiting for class to start that gets to me.

National Novel Writing Month
Of course you knew I wouldn't pass up the opportunity to promote NaNoWriMo while teaching a writing class, but I refrained from offering extra credit. Enough of my students have expressed an interest in writing novels, though, that I felt pretty confident making the plug. I started the class out with that, and mentioned that it had "about as much to do with Tech Writing as that conversation about DeBord's grading practices."

Still, I recommended it and wrote the URL on the marker board. Incidentally, that's the first time I've used the marker board.

Information
From there I went to the lecture, and my big point for the day was that Tech Writing is about more than just writing down information. Information is more available than ever, but most people have trouble using information. The role of the Tech Writer is to convert existing information into a usable form -- and often to convert the same information into multiple forms.

On that last point, I titled the lecture "Repurposing Documentation," and I described my work environment to them, where every little change to the system requires us to document the status quo, the proposed change, and the predicted effect of the change according to a very specific standard. Well, no, seven very specific (and very different) standards. An Engineering Study requires all of that information in five to ten pages, whereas a Safety Risk Management memo requires it in one short paragraph.

And, I pointed out, until they hired me five years ago, it was the engineers and programmers on my team who were writing those seven different documents for every single project. That point probably hit home. My major focus for the last several assignments has been on finding best practices to minimize the effort of properly formatting documents, which really comes in helpful when trying to repurpose information from one project to the next.

Doing It with Style
I followed that up with a brief demonstration. I pulled up my tutorial for Thursday ("How to Write a Resume") with no real formatting to it. Everything was reduced to Word's Normal style. I asked them to identify it, and they said, "It's instructions on how to write a resume." I waited for a more specific answer, and someone said, "It's poorly-formatted instructions on how to write a resume." I didn't really get a better answer than that.

So after a moment I said, "This is actually your tutorial for Thursday--" and I got a wave of surprised realization from them. That...wasn't really how I expected that to go. I use exactly the same wording in the introductory paragraph of every tutorial, so even without the formatting it should have been pretty clear. I guess it made the point better that way (how much of an impact formatting has), but it wasn't what I expected.

I went ahead, though, and asked them to help me format it. They've seen five tutorials now, all with consistent styling, so they were able to tell me where I needed to add spaces between paragraphs, where I needed to bold or change font sizes or change font styles...and after a little while I revealed to them that the document already had custom styles in it, so I could show how easy it was to go through the document and apply those styles.

Then, in the end, I brought up the original, unformatted document and showed it side-by-side with the one we'd just styled for comparison. It was a pretty stark difference, and that worked well.

The whole demonstration didn't, though. I'm not sure if I failed to set it up properly, or if I misjudged how familiar they would be with my tutorials, or what. I didn't feel like they engaged with it, though. Something to remember for next time, if there's a next time.

Playing Games
It didn't take terribly long, though, which was entirely my intention. As I was pointing out the differences between the two documents, I mentioned that once I had the custom styles designed and once I knew my basic template, it became just as easy to make the good tutorial as it would have been to make a crappy, unstyled one -- and look how much better the results were!

And they all agreed. So I looked around the room, and said, "Hey, remember back in week two when you guys made tutorials?" Immediately I got good-natured groans.

That was the time I divided them kindergarten-style into three groups, so today I made them return to those groups. Then I showed them where to find my Tutorial template (with embedded styles), and where to find their week two tutorials on the class's BlackBoard page. Just as they were about to get started, though, I said, "Now, before we start, we're going to make a little change. This [pointing to group two] is now group one. That's two, and that's three." Essentially, each table got assigned the document produced by the next table to the right.

Someone said, humorously pathetic, "I don't like this game!" They did a fantastic job, though. It's remarkable how much different their tutorials look now, after just a few weeks of training.

Microsoft Word 2007 for Mac OS X
Most of the time they were working on their activity, I was working one-on-one with one of my English majors who has been having a lot of trouble with the tutorials. Turns out (and I learned this about a week ago, when I got a frantic email from another student) Word 2007 on Windows doesn't really look anything like Word 2007 on Mac.

That's a problem I should have foreseen, but absolutely didn't. In the last couple weeks, their tutorials have gotten increasingly involved in the nuts-and-bolts of how to make Word apply specific style formatting, and a lot of my advice was worthless to the Mac users.

Now, their laptops can all dual boot to either OS X or Windows Vista, and the girl who initially emailed me just ended up switching to Windows to do the assignments (which, she said, ended up making the projects a lot easier, so it was worth it). Still, that's something I'm going to have to keep in mind in future tutorials, and try to find some good solution for.

We started on time, and though I released them on time, I had students in the classroom for another fifteen minutes afterward -- most of them trying to finish their activity. I probably could have cut the on-screen demonstration entirely, and they would have had more time for rewriting and formatting. I'm not sure how well that would have flowed, though.

More next week.

The OC (Week 7)

This post is part of an ongoing series.

After spending six hours or so on class prep Monday, I ended up canceling class yesterday with the following BlackBoard announcement:

Your professor has granted himself an excused absence for sickness today.

Thursday is Fall Break, so Week 7 will go down in the annals of history as one of the three least interesting weeks in this sixteen-week semester. Or maybe one of the five, depending how well the students do on their presentations....

More next week.

Journal Entry: October 14, 2009

No, there is too much. Let me sum up....

It's terribly frustrating to me that, as times get more and more interesting, I write less and less about it on my blog. That's been true of every NaNoWriMo I've been through (and how many birthday parties and Thanksgivings have been lost because of it?), and it's been true of both of my babies.

Admittedly, XP isn't doing anything terribly newsworthy. He's adorable, but that doesn't make for great plain-text updates. It's a shame, though, that when I look back at now three years from now, I won't have a very detailed record of the semester I decided to work full time and teach a college course while participating in two different writer's groups, having a new baby, and maintaining a 30-hour-per-week WoW habit. Oh, and writing. A little bit.

It's not going to get any better, either, because in the midst of all that, a NaNoWriMo is looming. All I'll have to look back on are these occasional complaints, and a word count ticker. I guess that's something....

Anyway, I've spent the last two weeks with "blog journal" as the longstanding not-marked-out item on my rolling Post-It Note To Do list, and I decided to shed the guilt and stress of that unwritten post getting longer and longer, and just write a quick post about yesterday.

I made that decision three days ago. And here we are.

There's been lots worth mentioning in the recent past, but the most exciting among them is probably B--'s new job and the party that went with it. That's more than a week ago, though, so it's lost to history. Last Friday night AB spent the evening with Diana, so T-- and I could have a date night. We went to Texas Roadhouse and then watched some TV. It was awesome.

On Saturday D-- and I went over to B-- and E--'s, because he had missed the previous weekend's party with some vile disease. Conversation and martinis, and about seven minutes of The Empire Strikes Back with RiffTrax.

Sunday the Cowboys barely beat the miserable Chiefs, and that gave us our first winning weekend of the season -- or at least the first one where I got to watch both games. It was exhilarating.

Monday was Columbus Day, which is actually a holiday for people like me, so I went to the Science Museum with T-- and the kids, then spent the afternoon preparing materials for my class.

Yesterday I woke up sick, but I went to work anyway. I did end up canceling my class, though, which gives the students a full week off because Thursday is Fall Break. Wasn't the flu, though -- I was better by bedtime. And today I'm back at work.

Other than that, it's just things and stuff.

The OC (Weeks 5 and 6)

This post is part of an ongoing series.

Week 5
Week 5 doesn't get its own post, because it would be terribly uninteresting. I gave them the day off last Tuesday so that they could work on their semester projects. I did still require them to turn in their proposals before the class's regular start time (by email), and I did still give them document assignments on both Thursdays. The first was some practical instruction on building a rudimentary, styled layout, and then filling in the paragraphs with your actual content. The second took that concept a step farther and built an actual Word template with custom styles.

Anyway, since we didn't meet in class it apparently lifted the Curse of Mr. Pogue. I didn't hear news of any life-altering drama that afflicted my students during week 5.

Life-Altering Drama
Week 6 was another matter entirely. We got the Swine Flu! Or technically (as I'm told), Novel H1N1. Anyway, OC canceled chapel this week in an effort to stem the spread of the disease on campus, and still I had two students miss class because of it, and another who left early (sniffling) for a doctor's appointment.

As a deeply-concerned educator and a compassionate human being, I really hope these disruptions stop happening. As a storyteller, though, I'm anxious to see what's going to befall my class next week. I've got sixteen students, and the class is sixteen weeks long. So far I took the bullet on week 4 (when it was the early birth of my son that interrupted class), and week 5 was a bye, but week 6 hit three students at once. So we're still on track for the rest of them to get one event per week. I'll keep you posted.

Handbook of Technical Writing
So I started my class by stepping out from behind the computer station and holding up a magnificent reference text, Handbook of Technical Writing, vol. 9. I showed it to the class, and said, "How many of you recognize this book?"

I got three or four raised hands. In the back corner, someone asked timidly, "Wait...is that the textbook for this class?"

I showed my teeth, in something like a smile. I asked, "How many of you have read anything in it?" One of them said he'd glanced at the section on copyright, out of curiosity. I shook my head sadly, and then I laid down the law.

Every one of the tutorials I've provided starts out with a list of "related topics," which are section titles straight out of the handbook. It's usually 6-10 pages worth of material, and I always read through those sections before writing my tutorials, so that I'm not repeating information. That means there's some important technical information in there that's the students aren't getting if they're not reading it.

And, I pointed it, it's information that I'm going to expect in their papers when I grade them. If it comes to it -- if I find myself having to hand out Cs and Ds because nobody's reading their textbook, I'll start having weekly reading quizzes. I don't want to do that, because this isn't information that needs to be memorized -- rather, they need to know how to use the textbook as a reference. They need to get a feel for what's in it, and how it's organized, so they can go look stuff up when they need it. I deliberately picked a cheap reference book instead of a big expensive textbook so that they would keep it at the end of the semester, and have that info handy.

So I did my best to express that, and pointed out (by way of example) that none of the multi-page proposal memos they'd turned in had used a header on the second page -- something explicitly stressed in the textbook. I saw some sheepish faces at that, but I'm not grading that one against them, because I hadn't actually taught them how to do headers yet.

Document Headers, Page Headers, and Section Headings
One of the confusing aspects of technical writing, I admitted, is overlapping terminology. For an industry built on clarity of expression, technical writing certainly accepts its share of confusing expressions.

In their first tutorial, I introduced the students to the standard business letter header (which might be a stylized letterhead, or it might just be the sender's contact info). Then the next week I showed them the standard memo header (which consists of four fields: To, From, Date, and Subject). I also asked them to divide their first memo into several sections, each labeled with a heading. Then this week I started complaining that their documents didn't have headers.

For clarity, I refer to this last kind of header as a "page header" (since it essentially appears on every page in the document), and that first kind of header as a "document header," since it only appears once at the top of the document. Actually after business letters and memos, the document header is mostly replaced by title pages, so it doesn't matter.

Still, there's room for confusion. I apologized for that, spelled out in detail what each of these elements is, and told them the trick to keeping it straight is learning the purpose of each element rather than its name. Because they serve clearly distinct purposes, and in context it's almost always easy to recognize which one is under discussion at any given time.

Introductory Paragraphs
Context. That's a word that's come up again and again in the last few weeks. In their proposal memo assignment, I told them exactly which sections they needed to include: Introduction, Scope, Methods, Timetable, Qualifications, and Conclusion. I also reiterated from previous tutorials that every document should have an introductory paragraph. One of my students wrote me during the week to ask if I intended the section labeled "Introduction" to be the introductory paragraph (ah, these overlapping terms again...), and I wrote back that, in fact, no I didn't. I sent that reply as a general email to everyone in the class, but still I got proposals that went straight from the document header into the section heading "Introduction."

So I took the chance to clarify that for them. The purpose of an introductory paragraph is to introduce the document that follows. This blog post starts with the simple, "This post is part of an ongoing series." That's not terribly telling, but it gives you some context. If blogs weren't inherently sequential, I would feel a much stronger need to tell you, in each post, why I'm writing that post.

Memos aren't inherently sequential. Most technical documentation isn't. Emails can be (specifically when they're replies), but most written communication ends up living a life of its own as an independent document. And, most importantly, it doesn't die. Long after you've forgotten about it, long after you lose track of why you asked your boss for two hours' leave in the middle of the day, the document you used to request it is still readily accessible.

More than that, it's reusable. I left aside their proposal memo and turned to email, because it makes the point more effectively. Email is something we do so casually, every day. Half the time, even business emails are just a matter of the guy from the next cubicle asking you to send him something in writing so he can remember that thing you discussed at the water cooler. It doesn't need to be anything more than, "Hey, remember that you agreed to review that document before Friday. --Aaron." We all get in the habit of jotting off quick emails.

Documents that Live Forever
The problem is, even if you know this email only needs to get to the guy in the next cubicle, and only needs to live until Friday, it sticks around. And the Forward button becomes the easiest and most dangerous thing in the world. (That comment got a laugh.) I told them that I'd written hasty little reminders like that to my coworkers that came back to me, years later, and somewhere in the list of people who'd replied in the meantime was the Secretary of the Department of Transportation. Somebody needed my opinion to back up a claim they were sending to Washington, so he forwarded my email on up the chain and I got it back long after I'd forgotten all about the project under discussion (let alone that particular opinion).

I was in the clear, though. I did get brought back into the conversation, but I was able to participate because I'm a good technical writer. Even my quick reminder email included enough of an introduction, enough context that when it popped back into my inbox my own message brought me back up to speed.

Preserving Context
That's exactly what documenting code is for, so I wasn't surprised when the concept resonated with my class. It's not an obvious concept, though. When you sit down to write a document, that's all you're thinking about. Why you're writing this document is so abundantly clear, you can't imagine a time when you would look at this document and not know what it was for. Writers run into this all the time when they try to write the cover letter to submit a novel to an agent or publisher. If I -- a writer -- am writing a letter to a literary agent, isn't it obvious that I'm writing to ask him to represent me? Why do they want introductory paragraphs? Why do I need to come up with some clear way of saying, "I'm writing to ask you to represent my novel." Shouldn't that be obvious?

The thing is, that's all dependent on information I have. I am a writer, and I'm writing to this person as a literary agent. I could be a salesman. I could be an assistant at a major publishing house. I could even be a literary agent. I could be any of those things and a writer seeking representation, or I could be any of those things and writing an identical-looking business letter to discuss something entirely different from a novel query.

The whole purpose of the introductory paragraph in a document is to provide the reader with the same context the writer brings to the document. So it always feels redundant and overdone and silly because it's stating out loud exactly what you've been thinking about since the moment you first realized you needed to write this document. The thing is, especially the way we do things today, your reader could be anybody. It goes so far beyond the literary agent having to guess if you're a writer or an industry professional or somebody trying to sell him vinyl siding. The way we save data today, the reader could be the literary agent, or it could be his assistant, or his boss. It could be one of his students decades from now, when he's given up representation and become a professor. It could be a graduate student decades later researching how I got my start in writing. It could be me decades later, looking back on where I got my start.

I still have every submission letter I've ever written. Most of them have lousy introductions, by the way. I still have most of the business letters I've ever written, for whatever reason. And I've got technical documents that I open up, scroll through a long list of technical information, and have to wonder why I pulled this information together, what purpose it served. For me, as much as for my audience, I need to write clear introductory paragraphs to establish a document's context.

Some Technicalities
All of that took about fifteen minutes. I transitioned from that topic into a discussion of page headers, which we use more than anything to stamp the document's title (and sometimes author) on the top of every page. It does for the page what the introductory paragraph does for the document -- provides context. Footers mostly carry the page number, but sometimes other legal or contextual text gets stuffed down there, too.

I pulled up the class syllabus on the projector and showed them precisely that -- every page had my name, the class name, and "Syllabus" in the header, and "Oklahoma Christian University" and a page number in the footer. By way of another example, I opened a copy of Gods Tomorrow and showed them how I used my name and the document title in the header, as any literary agent or submissions editor would require.

(We diverted into a little discussion of whether or not I'd give extra credit to them for reading my novel, when I caught some of them paying more attention to the text on the screen than to the headers and footers I was pointing out. I said no, because I already have plenty of phenomenal reviewers among you, my loyal readership. They were most disappointed.)

From there, I opened up a document template I'd built over the weekend, which consisted of two pages, landscape, with three columns per page. I walked them through the process of how to do each of those things in Word. Along the way I tried to show them how to insert Section breaks (so I could explain how Word handles different sections), and discovered that the lower resolution my monitor automatically switched to when I plugged in the overhead had truncated my menu bars, and as a result I couldn't find the command to insert section breaks.

That severely interfered with some of the other stuff I wanted to show them, so I had to go on with the lecture describing how this document would behave hypothetically if I had inserted section breaks. Frustrating, but I didn't let it get me flustered.

In-Class Activity
The whole formatting lecture only ran twenty minutes or so. When I was done, I said, "Now we've discussed some of the most frustrating things to work with in Word (columns and section breaks). I've got them all packed together onto this two-page template. Does anyone recognize this particular layout?" The only guess I got was a newspaper, but I didn't wait too long. Instead I picked up a blank piece of paper, turned it sideways, and said, "What if those columns were filled with text, and I folded along the gaps between them?'

I did so, and immediately they recognized the shape of a tri-fold brochure. So then I told them they would get to experience the agony and frustration of working with columns and section breaks, because they were going to build a brochure.

First I had them divide into small groups (3-4 each), and everyone shared with the rest of the group what his or her semester project topic was. They're each developing a new document with a real-world use, so I figured one out of every three or four would be worth promoting. So each group picked the project they thought would best fill a brochure, and got to work.

What I liked about that activity, more than the experience of making a brochure, was the way it got the students discussing their projects among themselves. They're going to have to make a presentation to the class later in the semester, but this way they were able to practice discussing the project out loud in a much less formal environment. More than that, they were asking each other questions and expressing interest in each others' projects in ways that I think will really help them move forward. And, of course, it helped that I got to eavesdrop on all of that from my place at the front of the room.

The Next Forty Minutes
I set them to work for the rest of the class period, and they took all of it. I'd intended to spend that time marking up the last of their proposals and then have them come to my desk one at a time to go over them, but I didn't end up having enough time for that. In the end, I returned all but two of the proposals in the last few minutes of class, and those two I went home, marked up, and scanned in to return by email.

It wasn't just time management that got me, though. I spent a lot of time interacting with the various groups, and they really got into the brochure project. I still remember trying to build my brochure from when I took the class under Gail Nash, and several of my classmates that I talked to about the class said that's the only thing they remember from it.

Ten minutes into it, my class clown said to his groupmates, "To be honest, I'm not really a fan of the in-class activity."

I looked up from the document I was marking up to hit him with a glare, and the English-major who'd joined his group went all wide-eyed and said, "Ohmygosh, he heard you!" Somehow, I didn't laugh.

I shook my head and said, "Oh, he's not scared of me. But, then, I haven't picked his grade yet."

That got a low chorus of, "Oooh," but he immediately shrugged it off and said, "All I need in this class is a D. This is my last semester of my senior year, and I could get Ds in all my classes and still graduate, so there's not a lot of pressure."

Someone else jumped in to lament the fact that he was also in his last semester but he'd already hit his threshold of Ds, and from there the conversation turned to which classes had been cause Ds in the past -- the primary candidates being "Western Civ" and "anything taught by Cami Agan." That one made me smile.

Anwyay, in spite of his claim, he spent the full forty minutes putting together a great brochure, and I've seen no less effort on any of the papers he's turned in. He admitted himself that he's something of a perfectionist, so even if I don't have a real threat to keep him in line, he's still going to meet or exceed my expectations on all my documents.

In the end, I think his antics keep the rest of the students more engaged and casual, and ultimately I think that's worth the little disruptions I have to deal with.

In the end, it was a pretty successful class period. I introduced Headers, Footers and Section Breaks in Microsoft Word (a topic that'll also become a tutorial at some point later in the semester), and everybody practiced looking at their projects from a slightly different angle, which is going to be important moving forward.

More next week.

Journal Entry: September 23, 2009

On Monday I told a lot of people, "Oh, it's so much easier with the second baby. With Annabelle we were up all night, every night, startling awake at every tiny sound. With Alexander, we're a lot more relaxed. I'm actually getting a lot of sleep."

On Monday night, he proved me a liar. Bigtime.

So, as a result, I woke up late yesterday and I was dragging. I went in to work anyway, and stumbled through the morning's responsibilities, and then spent my lunch break grading papers, and then darted out to OC for my fourth week of class. I will, of course, tell that tale elsewhere.

I had several students hang around after class to talk with me, as I'll mention in my recap. That was awesome, in the sense of making a connection with my students, but it was draining in the sense described in detail in last week's link, Caring for Your Introvert. On top of that, everyone I interacted with at work all day wanted to talk about the baby (and, frankly, I did too...but it's still tiring). Then I got home to a full house -- T--, two babies, and two in-laws.

It's nothing but whining about blessings, but all that interaction got to me yesterday. After three weeks of getting crippled before my classes by anxiety -- for days on end -- I managed to get away with fewer than three hours of anxiety problems this week, and they could be gone altogether by the next time we meet for class. But my night was still shot just from interaction exhaustion.

T-- let me hold Alexander as soon as I got home, and I took him to the couch and AB came running up to see him, and I asked her all about her day. At the same time, T--'s mom and dad got home from some shopping they asked me all about my day, and it was all perfectly nice but for some reason I just wanted to cry.

So I handed the baby off to his Papa, and then when no one was looking I slipped off to the bedroom to hide in the dark.

Karla and John naturally picked up that something was wrong, and they know me well enough that they were able to guess what, and they said they'd be willing to head home early if I needed a little alone time before my family showed up this weekend. I replied to that with an emphatic no, because they're doing so much to make our lives easier. I really, really appreciate all their help. I've just got my own crazies, and the demands of the situation don't really allow for any good outlets. It's a pretty short-term problem, though, and one I've weathered countless times before. I'm not going to go turning away good help just because I'm feeling a little uncomfortable.

Anyway, there was bacon on the griddle and brisket in the crockpot, so I didn't stay in hiding for too terribly long. I came out for dinner and then took sanctuary behind my laptop for the rest of the evening hours, while we watched Word World and Lie to Me. Then, when the rest of the family had gone to bed, I stayed up a little longer in the still silence and finished off Newsradio. Such a great show.

Ah. I did have one actual problem yesterday. T--'s laptop is dying. It takes forever to boot into Windows (if it does at all, before locking up), and then when it loads it gives a complaint about accessing the user profile and loads a temporary profile instead. It seems pretty clear that it's a hard drive problem -- probably from AB knocking the laptop off an end-table last week while she was watching videos -- but there's a lot of photos and T--'s work stuff on that hard drive that we're going to be incredibly frustrated to lose. And, y'know, no laptop. I don't cherish the idea of sharing mine with T-- and AB. We all have very different ideas about what a computer should be doing, and how it should be handled.

So, y'know, that's going to be a mess. Probably an expensive one, but sometimes we're saved by hand-me-downs and free IT services from friends we're all-too-happy to take advantage of. So I'll let you know how that turns out.

Other than that, it's just things and stuff.

The OC (Week 4)

This post is part of an ongoing series.

Technical Difficulties
I had 13 of my 16 students at 1:00. I waited a couple minutes and a couple more showed up, but the rest were in full chatterbox mode by then. I'd spent the last ten minutes at the podium, getting my visual aids ready for the day's discussion, but I figured if I waited too long, things would get out of hand.

So around 1:02 I stepped to the center of the room and said harshly, "Okay, okay, okay! Enough chit chat. It's time to stop gossiping and talking about your other classes, and focus on this class! I'm going to start the lecture now."

Then I stepped behind my laptop, and plugged in the cable to project my monitor onto the overhead. Nothing happened. I had my visuals all ready, but the screen kept displaying a blank screen. Some wiseguy in the back row said, "He probably just wants to show us pictures of his baby." I unplugged it and plugged it back in. I punched buttons.

Finally I sighed and said, "Well, yes, that was the whole joke. But this thing won't work."

Just as I said it, half the class (I'll let you guess which half) went, "Awwwwww!'

My first visual aid was this:



Someone immediately said, "Wow, she was born big."

I smiled, let the laughter die down, and said, "This is a picture of my beautiful, happy family about a week ago. I call it 'Before.'" Then I showed a couple I'd tacked together in Photoshop.



And I said, "And here's a picture of my beautiful but oh-so-tired family now." And then I said, "Of course, you can see the baby in both those pictures, but in case that's not quite enough....



Schedule Changes
I've had three real classes so far (not counting day one, when we just went over the syllabus and the class schedule), and in each of those classes I've had to dedicate some portion of the lecture to changes to the class schedule. This week, no surprise, was no different.

I moved straight from the baby photos to business. I pulled up the revised syllabus, and explained that I had rearranged the schedule so I could talk to them about their Semester Project today and then give them a work period next week. In the process, we lost the Promotional Brochure (something Gail had already cut in between the time I took the class and the last time she taught it, but I'd added it back in). Now, instead, I think I'm going to use it as an in-class activity on the day we talk about templates.

Anyway, their job is now to come up with a proposal for their Semester Project, and then once that's done we'll move on to the Employment Packet.

Subject Matter Experts
From there, I transitioned (weakly) (deliberately) to a mini-lecture on the topic of Subject Matter Experts -- a phrase (I explained) that they would encounter much in the business world. It's a vague sort of title, but refers to the person you'd go to for clarification on any given topic. Here at the FAA, I explained, we all work on radars, but if I need to talk to somebody about the antenna sail for the ARSR-3, there's one engineer I'd go to. He's the expert on that subject matter. I'd go to someone else if I needed information on the air conditioner, and someone else still for details on the speed controller.

And I explained that there's not really a scale to these things. For any given topic, someone either is a Subject Matter Expert, or he's not. The interesting thing about Technical Writers, though, is that they almost always start out not, and end up Subject Matter Experts. It's just part of the job.

By way of illustration, I pointed out some specific topics for which I've gone through that process:

• Industrial depthfinders
• Commercial fishfinders
• All manner of nautical and aviation sensors and gauges
• GPS satnav (straight-line navigation)
• Hiking and hunting personal GPS receivers
• Nautical GPS receivers
• Aviation GPS receivers
• Nautical vessel data networks (more on that later)
  
• Turn-by-turn navigation (driving directions)
• Automotive GPS receivers
• Automotive mp3 players (and audio interfaces)

And that, I said, was all at my first job.

I took a moment to point out some of the distinctions -- how some of those might look like they overlap, but there's a big difference between understanding how GPS satellites and receivers know where you are, and understanding how to operate the menus and screens of a particular type of GPS receiver.

I had another, similar list for my work at the FAA (8 items), and then listed three topics on which I've become a Subject Matter Expert in my free time: Novel-writing, Python programming for XBMC (I just rattled off that phrase and then held up a finger and said, "More on that later"), and Technical Writing (for this class).

Learn by Teaching
I said I knew they'd all heard, somewhere along the way, that teaching a topic is the best way to learn about it. I've certainly experienced that in preparing this class. I pulled up one of their weekly document-writing tutorials on the overhead and pointed it out as an example. I said that my group at work has to prepare a specific type of memo for every single project we release (the Safety Risk Management Decision Memo), and that we deal with lots of memos regularly. So when I wrote up my tutorial "How to Write Memos and Emails," I shared it with my boss -- Irene, our Documentation Team Lead -- and asked her for feedback, knowing she was familiar with the topic.

She responded to say she was amazed how much she learned about memos from it, even though she deals with them everyday. I stressed her job title when relaying that to the students, and they were suitably impressed with the comment.

Python Programming for XBMC
As a better example, I told them about Python Programming for XBMC. I had to start out by explaining to them what XBMC was, although I had one student raise his hand to interject that his XBox had it on there. Anyway, I have a pretty technical group, so it didn't take much to explain what XBMC was.

So then I told them how I'd first installed XBMC wanting to use it to stream media to my TV, but I was excited to learn it could run Python scripts -- simple add-ons written in a programming language I was already learning. I went online to find out how to do that, and everyone pointed me to this one resource -- a tutorial written by a French Canadian (that got a laugh), with no formatting whatsoever, and a lame attempt at humor (that got a laugh). So, in order to learn what I needed to know, I had to take this tutorial and translate it from English into English. (That got a big laugh.)

And I was only six months out from taking my own Technical Writing class at the time, so I decided that while I was doing the mental conversion anyway, I might as well fix the document for everyone else. And I had it up on the overhead so I was able to point out the specific formatting elements I'd used that I had already taught them in class (just last week).

Then I stepped away, and said, "I know it's a pretty niche community, but if you go to Google and search for 'XBMC Python,' you'll get my website." That got some impressed nods. "Because of this document," I explained. "It's not great technical writing...it's not even accurate anymore, because I haven't touched it in six years. But it's still the number-one-recommended, go-to source for information on this topic. Because of the research I did."

That's a certain kind of celebrity. It's not a huge deal and (I pointed out) it's not the biggest reward for doing this. The big reward is that, in the process of fixing that document, I learned what I wanted to know. I learned how to do everything with XBMC Python programming that I wanted to know.

Because I had to fully understand the material the original author was using, in order to translate it correctly -- from English to English (that got a laugh again). Not only that, but when I took the time to format it properly, to set the information in a structured framework, it became clear what was missing, what was underrepresented, what was excess. I was able to see what extra information was needed, and research that on my own.

The NMEA Bible
Then I brought up a third example -- the "nautical vessel data network" mentioned in my list of topics above. When I was working at Lowrance, big news came down from the head honcho that all of our products were going to become NMEA 2000 compatible. (It's pronounced "nee-muh," and don't ask me to defend that. Actually, I said the same to the class and followed up with, "The pronunciation was picked by boat people," no real emphasis, and it got a laugh.) But, yeah, our products were going to be NMEA 2000 compatible, and we needed a blurb in the front of each of our manuals expressing that and pointing the customer toward the sales department for more information.

We didn't have the first clue how to word that, though, because the whole phrase was nonsense to us (the tech writers). Turns out NMEA 2000 was a hardware standard that created an information bus for boats. I asked what that meant and I was told it was "like a LAN for a boat." Except that it had nothing to do with computers. After much investigation, I learned that it was used to connect sensors and monitors on a boat, so you could get a GPS signal at the front of the boat and share it to GPS monitors in three different places, or copy fish echoes from one transducer to multiple depthfinders -- that sort of thing.

But it was more complicated than that, because the network cable could be split and coupled and daisychained and all manner of nonsense, and you had to have exactly the right cable for each device that you wanted to attach for each possible configuration of what you had on your boat.

So I went to the Subject Matter Expert -- the one engineer in our company who really understood NMEA 2000 -- and asked him to explain it briefly so we could come up with this one-paragraph blurb.

Three hours later we left his office so we could move to a conference room with a whiteboard. Three weeks later, I finally understood it well enough to write that one paragraph.

But, while I was at it, I wrote down everything he'd explained to me in a way that I could still comprehend six months after our conversations. I went ahead and put it into our manual format, because that was what I was familiar with. When I was done, it came to around eight to ten pages, all formatted and illustrated, and it explained exactly what a NMEA 2000 network was, and how to configure one. I saved a copy on my desktop, printed off a copy for Mark, and went on with my life.

Then six months later there was a big meeting going on, that involved all the senior engineers and the CEO of the company, and they were arguing about something in design and two of our senior engineers couldn't agree on exactly how it was supposed to work, so somebody said, "Wait. Where's the NMEA Bible?"

And somebody else pulled out a copy of my pamphlet. The NMEA Bible. That had become the in-house nickname for my personal cheat sheet. The engineers -- the people who were designing these systems every day for years -- were going to my little pamphlet for reference.

And that was my point. I started out as someone who knew nothing about the system, and in the process of filling out my document, I became the reference. I took the information that one person had, and translated it from English to English, and made it available to all the people who needed it. That's what Technical Writing does.

The Semester Project
From there, I moved on to discuss their Semester Project. After all, I said, the purpose of the project was to take them through the same process I'd been through in each of those cases, and turn them into Subject Matter Experts through the process of documentation. I'd asked them last week (after the baby was born) to scrap their earlier assignment and instead read over a brief description of the Semester Project, and come to class with three possible topics that they could work on.

So after my mini-lecture, I said, "How many of you read the assignment?" and got all hands. Then, "How many of you understood it?" and got significantly fewer. "How many of you had trouble coming up with three topics?" got pretty much everyone. I paused a moment and said, "How many of you had trouble coming up with one?" That got more than I was hoping for.

Still, it was anticipated. I moved to the center of the room, and said, "The goal of this project is for you to make something of real-world use. That's actually a requirement. So, to make that possible, I have to leave it a little bit vague. You don't have a solid minimum or maximum word count, you don't have a specific document type (although I want some sort of long-form document). You don't even have a specified audience. You have to find an audience and then convince me they're legitimate."

I nodded, and said, "I understand all that. And I understand that's not fair to you. The solution is for you to talk with me. Ask questions when you're unsure, schedule an appointment if you need more time, email me, call me. Whatever. I'm deliberately leaving room in the schedule for you to request clarification, because you're going to need it. And that's what the rest of today is."

Q and A
That was at 1:40. Frankly, I'd expected 1:30. Still, they could have gotten up and walked out, but I guess there was enough uncertainty that I had them scared. I said, "So...any questions?"

Five hands went up, and I turned to the first girl on my right. She said, "Umm...what are we supposed to do?" That was not a positive start. Before I could formulate an answer, she said, "I mean, what are we supposed to write about? I get the feeling it's supposed to be technical, but I am so not a technical person."

So I asked her, "What are you interested in?"

"Books," she said, right away, and I froze. My mind started working frantically, trying to come up with something associated with books that could have a real client, and really match the framework of the document. Before I came up with anything remotely close, she said, "Oh, and baking."

And I lit up at that. So much easier, because baking is a technical process. As soon as she said it, I thought cookbook. After a little discussion, I suggested she could find a ladies' group for an area church that wanted to put together a cookbook for a fundraiser. That's a pretty common thing. Her client could be the woman organizing the effort, her research could be the gathering of recipes (and any follow-up necessary to translate scribbled notecards into useable information). She'd have less writing to do than some other possible projects, but she'd have a whole lot more formatting than some projects would require.

She was perfectly happy with that. She loved the idea, and it gave the rest of the class some idea of what I was looking for.

Musicians
Another girl in the back corner raised her hand to ask, "Can it be something for a musician?" I must have looked pretty blank at the question, because she clarified before I could ask her to. "I mean, like maybe a musician could use some sort of promotional material or something...."

I figured she was talking about a classmate or a roommate, some music major looking to strike it big, but that didn't worry me. I ducked my head and said, "The problem you're going to run into there is that promotional material is usually shorter, bite-sized. I want something that will generate a single, long-form document. That said," and I addressed this more generally to the class, "you can always ask what they actually need. Because everyone has some technical writing that they need done, and there's a chance you'll find something that will work. I assume you can talk to...him?"

She shrugged, a little uncomfortable, and said, "Well...it's Hanson. So I thought maybe--"

She didn't get to finish her comment because someone across the room shouted, "You know Hanson? Like, Hanson?"

She nodded and said, "I grew up with them."

(They're a boy band from five to ten years ago who you may remember as the perpetrators of "Mmm Bop." They're also Tulsa natives if I remember right, so there's no huge surprise there. Still, she got a moment of celebrity there in the class.)

I said, "I can't give you an A for cool factor alone, but I'd be interested to see what you could come up with for them."

Plenty of Need
One of the grading criteria for the project, though, is that it meets a real need. I could tell that was bothering some of them, so I went back to that point. I said, "If you're having trouble coming up with something to work on, find someone who could be a client and just ask them what they need. There's always work to be done, and nobody wants to do it. Talk to your boss, if you have one. Talk to your church secretary."

The problem with talking to your church secretary, I said, is that she's going to have a list eighty items long of things she needs done, and most of them aren't going to fit the shape of this semester's project. Then I hesitated as a thought struck me, and I said ruefully, "Well, no, the real problem of talking to your church secretary is that once you do -- especially if you do a good job -- she is never going to stop talking to you." That got a little chuckle, and I shrugged and said, "And...well, that's your service to God." That got a big laugh.

For those who just can't come up with anything -- or those who want to do something genuinely helpful -- I pointed out that I have some extra options. This class has been doing this assignment for so long, that most of the churches and charitable organizations in town know about it. As a result, the school pretty regularly gets requests for student assistance with documentation projects, and those are now getting passed along to me. I let the students know about that, but I didn't push it too hard. It's enough of a challenge to put together a big document, I would prefer for them to work on topics they're already interested in.

Although, to the girl who asked about promotional material for a musician (before she named the band), I did point out that once they'd finished this class, all of the students would be qualified and able to prepare and clean up documents -- promotional material, resumes, business letters, whatever -- even when it wasn't for a class assignment. They could do it as a favor, or as a hobby (like I did with the XBMC Python tutorial).

Hangers On
There were a few more questions, mostly looking for clarification on the project -- and a lot of them sort of unanswerable without specifics. I stressed again and again the need for them to maintain a line of communication with me, and I've already gotten a couple of emails from them since class on the topic.

Still, the questions trailed off around 2:00, and I dismissed them then. While they were packing up their stuff I distributed their graded memos from last week, and then went and sat down at my desk again, so I could address any last-minute discussion or help anyone who wanted to ask something face-to-face.

Turned out, there were a lot of them. Out of a class of fourteen (two never did show up), I had six or seven linger. Each of them had at least one question for me, but for the most part they stuck around and chatted even after their questions were answered. That caught me off-guard. I mentioned back in Week One that when I was panicking over time passing too quickly, all the veteran teachers I spoke with said that would get a lot easier once I had the students actually talking to me. They also all said that would probably happen sometime in November. I figured that was sort of an exaggeration, but I didn't expect to be hosting a salon by the end of the fourth week.

Of those six or seven that hung around after 2:00, four of them were still there at 2:30 when my real life demands forced me to leave. That was pretty cool.

Real Progress
While I was packing up, one of those four (who had already chosen his own project topic), asked in idle curiosity, "What are some of the coolest projects people have done before?"

And I hesitated (mind racing again), trying to decide whether to admit to my inexperience. I decided relatively quickly, shrugged, and said, "Actually, this is the first time I've taught the class, so I couldn't tell you."

His eyes shot wide, and he said, "Oh really?" Genuine surprise. That caught me off-guard.

I can only really think of one other time in my life when two words meant so much to me. I said out loud, "Yay!" Four weeks ago I was standing in front of them, paralyzed with fear, and today they're telling me I'm unrecognizable from a real professor. I call that real progress.

More next week.