Whenever you plan or design a system, you need to build in your own ashtrays—a codified way of dealing with the inevitability of somebody doing the wrong thing. Think of what your ideal scenario is—how do you want people to use whatever you’re building—and then try to identify any aspects of it which may be overly opinionated, prescriptive, or restrictive. Then try to preempt how people might try to avoid or circumvent these rules, and work back from there until you can design a safe middle-ground into your framework that can accept these deviations in the safest, least destructive way possible.
A great example of progressive enhancement in action.
You can perfectly use CSS grid layout today if you don’t expect exactly the same appearance in every single browser, which isn’t possible to achieve nowadays anyway. I’m well aware that this decision isn’t always up to us developers, but I believe that our clients are willing to accept those differences if they understand the benefits (future-proof design, better accessibility and better performance). On top of that, I believe that our clients and users have — thanks to responsive design — already learned that websites don’t look the same in every device and browser.
In which I have a conversation with a polar bear.
Very well-mannered species …I’ll miss them when they’re gone.
Jeremy Keith Keynote: Resilience in Web Development Tickets, Fri, Jul 14, 2017 at 5:00 PM | Eventbrite
People of the Twin Cities and environs: I will be giving a talk at The Nerdery in Bloomington on Friday evening. It’s free to attend. Swing on by if you’re in the neighbourhood.
- Networking and Happy Hour: 5:00 - 6:00 p.m.
- Keynote: 6:00 - 7:00 p.m.
- Networking and Q-and-A: 7:00 - 7:30 p.m.
David picks up on one of the closing themes of Resilient Web Design—how we choose our tools. This has been on my mind a lot; it’s what I’ll be talking about at conferences this year.
That’s part of my job to ease processes and reduce frictions. That’s part of my job to take into account from the early beginning of a product its lasting qualities.
There’s a very good point here about when and how we decide to remove the things we’ve added to our projects:
We spend our time adding features without considering at the same pace the removal of useless ones. And still the true resilience (or is it perfection Antoine?) is when there is nothing more to take away. What are you removing on Monday to make our Web more resilient?
Here’s the video of the talk I gave at Smashing Conference in Barcelona last month—one of its last outings.
Riffing on an offhand comment I made about progressive enhancement being a form of “technical credit”, Chris dives deep into what exactly that means. There’s some really great thinking here.
With such a wide array of both expected and unexpected properties of the current technological revolution, building our systems in such a way to both be resilient to potential failures and benefit from unanticipated events surely is a no-brainer.
Here’s the video of the talk I gave in Berlin recently. I had a lot to squeeze into a short time slot so I just went for it, and I got bit carried away …but people seemed to like that.
This is a terrific read that gets to the heart of why progressive enhancement is such a solid methodology: progressive enhancement improves resilience.
Meeting our many users’ needs is number one on our list of design principles. We can’t know every different setup a person might use while building our systems, but we can build them in a way that gives all of our users the greatest chance of success. Progressive enhancement lets us do this.
The article is full of great insights from a very large-scale web project.
I’m just back from a little mini 3-conference tour of Europe where I was delivering my talk on resilience. The first stop was Stockholm for Nordic.js and the video is already online.
I really, really like what Ember is aiming for here:
That’s how you get the holy grail of resilience and performance:
Subsequent visits and interactions are therefore nearly instantaneous, because they don’t rely on the network.
I sincerely hope other frameworks are paying attention to this layered approach.
Oh, and I also like this observation:
There’s an age-old argument about the difference between “web pages” and “web apps”. In reality, there’s a continuum between the two.
This beautiful poster could be the ideal decoration for your home or office.
You can download the original size (DIN A3) and print it to hang it on the walls in your office or wherever you want.
Stuart’s ideas for Lighthouse sound a lot like the resilience validator tool that Scott mentioned recently.
This is our chance to help stamp out sites that don’t do things right, and help define that a progressive web app should actually be progressive.
If you have ideas on this, please file an issue.
Jessman5 on Twitter: “I made a poster from @adactio’s talk about Resilience. :) This took me way too long…”
I love this illustration that Jess made of my Resilience talk at the Render conference.
A typically superb article by Aaron. Here, he breaks down a resilient approach to building for the web by examining the multiple ways you could add a button to a page. There’s a larger lesson here too:
We don’t control where our web-based products go or how our users access them. All we can do is imagine as many less-than-perfect scenarios as possible and do our best to ensure our creations will continue to do what they’re supposed to do. One of the easiest ways to do that is to be aware of and limit our dependencies.
Here’s the video of the talk I just gave at the Beyond Tellerrand conference in Düsseldorf: Resilience.
Eric asked me some questions and I was only too happy to give some answers.
I think that “Do we want to support users without JS?” is the wrong question. Progressive enhancement has benefits that reach far beyond that user group.
- Resilience—”If users can perform critical tasks when your JS breaks, it’s a minor inconvenience instead of a show stopper.”
- Business, Business, Business.
Apple offers its users the power to turn off much of the Web: fonts, styles, scripts, and more.
He rightly points out that the answer to building a robust, resilient web has been here all along: