Tags: writing

65

sparkline

Timing

Apple Inc. is my accidental marketing department.

On April 29th, 2010, Steve Jobs published his infamous Thoughts on Flash. It thrust the thitherto geek phrase “HTML5” into the mainstream press:

HTML5, the new web standard that has been adopted by Apple, Google and many others, lets web developers create advanced graphics, typography, animations and transitions without relying on third party browser plug-ins (like Flash). HTML5 is completely open and controlled by a standards committee, of which Apple is a member.

Five days later, I announced the first title from A Book Apart: HTML5 For Web Designers. The timing was purely coincidental, but it definitely didn’t hurt that book’s circulation.

Fast forward eight years…

On March 29th, 2018, Apple released the latest version of iOS. Unmentioned in the press release, this update added service worker support to Mobile Safari.

Five days later, I announced the 26th title from A Book Apart: Going Offline.

For a while now, quite a few people have cited Apple’s lack of support as a reason why they weren’t investigating service workers. That excuse no longer holds water.

Once again, the timing is purely coincidental. But it can’t hurt.

That new-book smell

The first copies of Going Offline showed up today! This is my own personal stash, sent just a few days before the official shipping date of next Monday.

I am excite!

To say I was excited when I opened the box of books would be an understatement. I was positively squealing with joy!

Others in the Clearleft office shared in my excitement. Everyone did that inevitable thing, where you take a fresh-out-of-the-box book, open it up and press it against your nose. It’s like the bookworm equivalent of sniffing glue.

Actually, it basically is sniffing glue. I mean, that’s what’s in the book binding. But let’s pretend that we’re breathing in the intoxicating aroma of freshly-minted words.

If you’d like to bury your nose in a collection of my words glued together in a beautifully-designed package, you can pre-order the book now and await delivery of the paperback next week.

Technical balance

Two technical editors worked with me on Going Offline.

Jake was one of the tech editors. He literally (co-)wrote the spec on service workers. There ain’t nuthin’ he don’t know about the code involved. His job was to catch any technical inaccuracies in my writing.

The other tech editor was Amber. She’s relatively new to web development. While I was writing the book, she had a solid grounding in HTML and CSS, but not much experience in JavaScript. That made her the perfect archetypal reader. Her job was to point out whenever I wasn’t explaining something clearly enough.

My job was to satisfy both of them. I needed to explain service workers and all its associated APIs. I also needed to make it approachable and understandable to people who haven’t dived deeply into JavaScript.

I deliberately didn’t wait until I was an expert in this topic before writing Going Offline. I knew that the more familiar I became with the ins-and-outs of getting a service worker up and running, the harder it would be for me to remember what it was like not to know that stuff. I figured the best way to avoid the curse of knowledge would be not to accrue too much of it. But then once I started researching and writing, I inevitably became more au fait with the topic. I had to try to battle against that, trying to keep a beginner’s mind.

My watchword was this great piece of advice from Codebar:

Assume that anyone you’re teaching has no knowledge but infinite intelligence.

It was tricky. I’m still not sure if I managed to pull off the balancing act, although early reports are very, very encouraging. You’ll be able to judge for yourself soon enough. The book is shipping at the start of next week. Get your order in now.

The audience for Going Offline

My new book, Going Offline, starts with no assumption of JavaScript knowledge, but by the end of the book the reader is armed with enough code to make any website work offline.

I didn’t want to overwhelm the reader with lots of code up front, so I’ve tried to dole it out in manageable chunks. The amount of code ramps up a little bit in each chapter until it peaks in chapter five. After that, it ramps down a bit with each subsequent chapter.

This tweet perfectly encapsulates the audience I had in mind for the book:

Some people have received advance copies of the PDF, and I’m very happy with the feedback I’m getting.

Honestly, that is so, so gratifying to hear!

Words cannot express how delighted I am with Sara’s reaction:

She’s walking the walk too:

That gives me a warm fuzzy glow!

If you’ve been nervous about service workers, but you’ve always wanted to turn your site into a progressive web app, you should get a copy of this book.

Table of Contents for Going Offline

A few people on Twitter have asked about the table of contents for my new book about service workers, Going Offline. Fair enough—why not see the menu before placing your order?

  1. Introducing Service Workers Does what is says on the tin. It also talks about switching to HTTPS. This chapter is online at A List Apart so you can try before you buy.
  2. Preparing for Offline This chapter talks about how you register a service worker, and introduces the concept of promises in JavaScript.
  3. Making Fetch Happen Yes, this chapter title is a Mean Girls reference; fight me. The chapter explains fetch events and shows how a service worker can intercept them.
  4. Cache Me if you Can This puntastic chapter is all about caching, and shows you can use caches in your service worker script.
  5. Service Worker Strategies This is the heart of the book, where you get decide what kind of strategy you want to implement—when to go to the network, when to go a cache, and so on. And as a last resort, you can have a custom offline page.
  6. Refining Your Service Worker Building on the previous chapter, this one looks at how you can use different strategies for different kinds of files—images, pages, etc.
  7. Tidying Up This chapter is about good service worker hygiene like deleting old caches. It also introduces some more coding style options.
  8. The Offline Experience By this chapter, the service worker script is done. But there’s still plenty of room for enhancements on that custom offline page, including the use of offline storage.
  9. Progressive Web Apps The book finishes with an explanation of progressive web apps, and a step-by-step guide to creating your own web app manifest.

Sound good? Pre-order your copy of the book now and you’ll have it in your hands ten days from now.

Live-blogging An Event Apart Seattle

