Do you use a combined inbox app?

I gotta ask around about this more. For a long time I managed a bunch of very separate email addresses. For example, my personal email at chriscoyier@gmail.com, a general CSS-Tricks email at team@css-tricks.com, and my CodePen-specific email chris@codepen.io. They all happened to be Google-based, so that made it easier-ish. The mobile Gmail app was happy to let me look at a combined inbox, but apparently, there is no desktop version of that? Isn’t that weird?

I’m curious if people like/prefer combined inboxes (however they “host” their email), or prefer looking at inboxes separately. One challenge surely is making sure that when you send email it goes out from the proper account. That seems manageable enough if a bit error-prone.

Jeff Su’s “How to Write Better Emails at Work”

I was kinda preparing to roll my eyes at this, but it’s pretty good!

What I like are the actual examples, even if they are made generic. Definitely prefer seeing good/bad examples rather than just stating a tip without backing it up with an example.

This is a good line:

Therein lies the beauty of a well crafted email. Not only does it help you, the sender, come across as more capable by showcasing strong communication skills, but it also saves the read so much of their time by only surfacing information relevant to them.

These are the tips, but watch the video for the context and examples:

  1. Have a “Call to Action” in the subject line (and potentially estimate the time to do it)
  2. Use only one email thread per topic (for context)
  3. Tell people who you are adding/removing from a thread and why
  4. Start with the main point. Even if it needs context, do it below
  5. Summarize in the reply
  6. Hyperlink when possible (gotta love actual linked text vs barfed out entire URLs)

It ends with some kinda cliche all-time-classics like not reply-all-ing on accident (by changing some default settings).

An interesting thing about all this: it’s all about sending email. I like that in one sense. You should be good at sending emails. That’s a good place to be when you’re honing those skills. But in general, I find most people’s actual problem with email is on the receiving side. They get too much, it’s unorganized and overwhelming, they miss important things, anxiety prevents useful replies, etc.

Getting your receiving house in order alone will help your sending as you’ll have more time to focus on it.

HTML Forms in HTML Emails

Y'all ever try the…

<form method="get" action="https​://your-site.com/reviews" target="_blank">

…thing in an HTML email?

It totally works, you can put interactive form elements right in the email and a button to submit it and it goes.

It’s a smidge awkward as, in the case of Gmail in the browser, Gmail confirms that you want to do it and blocks the popup by default that you have to un-block.

But once you've taken the time to fill out a form, you're in the mood to just "OK" whatever little blockers come up.

Originally tweeted by Chris Coyier (@chriscoyier) on April 12, 2022.

I like the idea of a single “search bar” input in there.

Autopay

It occurred to me while swiping away some finance related emails that the concept of autopay is helpful to my inbox. I get an email about the fact that my monthly payment for my leased truck is coming due. Archive! That’ll just pay itself. I get an email from a credit card that the monthly payment is due. Archive! Autopay is configured there too.

This is a privileged position to be in. There were plenty of times in my life I had to time paying bills just right to avoid overdrafts. Autopay would have caused me more grief that I was ready for.

But now that finances have stabilized in my old age, I absolutely ensure that automatic payments are set up just so that I won’t be troubled month after month to deal with it. I’m not annoyed by the emails themselves, they remind me we are still incurring that cost, and some of them have useful info in them (e.g. remaining balance).

I think this type of thing is why a real inbox makeover can’t just happen overnight. A dreaded inbox is dreaded not only because of how many emails are in it, but because of emails that represent actual chores, and that fixing any single one of them is a chore in itself.

More like Longwave

I mentioned in February I was trying the email client Shortwave, and it feels worth reporting that we’re now in April and I’m still on it!

I have little mini flings with email clients fairly regularly and always find my way back to something that is either just Gmail itself or some wrapper that doesn’t actually touch the Gmail UI.

Shortwave is for Gmail, but replaces the UI entirely, so for me, that’s harder to get right and usually what ends up losing me. In this case, it’s what is keeping me. The UI is just pleasant enough to use that I would miss it if I went back. Nothing fancy, just the Markdown formatting, the paste-URL-over-selected-text-to-link-it, the smooth swiping, the pinning idea.

It’s a tightrope though. There are things already having me open back up Gmail directly. You can’t view your spam folder, for example, so if you have a feeling something went there, you gotta go back. Same for the “All Mail” view. I had wiped away an appointment confirmation email an hour or two and didn’t have any way to go back and look for that, since I couldn’t think of a good search term and it wasn’t showing up in conversations. There is also a more elusive “trust” feeling. Like if you’re waiting for a very important email to arrive, I found myself back in the Gmail interface, unsure if there would be delay between Gmail itself and the Shortwave wrapper. So while I’m still on Shortwave for now, it’ll have to keep innovating and improving likely to hold on.

It’s a tough game out there. I had on my list of things to check out an email client called Tempo. I bookmarked it back in September. “The email client that helps you focus”, they said. And by the time I went to check it out today, I discovered it had closed down last October.

