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.
Previous Topic
