About

I'm Mike Pope. I live in the Seattle area. I've been a technical writer and editor for over 30 years. I'm interested in software, language, music, movies, books, motorcycles, travel, and ... well, lots of stuff.

Read more ...

Blog Search


(Supports AND)

Google Ads

Feed

Subscribe to the RSS feed for this blog.

See this post for info on full versus truncated feeds.

Quote

I was such an idiot just a few short years ago. But then, it's been my experience so far that no matter how old I get, I was always an idiot a few years ago.

Jerry Kindall



Navigation





<June 2021>
SMTWTFS
303112345
6789101112
13141516171819
20212223242526
27282930123
45678910

Categories

  RSS  
  RSS  
  RSS  
  RSS  
  RSS  
  RSS  
  RSS  
  RSS  
  RSS  
  RSS  
  RSS  
  RSS  
  RSS  
  RSS  
  RSS  
  RSS  
  RSS  
  RSS  
  RSS  
  RSS  
  RSS  
  RSS  
  RSS  
  RSS  
  RSS  
  RSS  
  RSS  
  RSS  
  RSS  
  RSS  

Contact Me

Email me

Blog Statistics

Dates
First entry - 6/27/2003
Most recent entry - 6/6/2021

Totals
Posts - 2636
Comments - 2645
Hits - 2,382,921

Averages
Entries/day - 0.40
Comments/entry - 1.00
Hits/day - 363

Updated every 30 minutes. Last: 7:48 PM Pacific


  08:54 AM

The hazards of overclaiming

I was listening to a podcast yesterday when it was interrupted with an ad that started like this:

Do you have 30 minutes to spare? Because after just one half hour, you'll never have to worry about a break-in at home again. That's how easy it is to set up a security system from [company name].

My editor brain froze at the point. What I heard was a claim that if you installed their system, you would not be broken into—you would be protected against burglary forever ("never have to worry").

When we technical-edit documents at work, one of our priorities is to check for what we call overclaiming. For example, we stay on the lookout for instances of overclaiming about security, like this:

This product prevents bad actors from hacking your system.

A claim like this simply can't be guaranteed. In the realm of security, the apparent strength of your product might just mean that a hacker hasn't found a flaw in it yet. For example, encryption algorithms that once seemed secure enough to be used by the NSA have been cracked.

We look for overclaiming in any discussion of performance:

Using this product makes your applications three times faster.

We look for it in mentions of costs:

This product reduces your computing costs by 50 percent.

For performance claims, we warn authors that anything that states a number has to have data to back it up. If you say your product is three times faster, you better be able to produce the tests that show this. The same applies to any mention of costs: numbers, please.

And we look for it in any text that involves comparison to other products:

Our product is substantially easier to use than [competitive product].

This claim is problematic in multiple ways. First, what does "easier" even mean? Something that's easy for me might be hard for you and vice versa. And competitive products are a moving target anyway; perhaps our product is "easier" than the current version of product X, but who knows what's in their next release.

So naturally I stumbled over "you'll never have to worry about a break-in at home again." But I thought about it for a bit. First, it's advertising copy, not a technical document on how to configure cloud computing. Maybe there's more wiggle room for wild claims, as in, people aren't expected to interpret these things literally.

I also homed in on the phrase "worry about." With some work, this can be made ambiguous. One idiomatic interpretation is that it means that something won't occur:

What if we run out of Cheetos tonight?
You don't need to worry about that[, we just went to Costco].

A more literal interpretation is that, well, you don't need to worry. This is the type of messaging that insurance companies use: it's not that [thing] won't happen, it's that you can stop worrying about [thing happening] because insurance.

I have a hard time fitting this second meaning onto the ad copy for home security systems. But if I had to defend that statement in court, say, that's what I'd go with.

Speaking of consequences, all of this hypervigilance about overclaiming is of course ultimately about protecting the company. The fear is not just that we'll be shown to have been wrong. ("Sorry.") When people spend vast sums based on assurances that you've given them about security or performance or cost, and when those assurances don't prove true, they might take a litigious turn of mind. At the very least, they're not going to trust you in the future and might look elsewhere to spend their money.