I tried do some live-blogging at An Event Apart Seattle. I surprised myself by managing to do all six talks on the first day. I even managed one or two after that, but that was the limit of my stamina. Torre, on the other hand, managed to live-blog every single talk—amazing!

Some of the talks don’t necessarily lend themselves to note-taking—ya kinda had to be there. But some of the the live-blogging I did ended up being surprisingly coherent.

Anyway, I figured it would be good to recap all the ones I managed to do here in one handy list.

  1. Beyond Engagement: the Content Performance Quotient by Jeffrey Zeldman. I think I managed to document the essence of what Jeffrey was getting at: for many sites, engagement isn’t the right metric to measure—the idea of a Content Performance Quotient is one alternative.
  2. Digital Marketing Strategies for the Busy “Web Master” by Sarah Parmenter. The structure of Sarah’s talk lent itself well to live-blogging, but I strongly disagreed with one or two of her suggestions (like encouraging people to install the disgusting abomination that is Facebook Pixel).
  3. Scenario-Driven Design Systems by Yesenia Perez-Cruz. This one was hard to live-blog because it was so packed with so many priceless knowledge bombs—an absolutely brilliant presentation, right up my alley!
  4. Graduating to Grid by Rachel Andrew. The afternoon sessions, with their emphasis on CSS, were definitely tricky to capture. I didn’t even try to catch most of the code, but I think I managed to get down most of Rachel’s points about learning new CSS.
  5. Fit For Purpose: Making Sense of the New CSS by Eric Meyer. There was a fair bit of code in this one, and lots of gasp-inducing demos too, so my account probably doesn’t do it justice.
  6. Everything You Know About Web Design Just Changed by Jen Simmons. There was no way I could document the demos, but I think I managed to convey the excitement in Jen’s talk.
  7. Navigating Team Friction by Lara Hogan. I only managed to do two talks on the second day, but I think they came out the best. Lara’s talk was packed full with great advice, but it was so clearly structured that I think I managed to get most of the main points down.
  8. Designing Progressive Web Apps by Jason Grigsby. I had a vested interest in the topic of Jason’s talk so I was scribing like crazy. Apart from a few missing diagrams, I think my notes managed to convey most of Jason’s message.

Of course the one talk I definitely couldn’t live-blog was my own. I’ve documented lists of links relating to the subject matter of my talk, but if you weren’t at An Event Apart Seattle, then the only other chance to see the talk is at An Event Apart Boston in June. That’s the only other time I’m giving it.

I thoroughly enjoyed giving the talk in Seattle, particularly when I treated the audience to a scoop: I announced my new book, Going Offline, during the talk (I had been scheming with Katel at A Book Apart and we co-ordinated the timing to a tee).

Announcing Going Offline from A Book Apart

I decided that I wanted a new mug.

I already have one very nice mug. It was sent to me by A Book Apart because I wrote the book HTML5 For Web Designers back in 2010. If I wanted another nice mug, it was clear what I had to do. I had to write another book.

So I’ve written a book. It’s called Going Offline and it’s available to pre-order now. It will start shipping a few weeks from now.

I think you will enjoy this book. Here’s why…

You have a website or you make websites for other people. You’re comfortable with HTML and CSS, but maybe you’re a bit apprehensive about JavaScript (like me). You keep hearing lots of talk about service workers and progressive web apps. You’re intrigued. But you’re put off by the resources out there. They all assume a certain level of JavaScript knowledge. What you need is a step-by-step guide to help you make your website work offline …a guide that won’t assume you’re already comfortable with code.

Does that sound like you? Then Going Offline is for you.

Thinking about it, a more accurate title for the book would’ve been Service Workers For Web Designers …although even that would assume too much existing knowledge (like, what the heck a service worker is in the first place).

Pre-order Going Offline today and it will be in your hands in just a few weeks.

Alas, I have no idea when my new mug will be ready.

Just change it

Amber and I often have meta conversations about the nature of learning and teaching. We swap books and share ideas and experiences whenever we’re trying to learn something or trying to teach something. A topic that comes up again and again is the idea of “the curse of knowledge“—it’s the focus of Steven Pinker’s book The Sense Of Style. That’s when the author/teacher can’t remember what it’s like not to know something, which makes for a frustrating reading/learning experience.

This is one of the reasons why I encourage people to blog about stuff as they’re learning it; not when they’ve internalised it. The perspective that comes with being in the moment of figuring something out is invaluable to others. I honestly think that most explanatory books shouldn’t be written by experts—the “curse of knowledge” can become almost insurmountable.

I often think about this when I’m reading through the installation instructions for frameworks, libraries, and other web technologies. I find myself put off by documentation that assumes I’ve got a certain level of pre-existing knowledge. But now instead of letting it get me down, I use it as an opportunity to try and bridge that gap.

The brilliant Safia Abdalla wrote a post a while back called How do I get started contributing to open source?. I definitely don’t have the programming chops to contribute much to a codebase, but I thoroughly agree with Safia’s observation:

If you’re interested in contributing to open source to improve your communication and empathy skills, you’re definitely making the right call. A lot of open source tools could definitely benefit from improvements in the documentation, accessibility, and evangelism departments.

What really jumps out at me is when instructions use words like “simply” or “just”. I’m with Brad:

“Just” makes me feel like an idiot. “Just” presumes I come from a specific background, studied certain courses in university, am fluent in certain technologies, and have read all the right books, articles, and resources. “Just” is a dangerous word.

But rather than letting that feeling overwhelm me, I now try to fix the text. Here are a few examples of changes I’ve suggested, usually via pull requests on Github repos:

