Sh*t my brain says and forgets about

Tag: communication

Being mindful during video calls

Working remote means I’m on a lot of video calls. I’ve come up with a bunch of little tweaks to help with attentiveness and mindfulness during the call. It is important to show you’re listening.

Look at the camera often

When you’re in person you look at people’s eyes to show them you’re listening. Doing that on a video call requires a bit of counter-intuitive body language by looking at the camera. You won’t be looking at the person but they’ll see you looking directly at them. It’s a subtle difference but I’ve found it highly effective.

Also try to place the video call window up the screen towards the camera. Also decrease the size of the window so the person’s eyes are naturally closer to the top of the window (closer to the camera). When you’re not looking at the camera while the person is speaking it’ll still look like you’re generally looking at them. If you see someone’s eyes darting around during a call it’s easy to assume they’re distracted.

Actually listen

Don’t get on a video call unless the other people have your attention. There’s nothing more dismissive than seeing people on the call absorbed in something else. Give the speaker visual cues you’re listening including the occasional nod. Mark yourself as do not disturb and turn off distractions.

Show your hands

Once in a while I’ll lean back or do something to have my hands show up on camera. Why? It shows I’m not typing. If I’m not typing then I’m not doing something else like chatting on Slack or coding. This is just another subtle way to show you’re paying attention.

Take written notes

Hand-written notes force you to not use the keyboard and further pay attention. I generally let people know I like taking hand-written notes so they know why I look down once in a while. Sometimes looking down can be disruptive particularly in 1:1 meetings –  conversations will naturally pause. If you need to be less obvious when taking notes then stick with typing notes.

Lighting, sound, camera

Make sure you’re properly lit and don’t have a light behind you that’s washing out your image. Use a headset or headphones to prevent feedback. Try using a higher quality microphone as well instead of the built-in one. If your camera is lower resolution consider getting a decent USB one. Looking and sounding good helps eliminate distractions from any message you’re trying to convey.

Turn off your own video preview

If you can, turn off the little window showing your own live view once you’re sure your lighting is good. You’ll find that once that preview is gone you’ll look more at the person on the other end of the call.

The Slack Channel Effect


Instead of talking in a big group we split off into separate channels which is somewhat anti-collaboration.

I realized the other day that channels in Slack (or any other group messaging platform) are both good and bad. When there are a small number of rooms it’s easier to find a conversation or to be involved in the majority of discussions. As the number of people in the rooms grows, chats become more noisy. The solution is to create another channel – ideally something subject-specific to filter out the noise. There’s a counter-effect which is somewhat unexpected – it can reduce interaction between members.

Turns out the more channels there are, the less conversations you have exposure to. This sounds stupidly obvious – but it’s not really when you’re so close to the effect. As your channel list grows it’ll reach a critical mass when information overwhelms you. Your only way to fight back is to start leaving channels.

A large room with a lot of activity is easier to mute either by shutting down the chat client or by using a muting feature. Rooms let you segment conversations by topic but then you have less interaction with teammates and less visibility of what is going on overall. The reality is neither method is sustainable. I haven’t quite figured out the solution for a balance between the two.

E-mail Notifications Aren’t Always Useful

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 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.

Apple’s Public Mailing Lists

You may not be aware but Apple has a pretty extensive set of public e-mail discussion lists.

There are topics ranging from fundamental Objective-C issues through to development for their various desktop applications.  Some of the lists are quite chatty but you can subscribe in digest format to get a daily e-mail instead of each individual message.  This is a great way to reach engineers working on the piece you’re interested in and is a quite interesting place to lurk.

Powered by WordPress & Theme by Anders Norén