I'm not personally aware of the various companies I've worked for being hauled into court to defend an assertion. ("You said we wouldn't be hacked!") But clearly the lawyercats think about this a lot, and I've certainly participated in my share of fire drills in which we dropped everything to grub through many documents, tweaking some text that was discovered to be overclaim-y.

I would not be surprised to hear an ad from the same company a year from now in which the claim "you don't need to worry about break-ins" has been hedged to something like "Get yourself some peace of mind." If I were editing their copy, that's definitely what would happen.

[categories]   , ,

|


  12:16 PM

Over the weekend, I bought a recliner at Costco, which my wife laughingly suggested was my admission that I'm an Old Guy. But before I could, you know, recline, I needed to assemble the chair and figure out how to work it. In our modern era, reclining chairs are electronic, which means there are 5 different controls, which in turn means that there is an instruction manual.

The manual has instructions for how to perform the one required assembly step, although tbh I had figured out how to do that without the instructions. There are also pictures of how to plug in the two (!) electronic connections, though again, these were self-evident and had also been designed so they could be plugged in only one way.

The useful part of the instructions was the diagram that showed what the buttons on the control panel do. Ironically, this illustration is very small for, you know, Old Guys. This is it to scale as best I can render it (2 inches wide):

A curious part of the manual is that whoever created the manual decided that they needed to cast the instructions as a set of numbered procedures. Here's step 2, which is one of the more forced applications of a numbered procedure step that I've seen.

Where is step 1, you ask? I'm saving the best part for last. Step 1 concerns a feature of the recliner that I had not previously thought needed instructing:

("While seated in the recliner, enjoy the rock feature which allows you to gently rock backward and forward.")

There's a lot of fun stuff to unpack here:

  • It's step 1.
  • Don't do this while standing next to the recliner.
  • Imperative "enjoy."
  • "The rock feature."
  • Which "allows" you to rock.
  • Gently.
  • Backward and forward, as if there might be other ways to rock in a recliner.

Moments after I read this out loud to my wife it seemed clear that "enjoy the rock feature" has a good chance of entering our familect, as it's called: we now have a stock answer to the question of "What are you doing right now?" "I'm enjoying the rock feature."

But to end on a serious note: numbered procedures ("how-to" documentation) are useful if the reader needs to follow a sequence of steps to achieve a task. Rocking a chair is not a task that requires numbered steps. Understanding what the controls on a control panel do needs reference documentation, not how-to documentation. There are many challenges in technical writing, and one of them is choosing the appropriate style of documentation for what the reader needs.

More dubious guidance: 1, 2, 3, 4, 5, 6, 7, 8, 9, 10

[categories]   ,

|


  10:42 AM

One of the effects of this year's protests is that it has brought about heightened consciousness about language and how it affects or reflects certain thinking. For example, there have been discussions in the editorial community about capitalizing the word Black "in a racial, ethnic or cultural sense."

In the world of IT, we've been discussing the implications of certain terms for a while. The Microsoft style guide has suggested for a over a decade that writers avoid the terms whitelist and blacklist in order to avoid a connotation that white==good and black==bad. (I wrote about this a while back.)

Our own style guide has a section on inclusive language, and it suggests finding alternatives to a range of language that, when you look at it consciously, can have negative connotations or the possibility of offense. In addition to disrecommending the word blacklist, we tell our authors to use alternatives to terms like crippled system, dummy variables, sanity checks, native features, and first-class citizen.

A short digression about cloud technology. (For tl;dr, you can skip to the discussion of terminology.) We work in the world of cloud computing, which has its own concepts and vocabulary. The cloud, as the jokey definition goes, is just using someone else's computer. More specifically, it means using someone else's one or ten or hundreds of computers, because a fundamental benefit of the cloud is that you can adjust computing power as needed. For example, if you have a retail business, your website might need medium power normally, low power during a summer slump, and heavy-duty computing power to handle your yearly sale. The point is that your need for computing resources goes up and down, and rather than having to build out your own data center to accommodate the maximum possible demand (and whose high capacity might mostly just sit idle), you build your system in the cloud and spin up computers (servers) when demand is high, and take them down when they're no longer needed.