They all have different codebases in different programming languages, but they’re all intended for humans, so having clear and kind documentation is a shared goal.

I like suggesting these kinds of changes. That initial feeling of frustration I get from reading the documentation gets turned into a warm fuzzy feeling from lending a helping hand.

Words I wrote in 2017

I wrote 78 blog posts in 2017. That works out at an average of six and a half blog posts per month. I’ll take it.

Here are some pieces of writing from 2017 that I’m relatively happy with:

Going Rogue. A look at the ethical questions raised by Rogue One

In AMP we trust. My unease with Google’s AMP format was growing by the day.

A minority report on artificial intelligence. Revisiting two of Spielberg’s films after a decade and a half.

Progressing the web. I really don’t want progressive web apps to just try to imitate native apps. They can be so much more.

CSS. Simple, yes, but not easy.

Intolerable. A screed. I still get very, very angry when I think about how that manifestbro duped people.

Акула. Recounting a story told by a taxi driver.

Hooked and booked. Does A/B testing lead to dark patterns?

Ubiquity and consistency. Different approaches to building on the web.

I hope there’s something in there that you like. It always a nice bonus when other people like something I’ve written, but I write for myself first and foremost. Writing is how I figure out what I think. I will, of course, continue to write and publish on my website in 2018. I’d really like it if you did the same.

Brian Aldiss

After the eclipse I climbed down from the hilltop and reconnected with the world. That’s when I heard the news. Brian Aldiss had passed away.

He had a good innings. A very good innings. He lived to 92 and was writing right up to the end.

I’m trying to remember the first thing I read by Brian Aldiss. I think it might have been The Billion Year Spree, his encyclopaedia of science fiction. The library in my hometown had a copy when I was growing up, and I was devouring everything SF-related.

Decades later I had the great pleasure of meeting the man. It was 2012 and I was in charge of putting together the line-up for that year’s dConstruct. I had the brilliant Lauren Beukes on the line-up all the way from South Africa and I thought it would be fun to organise some kind of sci-fi author event the evening before. Well, one thing led to another: Rifa introduced me to Tim Aldiss, who passed along a request to his father, who kindly agreed to come to Brighton for the event. Then Brighton-based Jeff Noon came on board. The end result was an hour and a half in the company of three fantastic—and fantastically different—authors.

I had the huge honour of moderating the event. Here’s the transcript of that evening and here’s the audio.

That evening and the subsequent dConstruct talks—including the mighty James Burke—combined to create one of the greatest weekends of my life. Seriously. I thought it was just me, but Chris has also written about how special that author event was.

Brian Aldiss, Jeff Noon, and Lauren Beukes on the Brighton SF panel, chaired by Jeremy Keith

Brian Aldiss was simply wonderful that evening. He regaled us with the most marvellous stories, at times hilarious, at other times incredibly touching. He was a true gentleman.

I’m so grateful that I’ll always have the memory of that evening. I’m also very grateful that I have so many Brian Aldiss books still to read.

I’ve barely made a dent into the ludicrously prolific output of the man. I’ve read just some of his books:

  • Non-stop—I’m a sucker for generation starship stories,
  • Hothouse—ludicrously lush and trippy,
  • Greybeard—a grim vision of a childless world before Children Of Men,
  • The Hand-reared Boy—filthy, honest and beautifully written,
  • Heliconia Spring—a deep-time epic …and I haven’t even read the next two books in the series!

Then there are the short stories. Hundreds of ‘em! Most famously Super-Toys Last All Summer Long—inspiration for the Kubrick/Spielberg A.I. film. It’s one of the most incredibly sad stories I’ve ever read. I find it hard to read it without weeping.

Passed by a second-hand book stall on the way into work. My defences were down. Not a bad haul for a fiver.

Whenever a great artist dies, it has become a cliché to say that they will live on through their work. In the case of Brian Aldiss and his astounding output, it’s quite literally true. I’m looking forward to many, many years of reading his words.

My sincerest condolences to his son Tim, his partner Alison, and everyone who knew and loved Brian Aldiss.

Posting to my site

I was idly thinking about the different ways I can post to adactio.com. I decided to count the ways.

Admin interface

This is the classic CMS approach. In my case the CMS is a crufty hand-rolled affair using PHP and MySQL that I wrote years ago. I log in to an admin interface and fill in a form, putting the text of my posts into a textarea. In truth, I usually write in a desktop text editor first, and then paste that into the textarea. That’s what I’m doing now—copying and pasting Markdown from the Typed app.

Directly from my site

If I’m logged in, I get a stripped down posting interface in the notes section of my site.

Notes posting interface

Bookmarklet

This is how I post links. When I’m at a URL I want to bookmark, I hit the “Bookmark it” bookmarklet in my browser’s bookmarks bar. That pops open a version of the admin interface tailored specifically for links. I really, really like bookmarklets. The one big downside is that they don’t work on mobile.

Text message

This is something I knocked together at Indie Web Camp Brighton 2015 using the Twilio API. It’s handy for posting notes if I’m travelling somewhere and data is at a premium. But I don’t use it that often.

Instagram

Thanks to Aaron’s OwnYourGram service—and the fact that my site has a micropub endpoint—I can post images from Instagram to my site. This used to happen instantaneously but Instagram changed their API rules for the worse. Between that and their shitty “algorithmic” timeline, I find myself using the service less and less. At this point I’m only on their for the doggos.

Swarm

Like OwnYourGram, Aaron’s OwnYourSwarm allows me to post check-ins and photos from the Swarm app to my site. Again, micropub makes it all possible.

