Tags: ala

I can’t resist bookshelves.

If I’m shown into someone’s home and left alone while the host goes and does something, you can bet I’m going to peruse their bookshelves.

I don’t know why. Maybe I’m looking for points of commonality. “Oh, you read this book too?” Or maybe it’s the opposite, and I’m looking for something new and—pardon the pun—novel. “Oh, that book sounds interesting!”

I like it when people have a kind of bookshelf on their website.

• Mandy’s reading list is always worth browsing.
• Remy has a comprehensive record of his reading history.
• Maggie has her library and her anti-library.
• Molly White has one shelf for fiction and another shelf for non-fiction.

Here’s my ad-hoc bookshelf, which is manually mirrored on Bookshop.org.

I like having an overview of what I’ve been reading. One of the reasons I started keeping track was so that I could try to have a nice balance of fiction and non-fiction.

I always get a little sad when I see someone’s online reading list and it only consists of non-fiction books that are deemed somehow useful, rather than simply pleasurable. Cameron wrote about when he used to do this:

I felt like reading needed to have some clear purpose. The topic of any book I read needed to directly contribute to being an “adult”. So I started to read non-fiction – stuff that reflected what was happening in my career. Books on management, books on finance, books on economics, books on the creative process. And for many years this diet of dry, literary roughage felt wholesome … but joyless. Each passage I highlited in yellow marker was a point for the scoreboard, not a memory to be treasured.

Now he’s redressing the imbalance and rediscovering the unique joy of entering other worlds by reading fiction.

For a while, I forced myself to have perfect balance. I didn’t allow myself to read two non-fiction books in a row or two fiction books in a row. I made myself alternate between the two.

I’ve let that lapse now. I’m reading more fiction than non-fiction, and I’m okay with that.

But I still like looking back on what I’ve been reading and seeing patterns emerge. Like there’s a clear boom in the last year of reading retellings of the Homeric epics (all kicked off by reading the brilliant Circe by Madeline Miller).

I also keep an eye out for a different kind of imbalance. I want to make sure that I’m not just reading books by people like me—middle-aged heterosexual white dudes.

You may think that a balanced reading diet would emerge naturally, but I’m not so sure. Here’s an online bookshelf. Here’s another online bookshelf. Plenty of good stuff in both. But do either of those men realise that they’ve gone more than a year without reading a book written by a woman?

It’s almost certainly not a conscious decision. It’s just that in the society we live in, the default mode tends towards what’s been historically privileged (see also films, music, and painting).

It’s like driving in a car that subtly pulls to one side. Unless you compensate for it, you’ll end up in the ditch without even realising.

I feel bad for calling attention to those two reading lists. It feels very judgy of me. And reading is something that doesn’t deserve judgement. Any reading is good reading.

Mind you, maybe being judgemental is exactly why I’m drawn to people’s bookshelves in the first place. It might be that I’m subsconsciously looking for compatibility signals. If I see a bookshelf filled with books I like, I’m bound to feel predisposed to like that person. And if I see a bookshelf dominated by Jordan Peterson and Ayn Rand, I’m probably going to pass judgement on the reader, even if I know I shouldn’t.

I’ve always associated good design with thoughtfulness. Like, I should be able to point to any element in an interface and the designer should be able to tell me the reasons it’s there. Those reasons may be rooted in user needs or asthetics or some other consideration, but the point is that there’s a justification for it. Justify every pixel!

But I’ve come to realise that this is a bit reductionist. Now when I point at an interface element, I still expect the designer to be able to justify its inclusion, but I’d also like to know the trade-offs that were made.

Suppose there’s a large hero image. I’m sure the designer would have no problem justifying its inclusion on the basis of impact and the emotional heft it delivers. But did they also understand the potential downsides? Were they aware of the performance implications of including a large image?

I hope the answer to both questions is yes. They understood the costs, but they decided that, on balance, the positives outweighed the negatives.

When it comes to the positives, universal principles of design often apply. Colour theory, typography, proximity, and so on. But the downsides tend to be specific to the medium that the design is delivered in.