In this environment, computers are commodities. Any single computer is just a faceless worker in your overall computing infrastructure. Compare that to the computer sitting on your desk; you've probably personalized how it runs, installed many updates, and otherwise fussed over it. If one of the faceless computers in the cloud crashes, it's not a big deal; another one spins up and carries on the work. On the other hand, if your personal computer crashes, it's usually a disaster.

Ok, back to terminology. To conceptualize the difference between the faceless fleet of computers in the cloud and your personal computer, technologists devised the metaphor "cattle, not pets."[1] If a computer is a quasi-anonymous something that can be replaced any time, it's "cattle"; if it's an indispensable part of your work, it's a "pet."

Some authors love this metaphor, because, undeniably, it has explanatory power. More than once it's appeared in a document I'm editing, and if I question it, I'll be pointed to how widespread the expression is in IT/cloud texts. And we try to use the vocabulary of our audience.

However. One of my colleagues recently pointed out what might be obvious to a lot of people: the expression "cattle, not pets" is … problematic. One of our principles is "avoid unnecessarily violent language," and once you think about it, you realize that there's implicit violence in the metaphor as pertains to the fate of the "cattle." Moreover, there are cultures in which no cow is just "cattle," and for whom the idea of animals being killed is abhorrent. Therefore, we've updated our guidance to "avoid the use of figurative language that relates to the slaughter of animals."

This sets up a tension we sometimes have when we tell writers to avoid terminology that's still common in a field. We might ask authors to avoid whitelist or cattle-not-pets, and they'll point out that these are well-understood expressions and that using some alternative form potentially confuses readers. ("Allowlist? Did you mean whitelist? Why not just say so?") And people might search for these terms and they'll have no joy if they don't appear in our documentation. Plus it can give off the vibe that we don't know our own field.

But change begins at home. Sure, these problematic terms are part of the industry lingo. And we can't just ignore them out of existence. What we often do, then, is to include the expression parenthetically on first mention of the preferred term. So we might suggest something like "Create an allowlist (whitelist)" or "servers as commodities (sometimes referred to as 'cattle, not pets')" to tie the old term in the reader's mind to a new, better one.

We hope that the collective work of consciousness-raising by many editors and writers over a period of time will gradually alter the perception of problematic terms. The work is never truly done, of course, but it has to start somewhere.

PS I should note that not everyone supports the idea of this type of language change; there's plenty of pushback in the IT world against changing to "so-called inclusive language." These things are not easy.

[1] Devised to explain scaling by Bill Baker, adapted for the cloud by Randy Bias.

[categories]   , ,

|


  09:24 AM

"Fewer your words": advice, not fetish

A couple of weeks ago, a (virtual) discussion broke out among the writers at work about "empty words" and how these should be eliminated. The original posting was about removing phrases like allows you to, helps you to, is intended for, and some others.

The topic generated a lot of interest, and people came to the conversation with different perspectives. One person: "Fluff should be eliminated." Another: More words make it that much harder for people who use assistive devices like screen readers.

You'd think that as an editor, I'd be delighted to see such keen interest among writers in the topic of "fewering your words," as we editors like to joke. There was a lot of advice that seemed helpful. And there were some nuanced points about reducing text too much.

But a number of issues came up that rubbed me the wrong way. I had to think about why that was, and I thought I should write down what I found.

The first thing that bugged me was a suggestion that we could train a machine-learning tool to eliminate these "unnecessary words." The proposer suggested that if there were a large enough training set that showed the work of human editors, this would be a good approach for suggesting changes. And I thought, how do you think grammar checkers work now?

Another thing that bothered me in the conversation was the confident assertion of absolutes. "The phrase in order to is never necessary," was one opinion. Hard disagree, as I explained a while back in the blog post "In order" to clarify meaning.[1]

For that matter, the original assertion that phrases like allows you to, helps you to, and is intended for are fluff was itself an absolute statement that I disagreed with. Many times I've added these with forethought and for good reasons. For example, many times we add the phrase helps [to] at the request of our lawyercats, who are extremely sensitive to what we might be claiming. Put on your lawyer hat for a second and compare the following:

Using our anti-virus tool makes your computer secure
Using our anti-virus tool helps make your computer secure

… and think about which of those statements you'd prefer to defend in court.[2]