OwnYourGram and OwnYourSwarm are very similar and could probably be abstracted into a generic service for posting from third-party apps to micropub endpoints. I’d quite like to post my check-ins on Untappd to my site.

Other people’s admin interfaces

Thanks to rel="me" and IndieAuth, I can log into other people’s posting interfaces using my own website as the log-in, and post to my micropub endpoint, like this. Quill is a good example of this. I don’t use it that much, but I really should—the editor interface is quite Medium-like in its design.

Anyway, those are the different ways I can update my website that I can think of right now.

Syndication

In terms of output, I’ve got a few different ways of syndicating what I post here:

Just so you know, if you comment on one of my posts on Facebook, I probably won’t see it. But if you reply to a copy of one of posts on Twitter or Instagram, it will show up over here on adactio.com thanks to the magic of Brid.gy and webmention.

Words

I like words. I like the way they can be tethered together to produce a satisfying sentence.

Jessica likes words even more than I do (that’s why her website is called “wordridden”). She studied linguistics and she’s a translator by trade—German into English. Have a read of her post about translating Victor Klemperer to get an inkling of how much thought and care she puts into it.

Given the depth of enquiry required for a good translation, I was particularly pleased to read this remark by John Le Carré:

No wonder then that the most conscientious editors of my novels are not those for whom English is their first language, but the foreign translators who bring their relentless eye to the tautological phrase or factual inaccuracy – of which there are far too many. My German translator is particularly infuriating.

That’s from an article called Why we should learn German, but it’s really about why we should strive for clarity in our use of language:

Clear language — lucid, rational language — to a man at war with both truth and reason, is an existential threat. Clear language to such a man is a direct assault on his obfuscations, contradictions and lies. To him, it is the voice of the enemy. To him, it is fake news. Because he knows, if only intuitively, what we know to our cost: that without clear language, there is no standard of truth.

It reminds me of one of my favourite Orwell essays, Politics and the English Language:

Political language — and with variations this is true of all political parties, from Conservatives to Anarchists — is designed to make lies sound truthful and murder respectable, and to give an appearance of solidity to pure wind.

But however much I agree with Le Carré’s reprise of Orwell’s call for clarity, I was brought up short by this:

Every time I hear a British politician utter the fatal words, “Let me be very clear”, these days I reach for my revolver.

Le Carré’s text was part of a speech given in Berlin, where everyone would get the reference to the infamous Nazi quote—Wenn ich Kultur höre … entsichere ich meinen Browning—and I’m sure it was meant with a sly wink. But words matter.

Words are powerful. Words can be love and comfort — and words can be weapons.

Aurora

I remember when I was first recommended to read Kim Stanley Robinson. I was chatting with Jon Tan about science fiction, and I was bemoaning the fact that dystopias seem to be the default setting. Asking "what’s the worst that could happen?" is the over-riding pre-occupation of most sci-fi. Black Mirror is the perfect example of this. Mind you, that’s probably why the ambiguous San Junipero is one of my favourites—utopia? dystopia? dystutopia? You decide.

Anyway, Jon told me I should check out Kim Stanley Robinson’s Three Californias; one book describes a dystopia, one book describes a utopia, and the other—his debut, The Wild Shore—is more ambiguous. I liked the sound of that, but I decided that if I were going to read Kim Stanley Robinson, I should start with his most famous work, the Mars trilogy.

So I read Red Mars. I liked it, but I found it tough going. It’s not exactly a light read. I still haven’t read Green Mars or Blue Mars, though I plan to. I can see why Red Mars is regarded as a classic of hard sci-fi, but it left me somewhat cold. Jessica read The Years of Rice and Salt and had a similar reaction—good premise, thoroughly researched, but tough going.

When I heard about 2312, I couldn’t resist its promise of a jaunt around the solar system. Again, I enjoyed it, but the plot—such as it was—didn’t grab me. I loved the ideas presented in the book. Heck, it inspired one of my Science Hack Day projects. Still, I found that its literary conceit wasn’t enough to carry the book—a character from Saturn who’s saturnian in nature meets a character from Mercury who’s mercurial in nature.

So I was kind of bracing myself for Aurora. Again, the subject matter really appealed to me. I’m a sucker for generation starships. Brian Aldiss’s Non-Stop was a fun read, although in typical Aldiss style, it was weird to the point of psychedelia (even if it looks positively tame next to the batshit crazy world of Hothouse). I was looking forward to reading Robinson’s hard science take on the space ark idea, but I was worried about how much of a slog the writing might be. I read some reviews and listened to some podcasts, and my heart sank when I heard about how the story is partly told by the ship’s AI, who is simultaneously trying to work out how to tell a story. It sounded just like one of those ideas that would be fine for a brief period, but which I could imagine Kim Stanley Robinson dragging out for hundreds of page.

Imagine my surprise when Aurora turned out to be an absolute pleasure. Not only does it have the thoroughly-researched hard science angle of Robinson’s other books, it’s also a rip-roaring tale, in my opinion. I had read of misgivings with the structure of the book—complaints that the story climaxes before the book is halfway done—but I think that misses the point of the story. This is not your typical tale of colonisation. Far from it. Kim Stanley Robinson is quite open about the underlying idea here, that there are certain endeavours that are simply beyond our capacity.

I know that sounds like a very pessimistic view, but I found the book to be a real testament to human ingenuity. But it certainly ruffled quite a few feathers. Like I said, the default setting for most sci-fi is to go negative, but for a sci-fi writer to claim outright that something cannot be done is audacious, and flies in the face of sci-fi tradition.

