What’s happening right now at the US border is heartbreaking and inexcusable. We’re donating 25% of all profits today and tomorrow (June 19 & 20) to RAICES, to help reunite detained immigrant parents and children.
The focus of the A Book Apart series is what makes it great …and that means having to reject some proposals that don’t fit. Even though I’ve had the honour of being a twice-published A Book Apart author, I also have the honour of receiving a rejection, which Jeffrey mentions here:
In one case we even had to say no to a beautifully written, fully finished book.
That was Resilient Web Design.
So why did we turn down books we knew would sell? Because, again—they weren’t quite right for us.
It was the right decision. And this is the right advice:
If you’ve sent us a proposal that ultimately wasn’t for us, don’t be afraid to try again if you write something new—and most importantly, believe in yourself and keep writing.
I know that Jeffrey and I sound like old men yelling at kids to get off the lawn when we bemoan the fetishisation of complex tools and build processes, but Jeffrey gets to the heart of it here: it’s about appropriateness.
As a designer who used to love creating web experiences in code, I am baffled and numbed by the growing preference for complexity over simplicity. Complexity is good for convincing people they could not possibly do your job. Simplicity is good for everything else.
And not to sound like a broken record, but once again I’m reminded of the rule of least power.
It turns out that Diana Smith isn’t just a genius with CSS—she’s a fantastic writer too. This post is somehow heartfelt and lighthearted at the same time. It’s also very humorous, but beneath the humour there’s an excellent point here about the rule of least power …and doing things the long, hard, stupid way.
Because something about those limitations just calls to me. I know I’m not alone when I say that a rigid set of restrictions is the best catalyst for creativity. Total artistic freedom can be a paralyzing concept.
That can sometimes be the case with programming. If you have the most powerful programming languages in the world at your disposal, it starts to seem natural that you should then have no difficulty solving any programming problem. With all these amazing tools offering countless solutions to solve the same problem, it’s no wonder that we sometimes freeze up with information overload.
This looks very useful: a script that will allow visitors to tailor which tracking scripts they want to allow. Seems like a win-win to me: useful for developers, and useful for end users. A safe and sensible approach to GDPR.
The focus here is on performance, but these tools are equally useful for shining a light on just how bad the situation is with online surveillance and tracking.
The Slow Death of Internet Explorer and the Future of Progressive Enhancement · An A List Apart Article
These are beautiful!
Featured below is a chronology of various attempts through the last four centuries to visually organise and make sense of colour.
My publishers asked me some questions. My answers turned out to be more revealing of my inner demons than I was expecting. I hope this isn’t too much oversharing, but I found it quite cathartic.
My greatest fear for the web is that it becomes the domain of an elite priesthood of developers. I firmly believe that, as Tim Berners-Lee put it, “this is for everyone.” And I don’t just mean it’s for everyone to use—I believe it’s for everyone to make as well. That’s why I get very worried by anything that raises the barrier to entry to web design and web development.
It really, really bothers me that wireframes have evolved from being a prioritisation tool into a layout tool (disempowering UI designers in the process), so I’m happy to see an alternative like this—somewhat like Dan Brown’s Page Description Diagrams.
Here’s a great even-handed in-depth review of Going Offline:
Aaron gives a timely run-down of all the parts of a web experience that are out of our control. But don’t despair…
Recognizing all of the ways our carefully-crafted experiences can be rendered unusable can be more than a little disheartening. No one likes to spend their time thinking about failure. So don’t. Don’t focus on all of the bad things you can’t control. Focus on what you can control.
Start simply. Code defensively. User-test the heck out of it. Recognize the chaos. Embrace it. And build resilient web experiences that will work no matter what the internet throws at them.
A short’n’sweet review of Going Offline:
Jeremy nails it again with this beginner-friendly introduction to Service Workers and Progressive Web Apps. The foreword to the book says “you’ll gain a solid understanding of how to put this new technology to work for you right away” and I’d say that is very accurate.
Jeremy’s technical writing is as superb as always. Similar to his first book for A Book Apart, which cleared up all my confusions about HTML5, Going Offline helps me put the pieces of the service workers’ puzzle together.
Sara describes the process of turning her site into a progressive web app, and has some very kind words to say about my new book:
Jeremy covers literally everything you need to know to write and install your first Service Worker, tweak it to your site’s needs, and then write the Web App Manifest file to complete the offline experience, all in a ridiculously easy to follow style. It doesn’t matter if you’re a designer, a junior developer or an experienced engineer — this book is perfect for anyone who wants to learn about Service Workers and take their Web application to a whole new level.
Too, too kind!
I highly recommend it. I read the book over the course of two days, but it can easily be read in half a day. And as someone who rarely ever reads a book cover to cover (I tend to quit halfway through most books), this says a lot about how good it is.
An interesting piece by Jessica Kerr that draws lessons from the histories of art and science and applies them to software development.
This was an interesting point about the cognitive load of getting your head around an existing system compared to creating your own:
And just because I’ve spent most of last year thinking about how to effectively communicate—in book form—relatively complex ideas clearly and simply, this part really stood out for me:
When you do have a decent mental model of a system, sharing that with others is hard. You don’t know how much you know.