Here's another thought: shorter isn't always clearer. By reducing words, you might make it harder to understand a sentence. Or maybe not harder for you, but for someone who's not a native speaker, or for a translator who sees the sentence with very little context.

My biggest objection, though, was with the whole premise that removing "fluff" and "needless words" was the ultimate good. One writer said they liked to see how many words they could eliminate or how many drafts they could go through. I had to marvel at the time that some writers must have to go over draft documentation again and again, and whether those last couple of passes to squeeze out just a few more words are really the best use of that writer's time.

An unnecessary in order to is virtually never the thing that's preventing the reader from finding and using the information they're looking for.

We're in the business of solving the reader's problems with the least amount of friction. Sure, reducing word count can be part of that strategy. But an unnecessary in order to or allows you to is virtually never the thing that's preventing the reader from finding and using the information they're looking for. As an editor, I am way, way more concerned that a document I'm looking at addresses a real user need, and that the reader can find the information as fast as possible, and that the information is presented in an order and at a level of detail that's correct for that reader, and that the information is accurate and complete. I have edited many documents that initially failed in some or all these ways, and it was far more important to take care of these things than it was to worry about "empty words."

Reduce word count when you can, but don't make a fetish of it, and don't turn it into a set of absolute rules ("in order to is never necessary"). Do not make reduced word count some sort of gauge of editing quality. There's a strong likelihood that there are more important things to concentrate on in your document.

[1] The longer I work as an editor, the less I believe that there are any absolute rules about anything to do with usage.

[2] I am not a lawyer, don't cite me on the legal implications of anything I say here.

[categories]   ,

|


  07:09 AM

My life has been blessedly free of the need for pharmacological intervention, but I recently went for a checkup and left with a fistful of prescriptions. Because this routine drug-taking was sort of new to me, I actually read the inserts that came with the several prescriptions because, well, perhaps there was something I needed to know.

The text was hard for me to read, but that was only because it was in such small print—8 points, perhaps less. And there was quite a lot of it. But this technological limitation at aside, I was surprised at how readable the words themselves proved to be. Perhaps—and this is my observation—by design?

Some details. There are about 1230 words in all, which is about two and a half pages. The text is printed in blobs, aka “walls of text.” The only formatting is ALL CAPS and ALL CAPS IN BOLD. The text is not laid out with an eye to scannability. You can get an idea from the following, with a US quarter coin (about 1 inch/24 mm) for scale.

But as I read the text, I noticed that it seems written for clarity. Here’s an example:

Use this drug as ordered by your doctor. Read all information given to you. Follow all instructions closely. Take this drug at the same time of day. Take with or without food. Keep taking this drug as you have been told by your doctor or other health care provider, even if you feel well.

I noticed these things:

  • Sentences are short.
  • Words are (for the most part) simple and direct.
  • Instructions are clear and are written as imperatives.
  • The text anticipates possible reader questions (“… even if you feel well”).

The headings for the text—the ALL CAPS bits—either lead the reader toward instructions or function as a kind of FAQ:

Ingredient name (includes a pronunciation guide!)
Common uses
Before using this medicine
        What do I need to tell my doctor before I take this drug?
        Tell your doctor if …
        Tell your doctor if …
        Tell your doctor if …
How to use this medicine
        How is this drug best taken?
        How do I store and/or throw out this drug?
        What do I do if I miss a dose?
Cautions
Possible side effects
        What are some side effects that I need to call my doctor about right away?
        What are some other side effects of this drug?
Overdose
Additional information

It’s not perfect (I’d certainly edit this a bit), but I think a lot of work went into deciding what information to put into this text, how to organize it, and how to phrase it. The result, I think, ends up being pretty readable.

So-called readability scores aren’t considered particularly precise, but I ran the text through Word’s readability checker and got these results:

The averages in the middle are the ones that seem significant to me:

  • An average of 13 words per sentence is great. A study from 2008 suggested that comprehension dips below 90% when sentence are longer than 14 words. (And many sentences in the text are shorter than that.)
  • The average of less than 5 characters per word is also good. This is supposed to index the proportion of monosyllabic—hence “simpler”—words.