Gregory Benford wrote a review over on one of my favourite blogs, Centauri Dreams. He takes Robinson to task for stacking the deck against the crew of the ship in Aurora—an inversion of the usual deus ex machina plot devices. I find that criticism puzzling when another review, also on Centauri Dreams, by Stephen Baxter, James Benford and Joseph Miller, takes the book to task for being scientifically naïve.

For me, Aurora was perfectly balanced. It simultaneously captured the wonder of scientific exploration and our own insignificance in the universe. Best of all, it featured central characters that I was utterly invested in—one human, and one artificial. Given my previous experiences with Kim Stanley Robinson books, that was perhaps its greatest achievement. Whereas I might have previously recommended something like 2312, I would have certainly caveated the recommendation. But I wholeheartedly recommend Aurora. It’s easily the best Kim Stanley Robinson book I’ve read so far, and one of the finest science fiction books of recent years. It makes a great companion piece to Neal Stephenson’s Seveneves—not only are they both dealing with space arks, they’ve also got some in-depth descriptions of angular momentum in action, and they’re both thoroughly enjoyable stories that stretch beyond a single human lifespan.

I’m looking forward to digging back through Kim Stanley Robinson’s back catalogue, and I’m very intrigued by his newest book, New York 2140. From listening to his Long Now talk at The Interval, it sounds like the book has as much to say about near-future economics as it does about climate change.

It’s ironic though. Kim Stanley Robinson was first recommended to me because he was one of the few sci-fi writers unafraid to depict a utopia. But his writing never clicked with me until I read Aurora, whose central message sounds like the ultimate downer …that some scientific achievements will forever remain out of reach for humanity.

Writing on the web

Some people have been putting Paul’s crazy idea into practice.

  • Mike revived his site a while back and he’s been posting gold dust ever since. I enjoy his no-holds-barred perspective on his time in San Francisco.
  • Garrett’s writing goes all the way back to 2005. The cumulative result is two fascinating interweaving narratives—one about his health, another about his business.
  • Charlotte has been documenting her move from Brighton to Sydney. Much as I love her articles about front-end development, I’m liking the slice-of-life updates on life down under even more.
  • Amber has a great way with words. As well as regularly writing on her blog, she’s two-thirds of the way through writing 100 words every day for 100 days.
  • Ethan has been writing about responsive design—of course—but it’s his more personal posts that make me really grateful for his site.
  • Jeffrey and Eric never stopped writing on their own sites. Sure, there’s good stuff on their about web design and development, but it’s the writing about their non-web lives that’s so powerful.

There are more people I could mention …but, to be honest, not that many more. Seems like most people are happy to only publish on Ev’s blog or not at all.

I know not everybody wants to write on the web, and that’s fine. But it makes me sad when people choose not to publish their thoughts because they think no-one will be interested, or that it’s all been said before. I understand where those worries come from, but I believe—no, I know—that they are unfounded.

It’s a world wide web out there. There’s plenty of room for everyone. And I, for one, love reading the words of others.

Introducing Resilient Web Design

I wrote a thing. The thing is a book. But the book is not published on paper. This book is on the web. It’s a web book. Or “wook” if you prefer …please don’t prefer. Here it is:

Resilient Web Design.

It’s yours for free.

Much of the subject matter will be familiar if you’ve seen my conference talks from the past couple of years, particularly Enhance! and Resilience. But the book ended up taking some twists and turns that surprised me. It turned out to be a bit of a history book: the history of design, the history of the web.

Resilient Web Design is a short book. It’s between sixteen and seventeen megawords long. You could read the whole thing in a couple of hours. Or—because the book has seven chapters—you could take fifteen to twenty minutes out of a day to read one chapter and you’d have read the whole thing done in a week.

If you make websites in any capacity, I hope that this book will resonate with you. Even if you don’t make websites, I still hope there’s an interesting story in there for you.

You can read the whole book on the web, but if you’d rather have a single file to carry around, I’ve made some PDFs as well: one in portrait, one in landscape.

I’ve licensed the book quite liberally. It’s released under a Creative Commons attribution share-alike licence. That means you can re-use the material in any way you want (even commercial usage) as long as you provide some attribution and use the same licence. So if you’d like to release the book in some other format like ePub or anything, go for it.

I’m currently making an audio version of Resilient Web Design. I’ll be releasing it one chapter at a time as a podcast. Here’s the RSS feed if you want to subscribe to it. Or you can subscribe directly from iTunes.

I took my sweet time writing this book. I wrote the first chapter in March 2015. I wrote the last chapter in May 2016. Then I sat on it for a while, figuring out what to do with it. Eventually I decided to just put the whole thing up on the web—it seems fitting.

Whereas the writing took over a year of solid procrastination, making the website went surprisingly quickly. After one weekend of marking up and styling, I had most of it ready to go. Then I spent a while tweaking. The source files are on Github.

I’m pretty happy with the end result. I’ll write a bit more about some of the details over the next while—the typography, the offline functionality, print styles, and stuff like that. In the meantime, I hope you’ll peruse this little book at your leisure…

Resilient Web Design.

If you like it, please spread the word.

Fifteen

My site has been behaving strangely recently. It was nothing that I could put my finger on—it just seemed to be acting oddly. When I checked to see if everything was okay, I was told that everything was fine, but still, I sensed something that was amiss.

I’ve just realised what it was. Last week on the 30th of September, I didn’t do or say anything special. That was the problem. I had forgotten my blog’s anniversary.

