raganwald
(This is a snapshot of my old weblog. New posts and selected republished essays can be found at raganwald.com.)

Monday, February 06, 2006
  Three Email Courtesies


The following are courtesies: they help the people who read your emails save time. That makes them more productive and, hopefully, a little bit grateful to you :-)

How and when to mark emails "important:"

Use the low and high importance flags to mean urgent and not urgent. Specifically, high priority should mean "read this the moment you see it in your in box." Low priority means "you don't need to read this if you don't want to." Anything else means "use your own judgment, but please read this in the fullness of time."

What I do with the high priority flag is this: I use it whenever I would feel justified in interrupting someone else's meeting to tell them something. If it isn't that urgent, I do not mark it high importance.

Edit the subject line freely:

Edit the subject line for replies and forwards. Your reader is scanning their in box. What does "RE: RE: RE: FW: RE: the meeting" mean? Help them scan your subject at a glance. I suggest you almost never use the default "RE:" Instead, do this:

Make up a new subject line that describes your answer to an email and then prepend it to the old line. For example, instead of : "RE: the meeting", use "Some suggested topics | RE: the meeting."

This saves your reader a lot of time. Isn't that a tremendous gift?

Put short replies in the subject:

Does your reader need to open your email just to read the word "thanks"? I know Outlook has a preview pane. But it's still extra work to click on each message to see its preview. And if your reader has to set things up to preview every message in their inbox, they can see fewer messages.

Try this instead: put short replies right in the subject line with an indicator that there is no body. I use <eom/> because it's XML-ish and I happen to hate XML, so it feels like an inside joke. But everyone understands it. So try: "I'll bring the bagels! <eom/> | RE: the meeting."

That saves your reader even more time. The gift that keeps on giving!

I did not invent these ideas. I don't remember where I heard of them, but I wouldn't be surprised if at some time in the recent past I read a post just like this with these ideas in it. If someone can point out a source for these ideas, please comment and I'll give the proper attribution.
 

Comments on “Three Email Courtesies:
Geek to Live: Train others how to use email

http://tinyurl.com/784ss
 
If it really is urgent, pick up the phone. Or hail the nearest taxi and tell them to break the speed limit.
 
One thing to watch out for: if your receipient's email program groups emails by subject line, changing the title may be an inconvenience for them, not a convenience.

In that case, don't change the subject line, or maybe use a different style where your add-on is at the END and not the beginning.

Don't send them links for downloading a mail reader that can thread replies more flexibly.

After all, this is meant as a courtesy for the recipient. if it makes life harder for them, it isn't very courteous.
 




<< Home
Reg Braithwaite


Recent Writing
Homoiconic Technical Writing / raganwald.posterous.com

Books
What I‘ve Learned From Failure / Kestrels, Quirky Birds, and Hopeless Egocentricity

Share
rewrite_rails / andand / unfold.rb / string_to_proc.rb / dsl_and_let.rb / comprehension.rb / lazy_lists.rb

Beauty
IS-STRICTLY-EQUIVALENT-TO-A / Spaghetti-Western Coding / Golf is a good program spoiled / Programming conventions as signals / Not all functions should be object methods

The Not So Big Software Design / Writing programs for people to read / Why Why Functional Programming Matters Matters / But Y would I want to do a thing like this?

Work
The single most important thing you must do to improve your programming career / The Naïve Approach to Hiring People / No Disrespect / Take control of your interview / Three tips for getting a job through a recruiter / My favourite interview question

Management
Exception Handling in Software Development / What if powerful languages and idioms only work for small teams? / Bricks / Which theory fits the evidence? / Still failing, still learning / What I’ve learned from failure

Notation
The unary ampersand in Ruby / (1..100).inject(&:+) / The challenge of teaching yourself a programming language / The significance of the meta-circular interpreter / Block-Structured Javascript / Haskell, Ruby and Infinity / Closures and Higher-Order Functions

Opinion
Why Apple is more expensive than Amazon / Why we are the biggest obstacles to our own growth / Is software the documentation of business process mistakes? / We have lost control of the apparatus / What I’ve Learned From Sales I, II, III

Whimsey
The Narcissism of Small Code Differences / Billy Martin’s Technique for Managing his Manager / Three stories about The Tao / Programming Language Stories / Why You Need a Degree to Work For BigCo

History
06/04 / 07/04 / 08/04 / 09/04 / 10/04 / 11/04 / 12/04 / 01/05 / 02/05 / 03/05 / 04/05 / 06/05 / 07/05 / 08/05 / 09/05 / 10/05 / 11/05 / 01/06 / 02/06 / 03/06 / 04/06 / 05/06 / 06/06 / 07/06 / 08/06 / 09/06 / 10/06 / 11/06 / 12/06 / 01/07 / 02/07 / 03/07 / 04/07 / 05/07 / 06/07 / 07/07 / 08/07 / 09/07 / 10/07 / 11/07 / 12/07 / 01/08 / 02/08 / 03/08 / 04/08 / 05/08 / 06/08 / 07/08 /