The “reading ease” score of 78 is good (out of 100), and of course the “grade level” score of 5.4 is likewise is supposed to tell you that this text is intended to have the same readability as a text aimed at 10-year-olds. (All of this, let us remember, supposedly.)[1]

But the numbers are only an imperfect way of capturing what I think is going on here, namely that the text has been designed to be comprehensible to as many readers as possible. The whole setup of providing instructions for drugs works against the pharmacist and other interested parties. The medium is bad (a printed insert in a prescription bag). A lot of people don't want to read this type of text. Some of the patients might not be strong readers. So the people who created this text tried to distill the information to the essentials and to present them as clearly as possible.

By the way, it doesn’t escape me that this text was almost certainly not written-written; it was probably assembled. I’m sure there’s a database of “drug insert text,” and a computer pulls out individual sentences to create text that’s relevant for a specific drug, and then prints it along with the labels for the pill bottles and the other stuff that’s stuck into the bag. Nonetheless, the result mostly works; not in layout, but in terms of the text itself. I give this a good grade and salute the many people who probably spent a long time putting this whole system together.

[1] By way of comparison, this post clocks in at 2.8 sentences per paragraph, 15.3 words per sentence, and 4.3 characters per word.

[categories]   ,

|


  10:00 PM

There are a variety of editorial truisms: long sentences are hard to read; lists should be parallel; consistency is good. This wisdom is taught, and it's reinforced by personal experience; editors are themselves readers, after all, and they monitor their own reactions when reading.

However, there isn't always hard, empirical data that editors can point to to support what experience and insight tells them is true. But sometimes there is, and just this week I ran across something that underscores the editorial push toward consistency, and I was pretty excited about it.

I'm in a linguistics class right now, and one of our lectures was by the linguist Gareth Carrol, who uses eye-tracking studies to understand how people read. He started his lecture by noting that people do not read smoothly across the page, line by line. They stop on words (fixations); they jump (saccades); they back up (regressions). By studying what's happening with these movements, linguists can determine where people are having trouble with a text, and importantly, where they're not.


Heat map from eye-tracking study (source).

In our lecture, he discussed binomials, which are pairs of words linked by and: fish and chips, bread and butter, salt and pepper. An interesting thing about binomials is that they have a conventional order: people say I'm sick and tired of it; they don't say I'm tired and sick of it.

Eye tracking studies have determined that people can read binomials quickly. It's like the brain sees a familiar binomial and says "Oh, I get this" and can flit to the next bit of text. In an experiment, Carrol and his researchers wrote some stories that included invented binomials—pairs like wire and pipes and leaves and grass. These are perfectly normal pairs of words, but not binomials that have a conventional order.

So what did they learn? A couple of things:

  • People took longer to process these unfamiliar (invented) binomials than to process familiar ones. But …
  • If people saw the same invented binomial four or five times in a story, they acclimated to it and were able to process it faster.

To my mind, this translates easily to the editorial guideline of consistency.

Of course, I'm in the world of tech writing. We already know in our world that readers don't really want to read-read; they want information, and the faster, the better. If you want to reduce friction for the reader (that is, reduce fixations), be conventional. Use words consistently and construct text consistently. By doing this, science says that you're reducing the effort that the reader has to make to process the text, and the sooner they can back to doing whatever it is that they were reading about.

[categories]   ,

|


  11:33 PM

The other day I was taking an introductory training class for some technology at work. There was a slide that outlined the technology, and one of the bullet points had an asterisk next to it. At the bottom of the page was this footnote:

Most strong statements like this are only mostly true. Don’t worry about it.

I had to stop for a while to ponder the pedagogical implications of this footnote.

There's an inherent problem in trying to describe something complicated to a newbie: how do you start? If someone knows absolutely nothing about, say, playing bridge, or verbs in Spanish, or physics, or grammar, you have to give them a large-picture, broad-stroke overview of this thing they're about to dive into.

This is hard. One reason is that people who are familiar with some domain frequently have difficulty coming up with sufficiently high-level overviews that make sense to a beginner. I've had a couple of people attempt to explain the game of bridge to me, but they could not come up with a simple, comprehensible explanation of the bidding process.[1]