Let’s say you’re designing for print. You want to include an extra typeface just for footnotes. No problem. There isn’t really a downside. In print, you can use all the typefaces you want. But if this were for the web, then the calculation would be different. Every extra typeface comes with a performance penalty. A decision that might be justified in one medium might not work in another medium.

It works both ways; on the web you can use all the colours you want, without incurring any penalties, but in print—depending on the process you’re using—you might have to weigh up that decision very differently.

From this perspective, every design decision is like a balance sheet. A good web designer understands the benefits and the costs behind each decision they make.

It’s a similar story when it comes to web development. Heck, we even have the term “tech debt” to describe decisions that we know aren’t for the best in the long term.

In fact, I’d say that consideration of the long-term effects is something that should play a bigger part in technical decisions.

When we’re weighing up the pros and cons of using a particular tool, we have a tendency to think in the here and now. How might this help me right now? How might this hinder me right now?

But often a decision that delivers short-term gain may well end up delivering long-term pain.

Alexander Petros describes this succinctly:

Reopen a node repository after 3 months and you’ll find that your project is mired in a flurry of security warnings, backwards-incompatible library “upgrades,” and a frontend framework whose cultural peak was the exact moment you started the project and is now widely considered tech debt.

When I wrote about making the Patterns Day website I described my process as doing it “the long hard stupid way”—a term that Frank coined in a talk he gave a few years back. But perhaps my hands-on approach is only long, hard and stupid in the short time. With each passing year, the codebase will retain a degree of readability and accessibility that I would’ve sacrificed had I depended on automated build processes.

Robin Berjon puts this into the historical perspective of Taylorism and Luddism:

Whenever something is automated, you lose some control over it. Sometimes that loss of control improves your life because exerting control is work, and sometimes it worsens your life because it reduces your autonomy.

Or as Marshall McLuhan put it:

Every extension is also an amputation.

…which is fine as long as the benefits of the extension outweigh the costs of the amputation. My worry is that, when it comes to evaluating technology for building on the web, we aren’t considering the longer-term costs.

Maintenance matters. With the passing of time, maintenance matters more and more.

Maybe we avoid thinking about the long-term costs because it would lead to decision paralysis. That’s understandable. But I take comfort from some words of wisdom on the web from the 1990s. Tim Berners-Lee’s style guide for hypertext:

Because hypertext is potentially unconstrained you are a little daunted. Do not be. You can write a document as simply as you like. In many ways, the simpler the better.

Efficiency trades off against resiliency - Made of Bugs

Past some point, making a system more efficient will mean making it less resilient, and, conversely, building in robustness tends to make a system less efficient (at least in the short run).

This is true of software, networks, and organisations.

When we set metrics or goals for a system or a team or an organization that ask for efficiency, let us be aware that, absent countervailing pressures, we are probably also asking for the system to become more brittle and fragile, too.

CSS Text balancing with text-wrap:balance - Ahmad Shadeed

Ahmad runs through some of the scenarios where text-wrap: balance could be handy.

Even though it’s not well-supported yet in browsers, there’s no reason not to start adding it to sites now; it’s classic progressive enhancement.

An end to typographic widows on the web | Clagnut by Richard Rutter

Rich explains what text-wrap:balance does …and what it doesn’t.

Building the new Utopia homepage | Trys Mudford

Trys has written up how he made that nifty little resizing widget on the Utopia homepage.

Cultivating a sense of the galactic centre (Interconnected)

I love the idea of cultivating a sixth sense for the location of Sagittarius A.

(I bet Matt would get a kick out of Charlotte’s magnet fingers too.)

Now THAT’S What I Call Service Worker! – A List Apart

This is terrific! Jeremy shows how you can implement a fairly straightforward service worker for performance gains, but then really kicks it up a notch with a recipe for turning a regular website into a speedy single page app without framework bloat.

Responsive web design turns ten. — Ethan Marcotte

2010 was quite a year:

And exactly three weeks after Jeremy Keith’s HTML5 For Web Designers was first published, “Responsive Web Design” went live in A List Apart.

Nothing’s been quite the same since.

I remember being at that An Event Apart in Seattle where Ethan first unveiled the phrase and marvelling at how well everything just clicked into place, perfectly capturing the zeitgeist. I was in. 100%.

