In Praise of Resilient Web Design by Jeremy Keith
I thoroughly enjoyed reading Resilient Web Design by Jeremy Keith.
It made me fall back in love with the web and with making things for the web.
It took me back to my first proper job, in 1998, when CSS was still considered a highly questionable technology choice. I remember thinking, as I struggled to make our website HTML standards compliant and fended off colleagues questioning the decision to use CSS, one day you'll probably be able to justify this kind of tinkering about as an actual career.
It also made me remember the first proper website I took over, looking through all the tangled table layout code - see https://resilientwebdesign.com/chapter2/ for a resume of the crazy stuff done to get a layout to work. At that point I didn't really know what all the and tags meant and I remember looking them up to find out.. Jeremy's book also helped me to remember CSS Zen Garden, which was such an inspiration even to a "non-designer" like myself - see http://www.csszengarden.com/
But while Resilient Web Design is in part a lovely nostalgic journey for an old codger like myself, what I'm most interested in are the forward facing aspects of the book. Part of the point of the book is that there really is no grounds for nostalgia about the web in 1998 or 2002 anyway - there was so much horrible hackery required then to do basic things, or to do pretty much anything in Netscape 4. We are in a better place now, or more precisely we are potentially in a better place - HTML5 and the latest CSS developments, including flexbox and the grid model, should finally make the long heralded separation of content and presentation a reality.
The only aspect of long gone times that I miss is the sense that - even with the caveats above about hackery requirements - you could make a web page more easily. I completely agree with the sentiments expressed in Martin Wright's blog post Complexity is Kill the Web - see http://mynameismartin.com/complexity-killing-web/. I too worry that it's become impossible to teach someone how to create a simple page, which could be simply and cheaply hosted.
It's a bit like the state popular music had got itself in by the mid 1970s, where people felt that you couldn't make an album without elaborate guitar solos or long and expensive periods of time spent in studios. We seem to have strayed from our original focus on the creation of content to be shared.
The solution proposed in Resilient Web Design to this over-whelming complexity is progressive enhancement. Progressive enhancement is a concept that has been around for years, but one that has been expressed far less vocally in recent years. I must admit that I've strayed from this righteous path too. But Resilient Web Design has got me back on the path.
I love the idea of starting a piece of work by identifying the irreducible core of what you are trying to achieve, finding the simplest way of delivering that core, and then - if and as required -enhancing it. Progressive enhancement doesn't have to be puritanical or backwards facing. Sometimes a complex framework or tool might be entirely appropriate. The point is that is that you have applied awareness to the process of creation: you haven't just fired up a development tool that makes a series of design decisions on your behalf that you then can't easily undo.
I think there's a nice parallel between the wish in agile methodologies to get work in front of clients as quickly as possible - at work, we talk about Brutal Delivery, getting work pared down to its bare essentials so a client can see it - and the aim in progressive enhancement of working on the core of the project first, and as simply as possible. It also helps to emphasise what is most important in a piece of work - which often actually is the simple intention to share some information.
Part of what is regained from this more aware approach to design is the feeling of being back in control. When I use AngularJS for front end work, it solves a number of short-term problems for me - for example, how do I keep a number of screen elements updated in response to changes in my application. What I lose is a clear sense of how my application actually works. I find myself trying to understand Angular's digest loop to understand unexpected behaviour (see https://www.ng-book.com/p/The-Digest-Loop-and-apply/) If I don't fully understand how Angular works under the hood, I'm building up a technical debt and future uncertainties - what happens if the application stops working - do I know enough about Angular to resolve the issue? I'm also taking on dependencies in terms of managing Angular updates. What happens when I want to make further changes. It's a bit like a modern car, where the number of people who fully understand the mechanics and have access to the diagnostic kit required is ever-decreasing.
In the spirit of Resilient Web Design, I've spent some of the Christmas period simplifying my personal site. I've stripped back the CSS, taken out Bootstrap, removed modernizer, said goodnight and thankyou to jQuery. I've made the HTML properly semantic. I've taken out the blogging package I was using and written my own, incredibly simple, alternative. All of the frameworks I've removed absolutely have their value and I am in no way dismissing them - but I didn't actually really need any of them for a simple website.
Now the site still feels far more complex than it strictly needs to be - it's running on a full CMS (Umbraco), when I could use one of the lightweight CMSes like Perch. It's running on an Azure website with no separate SQL database (it's running on SQL Compact Edition which is adequate for a low volume site). It's a very simple piece of work, visually underwhelming, but I feel in total control of it, and it's been a pleasure to work on. And the performance of the site, with all the excess fat burned off, has been transformed.
So here's to a progressively enhancing 2017..
The Intentional Technology Newsletter...
... will help you use technology with focus and enjoyment.