I’m so sorry, adactio.com! Honestly, I had been thinking about it for all of September but then on the day, one thing led to another, I was busy, and it just completely slipped my mind.

So this is a bit late, but anyway …happy fifteenth anniversary to this journal!

We’ve been through a lot together in those fifteen years, haven’t we, /journal? Oh, the places we’ve been and the things we’ve seen!

I remember where we were on our tenth anniversary: Bologna. Remember we were there for the first edition of the From The Front conference? Now, five years on, we’ve just been to the final edition of that same event—a bittersweet occasion.

Like I said five years ago:

It has been a very rewarding, often cathartic experience so far. I know that blogging has become somewhat passé in this age of Twitter and Facebook but I plan to keep on keeping on right here in my own little corner of the web.

I should plan something special for September 30th, 2021 …just to make sure I don’t forget.

Talking about hypertext

#CSSday starts off with a great history lesson of our industry by @adactio

I’ve just published a transcript of the talk I gave at the HTML Special that preceded CSS Day a couple of weeks back. I’ve also recorded an audio version for your huffduffing pleasure.

It’s not like the usual talks I give. The subject matter was assigned to me, Mission Impossible style. PPK wanted each speaker to give an entire talk on just one HTML element. He offered me the best element of them all: the A element.

There were a few different directions I could’ve taken it. I could’ve tried to make it practical, but I quickly dismissed that idea. Instead I went in the completely opposite direction, making it as pretentious as possible. I figured a talk about hypertext could afford to be winding and circuitous, building on some of the ideas I wrote about in my piece for The Manual a few years back. It’s quite self-indulgent of me, but I used it as an opportunity to geek out about some of my favourite things; from Borges, Babbage, and Bletchley to Leibniz, Lovelace, and Licklider.

I wouldn’t usually write out an entire talk word-for-word in advance, but somehow it felt right for this one. In fact, my talk preparation this time ‘round was very similar to the process Charlotte recently wrote about:

  1. Get everything out of my head and onto a mind map.
  2. Write chunks of content in short bursts—this was when I was buddying up with Paul.
  3. Put together a slide deck of visuals to support the narrative.
  4. Practice delivering the talk so I don’t look I’m just reading off a screen.

It takes me a long time to prepare talks. As the deadline for this one approached, I was getting quite panicked. It was touch and go there for a while, but I managed to get it done in time.

I’m pleased with how it turned out. On the day, I had fun delivering it. People seemed to like it too, which was gratifying.

Although with this kind of talk, it was inevitable that I wouldn’t be able to please everyone.

I guess this talk was a one-off affair. That said, if you’re putting on an event and you think this subject matter would be appropriate, let me know. I’d be more than happy to deliver it again.

Regression toward being mean

I highly recommend Remy’s State Of The Gap post—it’s ace. He summarises it like this:

I strongly believe in the concepts behind progressive web apps and even though native hacks (Flash, PhoneGap, etc) will always be ahead, the web, always gets there. Now, today, is an incredibly exciting time to be build on the web.

I agree completely. That might sound odd after I wrote about Regressive Web Apps, but it’s precisely because I’m so excited by the technologies behind progressive web apps that I think it’s vital that we do them justice. As Remy says:

Without HTTPS and without service workers, you can’t add to homescreen. This is an intentionally high bar of entry with damn good reasons.

When the user installs a PWA, it has to work. It’s our job as web developers to provide the most excellent experience for our users.

It has to work.

That’s why I don’t agree with Dion’s metrics for what makes a progressive web app:

If you deliver an experience that only works on mobile is that a PWA? Yes.

I think it’s important to keep quality control high. Being responsive is literally the first item in the list of qualities that help define what a progressive web app is. That’s why I wrote about “regressive” web apps: sites that are supposed to showcase what we can do but instead take a step backwards into the bad old days of separate sites for separate device classes: washingtonpost.com/pwa, m.flipkart.com, lite.5milesapp.com, app.babe.co.id, m.aliexpress.com.

A lot of people on Twitter misinterpreted my post as saying “the current crop of progressive web apps are missing the mark, therefore progressive web apps suck”. What I was hoping to get across was “the current crop of progressive web apps are missing the mark, so let’s make better ones!”

Now, I totally understand that many of these examples are a first stab, a way of testing the waters. I absolutely want to encourage these first attempts and push them further. But I don’t think that waiving the qualifications for progressive web apps helps achieves that. As much as I want to acknowledge the hard work that people have done to create those device-specific examples, I don’t think we should settle for anything less than high-quality progressive web apps that are as much about the web as they are about apps.

Simply put, in this instance, I don’t think good intentions are enough.

Which brings me to the second part of Regressive Web Apps, the bit about Chrome refusing to show the “add to home screen” prompt for sites that want to have their URL still visible when launched from the home screen.

Alex was upset by what I wrote:

if you think the URL is going to get killed on my watch then you aren’t paying any attention whatsoever.

so, your choices are to think that I have a secret plan to kill URLs, or conclude I’m still Team Web.

I’m galled that anyone, particularly you @adactio, would think the former…but contrarianism uber alles?

I am very, very sorry that I upset Alex like this.

But I stand by my criticism of the actions of the Chrome team. Because good intentions are not enough.

I know that Alex is huge fan of URLs, and of the web. Heck, just about everybody I know that works on Chrome in some capacity are working for the web first and foremost: Alex, Jake, various and sundry Pauls. But that doesn’t mean I’m going to stay quiet when I see the Chrome team do something I think is bad for the web. If anything, it’s precisely because I hold them to a high standard that I’m going to sound the alarm when I see what I consider to be missteps.

