March 14th: Editing Reflections

Announcements/Overview

• Midterm Review
• Bibliographic Essay--5181 students only
• Persona Research--Think about the types of audiences you may serve and technological literacy

Midterm Review

The midterm is closed in Moodle, but I have a copy up on the big screen. Let's go over the questions.

Technical Writing 101: Ch. 9, 10, & 11

Chapters 9, 10, and 11 are probably things you've covered in the Editing class, so we won't go into too much detail on grammar rules and formatting.

Chapter 9 Highlights:

We've discussed many of the topics in this chapter at some point already this semester. Instead of thinking about the rules for various types of editing, I'd like us to consider audience needs and make connections to Cooper if possible. Editing is important to documents, and we ought to think of ways to be more efficient because the task of editing more often than not will fall on the individual.

Instead of picking out pearls of wisdom from the chapter, let's focus on topics that can be discussed in a larger class forum. After all, "rules" aren't universal. Also, some of you expressed concern about your participation grades, so thoughtful contributions--talk out ideas in a critical fashion--would be beneficial.

• Fewer technical editors p. 148
  • A fresh set of eyes
• Knowing the rules of the organization p. 149
• Client expectations and other audience expectations p. 151
• Style Guide vs. Grammar (peferences are like...)
  • Web page
  • Webpage
  • webpage
• Types of editing pp. 153-154
  • copy editing (lower-order concerns)
  • technical editing (content)
  • production editing (printing)
• Personas and the editing process p. 154
  Technical Writing 101 does not use the term personas.
• Editors and other readers offer a fresh set of eyes for your work and help point out writer-based prose p. 156
  • A note or two on feedback p. 157
  • Global search and replace pp. 157-158
  • Diacritical marks are most likely found in journalism and publishing
• Style is not capital-T "Truth"; it's preference pp. 161-162
• Time constraints and rearranging deck chairs on the Titanic
• Structured authoring (pp. 42-43) takes the formatting out of the hands of the writers...or does it?
  • What type or types of writing/communicating lend themeselves well to structured authoring?

Chapter 10 Highlights:

Although this chapter offers insight into how to create an index, it is just a brief discussion. The study of indexology is quite vast; they even have their own society. We'll try to focus on needs for indexes (or is it indices...this page takes up the issue). What should you consider before doing one? Do you even need one?

• User guides are reference materials, not novels p. 165
• Google: quicker than flipping pages...or is it?
  • Perception is reality p. 166
• Indexing will not be replaced by searching (my speculation)
  • Indexing helps organize information and may allow for you to have a quasi-checklist of content p. 167
• Terminology
  • What terms should you use?
• Who do you ask?
• To "query" or not to "query" p. 170
• Index definitions and tasks p. 169
• Variations of entries--how many? p. 171
  • Audience criteria (and audiences)
  • Purpose critieria (reference only, tutorial only, or both)
  • "see" and "see also" pp. 173-174
• Too broad of a page range p. 176
  • Why would 18 pages be unhelpful?
  • What is it mimicking?
• Parallelism--good for all documents...except for mine because I have a different purpose, reflection.

Pretend Google Searching index entry:

Entries to think about:

• Searching i-20
• Searching
  see refining searches
• Searching
  see also refining searches
  asterisks 10
  boolean operators 14
  limiters (limiting terms) 15
  phrases 9
  using quotation marks 7
  wildcards 11
  

Let's think critically about the above entries. Are they effective? Why or why not?

Chapter 11 Highlights:

This chapter is probably not new to many of you. It discusses production editing tips. Let's think about why structured authoring (pp. 42-44) represents a trend towards automation. We're thinking on a social scale.

• Grammar and hygienic goals/factors (Cooper returns) p. 182
• DIY publishing and information design required by technical communicators
• Structured authoring and the automation of writing p. 183
  • Saving money?
• When online documents get printed out are there pagination worries? p. 187
• Format after content has been created p. 188
• Widows: a few words at the top of the page
  Orphans: first line or heading at the bottom of a page pp. 188-189
