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.


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.


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.

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.

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.

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.