I think that good people can make bad decisions with the best of intentions. Usually it involves long-term thinking—something I think is very important. “The ends justify the means” is a way of thinking that can create a lot of immediate pain, even if it means a better future overall. Balancing those concerns is front and centre of the Chromium project:

As browser implementers, we find that there’s often tension between (a) moving the web forward and (b) preserving compatibility. On one hand, the web platform API surface must evolve to stay relevant. On the other hand, the web’s primary strength is its reach, which is largely a function of interoperability.

For example, when Alex talks of the Web Component era as though it were an inevitability, I get nervous. Not for myself, but for the millions of Opera Mini users out there. How do we get to a better future without leaving anyone behind? Or do we sacrifice those people for the greater good? Do the needs of the many outweigh the needs of the few? Do the ends justify the means?

Now, I know for a fact that the end-game that Alex is pursuing with web components—and the extensible web manifesto in general—is a more declarative web: solutions that first get tackled as web components end up landing in browsers. But to get there, the solutions are first created using modern JavaScript that simply doesn’t work everywhere. Is that the price we’re going to have to pay for a better web?

I hope not. I hope we can find ways to have our accessible cake and eat it too. But it will be really, really hard.

Returning to progressive web apps, I was genuinely shocked and appalled at the way that the Chrome team altered the criteria for the “add to home screen” prompt to discourage exposing URLs. I was also surprised at how badly the change was communicated—it was buried in a bug report that five people contributed to before pushing the change. I only found out about it through a conversation with Paul Kinlan. Paul encouraged me to give feedback, and that’s what I did on my website, just like Stuart did on his.

Of course the Chrome team are working on ways of exposing URLs within progressive web apps that are launched in from the home screen. Opera are working on it too. But it’s a really tricky problem to solve. It’s not enough to say “we’ll figure it out”. It’s not enough to say “trust us.”

I do trust the people I know working on Chrome. I also trust the people I know at Mozilla, Opera and Microsoft. That doesn’t mean I’m going to let their actions go unquestioned. Good intentions are not enough.

As Alex readily acknowledges, the harder problem (figuring out how to expose URLs) should have been solved first—then the change to the “add to home screen” metrics would be uncontentious. Putting the cart before the horse, discouraging display:browser now, while saying “trust us, we’ll figure it out”, is another example of saying the ends justify the means.

But the stakes are too high here to let this pass. Good intentions are not enough. Knowing that the people working on Chrome (or Firefox, or Opera, or Edge) are good people is not reason enough to passively accept every decision they make.

Alex called me out for not getting in touch with him directly about the Chrome team’s future plans with URLs, but again, that kind of rough consensus to do something is trumped by running code. Also, I did talk to Chrome people—this all came out of a discussion with Paul Kinlan. I don’t know who’s who in the company’s political hierarchy and I don’t think I should need an org chart to give feedback to Google (or Mozilla, or Opera, or Microsoft).

You’ll notice that I didn’t include Apple there. I don’t hold them to the same high standard. As it turns out, I know some very good people at Apple working on WebKit and Safari. As individuals, they care about the web. But as a company, Apple has shown indifference towards web developers. As Remy put it:

Even getting the hint of interest from Apple is a process of dumpster-diving the mailing lists scanning for the smallest hint of interest.

With that in mind, I completely understand Alex’s frustration with my post on “regressive” web apps. Although I intended it as a push towards making better progressive web apps, I can see how it could be taken as confirmation by those who think that progressive web apps aren’t worth investing in. Apple, for example. As it is, they’ll have to be carried kicking and screaming into adding support for Service Workers, manifest files, and other building blocks. From the reaction to my post from at least one WebKit developer on Twitter, not only did I fail to get across just how important the technologies behind progressive web apps are, I may have done more harm than good, giving ammunition to sceptics.

Still, I hope that most people took my words in the right spirit, like Addy:

We should push them to do much better. I’ll file bugs. Per @adactio post, can’t forget the ‘Progressive’ part of PWAs

Seeing that reaction makes me feel good …but seeing Alex’s reaction makes me feel bad. Very bad. I’m genuinely sorry that I made Alex feel that way. It wasn’t my intention but, well …good intentions are not enough.

I’ve been looking back at what I wrote, trying to see it through Alex’s eyes, looking for the parts that could be taken as a personal attack:

Chrome developers have decided that displaying URLs is not “best practice” … To declare that all users of all websites will be confused by seeing a URL is so presumptuous and arrogant that it beggars belief. … Withholding the “add to home screen” prompt like that has a whiff of blackmail about it. … This isn’t the first time that Chrome developers have made a move against the address bar. It’s starting to grind me down.

Some pretty strong words there. I stand by them, but the tone is definitely strident.

When we criticise something—a piece of software, a book, a website, a film, a piece of music—it’s all too easy to forget that there are real people behind it. But that isn’t the case here. I know that there are real people working on Chrome, because I know quite a few of those people. I also know that their intentions are good. That’s not a reason for me to remain silent—that’s a reason for me to speak up.

If I had known that my post was going to upset Alex, would I have still written it? That’s a tough one. On the one hand, this is a topic I care passionately about. I think it’s vital that we don’t compromise on the very things that make the web great. On the other hand, who knows if what I wrote will make the slightest bit of difference? In which case, I got the catharsis of getting it off my chest but at the price of upsetting somebody I respect. That price feels too high.

I love the fact that I can publish whatever I want on my own website. It can be a place for me to be enthusiastic about things that excite me, and a place for me to rant about things that upset me. I estimate that the enthusiastic stuff outnumbers the ranty stuff by about ten to one, but negativity casts a disproportionately large shadow.

