Robin Rendle

I love this post from Chris where he asks if CSS is a programming language and confronts it in a way I’ve always felt quietly but never put into words:

I have a real distaste for this question. It might seem like a fun question to dig into on the surface, but the way it enters public discourse rarely seems to be in good faith. There are ulterior motives at play involving respect, protective emotions, and desires to break or maintain the status quo.

And I am legally bound to quote this part, too:

OK fine, CSS is essentially Turing complete, but it just doesn’t feel like CSS (or HTML for that matter) is a programming language to you. It’s too declarative. Too application-specific. Whatever it is, I honestly don’t blame you. What I hope is that whatever conclusion you come to, the answer doesn’t affect things that really matter, like pay and respect.

Respect is in order, no matter what any of us come to for an answer.

When you’re building an app you often want to know two things: why are things slow and what’s on fire? Or: how miserable are my users and where is that pain felt the most? That’s why we just shipped a host of improvements that should help you answer those types of questions.

It also happens to be my first big project at Sentry: a sweeping update to alerts.

With Sentry you can set up an alert to monitor when your users see 404 pages or we can alert you when your app has too many errors. We can also alert you when performance is bad, for example when a Core Web Vital is too dang slow. There’s a host of other things we can alert you about too which is why we now show you a handy list of examples when you’re creating an alert:

Once you’ve set up an alert you can head on over to the Alerts page where you’ll see a list of the alert rules you’ve created and their status. Is everything green? Neato, you don’t have to worry about anything (yet).

But if an alert rule detects a problem then it’ll float to the top of the list and tell you precisely what’s on fire and how bad that fire is:

Okay, neat. So let’s say you have an alert that’s shouting at you about the Largest Contentful Paint on the Checkout page. Dang, I thought we fixed that! Well, not to worry. If you click on that alert you’ll now find a page that explains what’s happening in more detail and it’ll show you some hints as to what the solution might be. You can also zoom in and zoom out to see how many alerts were triggered by that rule over the past 7 days, giving a better idea of patterns instead of a specific problem:

You’ll see which transactions were slow or which issues have happened in that period of time so you can see the impact of the problem and information about how to go about fixing it.

We’re pretty dang happy with how this project turned out but your scalding, uncompromisingly brutal feedback is always very welcome. Also compliments. I love those, too.

I love it when blog post titles are indecipherable to search engines. There are exceptions, like when you want to document a technical thing and so you should have a blog post title describe that but the majority of the time I feel like blog post titles should sound like the chapters of a book: cool and not entirely obvious what they’re about.

There’s something so dang refreshing about making something for the sake of the thing, rather than for the random praise of a search engine deity.

Mercure looks bloody lovely. Not entirely sure what it is that I like about it, besides it’s obvious elegance and quietness. I adore the capital, Trojan-esque characters and the shhhh-ness of the text when in long, bookish columns.

I had never heard of the type foundry Abyme before, nor had I seen their Tumblr-like website with random images and typeset chunks that float all over the place. This reminds me that at this point in the life of the web, any website that doesn’t start with a single sentence at the top of the page feels cool to me. Like, when I have to really stare at a website to understand what it wants me to do, how it wants me to read it—that’s just so thrilling.

That cool-mystery-website feeling is extremely rare. And I was reminded this the other day when I stumbled upon Ftrain’s Ways of Reading. I was shocked that a website could restructure and retrofit multiple tables of contents to suit multiple ways of reading — but of course you can!

It’s a reminder for me that there’s not just one way to make a website. And it takes a degree of stubbornness that I admire to find something entirely new.

I’m redesigning the homepage right now (it’s so dang hard introducing yourself on the web!) and I’m bumping into tons of weird, old decisions I made whilst writing the CSS maybe four or five years ago. I try hard not to rewrite things from scratch when it comes to my personal site but the styles are starting to creak and moan under the weight of so many tiny bug fixes and what-if-I-just-change-this-one-thing moments.

It’s getting to the point where burning it all to the ground and starting again would be so much faster than just continuing to type over it all.

For example: what the heck is this .m-longform CSS class? Why did I think that wrapping every typographic element in that was a sensible thing to do? Why are all the font-sizes way, way too big? Why did I use all these link mixins for Sass and why did I add all these spacing utility classes when I don’t really need them? Why did I tie all these design components together in such a dependent way?

It’s easy to hate your old work but all of these things were attempts to fix one problem or another. And it’s important to remember that every system, given enough time, becomes bloated and unwieldy. It’s impossible to build a website without tech debt, or without problems. But now I’m thinking about longer term solutions to these issues I’m bumping into.

Would variable fonts, adaptive typography, container queries fix this? Are these problems technology based? Or is it a problem with the way that I approached my work in the past?

In short: how do I prevent future problems? And how do I avoid redesigns of the system five years from today?

A few months ago I couldn't stop looking at a photograph. It was taken at Fort Riley in Kansas around 1918 and shows an enormous, cavernous room stacked full of patients lying on beds; soldiers stricken with the Spanish Flu. Hats, masks, no phones. Doctors and nurses make their rounds.

In the center of the photograph, a man younger than me is holding a letter and, at just the right moment, he looks at the camera.

I got the first shot of the Pfizer vaccine today. Celine dropped me off at the Oakland Convention Center — an enormous, cavernous room setup for vaccinations. And as soon as I walked in I thought of that photograph. Imagine the scale of this machine, all over the country there are rooms like this.

Except, well, as a Brit there's something odd, something evil in fact, about getting a vaccination from a company (in my case, Kaiser Permanente). I'm incredibly lucky to have health insurance but standing in that room made my blood boil. You see, getting a vaccine from Kaiser is like getting a vaccine from Coca Cola or McDonald's. Why the fuck is a company giving out the vaccine?

As I’m in line, standing there teary-eyed from the downright majesty of the moment but also standing there with a clenched fist from the absolute evil of commercialized medicine, someone behind me calls out to a nurse. “Excuse me," she said “is this vaccine free?”

“Of course,” she replied. Of course.

I’m outside waiting for Celine to pick me up now and I can’t stop thinking of that photograph over and over again. I was in one of those photographs just a moment ago. That was me.

This is something I have to keep reminding myself when it comes to design: don't think like a database.

If the data or the back-end requires you to do something, it doesn't mean that's how users should think about a problem. It's a common mistake in UI design: revealing the database in a form or the navigation. But complexity on the back-end doesn't mean you should show that complexity on the front-end.

My team at Sentry just released a ton of updates which I'll write about this month and our goal with the design was to ignore that complexity entirely and focus on what the user needs to accomplish. It's hard doing that though because first you have to understand the back-end. Then you have to unlearn it.

Designers must hide the enormously complex machine that's spinning away on servers somewhere out there. And I'm still not good at it, I make a ton of mistakes all the time, but I think it's an important note to remember next time.

When it comes to design: forget the database, pretend it isn’t there.

I wrote an email to Lucy over the weekend all about, well, email and the web:

Anyway, I see HTML and CSS as a bridge—a set of languages and agreements between browsers that give us access to nigh-on everyone in the world. (And I think that’s a neat way to see publishing in general, actually. Publish a thing and suddenly you have access to more ideas and weirder friends, rather than just simply acquiring a handful of retweets and a bunch of $).

Anyway anyway, I’m typing at you now from my inbox which is then being published as a blog post via Hey World—once I hit send it’ll be catapulted out into the ether for everyone to read. Isn’t that exciting? Even our inboxes are publishing platforms now. And sure, Hey is a commercial product, but what this suggests to me is that we haven’t even come close to figuring out the web yet.