About

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

Read more ...

Blog Search


(Supports AND)

Feed

Subscribe to the RSS feed for this blog.

See this post for info on full versus truncated feeds.

Quote

If you bring forth what is within you, what you bring forth will save you. If you do not bring forth what is within you, what you do not bring forth will destroy you.

Gospel of Thomas



Navigation





<March 2025>
SMTWTFS
2324252627281
2345678
9101112131415
16171819202122
23242526272829
303112345

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/4/2024

Totals
Posts - 2655
Comments - 2677
Hits - 2,730,925

Averages
Entries/day - 0.33
Comments/entry - 1.01
Hits/day - 344

Updated every 30 minutes. Last: 10:12 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]   ,

|