A closely related reason is that experts often cannot let go of details. For example, in your first week of Spanish class, the teacher tells you that the verb hablar means "to speak," and that to say "I speak" you cut off -ar and add -o: hablo. And that this is the pattern for any verb that ends in -ar. So to say "I take," you use the verb tomar and turn it into tomo.

Easy! Powerful! Also, of course, only mostly true: there are irregular verbs and reflexive verbs and other fun. But throwing those additional details at you in the first week of Spanish 101 is counterproductive. There will be time to sort out the exceptions later, once you understand some basics.

I took physics in high school, and when you start, you're learning a lot about f=ma. I have memories of homework problems involving blocks being pulled or pushed, and the problems always said something like "… ignoring the effects of air resistance." A beginning physics student has enough to think about when calculating the effect of gravitational acceleration without trying to factor in air resistance and all the other real-life variables that come into play. In fact, there's a well-known joke in the physics community about a "spherical cow" that represents the ultimate in simplifying a model.

One more example. In the linguistics community, it's widely discussed that even if kids are taught grammar, it's not taught very well. People who are experts in grammar will sometimes complain (example) that the explanations we give students are hopelessly simplistic. "A noun is the name for a person, place, or thing," goes a typical definition. This doesn't adequately cover gerunds ("Smoking is bad for you") or concepts ("Orange is the new black") or many other ways in which we noun things.

But this gets back to the point. If you're faced with a classroom of 8-year-olds, how do you tell them what a noun is? Using terms like "lexical category" and "defined by its role in the sentence" is not going to work. You have to start somewhere.[2][3]

And that means ignoring messy details. As one of the commenters on the linked grammar post describes it, "It's quite normal for us to use 'lies to children' in education." Or, to get back to where we started, you sometimes have to make strong statements that are only mostly true.

[1] There are people can do this; it just wasn't the people I was playing with.

[2] By coincidence, I ran across a video that tries to explain what nouns and verbs are. We can have a think about whether this is a description that would be suitable for first-time grammar leaners.

