Daily Archives: December 12, 2006

Pet Peeve: E-mail is not Instantaneous

I just received a phone call from an external party that I’ve been working with on a project. It started off like this:

Him: “Hi Chase, do you have a couple minutes to chat?”
Me: “Yeah, sure.”
Him: “OK, excellent. I have a question for you. Here, I’m sending you an e-mail with a couple URLs in it… and… OK, I just sent it.”
Me: [clicking send/receive... clicking send/receive] “While I’m waiting, can you explain what the question is?”

It turns out the question was dead simple, and really didn’t require the supporting URLs to clarify. I answered his question, wrapped up the conversation, and hung up. 30 seconds later his e-mail finally appeared in my inbox.

Aside from my slight annoyance at starting a phone conversation with: “Do you have a couple minutes to chat?” (if I didn’t, I probably wouldn’t have answered the phone), or the sending of the e-mail after the phone call is started… what really bugs me is the common misconception that e-mail is instantaneous. Sure, you can send me an e-mail and most of the time it’ll get delivered pretty quick, but “pretty quick” can range from 30 seconds to minutes, to hours (or to days if there are more serious server issues). Because people have become so used to the more common quick deliveries, they come to expect them and rely on them, and in turn they get frustrated when delivery is delayed. This write-up about e-mail from the University of California, is the first result for a search on “email is not instantaneous” and it covers many other realities of e-mail.

This is really a basic case of taking something for granted. We all do it in various ways, and it’s a particularly interesting issue when it comes to delivering products or services. If my product is only designed to realiably do a task in say, 10 minutes, but it regularly does it faster, then how do I address user complaints when it starts taking the full 10 minutes again? That’s a whole different can of worms about controlling user expectations and properly communicating what “normal” behavior should be. Now that e-mail has become so commonplace, and technology has brought it to near-instantaneous speeds, it would be entirely impractical/obnoxious for e-mail clients to start popping up a dialog box each time I send a message, saying: “This could take an hour or more to send.” Even worse, what if e-mail server technology automatically dialed itself down to the more reliable speeds (I know it could never work with the architechture of the internet). Should we design popular products to only perform as promised? No, that’s certainly not an answer either, and designers that purposefully “cripple” their products in these ways are annoying.

With e-mail, it’s clearly too late to manage expectations. The common misconception/expectataion of e-mail being instantaneous can be frustrating, and is a pet-peeve of mine. Keep in mind that things won’t always behave the way you’re used-to, and the last thing I want is to sit on the phone with you while refreshing my inbox.