Resilient Web Design
►https://resilientwebdesign.com
temps de lecture - 1 heure
The World Wide Web has been around for long enough now that we can begin to evaluate the twists and turns of its evolution. I wrote this book to highlight some of the approaches to web design that have proven to be resilient. I didn’t do this purely out of historical interest (although I am fascinated by the already rich history of our young industry). In learning from the past, I believe we can better prepare for the future.
You won’t find any code in here to help you build better websites. But you will find ideas and approaches. Ideas are more resilient than code. I’ve tried to combine the most resilient ideas from the history of web design into an approach for building the websites of the future.
Citations
Java is to JavaScript as ham is to hamster.
C’est marrant. Mais il y a des informations sérieuses aussi.
2.0
The rise of JavaScript was boosted in 2005 with the publication of an article entitled Ajax: A New Approach to Web Applications by Jesse James Garrett. The article put a name to a technique that was gaining popularity. Using a specific subset of JavaScript, it was possible for a web browser to send and receive data from a web server without refreshing the whole page. The result was a smoother user experience.
The term Ajax was coined at the same time that another neologism was in the ascendent. Tim O’Reilly used the phrase Web 2.0 to describe a new wave of web products and services. Unlike Ajax, it was difficult to pin down a definition of Web 2.0. For business people, it meant new business models. For graphic designers, it meant rounded corners and gradients. For developers, it meant JavaScript and Ajax.
... puis ...
Stuart Langridge put together a list of all the potential points of failure under the title Everyone has JavaScript, right?
...
This doesn’t mean that web designers shouldn’t use JavaScript. But it does mean that web designers shouldn’t rely on JavaScript when a simpler solution exists.
...A platform provides a controlled runtime environment for software. As long as the user has that runtime environment, you can be confident that they will get exactly what you’ve designed. If you build an iOS app and someone has an iOS device, you know that they will get 100% of your software. But if you build an iOS app and someone has an Android device, they will get 0% of your software. You can’t install an iOS app on an Android device. It’s all or nothing.
The web isn’t as binary as that. If you build something using web technologies, and someone visits with a web browser, you can’t be sure how many of the web technologies will be supported. It probably won’t be 100%. But it’s also unlikely to be 0%. Some people will visit with iOS devices. Others will visit with Android devices. Some people will get 80% or 90% of what you’ve designed. Others will get just 20%, 30%, or 50%. The web isn’t a platform. It’s a continuum.
To paraphrase Karl Marx, progressive enhancement allows designers to ask from each browser according to its ability, and to deliver to each device according to its needs.
►http://dowebsitesneedtolookexactlythesameineverybrowser.com
Feature detection, cutting the mustard, whatever you want to call it, is a fairly straightforward technique. Let’s say you want to traverse the DOM using querySelector and attach events to some nodes in the document using addEventListener. Your mustard‐cutting logic might look something like this:
if (document.querySelector && window.addEventListener) {
// Enhance!
}
There are two points to note here:
This is feature detection, not browser detection. Instead of asking “which browser are you?” and trying to infer feature support from the answer, it is safer to simply ask “do you support this feature?”
There is no else statement.
As Brad Frost puts it:
“There is a difference between support and optimization.”
Support every browser ...but optimise for none.
“Always design a thing by considering it in its next larger context”
...
Here’s a three‐step approach I take to web design:
– Identify core functionality.
– Make that functionality available using the simplest possible technology.
– Enhance!
Building resilient websites is challenging. It takes time to apply functionality and features in a considered layered way. The payoff is a website that can better react to unexpected circumstances—unusual browsers, flaky network connections, outdated devices. Nonetheless, for many web designers, the cost in time seems to be too high.
Behaviour change is hard. Even if you are convinced of the benefits of a resilient approach to web design, you may find yourself struggling to convince your colleagues, your boss, or your clients. It was ever thus. Take comfort from the history of web standards and responsive design. Those approaches were eventually adopted by people who were initially resistant.
Demonstrating the benefits of progressive enhancement can be tricky. Because the payoff happens in unexpected circumstances, the layered approach is hard to sell. Most people will never even know whether or not a site has been built in a resilient way. It’s a hidden mark of quality that will go unnoticed by people with modern browsers on new devices with fast network connections.
For that same reason, you can start to implement this layered approach without having to convince your colleagues, your boss, or your clients. If they don’t care, then they also won’t notice. As Grace Hopper also said, “it’s easier to ask forgiveness than it is to get permission.”
Realising that it was impossible to be future‐proof, we instead resolved to be future-friendly:
Acknowledge and embrace unpredictability.
Think and behave in a future-friendly way.
Help others do the same.
That first step is the most important: acknowledging and embracing unpredictability. That is the driving force behind resilient web design. The best way to be future-friendly is to be backwards‐compatible.
The future, like the web, is unknown.
The future, like the web, will be written by you.