I need to get better at tempering my words. Not that I’m going to stop criticising bad decisions when I see them, but I need to make my intentions clearer …because just having good intentions is not enough. Throughout this post, I’ve mentioned repeatedly how much I respect the people I know working on the Chrome team. I should have said that in my original post.

Owning my words

When I wrote a few words about progressive enhancement recently, I linked to Karolina’s great article The Web Isn’t Uniform. I was a little reluctant to link to it, not because of the content—which is great—but because of its location on Ev’s blog. I much prefer to link directly to people’s own websites (I have a hunch that those resources tend to last longer too) but I understand that Medium offers a nice low barrier to publishing.

That low barrier comes at a price. It means you have to put up with anyone and everyone weighing in with their own hot takes. The way the site works is that anyone who writes a comment on your article is effectively writing their own article—you don’t get to have any editorial control over what kind of stuff appears together with your words. There is very little in the way of community management once a piece is published.

Karolina’s piece attracted some particularly unsavoury snark—tech bros disagreeing in their brash bullying way. I linked to a few comments, leaving out the worst of the snark, but I couldn’t resist editorialising:

Ah, Medium! Where the opinions of self-entitled dudes flow like rain from the tech heavens.

I knew even when I was writing it that it was unproductive, itself a snarky remark. Two wrongs don’t make a right. But I wanted to acknowledge that not only was bad behaviour happening, but that I was seeing it, and I wasn’t ignoring it. I guess it was mostly intended for Karolina—I wanted to extend some kind of acknowledgment that the cumulative weight of those sneering drive-by reckons is a burden that no one should have to put up with.

I knew that when I wrote about Medium being “where the opinions of self-entitled dudes flow like rain from the tech heavens” that I would (rightly) get pushback, and sure enough, I did …on Medium. Not on Twitter or anywhere else, just Medium.

I syndicate my posts to Ev’s blog, so the free-for-all approach to commenting doesn’t bother me that much. The canonical URL for my words remains on my site under my control. But for people posting directly to Medium and then having to put up with other people casually shitting all over their words, it must feel quite disempowering.

I have a similar feeling with Twitter. I syndicate my notes there and if the service disappeared tomorrow, I wouldn’t shed any tears. There’s something very comforting in knowing that any snarky nasty responses to my words are only being thrown at copies. I know a lot of my friends are disheartened about the way that Twitter has changed in recent years. I wish I could articulate how much better it feels to only use Twitter (or Medium or Facebook) as a syndication tool, like RSS.

There is an equal and opposite reaction too. I think it’s easier to fling off some thoughtless remarks when you’re doing it on someone else’s site. I bet you that the discourse on Ev’s blog would be of a much higher quality if you could only respond from your own site. I find I’m more careful with my words when I publish here on adactio.com. I’m taking ownership of what I say.

And when I do lapse and write snarky words like “Ah, Medium! Where the opinions of self-entitled dudes flow like rain from the tech heavens.”, at least I’m owning my own snark. Still, I will endeavour to keep my snark levels down …but that doesn’t mean I’m going to turn a blind eye to bad behaviour.

Content Buddy

I have a new role at Clearleft. It’s not a full-time role. It’s in addition to my existing role of …um …whatever it is I do at Clearleft.

Anyway, my new part-time role is that of being a content buddy. Sounds a little dismissive when I put it like that. Let me put in capitals…

My new part-time role is that of being a Content Buddy.

This is Ellen’s idea. She’s been recruiting Content Guardians and Content Buddies. The Guardians will be responsible for coaxing content out of people, encouraging to write that blog post, article, or case study. The role of the Content Buddy is to help shepherd those pieces into the world.

I have let it be known throughout the office that I am available—day or night, rain or shine—for proof-reading, editing, and general brain-storming and rubber-ducking.

On my first official day as a Content Buddy on Friday I helped Ben polish off a really good blog post (watch this space), listened to a first run-through of Charlotte’s upcoming talk at the Up Front conference in Manchester (which is shaping up to be most excellent), and got together with Paul for a mutual brainstorming session for future conference talks. The fact that Paul is no longer a full-time employee at Clearleft is a mere technicality—Content Buddies for life!

Paul is preparing a talk on design systems for Smashing Conference in Freiburg in September. I’m preparing a talk on the A element for the HTML Special part of CSS Day in Amsterdam in just one month’s time (gulp!). We had both already done a bit of mind-mapping to get a jumble of ideas down on paper. We learned that from Ellen’s excellent workshop.

Talk prep, phase 1: doodling.

Then we started throwing ideas back and forth, offering suggestions, and spotting patterns. Once we had lots of discrete chunks of stuff outlined (but no idea how to piece them together), we did some short intense spurts of writing using the fiendish TheMostDangerousWritingApp.com. I looked at Paul’s mind map, chose a topic from it for him, and he had to write on that non-stop for three to five minutes. Meanwhile he picked a topic from my mind map and I had to do the same. It was exhausting but also exhilarating. Very quickly we had chunks of content that we could experiment with, putting them in together in different ways to find different narrative threads. I might experiment with publishing them as short standalone blog posts.

The point was not to have polished, finished content but rather to get to the “shitty first draft” stage quickly. We were following Hemingway’s advice:

Write drunk, edit sober.

…but not literally. Mind you, I could certainly imagine combining beer o’clock on Fridays with Content Buddiness. That wasn’t an option on this particular Friday though, as I had to run off to band practice with Salter Cane. A very different, and altogether darker form of content creation.