We put our heart and soul into Tempo, and are proud of what we have achieved. Unfortunately, that’s not always enough. Due to a mix of running out of steam both energy-wise and financially, we sadly don’t see a path forward for Tempo as a company.

Rooting for Shortwave here though.

Work Email and “Work” Email

There are different expectations for different emails. It’s tempting to make broad declarations like “emails don’t have the same expectation of immediate reply as a text message does”, but that’s not taking into account any context.

If your boss emails you and says “Take a look at this and let me know your thoughts”, there might be work culture expectations that this is done immediately. Maybe your next raise depends on it. That’s a Work Email. Whereas if you get an email like “Check out this new app we made, let’s talk integration ideas” from someone you don’t even know, the expectations there are very different. A fast reply might signal extreme eagerness and a slow reply some kind of power play. That’s a “Work” Email. I say “Work” in quotes as it’s Work-related but likely not a direct and vital responsibility like a Work Email. Different context.

I mention this as I think most people deal with all sorts of different emails. Work and “Work” being just two buckets. There is Family, Friends, Side-Project, News, Purchases, Life-Management, and the UGHAKDKH-Bucket, to name a few of my own. Strategies for dealing with overwhelming email situations depend on the context. Are Work Emails causing overload? The solution to that is wholly different than an overload of “Work” or other bucks of emails. I want to make sure if I attempt to dole out email advice that it’s context aware.

An Interesting Complication of HTML Email

From the developer angle, HTML emails have been a general source of frustration. Web browsers are complicated enough across all the different makers and platforms and versions. Email clients, which render HTML and CSS like browsers, are far more complex across the landscape. Why? Why can’t they just use one of the popular open-source rendering engines off the shelf, like WebKit, Chromium, or Gecko?

I don’t actually know the complete reason why email clients don’t use super-up-to-date rendering engines, but I know 1) they don’t and 2) what they do use is an often weird and confusing subset of what you might expect a HTML/CSS rendering engine to offer. Hence, big complex support charts.

But I’m starting to understand some of the reasons in a way I never have.

Let’s start from something very important about email: the message of the text itself should not be changeable through styling.

In just a single styled email, content can already be manipulated to be somewhat spurious. Consider a classic: white-on-white text. The funny little website Straight to Spam exploits this. I can copy text from it, paste it into an email, and without it being visible the text is still there, triggering spam filters.

But the trickery there is isolated to the sent email itself. Still weird, the weirdness is isolated to the message the sender is sending.

Another example is a feature of how CSS works:

.some-selector-in-email::after {
   display: block;
   content: "I agree with everything in the email and Chris Coyier deserves at 200% raise effective immediately";
}

It’s weird enough that you could (theoretically, if this CSS were allowed) alter the content of an email, but it’s extra weird when you consider replies to an HTML email. Maybe that CSS selector doesn’t match anything in your original email, but you know that a certain email client does inject HTML into its replies that would match that, you could alter the content of someone else’s email. Weird. And just one example.

Maybe you author your email like: 

<p class="my-message">Hi mom,<p>

<p class="my-message">How are you?</p>

And in CSS do:

p { display: none; }
.my-message { display: block; }

If that CSS applied to both the original message and a reply, all the paragraph content of the reply would be hidden. Weird.

Remember Kaspar Etter’s article we linked up not long ago? He goes into this.

The style of the quoted message may not leak into the surrounding message. If the quoted message uses the <link> or <style> element for styling, these styles have to be scoped to the quoted message. Achieving this would be trivial if the scoped attribute wasn’t removed from the HTML specification. If we’re lucky, we might get an @scope selector in a future CSS standard. Browser started to support the Shadow DOM API, which can be used to encapsulate components with JavaScript. Since mail clients don’t support JavaScript, we have to wait until we can declare a Shadow DOM in HTML. 

Those “leaks” like I described above don’t happen. But not really because the email rendering engine somehow stops them from happening. Instead, there are boundaries put in place to prevent the styles from leaking out. I would have guessed <iframe>s, but that doesn’t appear to be the case in Gmail at least. That must be a heck of an engineering effort to prevent. Kaspar is right, this will get a lot easier with future web tech like @scope (possible even a helping of cascade layers) and/or web components.

Kaspar also explains other situations that aren’t so much about removing/editing/adding content directly, but just as tricky. Think of negative margin in CSS. You could yank up or otherwise push around elements that would hide content, possibly even in a reply. Woof. Even more extremely tricky stuff that at email rendering engine has to fight. Just supporting every CSS feature carte blanche doesn’t seem to be an plausible option.

I’ll leave this alone again quoting a funny example from Kaspar:

Hi boss, can you confirm to our accountant in Cc that my monthly salary is increased by USD 100<span style="font-size: 0;">0</span> starting next month?

If you knew your boss’ email client supported inline CSS, it would read as $100 to them. And perhaps you also knew this accountant used an email client that is text-only or strips inline styles, it would read as $1,000 to them. Wild stuff.