It was 20 years ago today… - Web Directions

John’s article, A Dao Of Web Design, is twenty years old. If anything, it’s more relevant today than when it was written.

Here, John looks back on those twenty years, and forward to the next twenty…

Standards for Writing Accessibly – A List Apart

• Write Chronologically, Not Spatially
• Write Left to Right, Top to Bottom
• Don’t Use Colors and Icons Alone
• Describe the Action, Not the Behavior

The Size of Space

Celestial objects ordered by size, covering a scale from one astronaut to the observable universe.

Request with Intent: Caching Strategies in the Age of PWAs – A List Apart

Aaron outlines some sensible strategies for serving up images, including using the Cache API from your service worker script.

Responsible JavaScript: Part III – A List Apart

This chimes nicely with my recent post on third-party scripts. Here, Jeremy treats third-party JavaScript at technical debt and outlines some solutions to staying on top of it.

Convenience always has a price, and the web is wracked by our collective preference for it. JavaScript, in particular, is employed in a way that suggests a rapidly increasing tendency to outsource whatever it is that We (the first party) don’t want to do. At times, this is a necessary decision; it makes perfect financial and operational sense in many situations.

But make no mistake, third-party JavaScript is never cheap. It’s a devil’s bargain where vendors seduce you with solutions to your problem, yet conveniently fail to remind you that you have little to no control over the side effects that solution introduces.

At Dynamicland, The Building Is The Computer — Carl Tashian

A look at the ubiquitous computing work that Bret Victor has been doing over the past few years at Dynamicland.

A bit of a tangent, but I love this description of reading maps:

Map reading is a complex and uniquely human skill, not at all obvious to a young child. You float out of your body and into the sky, leaving behind the point of view you’ve been accustomed to all your life. Your imagination turns squiggly blue lines and green shading into creeks, mountains, and forests seen from above. Bringing it all together in your mind’s eye, you can picture the surroundings.

The Management Strategy That Saved Apollo 11

The story of Jack Garman and the 1202 alarm—as covered in episode two of the 13 Minutes To The Moon podcast.

Next time you’re faced with a decision, ask yourself: how can this decision be made on the lowest level? Have you given your team the authority to decide? If you haven’t, why not? If they’re not able to make good decisions, you’ve missed an opportunity to be a leader. Empower, enable, and entrust them. Take it from NASA: the ability to delegate quickly and decisively was the key to landing men on the moon.

Nothing Fails Like Success – A List Apart

On an individual and small collective basis, the IndieWeb already works. But does an IndieWeb approach scale to the general public? If it doesn’t scale yet, can we, who envision and design and build, create a new generation of tools that will help give birth to a flourishing, independent web? One that is as accessible to ordinary internet users as Twitter and Facebook and Instagram?

Accessibility for Vestibular Disorders: How My Temporary Disability Changed My Perspective · An A List Apart Article

This is a fascinating insight into what it’s like to use the web if you’ve got vertigo (which is way more common than you might think):

Really, there are no words to describe just how bad a simple parallax effect, scrolljacking, or even background-attachment: fixed would make me feel. I would rather jump on one of those 20-G centrifuges astronauts use than look at a website with parallax scrolling.

Every time I encountered it, I would put the bucket beside me to good use and be forced to lie in bed for hours as I felt the room spinning around me, and no meds could get me out of it. It was THAT bad.

Responsible JavaScript: Part I · An A List Apart Article

As I pick apart yet another bundle not unlike a tangled ball of Christmas tree lights, it’s become clear that the web is drunk on JavaScript. We reach for it for almost everything, even when the occasion doesn’t call for it. Sometimes I wonder how vicious the hangover will be.

I love everything about this article and I can’t wait for part two.

What we tend to forget is that the environment websites and web apps occupy is one and the same. Both are subject to the same environmental pressures that the large gradient of networks and devices impose. Those constraints don’t suddenly vanish when we decide to call what we build “apps”, nor do our users’ phones gain magical new powers when we do so.

Needless to say, I endorse this message:

Whether you think of your site as an “app” or not, adding a service worker to it is perhaps one of the most responsible uses of JavaScript that exists today.