• The times they are a-changing
  • What do portable technologies and handhelds hold for future documents? p. 196
  • Which browser should you use?

All this automation means something. Does it mean the software will index for us and generate useful help topics, so technical writers will no longer be needed? Well, if all you're knowledgeable in is formatting, your time is up! Knowing what questions to ask regarding what the audience needs and what purpose the document/system serves is more important.

So what's useful? What drives technical communication for the 21st Century? Who's going to write for Sixth Sense Technology?

Non-biased Questions and Likert Scale

I have a bias. Yes, I, too, am not above bias. I know what you're thinking, "Toscano is biased?!? Say it ain't so!" Well, I am biased against surveys. I think that most questionnaires are highly inaccurate. Self-reporting doesn't yield the most "truthful" results. I also am biased about statistics--I think they're bogus 4 out of 5 times, but that's another story. There are legitimate uses for statistics, but they must be scrutinized and not assumed to be "facts speaking for themselves"--someone always interprets the data to make it useful information. That doesn't mean someone is manipulating an audience, but we ought to think critically about statistics thrown at us.

As individuals interested in getting information from users, we ought to be sensitive to getting that information effectively. I think our discussion might help.

Are yes/no questions effective for getting feedback? HA! Get it? I need to ask Why or Why Not?

What's the advantage (and disadvantage) of open-ended questions?

Remember, users like to please the testers, so you ought to avoid some leading questions. (I know, a generalization, but 59.8% of what I've read on the subject mentions this.)

What's the difference between the following questions?

• Do you like the interface?
  How do you feel about the interface?
• Isn't this a cute little button to use for submitting?
  How did you use the submit feature? Why? Why not?
• How well did you like the documentation?
  Was the documentation useful? {easy...it's yes/no}
  How did you use the documentation for assistance? Why did you use the documentation for assistance? Why did you not use the documentation for assistance?

User Doc #2 User Testing

Next week you'll have a more in-depth user test to accompany your more in-depth User Doc #2. I know all of you will work hard to help your fellow classmates by being as objective as possible. The first change, though, will be that I want you all to come up with three personas for the instrument you'll document. I also want you to include the following in what you'll turn in to me on 3/28:

• Describe the instrument

• Explain how the user will approach the set of instructions {online, printed out, on the moon, etc.}

• Plan how you will test your draft

  • Develop a pre-test briefing strategy: make a statement to tell each user (a script), ask questions about comfort level, and/or have them watch something (this last one works best for descriptive documents like natural or mechanical proceses).
  • Come up with five post-test questions that use a Likert scale and have a comments section
  • Set at least four goals and make sure they're measurable
    • User did all steps in XX minutes...
    • User completed the instructions in XX minutes...
    • User used the help menu less than XX times
      -or-
      User never had to look at the help menu or ask for help.
• Describe three personas you had in mind when creating the document--these are Cooper personas and not the detailed ones for your Persona Research assignment
• Come up with five post-test questions that use a Likert scale and have a comments section (just ask the user to comment)
• Set at least four goals and make sure they're measurable

Note: measurable goals mean that users can not only accomplish tasks but they can accomplish them within or under quantifiable standards. For instance, a vague, immeasurable goal would be, "create a user friendly set of instructions"; whereas, a measurable (operationalized) goal would be, "create a document that gets users to setup the instrument within five minutes with no more than two lookups in the help menu." Additionally, a Likert scale could be an attempt to quantify qualitative data: On a scale of 1 to 5 (5 being the highest), please rate your satisfaction with the product."

But let's be critical of our Likert Scales and quantifying subject data in general.

User Test Setup

I may or may not choose who you should get to user test your document. I'll be coming around to note who has their drafts. Make sure you give the users the post-test questions. Don't have those...get moving on that!

Before We Go...

Next week you have the last chapter (we'll read) in Technical Writing 101 and we'll start Degani's Taming HAL, an interesting work. Your User Document #2 user test is next week, and it's due in two weeks (3/28).

..