There’s been a lot of talk over the years and especially recently about progressive enhancement: building things for the Web that work, that are available to all, whether that’s people in a bad cellphone area or people on dodgy hotel wifi or people with a Windows phone or cognitive issues or Safari on some retina screen in a coffee shop. And one of the lead voices in that discussion has been Aaron Gustafson who has just written a book. It’s called Adaptive Web Design: Crafting Rich Experiences with Progressive Enhancement, Second Edition. Bit of a mouthful as a title, but it’s worth it. I won’t give a tldr because it’s not too long and I did read it, but the short version is: this book is worth your time. And I was sent a free copy to review, I should note.
It surprised me to discover that it’s not actually really a technical book. Well, it is of course — it’s useless to you if you’re not building things for the Web, and it’s full of code snippets — but it’s not just about HTML or about server technologies or whatever. It’s got lots of advice on how to write copy, on design, on how to think about building the Web. It’s not, if I’m honest, a single book putting together and proposing a single idea; it’s more a collection of related relevant stuff that broadly fits under the heading. It’s “How To Do My Job, by Aaron Gustafson”, if you will.
I agree with most of it. Making your Web stuff available to everyone is not just a conversation about the technology; it does involve thinking about all of your design and your technology and your strategy and your copy. Technology is the least important bit, most of the time.
I have a few complaints, mind. Some minor nitpicking and some… well, some a bit more serious.
On the nitpicking front, the clear leader is that all the links in the book (I have the epub ebook version) are to shortened perma.cc URLs. In any book this would annoy me; in one such as this which waxes rhapsodic about the Web as a platform it’s practically criminal. I have no idea where these links go. Yes, it’s a link archiving service, but being able to see what the link actually is is also important! And, as Pat Lauke notes, sometimes the service goes down, which it did over New Year 2015. Full credit to Aaron for getting on their case, and it came back after some time, but in the interim I was entirely lost. Yes, there’s a risk — nay, a certainty — that over time the book will become less and less useful as the links therein head off to the 404 Promised Land. But perma.cc is a single point of failure; it fails, as we’ve seen; and even if it doesn’t, it’s useless without the Internet. I feel strangely reluctant to visit links with no indication whatever of what they’re for; I feel the same way about URL shortened links. At least if I had the URL I could punch it into archive.org, and maybe making sure they were all there would have been a better use of time.
There’s also a little bit of a tendency to go for the sonorous quotable soundbite even if it undermines the point: as an example, take “The purpose of design is not to make something pretty; it’s to clarify.” Nice quotable sentiment, but no it isn’t. It’s to do both. The aesthetic usability effect is a real thing. People like things more when they’re pretty, and they objectively find things easier to use when they’re pretty, all else being equal. Certainly being pretty at the expense of clarity is a bad thing (Aaron himself says rather elegantly that “beauty has its place, but a beautiful, unusable thing is not design; it’s art”) and you can doubtless name a number of products which do exactly that. But being clear and not pretty is just as bad, because then nobody uses your thing.
There are places where warnings are given but solutions are not. “Remember Jason Samuels and the 1,000 different screen sizes he was seeing every quarter? You can’t design every one of those experiences”, says our author. But the counter argument is: we’ll design the important ones (which normally means “the designer’s iPhone and the designer’s high dpi macbook”) and the rest aren’t important. Having more ammunition to counter this claim would have been nice. The next page actually gives such designers the excuse they need by saying that it’d be foolish to not do this! “That content is largely lost to history because the format evolved in a way that made newer versions of Word incapable of reading those older files.” Agreed entirely. Now, how do we stop people repeating the same mistake by buying an iPhone? There’s the aesthetic usability effect again.
But there is a larger complaint, and it’s related to the desire to make important-sounding pronouncements. Firstly, though, cards on the table: I am at least as guilty of this as Aaron is, and likely more. So know that I say it with love.
You see, there’s very little in the way of problems, things to be overcome in our industry, in building for the web, that we honestly don’t know how to solve. There’s not much where everyone’s scratching their heads and saying, well, this is just difficult, sorry. Most things are known. Some are known better than others, and some are certainly explained better than others; doing that explanation is why books such as this exist. But that ain’t the secret. The secret is that most people who work on the web aren’t Aaron. They don’t know; they don’t follow; they don’t read. And a part of that is because some of them don’t care, but most people do. No, the reason most web developers don’t leap into action to make great things is that most of what we say just doesn’t seem relevant to them. It’s all well and good saying “start by writing the kind of copy you want to read”, but what do you do when you’re writing the safety manual for an airport? Or a table of delivery instructions? And when last time you did this you put in a bit of a joke to make the copy better and nearly got fired for it? I’ve heard a bunch of people — to be clear, not Aaron — say “well, just don’t take on clients with boring work” or “quit your job and do something you enjoy instead”. Would that everyone were that lucky, Mr Rock Star Consultant Bloke. And there’s a touch of this attitude in some of this book: “We often use fake text… while we are waiting for ‘final, approved copy’ (as though such a thing exists).” You know, I know, everyone knows that there isn’t any magic anointed “final approved copy”, but that doesn’t mean that a developer can act like they know that. Superstar consultants can. People on the front lines normally can’t, even if they know it for the truth. And I think this prevailing attitude — the “if you don’t like your job, quit and get a better one” — turns off people in our industry who want to do better but don’t have the free hand that, say, I do. This is something I want to work on in myself during 2016.
But all this is beside the point. The book is worth it. Whatever you do on the web there’ll be something in this book you didn’t know and will be better off for knowing. Jeremy’s datalist trick? Well impressed. That feels like Duff’s device must have done to C people. PageRank being named for Larry rather than because it ranks pages? Blimey. So, good work, Aaron. People: read this book.