I enjoyed reading through these essays about the web of twenty years ago: music, photos, email, games, television, iPods, phones…
Much as I love the art direction, you’d never know that we actually had some very nice-looking websites back in 2004!
My reaction to this surprised me: I was repelled
I imagine this is what it feels like when you’re on a phone call with someone and towards the end of the call you hear a distinct flushing sound.
I got a nice email from someone regarding my recent posts about performance on The Session. They said:
I hope this message finds you well. First and foremost, I want to express how impressed I am with the overall performance of https://thesession.org/. It’s a fantastic resource for music enthusiasts like me.
How nice! I responded, thanking them for the kind words.
They sent a follow-up clarification:
Awesome, anyway there was an issue in my message.
The line ‘It’s a fantastic resource for music enthusiasts like me.’ added by chatGPT and I didn’t notice.
I imagine this is what it feels like when you’re on a phone call with someone and towards the end of the call you hear a distinct flushing sound.
I wrote back and told them about Simon’s rule:
I will not publish anything that takes someone else longer to read than it took me to write.
That just feels so rude!
I think that’s a good rule.
This anthology of Steve Jobs interviews, announcements and emails is available to read for free as a nicely typeset web book.
Almost no-one has given informed constent to being tracked through spy pixels in emails, and yet the practice is endemic. This is wrong. It needs to change.
The day we started to allow email clients to be full-blown web browsers (but without the protections of browsers) was the day we lost — time, security, privacy, and effectiveness. Now we spend all our time fighting with the materials of an email (i.e. color and layout) rather than refining its substance (i.e. story and language).
I like reading RSS feeds. I’ve written before about how my feed reader feels different to my email client:
When I open my RSS reader to catch up on the feeds I’m subscribed to, it doesn’t feel like opening my email client. It feels more like opening a book. And, yes, books are also things to be completed—a bookmark not only marks my current page, it also acts as a progress bar—but books are for pleasure. The pleasure might come from escapism, or stimulation, or the pursuit of knowledge. That’s a very different category to email, calendars, and Slack.
Giles put it far better when described what using RSS feeds feels like :
To me, using RSS feeds to keep track of stuff I’m interested in is a good use of my time. It doesn’t feel like a burden, it doesn’t feel like I’m being tracked or spied on, and it doesn’t feel like I’m just another number in the ads game.
To me, it feels good. It’s a way of reading the web that better respects my time, is more likely to appeal to my interests, and isn’t trying to constantly sell me things.
That’s why I feel somewhat conflicted about email newsletters. On the one hand, people are publishing some really interesting things in newsletters. On the hand, the delivery mechanism is email, which feels burdensome. Add tracking into the mix, and they can feel downright icky.
But never fear! My feed reader came to the rescue. Many newsletter providers also provide RSS feeds. NetNewsWire—my feed reader of choice—will try to find the RSS feed that corresponds to the newsletter. Hurrah!
I get to read newsletters without being tracked, which is nice for me. But I also think it would be nice to let the authors of those newsletters know that I’m reading. So here’s a list of some of the newsletters I’m currently subscribed to in my feed reader:
The Whippet by McKinley Valentine:
A newsletter for the terminally curious.
Sentiers by Patrick Tanguay:
A carefully curated selection of articles with thoughtful commentary on technology, society, culture, and potential futures.
Policy, ethics and applied rationality with an Irish slant.
How science shapes stories about the future and how stories about the future shape science.
Adjacent Possible by Steven Johnson:
Exploring where good ideas come from—and how to keep them from turning against us.
Faster, Please! by James Pethokoukis:
Discovering, creating, and inventing a better world through technological innovation, economic growth, and pro-progress culture.
undefended / undefeated by Sara Hendren:
Ideas at the heart of material culture—the everyday stuff in all our lives
Today in Tabs by Rusty Foster:
Your favorite newsletter’s favorite newsletter.
I must remember to try this out-of-office email strategy.
Even if you can somehow justify using tracking technologies (which don’t work reliably) to make general, statistical decisions (“fewer people open our emails when the subject contains the word ‘overdraft’!”), you can’t make individual decisions based on them. That’s just wrong.
Prompted by my post on tracking, Chris does some soul searching about his own use of tracking.
I’m interested not just in the ethical concerns and my long-time complacency with industry norms, but also as someone who very literally sells advertising.
He brings up the point that advertisers expect to know how many people opened a particular email and how many people clicked on a particular link. I’m sure that’s right, but it’s also beside the point: what matters is how the receiver of the email feels about having that information tracked. If they haven’t given you permission to do it, you can’t just assume they’re okay with it.
I’ve been reading the excellent Design For Safety by Eva PenzeyMoog. There was a line that really stood out to me:
The idea that it’s alright to do whatever unethical thing is currently the industry norm is widespread in tech, and dangerous.
It stood out to me because I had been thinking about certain practices that are widespread, accepted, and yet strike me as deeply problematic. These practices involve tracking users.
The first problem is that even the terminology I’m using would be rejected. When you track users on your website, it’s called analytics. Or maybe it’s stats. If you track users on a large enough scale, I guess you get to just call it data.
Those words—“analytics”, “stats”, and “data”—are often used when the more accurate word would be “tracking.”
Or to put it another way; analytics, stats, data, numbers …these are all outputs. But what produced these outputs? Tracking.
Here’s a concrete example: email newsletters.
Do you have numbers on how many people opened a particular newsletter? Do you have numbers on how many people clicked a particular link?
You can call it data, or stats, or analytics, but make no mistake, that’s tracking.
Follow-on question: do you honestly think that everyone who opens a newsletter or clicks on a link in a newsletter has given their informed constent to be tracked by you?
You may well answer that this is a widespread—nay, universal—practice. Well yes, but a) that’s not what I asked, and b) see the above quote from Design For Safety.
You could quite correctly point out that this tracking is out of your hands. Your newsletter provider—probably Mailchimp—does this by default. So if the tracking is happening anyway, why not take a look at those numbers?
But that’s like saying it’s okay to eat battery-farmed chicken as long as you’re not breeding the chickens yourself.
When I try to argue against this kind of tracking from an ethical standpoint, I get a frosty reception. I might have better luck battling numbers with numbers. Increasing numbers of users are taking steps to prevent tracking. I had a plug-in installed in my mail client—Apple Mail—to prevent tracking. Now I don’t even need the plug-in. Apple have built it into the app. That should tell you something. It reminds me of when browsers had to introduce pop-up blocking.
If the outputs generated by tracking turn out to be inaccurate, then shouldn’t they lose their status?
But that line of reasoning shouldn’t even by necessary. We shouldn’t stop tracking users because it’s inaccurate. We should stop stop tracking users because it’s wrong.
The Clearleft newsletter goes out every two weeks on a Thursday. You can peruse the archive to see past editions.
I think it’s a really good newsletter, but then again, I’m the one who writes it. It just kind of worked out that way. In theory, anyone at Clearleft could write an edition of the newsletter.
To make that prospect less intimidating, I put together a document for my colleagues describing how I go about creating a new edition of the newsletter. Then I thought it might be interesting for other people outside of Clearleft to get a peek at how the sausage is made.
So here’s what I wrote…
The description of the newsletter is:
A round-up of handpicked hyperlinks from Clearleft, covering design, technology, and culture.
It usually has three links (maybe four, tops) on a single topic.
The topic can be anything that’s interesting, especially if it’s related to design or technology. Every now and then the topic can be something that incorporates an item that’s specifically Clearleft-related (a case study, an event, a job opening). In general it’s not very salesy at all so people will tolerate the occasional plug.
You can use the “iiiinteresting” Slack channel to find potential topics of interest. I’ve gotten in the habit of popping potential newsletter fodder in there, and then adding related links in a thread.
Imagine you’re telling a friend about something cool you’ve just discovered. You can sound excited. Don’t worry about this looking unprofessional—it’s better to come across as enthusiastic than too robotic. You can put real feelings on display: anger, disappointment, happiness.
That said, you can also just stick to the facts and describe each link in turn, letting the content speak for itself.
If you’re expressing a feeling or an opinion, use the personal pronoun “I”. Don’t use “we” unless you’re specifically referring to Clearleft.
But most of the time, you won’t be using any pronouns at all:
So-and-so has written an article in such-and-such magazine on this-particular-topic.
You might find it useful to have connecting phrases as you move from link to link:
Speaking of some-specific-thing, this-other-person has a different viewpoint.
or
On the subject of this-particular-topic, so-and-so wrote something about this a while back.
The format of the newsletter is:
Take a look through the archive of previous newsletters to get a feel for it.
Currently the newsletter is called dConstruct from Clearleft. The subject line of every edition is in the format:
dConstruct from Clearleft — Title of the edition
(Note that’s an em dash with a space on either side of it separating the name of the newsletter and the title of the edition)
I often try to come up with a pun-based title (often a punny portmanteau) but that’s not necessary. It should be nice and short though: just one or two words.
Firefox has a nifty extension—made by Mozilla—called Facebook Container. It does two things.
First of all, it sandboxes any of your activity while you’re on the facebook.com domain. The tab you’re in is isolated from all others.
Secondly, when you visit a site that loads a tracker from Facebook, the extension alerts you to its presence. For example, if a page has a share widget that would post to Facebook, a little fence icon appears over the widget warning you that Facebook will be able to track that activity.
It’s a nifty extension that I’ve been using for quite a while. Except now it’s gone completely haywire. That little fence icon is appearing all over the web wherever there’s a form with an email input. See, for example, the newsletter sign-up form in the footer of the Clearleft site. It’s happening on forms over on The Session too despite the rigourous-bordering-on-paranoid security restrictions in place there.
Hovering over the fence icon displays this text:
If you use your real email address here, Facebook may be able to track you.
That is, of course, false. It’s also really damaging. One of the worst things that you can do in the security space is to cry wolf. If a concerned user is told that they can ignore that warning, you’re lessening the impact of all warnings, even serious legitimate ones.
Sometimes false positives are an acceptable price to pay for overall increased security, but in this case, the rate of false positives can only decrease trust.
I tried to find out how to submit a bug report about this but I couldn’t work it out (and I certainly don’t want to file a bug report in a review) so I’m writing this in the hopes that somebody at Mozilla sees it.
What’s really worrying is that this might not be considered a bug. The release notes for the version of the extension that came out last week say:
Email fields will now show a prompt, alerting users about how Facebook can track users by their email address.
Like …all email fields? That’s ridiculous!
I thought the issue might’ve been fixed in the latest release that came out yesterday. The release notes say:
This release addresses fixes a issue from our last release – the email field prompt now only displays on sites where Facebook resources have been blocked.
But the behaviour is unfortunately still there, even on sites like The Session or Clearleft that wouldn’t touch Facebook resources with a barge pole. The fence icon continues to pop up all over the web.
I hope this gets sorted soon. I like the Facebook Container extension and I’d like to be able to recommend it to other people. Right now I’d recommed the opposite—don’t install this extension while it’s behaving so overzealously. If the current behaviour continues, I’ll be uninstalling this extension myself.
Update: It looks like a fix is being rolled out. Fingers crossed!
Denise shares a cautionary tale of service design gone wrong.
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.
I’ve written before about how I’ve got a blind spot for the web so it’s no surprise that I was praising the use of a well marked-up form, styled clearly, and unencumbered by unnecessary JavaScript. But other technologies were in play too: Short Message Service (SMS) and email.
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.
Hence my soft spot for the boring and basic technologies like email, SMS, and yes, web pages. The difference with web pages is that you can choose to layer added extras on top. As long as the fundamental functionality is using universally-supported technology, you’re free to enhance with all the latest CSS and JavaScript. If any of it fails, that’s okay: it falls back to a nice solid base.
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.
Progressive enhancement is at the heart of everything I do on the web. It’s the bedrock of my speaking and writing too. Whether I’m writing about JavaScript, Ajax, HTML, or service workers, it’s always through the lens of progressive enhancement. Sometimes I explicitly bang the drum, like with Resilient Web Design. Other times I don’t mention it by name at all, and instead talk only about its benefits.
I sometimes get asked to name some examples of sites that still offer their core functionality even when JavaScript fails. I usually mention Amazon.com, although that has other issues. But quite often I find that a lot of the examples I might mention are dismissed as not being “web apps” (whatever that means).
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.
Enhance!
Now add all the enhancements that improve the experience—keyboard shortcuts; Ajax instead of full-page refreshes; local storage, all that stuff.
Can you build something that works just like Gmail without using any JavaScript? No. But that’s not what progressive enhancement is about. It’s about providing the core functionality (reading and writing emails) with the simplest possible technology (HTML) and then enhancing using more powerful technologies (like JavaScript).
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.
Sam Stephenson describes the approach they took:
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?”
It reminds me of responsive web design:
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.