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

Outside of a dog, a book is probably man's best friend; inside of a dog, it's too dark to read.

— Groucho Marx



Navigation





<September 2021>
SMTWTFS
2930311234
567891011
12131415161718
19202122232425
262728293012
3456789

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 - 9/13/2021

Totals
Posts - 2638
Comments - 2642
Hits - 2,409,714

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

Updated every 30 minutes. Last: 11:25 AM Pacific


  08:54 PM

A culture-specific image! In German, people hope for good luck by 'pressing their thumbs.'In technical writing, you might see the word should used in a couple of senses.

Sense 1
Example:

After making these changes, you should save the file.

This sense conveys (to quote our style guide) "an action that is recommended, but optional." It's fine, with the qualification that in this sense, should is strictly a recommendation, not a requirement. (If the action is required, use must: To finish the operation, you must save the contents to a file.)

There are variants on this. For examples, error messages are often written this way, as shown here in a couple of examples from our documentation:

Assemblies should declare minimum security.
Enums should have zero value.

Sense 2
Example:

Click New. The New File dialog box should be displayed.

This sense conveys the, um, desired outcome of an action. This usage is relatively common, I've found. But in general, I edit away should when it's used in this sense. When you're writing procedures, you don't want to sound like you're hesitant about what's supposed to be happening. Or to put it a different way, you're conveying a slight sense of doubt about whether the instruction you just gave actually works. Probably it will work. We hope this works. It ought to work.

Contrast these:

Click New. The New File dialog box should be displayed.
Click New. The New File dialog box is displayed.

Run the page again. Your changes should appear.
Run the page again. Your changes appear.

I can't see any reason why the second variation in each case isn't the better approach.

There's some wiggle room here. I would not say that should should never be used in this type of context. Perhaps it's ok in an instruction like this:

Install the newest versions of the assemblies. This should resolve the problem. If it doesn't, proceed to the next recommendation.

In this sense (invented), you really do want to convey that it's the desired and/or probable outcome, but nonetheless might still not occur. (You could also write around it by saying If this doesn't work, proceed ...)

So: if you're writing instructions and if action A should result (haha) in result B, then be bold: skip should and just press onward without the modal verb. Your readers will (or should) appreciate your confidence.

[categories]   ,

|