[3] And another! Jed Hartman (of Hartman's Law of Prescriptive Retaliation) also has an entry Coming Down with Noun Syndrome about the challenges of identifying parts of speech. ("[A]s usual, the truth is a little more complicated than we were taught. Oops.")

[categories]   , ,

|


  09:37 AM

I know how this happens, I do. A tech writer is given a task to "document the product," and it turns out there isn't much to say. But telling the bosses that nope, it's ok, we don't actually need to say anything about this might be perceived as, dunno, not being cooperative. Maybe even suggesting that the writer's job isn't that important.

Anyway, today we have a couple of examples of what might result if the writer (and common sense) does not prevail. First up, we have these, um, helpful instructions that came with a compass that I own:

There must be a universe in which people buy compasses who don't already know what N, E, S, and W mean. I don't believe we live in that universe.

But even that is reasonable compared to the following, which Twitter user Alex Warren posted today:

More dubious guidance: 1, 2, 3, 4, 5, 6, 7, 8, 9

[categories]   ,

|


  09:46 PM

Suppose you're on vacation and you're driving to a place named Lisbon Falls. You see this sign, so you turn right.


After you turn, you drive for a long time, but you don't see Lisbon Falls, and you start to doubt that you're on the right road. How helpful would it be to see a sign that said "Lisbon Falls—keep going "?

Obviously, we need signposts to tell us where to turn. But sometimes we need signposts to reassure us that we're going the right way. Since I work in documentation, I'm going to talk about this applies when you're writing instructions.

The first and least controversial example is to show the results of the user's action, like this:


This type of signpost reassures the reader that they've run the command correctly, or made the right gestures in the page, or whatever.

A second type of signpost is one that makes sure the reader is properly oriented at the beginning of a procedure. This comes up a lot in the complex tutorials I work with, which might have many separate procedures. What I tell my writers is that at the beginning of each procedure, they should make sure that the user is clear about where they are. Here's an example:


I sometimes get pushback from an author about this if the user isn't changing contexts between procedures. "They should just keep entering commands where they left off!" the author might say. I get this; it can feel like we're sort of stating the obvious. But remember my example at the beginning—sometimes it's helpful just to know that you're on the right road, even if you haven't gotten any indication that you're not.

The final example is one that I see rarely in technical documentation, which is too bad. This type of signposting warns the user of something out of the ordinary: an unexpected result, a long delay, a tricky procedure, or a non-intuitive process. Here's a sort-of example:


During the editing process, I asked the author "Is that period on the end of the cp command correct?" Yes, was the answer, "unfortunately." This might have been an opportunity to actually say to the reader "Hey, that period at the end? That's part of the syntax." But we didn't do that, perhaps because the author felt that the audience for this piece would not have that question. But you can probably think of other examples where a little authorial aside to point out something weird would have been helpful for the reader.

One of my favorite examples of this was an article about installing tools for Python. It included the following refreshingly honest instruction:
See all that stuff flying by? Forget about it.
(I wrote about this a few years ago.)

Talk about reassuring!

Update On Twitter, Leon (@secretgeek) points out another example of signposting that I didn't call out. In the first example earlier, the instruction starts with "Wait 3 to 4 minutes"—this notifies the user that a delay here is to be expected.

All of these examples—indeed, signposting in general—is a matter of putting yourself in the user's shoes. At what point(s) in the user's journey is it helpful to reassure them that they're still driving in the right direction? As an editor—hence, a user advocate—I'll suggest that it's more often than you think.

[categories]   ,

[2] |


  08:28 AM

There are many reasons to use styles in Word, as I've noted before. One feature I find handy is using styles that have different spell-check options for different types of text. I'll explain a couple of examples: one where I set a non-default spell-check option (Spanish), and another where I disable spell check for code snippets.

Note: If you'd rather see this on video, see the links below.

Spell check for non-default languages

Suppose you're writing a document that has quotations in different languages. If you run spell check over the document, it'll barf when it gets to your citations in Spanish or French or Latin or whatever.[1]

The hard way to solve this problem is to select the text of each citation, one by one, and then to set the proofing language (Review tab > Language > Set Proofing Language).

The easier way to do it is to define a style and set the language for that style. Then you can just apply the style to your citations.

Suppose I'm writing about One Hundred Years of Solitude by Gabriel Garcia-Marquez:


I run spell check, and uh-oh: if it's going to stop on every word of Spanish, it's going to be a long night proofing this doc:


Instead, I'll create a style just for my quotations in Spanish. In this case, I'll create a paragraph style, although I can set language options for character styles also, which is useful for cites in running text.

Here's the Create New Style dialog. The new style is named Quotation in Spanish. It's a paragraph style, based on Normal, and I've set an indent.


Then in the Format options (bottom left), I choose Language:


For the language, I choose Colombian Spanish:


Now I can apply this style to any citations in the document that are in Spanish. When spell check gets to the citations, it switches to checking spelling in Spanish. (Which is handy, since I'm a bad typist in multiple languages.)


If the document contains text in several languages, you create a different style for each non-default language that you're using and apply them as needed.

Disabling spell check for selected text

I don't actually encounter a lot of Spanish citations in my work, but I do encounter a lot of snippets of program code and HTML. I also encounter filenames and URLs that are oddly spelled per English conventions. As with non-English text, this can throw spell check off. So I create a style for code and for HTML blocks and for filenames and for URLs. In those styles, I disable spell check altogether.

Skipping ahead, here's an example of what some sample text looks like when these styles have been applied:


There are 3 styles at work here. The green monospace marks a character style named Code. The blue italics mark a character style named Filename. And the indented block with gray background marks text that's styled using a paragraph style named Pre (a nod to the HTML element name for code blocks).

In addition to the various formatting settings that I defined for these styles (italics, blue, green, monospace, indented, etc.), in each case I chose the Language setting. Then in the Language dialog, I chose Do not check spelling or grammar:


When spell check runs, it skips over any text that has been styled using a style with this setting.

I should note that for code and HTML snippets, it can instead make sense to add the various keywords to your dictionary. (I do this for filenames that I encounter often.) However, defining a style that simply turns off spell check has been very handy for me in the code- and HTML-heavy documents that I work on.

Videos

I made a couple of videos about this also and put them on YouTube:
[1] I do realize that Word can be set to auto-detect languages, and that this works pretty well. But the method I describe here also covers scenarios where auto-detect doesn't work well. (Klingon? Dothraki? Etc.)

[categories]   ,

|