Tags: resilience

69

sparkline

Monday, May 18th, 2020

Hard to break

I keep thinking about some feedback that Cassie received recently.

She had delivered the front-end code for a project at Clearleft, and—this being Cassie we’re talking about—the code was rock solid. The client’s Quality Assurance team came back with the verdict that it was “hard to break.”

Hard to break. I love that. That might be the best summation I’ve heard for describing resilience on the web.

If there’s a corollary to resilient web design, it would be brittle web design. In a piece completely unrelated to web development, Jamais Cascio describes brittle systems:

When something is brittle, it’s susceptible to sudden and catastrophic failure.

That sounds like an inarguably bad thing. So why would anyone end up building something in a brittle way? Jamais Cascio continues:

Things that are brittle look strong, may even be strong, until they hit a breaking point, then everything falls apart.

Ah, there’s the rub! It’s not that brittle sites don’t work. They work just fine …until they don’t.

Brittle systems are solid until they’re not. Brittleness is illusory strength. Things that are brittle are non-resilient, sometimes even anti-resilient — they can make resilience more difficult.

Kilian Valkhof makes the same point when it comes to front-end development. For many, accessibility is an unknown unknown:

When you start out it’s you, notepad and a browser against the world. You open up that notepad, and you type

<div onclick="alert('hello world');">Click me!</div>

You fire up your browser, you click your div and …it works! It just works! Awesome. You open up the devtools. No errors. Well done! Clearly you did a good job. On to the next thing.

At the surface level, there’s no discernable difference between a resilient solution and a brittle one:

For all sorts of reasons, both legitimate and, as always, weird browser legacy reasons, a clickable div will mostly work. Well enough to fool someone starting out anyway.

If everything works, how would they know it kinda doesn’t?

Killian goes on to suggest ways to try to make this kind of hidden brittleness more visible.

Furthermore we could envision a browser that is much stricter when developing.

This something I touched on when I was talking about web performance with Gerry on his podcast:

There’s a disconnect in the process we go through when we’re making something, and then how that thing is experienced when it’s actually on the web, which is dependent on network speeds and processing speeds and stuff.

I spend a lot of time wondering why so many websites are badly built. Sure, there’s a lot can be explained by misaligned priorities. And it could just be an expression of Sturgeon’s Law—90% of websites are crap because 90% of everything is crap. But I’ve also come to realise that even though resilience is the antithesis to brittleness, they both share something in common: they’re invisible.

We have a natural bias towards what’s visible. Being committed to making sure something is beautiful to behold is, in some ways, the easy path to travel. But being committed to making sure something is also hard to break? That takes real dedication.

Thursday, April 30th, 2020

‘The stakes feel higher but, with good practice, it need not be scary’ – NHS.UK design lead on responding to coronavirus | PublicTechnology.net

This isn’t the time to get precious about your favourite design and development tools. Use progressive enhancement as your philosophy. Your service might have to be accessed on old devices in hospitals with outdated tech or unsupported operating systems. HTML+CSS is your best bet to ensure that the service can be accessed in unlikely scenarios you’ve never even considered. Do you want to take that risk at a time like this? Nope, me neither.

Save the React squabbles for another time. Make it accessible and robust from day one.

Tuesday, April 28th, 2020

Web Typography News #43: Typesetting Moby-Dick, part 2

Great typography on the web should be designed in layers. The web is an imperfect medium, consumed by countless different devices over untold numbers of network connections—each with their own capabilities, limitations, and peculiarities. To think that you can create one solution that will look and work the same everywhere is a fantasy. To make this more than just one nice book website, the whole project and process needs to embrace this reality.

What is a resilient website? (with Jeremy Keith) | A Question of Code

I really enjoyed having a chat with Ed and Tom on their podcast. It’s aimed at people making a career shift into web development, but that didn’t stop me banging on about my usual hobby horses: progressive enhancement, resilient web design, and all that jazz.

Available for your huffduffing pleasure.

Monday, April 27th, 2020

Looking at coronavirus.data.gov.uk - Matthew Somerville

I worry that more and more nowadays, people jump to JavaScript frameworks because that is what they know or have been taught, even though they are entirely inappropriate for a wide array of things and can often produce poor results.

Last week I wrote about the great work that Matthew did and now he’s written up his process:

The important thing is to have a resilient base layer of HTML and CSS, and then to enhance that with JavaScript.

Tuesday, March 24th, 2020

BBC - Future Media Standards & Guidelines - Accessibility Guidelines v2.0

A timely reminder:

The minimum dependency for a web site should be an internet connection and the ability to parse HTML.

Monday, March 23rd, 2020

Get Static – Eric’s Archived Thoughts

Performance matters …especially when the chips are down:

If you are in charge of a web site that provides even slightly important information, or important services, it’s time to get static. I’m thinking here of sites for places like health departments (and pretty much all government services), hospitals and clinics, utility services, food delivery and ordering, and I’m sure there are more that haven’t occurred to me. As much as you possibly can, get it down to static HTML and CSS and maybe a tiny bit of enhancing JS, and pare away every byte you can.

Wednesday, February 26th, 2020

Software and Home Renovation | Jim Nielsen’s Weblog

Lessons for web development from a home renovation project:

  • Greenfield Projects Are Everyone’s Favorite
  • The Last Person’s Work Is Always Bewildering
  • It’s All About the Trade-Offs
  • It ALWAYS Takes Longer Than You Think
  • Communication, Communication, Communication!

And there’s this:

You know those old homes people love because they’re unique, have lasted for decades, and have all that character? In contrast, you have these modern subdivision homes that, while shiny and new, are often bland and identical (and sometimes shoddily built). node_modules is like the suburbia/subdivision of modern web development: it seems nice and fancy today, and most everyone is doing it, but in 30 years everyone will hate the idea. They’ll all need to be renovated or torn down. Meanwhile, the classical stuff that’s still standing from 100 years ago lives on but nobody seems to be building houses that way anymore for some reason. Similarly, the first website ever is still viewable in all modern web browsers. But many websites built last year on last year’s bleeding edge tech already won’t work in a browser.

Monday, February 3rd, 2020

Progressive enhancement doesn’t have to be hard - Levi McGranahan

It’s wild because in engineering terms this question, how does it fail?, should be the first one we ask, but oftentimes it is never even considered in front-end development. A good example is most client-side JS frameworks that render the entire UI in the browser, how would your app or site fail in that situation?

Tuesday, September 17th, 2019

NoJS Side-by-Side

Drag this to your browser’s bookmark bar now!

Such a useful quick check for resilience—this bookmarklet shows you a side-by-side comparison of a site with JavaScript enabled and disabled.

Thursday, July 18th, 2019

Ralph Lavelle: On resilience

Thoughts on frameworks, prompted by a re-reading of Resilient Web Design. I quite like the book being described as a “a bird’s-eye view of the whole web design circus.”

Saturday, July 6th, 2019

Chaos Design: Before the robots take our jobs, can we please get them to help us do some good work?

This is a great piece! It starts with a look back at some of the great minds of the nineteenth century: Herschel, Darwin, Babbage and Lovelace. Then it brings us, via JCR Licklider, to the present state of the web before looking ahead to what the future might bring.

So what will the life of an interface designer be like in the year 2120? or 2121 even? A nice round 300 years after Babbage first had the idea of calculations being executed by steam.

I think there are some missteps along the way (I certainly don’t think that inline styles—AKA CSS in JS—are necessarily a move forwards) but I love the idea of applying chaos engineering to web design:

Think of every characteristic of an interface you depend on to not ‘fail’ for your design to ‘work.’ Now imagine if these services were randomly ‘failing’ constantly during your design process. How might we design differently? How would our workflows and priorities change?

Tuesday, June 25th, 2019

In defence of graceful degradation and where progressive enhancement comes in by Adam Silver

This does a really good job of describing the difference between progressive enhancement and graceful degradation …but I don’t buy the conclusion: I don’t think that feature detection equates to graceful degradation. I do agree though that, when it comes to JavaScript, the result of progressive enhancement is that the language degrades gracefully.

This is progressive enhancement. An approach to making interfaces that ensures JavaScript degrades gracefully—something that HTML and CSS do automatically.

But there’s a difference between something degrading gracefully (the result) and graceful degradation (the approach).

Friday, April 26th, 2019

How I failed the <a>

I think the situation that Remy outlines here is quite common (in client-rehydrated server-rendered pages), but what’s less common is Remy’s questioning and iteration.

So I now have a simple rule of thumb: if there’s an onClick, there’s got to be an anchor around the component.

Monday, March 25th, 2019

Stuffing the Front End

53% of mobile visits leave a page that takes longer than 3 seconds to load. That means that a large number of visitors probably abandoned these sites because they were staring at a blank screen for 3 seconds, said “fuck it,” and left approximately half way before the page showed up. The fact that the next page interaction would have been quicker—assuming all the JS files even downloaded correctly in the first attempt—doesn’t amount to much if they didn’t stick around for the first page to load. What was gained by putting the business logic in the front end in this scenario?

Monday, March 18th, 2019

The Lean Web video from Boston CSS | Go Make Things

A good talk from from Chris Ferdinandi, who says:

One of the central themes of my talk on The Lean Web is that we as developers repeatedly take all of the great things the web and browsers give us out-of-the-box, break them, and then re-implement them poorly with JavaScript.

Monday, February 11th, 2019

A Simpler Web: I Concur

Tales of over-engineering, as experienced by Bridget. This resonates with me, and I think she’s right when she says that these things go in cycles. The pendulum always ends up swinging the other way eventually.

Friday, February 1st, 2019

New Adventures 2019 | Part Two: Progressive Web | Abstrakt

Here’s a thorough blow-by-blow account of the workshop I ran in Nottingham last week:

Jeremy’s workshop was a fascinating insight into resilience and how to approach a web project with ubiquity and consistency in mind from both a design and development point of view.

Thursday, January 31st, 2019

Openness and Longevity

A really terrific piece from Garrett on the nature of the web:

Markup written almost 30 years ago runs exactly the same today as it did then without a single modification. At the same time, the platform has expanded to accommodate countless enhancements. And you don’t need a degree in computer science to understand or use the vast majority of it. Moreover, a well-constructed web page today would still be accessible on any browser ever made. Much of the newer functionality wouldn’t be supported, but the content would be accessible.

I share his concerns about the maintainability overhead introduced by new tools and frameworks:

I’d argue that for every hour these new technologies have saved me, they’ve cost me another in troubleshooting or upgrading the tool due to a web of invisible dependencies.

Tuesday, January 1st, 2019

The Elements of UI Engineering - Overreacted

These are good challenges to think about. Almost all of them are user-focused, and there’s a refreshing focus away from reaching for a library:

It’s tempting to read about these problems with a particular view library or a data fetching library in mind as a solution. But I encourage you to pretend that these libraries don’t exist, and read again from that perspective. How would you approach solving these issues?