https://www.flickr.com/photos/restlessglobetrotter/2660204217
Notifications are an essential part of most computer systems. Operations happen asynchronously and users who care about the completion of them need to be notified somehow. In most cases e-mail is the primary way someone is notified. E-mail has been around forever and it’s easy to address a message to a specific user or a group of users. Most programming frameworks also include the ability to e-mail.
I hate e-mail notifications. Okay; so hate is a powerful word. I severely dislike e-mail notifications.
E-mail is fundamentally broken.
E-mail has been around since the beginning of Internet time – even before it. Internet e-mail protocols have remained rather unchanged since 1982 when SMTP was introduced. This means e-mail is a reliable protocol but also it partially means it hasn’t held up well to the rapidly changing ways of how we communicate. E-mail usage has been eclipsed dramatically by things like SMS, iMessage, WhatsApp, Facebook Messenger and so on. This feels very much like how the postal service’s letter carrying service has evolved into only the mechanism in which bills and advertisements arrive to your house.
E-mail can be hard to set up. We all have problems remembering usernames and passwords. E-mail is even worse with mixing in POP/IMAP/SMTP server addresses, port numbers, authentication methods, and SSL settings. Thankfully the major players like Gmail have wizards in most modern operating systems making the configuration process somewhat easier. Work e-mail can be confounded even more with VPN and proxy requirements.
We live in a world of data caps on cellular networks and home Internet connections. E-mail is not a super efficient player in this world. While most messages are a small number of bytes e-mail clients can add a ton of bloat. HTML formatting, attached images, and protocol inefficiencies can silently suck up your data. I’ve had many e-mail clients get stuck sending a message in a loop wiping out my remaining data for the month.
Rich content in e-mail clients is vastly difficult to pull off. Ask any web developer whom has been asked to create a slick marketing message or pretty template. Life becomes painful when you have to test your HTML against many e-mail clients. Rendering is randomly broken, JavaScript doesn’t always work, and localizing isn’t really possible.
In the end there’s no guarantee that your message was delivered to the recipient. You also don’t reliably have a way to determine if your message was read either. There are tricks for read notifications and newer optional protocols for delivery reliability. None of these really do much more than add more uncertainty to the process.
We use e-mail for everything. Notifications are lost in the noise.
How many of you have thousands of unread (and read) messages in your inbox right now? I’d guess a lot of you. E-mail clearly isn’t working for how we’re using it.
There are classes given at a corporate level to teach e-mail etiquette. Don’t carbon-copy your entire team, don’t include the body of the message you’re replying to, don’t put pictures in your e-mail signature, save the environment don’t print this e-mail, and so on. It’s a system that’s easy to abuse.
An automated notification e-mail from your production system monitor comes in to tell you something is wrong. How long does it take for you to see it? Do you have rules set up to bubble “important” things to the top or in another bucket? I bet some of those monitoring systems are false alerts or not super serious so they sit in your inbox, unread. You’ll eventually get to them and the problem will be fixed. You better leave those messages there “for the reminder’s sake.” Sound familiar?
The important stuff gets lost. We can’t easily mute the things that aren’t important. There’s no simple way to move a bar up and down for the severity of your notifications. You get all or nothing and that adds to information fatigue.
Changes aren’t transmitted well.
I subscribe to a number of internal WordPress blogs at Automattic using the O2 theme. This theme gives us nested comments and a super lightweight way of communicating in an asynchronous manner. However, we do have so many of these blogs and you can only subscribe to so many before your brain asplodes. I use the WordPress.com Reader to subscribe to new posts. A lot of my colleagues use e-mail notifications for this.
Blog posts aren’t static. Once they’ve been posted they can still be edited. By subscribing to new posts via e-mail you’re missing any edits done after the initial post. Imagine sending out a piece of code for your coworkers to test and right after you publish it you realize you made a mistake. You quickly edit the post, wipe your brow, and then hope nobody saw it. Anyone who got the e-mail notification won’t see your update and will comment on the error. Chances are the other person won’t read the edited post when the link to the post is clicked to comment on it. Subscribing to edits on posts as a solution is terribly taxing on the brain.
So what’s the solution?
There are a lot of ways to communicate to users that isn’t e-mail. Push notifications are the cleanest solution but they typically require a mobile or desktop app to be the receiver/displayer of the notifications. The WordPress mobile and desktop apps provide a contextually-relevant place to queue the notifications and read when appropriate. Badge icons, banner notifications and sounds all are configurable by the user to reduce fatigue. Use do not disturb on your device when you’re opting out of everything for a period of time.
Push notifications aren’t without their failings either. Most providers don’t offer 100% guarantee of delivery. Users can also feel bombarded by every app sending notifications and end up turning the feature off. There are ways to handle these situations in a series of escalation steps.
In normal circumstances users view/respond to a push notification in an allowable amount of time. Urgent notifications requiring action should be allotted less time. Notification read receipts may be a feature available by the platform. At least if the app is launched you can generally determine that the notification has been seen. Then the app silently indicates such through to your servers.
Notifications that don’t get read can get pushed again, sent as an e-mail with a high priority, or end up turning into a phone call. You may choose to “dial down” the number sent if a user isn’t reading less important notifications. Instead choose to notify your user less but with more content to prevent them from feeling fatigue and uninstalling your app.
E-mail isn’t always the best option for communicating things to your users. Know how your users want to use your systems and come up with a method that prevents both missed messages and fatigue. Notify people when it’s contextually relevant and give them options to turn things off when it bothers them. Users who ignore your notifications are one step away from not finding value in your product or service.
