Receive one email a day for 30 days, each featuring at least one HTML element.
Right up my alley!
Receive one email a day for 30 days, each featuring at least one HTML element.
Right up my alley!
I’ve been thinking some more about the technical experience of booking a vaccination apointment and how much joy it brought me.
All of those technologies are platform-agnostic.
No matter what operating system I’m using, or what email software I’ve chosen, email works. It gets more complicated when you introduce HTML email. My response to that is the same as the old joke; you know the one: “Doctor, it hurts when I do this.” (“Well, don’t do that.”)
No matter what operating system my phone is using, SMS works. It gets more complicated when you introduce read receipts, memoji, or other additions. See my response to HTML email.
Then there’s the web. No matter what operating system I’m using on a device that could be a phone or a tablet or a laptop or desktop tower, and no matter what browser I’ve chosen to use, the World Wide Web works.
It feels like the principle of least power in action.
But another way of rephrasing “least power” is “most availability.” Technologies that are old, simple, and boring tend to be more widely available.
I remember when software used to come packaged in boxes and displayed on shelves. The packaging always had a list on the side. It looked like the nutritional information on a food product, but this was a list of “system requirements”: operating system, graphics card, sound card, CPU. I never liked the idea of system requirements. It felt so …exclusionary. And for me, the promise of technology was liberation and freedom to act on my own terms.
Alas, many developers don’t build with this mindset. I mean, I understand why: it means thinking about users with the most boring, least powerful technology. It’s simpler and more exciting to assume that everyone’s got a shared baseline of newer technology. But by doing that, you’re missing out on one of the web’s superpowers: that something served up at the same URL with the same underlying code can simultaneously serve people with older technology and also provide a whizz-bang experience to people with the latest and greatest technology.
Anyway, I’ve been thinking about the kind of communication technologies that are as universal as email, SMS, and the web.
QR codes are kind of heading in that direction, although I still have qualms because of their proprietary history. But there’s something nice and lo-fi about them. They’re like print stylesheets in reverse (and I love print stylesheets). A funky little bridge between the physical and the digital. I just wish they weren’t so opaque: you never know if scanning that QR code will actually take you to the promised resource, or if you’re about to rickroll yourself.
Telephone numbers kind of fall into the same category as SMS, but with the added option of voice. I’ve always found the prospect of doing something with, say, Twilio’s API more interesting than building something inside a walled garden like Facebook Messenger or Alexa.
I know very little about chat apps or voice apps, but I don’t think there’s a cross-platform format that works with different products, right? I imagine it’s like the situation with native apps which require a different codebase for each app store and operating system. And so there’s a constant stream of technologies that try to fulfil the dream of writing once and running everywhere: React Native, Flutter.
They’re trying to solve a very clear and obvious problem: writing the same app more than once is really wasteful. But that’s the nature of the game when it comes to runtime-specific apps. The only alternative is to either deliberately limit your audience …or apply the principle of least power/most availability.
The wastefulness of having to write the same app for multiple platforms isn’t the only thing that puts me off making native apps. The exclusivity works in two directions. There’s the exclusive nature of the runtime that requires a bespoke codebase. There’s also the exclusive nature of the app store. It feels like a return to shelves of packaged software with strict system requirements. You can’t just walk in and put your software on the shelf. That’s the shopkeeper’s job.
There is no shopkeeper for the World Wide Web.
The Right Number is a gentle, noncommercial space where your only job is to be yourself. Upon dialing you’ll be connected to a voicemail box and given a brief prompt. You have three minutes to answer however you’d like.
I use Apple’s Mail app for my email so this is very handy:
An email tracker, read receipt and spy pixel blocker plugin for macOS Apple Mail.
Thirty years later, it is easy to overlook the web’s origins as a tool for sharing knowledge. Key to Tim Berners-Lee’s vision were open standards that reflected his belief in the Rule of Least Power, a principle that choosing the simplest and least powerful language for a given purpose allows you to do more with the data stored in that language (thus, HTML is easier for humans or machines to interpret and analyze than PostScript). Along with open standards and the Rule of Least Power, Tim Berners-Lee wanted to make it easy for anyone to publish information in the form of web pages. His first web browser, named Nexus, was both a browser and editor.
The pushback I get usually takes the form of “Well, that approach is fine for websites, but it wouldn’t work something like Gmail.”
It’s always Gmail. Which is odd. Because if you really wanted to flummox me with a product or service that defies progressive enhancement, I’d have a hard time with something like, say, a game (although it would be pretty cool to build a text adventure that’s progressively enhanced into a first-person shooter). But an email client? That would work.
Identify core functionality.
Read emails. Write emails.
Make that functionality available using the simplest possible technology.
HTML for showing a list of emails, HTML for displaying the contents of the HTML, HTML for the form you write the response in.
Now add all the enhancements that improve the experience—keyboard shortcuts; Ajax instead of full-page refreshes; local storage, all that stuff.
Progressive enhancement isn’t about making a choice between using simpler more robust technologies or using more advanced features; it’s about using simpler more robust technologies and then using more advanced features. Have your cake and eat it.
Fortunately I no longer need to run this thought experiment to imagine what it would be like if something like Gmail were built with a progressive enhancement approach. That’s what HEY is.
HEY’s UI is 100% HTML over the wire. We render plain-old HTML pages on the server and send them to your browser encoded as text/html. No JSON APIs, no GraphQL, no React—just form submissions and links.
If you think that sounds like the web of 25 years ago, you’re right! Except the HEY front-end stack progressively enhances the “classic web” to work like the “2020 web,” with all the fidelity you’d expect from a well-built SPA.
See? It’s not either resilient or modern—it’s resilient and modern. Have your cake and eat it.
And yet this supremely sensible approach is not considered “modern” web development:
The architecture astronauts who, for the past decade, have been selling us on the necessity of React, Redux, and megabytes of JS, cannot comprehend the possibility of building an email app in 2020 with server-rendered HTML.
HEY isn’t perfect by any means—they’ve got a lot of work to do on their accessibility. But it’s good to have a nice short answer to the question “But what about something like Gmail?”
When Ethan Marcotte demonstrated the power of responsive design, it was met with resistance. “Sure, a responsive design might work for a simple personal site but there’s no way it could scale to a large complex project.”
Then the Boston Globe launched its responsive site. Microsoft made their homepage responsive. The floodgates opened again.
It’s a similar story today. “Sure, progressive enhancement might work for a simple personal site, but there’s no way it could scale to a large complex project.”
The floodgates are ready to open. We just need you to create the poster child for resilient web design.
It looks like HEY might be that poster child.
I have to wonder if its coincidence or connected that this is a service that’s also tackling ethical issues like tracking? Their focus is very much on people above technology. They’ve taken a human-centric approach to their product and a human-centric approach to web development …because ultimately, that’s what progressive enhancement is.
A service that—amongst other things—allows you to read newsletters in your RSS reader.
This is a wonderful deep dive into all the parts of a URL:
There’s a lot of great DNS stuff about the
Root DNS servers operate in safes, inside locked cages. A clock sits on the safe to ensure the camera feed hasn’t been looped. Particularily given how slow DNSSEC implementation has been, an attack on one of those servers could allow an attacker to redirect all of the Internet traffic for a portion of Internet users. This, of course, makes for the most fantastic heist movie to have never been made.
Mike follows up on the changes made by email startup Superhuman after his initial post:
I will say this: if you were skeptical of Superhuman’s commitment to privacy and safety after reading the last article, you should probably be even more skeptical after these changes. The company’s efforts demonstrate a desire to tamp down liability and damage to their brand, but they do not show an understanding of the core problem: you should not build software that surreptitiously collects data on people in a way that would surprise and frighten them.
A really excellent analysis by Mike of a dark pattern in the Superhuman email app.
That’s right. A running log of every single time you have opened my email, including your location when you opened it. Before we continue, ask yourself if you expect this information to be collected on you and relayed back to your parent, your child, your spouse, your co-worker, a salesperson, an ex, a random stranger, or a stalker every time you read an email.
Exactly! This violates the principle of least surprise. Also, it’s just plain wrong.
Amazingly though, Mike has been getting pushback from guys on Twitter (and it’s always guys) who don’t think this is a big deal.
Anyway, read the whole thing—it’s fair, balanced, and really well written.
Spoiler: it’s plain text. Every time.
Nothing boosts opens and clicks as well as an old school, plain-text email.
I feel vindicated.
People say they prefer HTML emails ..but they actually prefer plain-text.
This seems like a plausable explanation:
Think about how you email colleagues and friends: Do you usually add images or use well-designed templates? Probably not, and neither does your audience. They’re used to using email to communicate in a personal way, so emails from companies that look more personal will resonate more.
Now get off my lawn, you pesky HTML-email lovin’ kids.
Coming to your inbox soon:
The Training Commission is a speculative fiction email newsletter about the compromises and consequences of using technology to reckon with collective trauma. Several years after a period of civil unrest and digital blackouts in the United States, a truth and reconciliation process has led to a major restructuring of the federal government, major tech companies, and the criminal justice system.
I’ve been using Mailchimp for years now to send out a weekly newsletter from The Session. But I never visit the Mailchimp website. Instead, I use the API to create a campaign each week, and then send it out. I also use the API whenever a member of The Session updates their email preferences (or changes their details).
I got an email from Mailchimp that their old API was being deprecated and I’d need to update to their more recent one. The code I was using had been happily running for about seven years, but now I’d have to change it.
Everything went pretty smoothly. I was able to create campaigns, send campaigns, add new subscribers, and delete subscribers. But I ran into an issue when I wanted to update someone’s email address (on The Session, you can edit your details at any time, including your email address).
Here’s the set up:
use \DrewM\MailChimp\MailChimp; $MailChimp = new MailChimp('abc123abc123abc123abc123abc123-us1'); $list_id = 'b1234346'; $subscriber_hash = $MailChimp -> subscriberHash('firstname.lastname@example.org'); $endpoint = 'lists/'.$listID.'/members/'.$subscriber_hash;
Now to update details, according to the API, I can use the
patch method on that endpoint:
$MailChimp -> patch($endpoint, [ 'email_address' => 'email@example.com' ]);
But that doesn’t work. Mailchimp effectively treats email addresses as unique IDs for subscribers. So the only way to change someone’s email address appears to be to delete them, and then subscribe them fresh with the new email address:
$MailChimp -> delete($endpoint); $newendpoint = 'lists/'.$listID.'/members'; $MailChimp -> post($newendpoint, [ 'email_address' => 'firstname.lastname@example.org', 'status' => 'subscribed' ]);
That’s somewhat annoying, as the previous version of the API allowed email addresses to be updated, but this workaround isn’t too arduous.
Anyway, I figured it share this just in case it was useful for anyone else migrating to the newer API.
Update: Belay that. Turns out that you can update email addresses, but you have to be sure to include the
$MailChimp -> patch($endpoint, [ 'email_address' => 'email@example.com', 'status' => 'subscribed' ]);
Okay, that’s a lot more straightforward. Ignore everything I said.
After musing on newsletters, Craig shares how he’s feeling about Instagram and its ilk:
Instagram will only get more complex, less knowable, more algorithmic, more engagement-hungry in 2019.
I’ve found this cycle has fomented another emotion beyond distrust, one I’ve felt most acutely in 2018: Disdain? (Feels too loaded.) Disappointment? (Too moralistic.) Wariness? (Yes!) Yes — wariness over the way social networks and the publishing platforms they provide shift and shimmy beneath our feet, how the algorithms now show posts of X quality first, or then Y quality first, or how, for example, Instagram seems to randomly show you the first image of a multi-image sequence or, no wait, the second.8
I try to be deliberate, and social networks seem more and more to say: You don’t know what you want, but we do. Which, to someone who, you know, gives a shit, is pretty dang insulting.
Wariness is insidious because it breeds weariness. A person can get tired just opening an app these days. Unpredictable is the last thing a publishing platform should be but is exactly what these social networks become. Which can make them great marketing tools, but perhaps less-than-ideal for publishing.
Craig’s slow walk away from Instagram:
I want to have a place very far apart from that, where I can post photos on my own terms. Not have an algorithm decide which of my posts is best (have you noticed Instagram making the second photo in series appear first in the carousel?). And I don’t want to be rewarded for being anodyne, which is what these general algorithms seem to optimize for: things that are easily digestible, firmly on the scale of “fine, just fine.” It becomes a self-fulfilling prophecy, as the more boring stuff we shove into our eyeballs, the more boring our taste becomes.
Craig writes about reading and publishing, from the memex and the dynabook to the Kindle, the iPhone, and the iPad, all the way back around to plain ol’ email and good old-fashioned physical books.
We were looking for the Future Book in the wrong place. It’s not the form, necessarily, that needed to evolve—I think we can agree that, in an age of infinite distraction, one of the strongest assets of a “book” as a book is its singular, sustained, distraction-free, blissfully immutable voice. Instead, technology changed everything that enables a book, fomenting a quiet revolution. Funding, printing, fulfillment, community-building—everything leading up to and supporting a book has shifted meaningfully, even if the containers haven’t. Perhaps the form and interactivity of what we consider a “standard book” will change in the future, as screens become as cheap and durable as paper. But the books made today, held in our hands, digital or print, are Future Books, unfuturistic and inert may they seem.
Philosophically, I’m completely against Google’s AMP project and AMP for Email, too. I will always side with the open web and the standards that power it, and AMP is actively working against both. I’m all-in on a faster web for everyone, but I just can’t get behind Google’s self-serving method for providing that faster web.
This looks like an interesting alternative to TinyLetter for writing and sending email newsletters, like all the cool kids are doing.
Language is a technology. It’s a particularly strange one that’s made of squiggles and sounds and maps of meaning, but like any other technology, it’s hackable.
Good advice on reducing unintended stress via email.
Negativity bias is a tendency for negatives to have a greater effect than positives on our emotional state.
For email this can have radical effects: positive emails seem neutral, neutral emails seem negative, and even slightly negative emails can lead to actual, measurable pain.
Even with the best of intentions we can come off distant — or just plain mean.