the important work is making the decision and moving on to the next stage. If the actual outputs at each stage are mediocre, that seems to be okay, as long as they’re just good enough to inform a go/no-go decision.

I like it — “good enough” for the next stage of iterative decision making. That’s an evolutionary process (akin to what Ken Koecienda describe in his book “Creative Selection”). That vibes with me for building software.

Jeremy Keith points out something I’d never thought of: the mobile web’s UX is so terrible because its security is so good!

Ironically, it’s the strength of the web—and web browsers—that has led to such shitty mobile web experiences. The pretty decent security model on the web means that sites have to pester you.

Part of the reason why you don’t see the same egregious over-use of pop-ups and overlays in native apps is that they aren’t needed. If you’ve installed the app, you’re already being tracked.

After all these years, what’ve we done with the technical promise of responsive design?

Sure, we use media queries and other responsive techniques, but all we’ve really done is make sure that a terrible experience fits on the screen.

Jeremy brings the fire in this one:

we’ve spent the last fifteen years teaching users that if they want a good experience on their mobile device, they should look in an app store, not on the web.

Blogging is the greatest procrastination tool there is. You’re skiving off doing the thing you should be doing, but then when you’ve published the blog post, you’ve actually done something constructive so you don’t feel too bad about avoiding that thing you were supposed to be doing.

I feel seen.

I quite like having redesigns that are cumulative instead of destructive.

I love and deeply respect the idea and discipline to do “redesigns” that are accretive. But I can’t do them. My approach to redesigns is burn it all down and start afresh, like a forest fire.

And forest fires are healthy — just maybe not every 3 to 6 months lol.

The book is free to read. Properly free. Not the kind of “free” where you have to supply an email address first. Why would I make you go to the trouble of generating a burner email account?

You can use any attributes you want on a web component…I’m a little nervous about this. What if HTML ends up with a new global attribute in the future that clashes with something I’ve invented? It’s unlikely but it still makes me wary.

So I use data- attributes…[and] the browser gives me automatic reflection of the value in the dataset property.

Wait, what? Why am I not doing this?

Instead of getting a value with this.getAttribute('maximum') I get to use this.dataset.maximum. Nice and neat.

Smart.

When asked:

why [do] you advocate the use of multi-page web apps and not single-page ones?

Jeremy has a great response, including this bit about going with the grain of the web:

I find the framing of your question a little concerning. It should be inverted. The default approach should be to assume a multi-page approach (which is the way the web works by default). Deciding to take a JavaScript-driven single-page approach should be the exception…

When it comes to front-end development, I’m worried that we’ve reached a state where the more complex over-engineered approach is viewed as the default.

Jeremy, talking about his relationship to all the social networks coming and going these days, drops this indie web burn:

[Social networks are] all just syndication endpoints to me.

No one has ever complained that a website is too fast.

Reminds me of Bezos’ quote about how customers will never say, “I wish you’d deliver packages a little slower”.

the term [AI] is so vague as to be meaningless. Sometimes—though rarely—AI refers to general artificial intelligence. Sometimes AI refers to machine learning. Sometimes AI refers to large language models. Sometimes AI refers to a series of if/else statements. That’s quite a spectrum of meaning.

If you’re well versed in HTML, CSS, and vanilla JavaScript, but you’re not up to speed on pipelines and frameworks, you’re going to have a hard time.

That doesn’t seem right. We should change it.

This seems right. I feel like there’s a metaphor here I’m reaching for but can’t quite articulate…

Surely other professions feel this pain where the growing complexity of the field pinches out a certain kind of practitioner and the field becomes more poor without those folks?

I had video call this morning with someone who was in India. The call went great, except for a few moments when the video stalled.

“Sorry about that”, said the person I was talking to. “It’s the monkeys. They like messing with the cable.”

At first I thought this was some reference to chaos engineering and the chaos monkey, but nope. Turns out this was real monkeys.

There’s something charming about an intercontinental internet-enabled meeting being slightly disrupted by some fellow primates being unruly.

But as Eric once said, every line of you CSS you write is a suggestion to the browser. That’s not how we think about CSS though. We think of CSS like a series of instructions rather than suggestions. Never mind respecting the user’s preferences; one of the first things we do is reset all the user agent’s styles.

“User agent stylesheets” are a fascinating thing to me. It does seem like, as an industry, we don’t think about them as the default styles for the user. Rather, we see them as the absolute bare minimum which we feel obliged to completely disregard and overwrite without any forethought.

The technologies are the easy bit. Getting people to re-evaluate their opinions about technologies? That’s the hard part.

As is so often the case with CSS, I think new features like [logical properties] are easier to pick up if you’re new to the language. I had to unlearn using floats for layout and instead learn flexbox and grid. Someone learning layout from scatch can go straight to flexbox and grid without having to ditch the cognitive baggage of floats. Similarly, it’s going to take time for me to shed the baggage of directional properties and truly grok logical properties, but someone new to CSS can go straight to logical properties without passing through the directional stage.

I found this a perceptive articulation of a feeling I know I’ve had many times: unlearning to make room for the new is hard. For example, you get really good working with a claw hammer. Then somebody says “hey, we have a sledge hammer now!” All your tips and tricks for doing a sledge hammer’s job with a claw hammer are now obsolete. You’re now on a level playing field with folks who just started and have both the claw and the sledge hammer in their tool belt. Meanwhile, you’re over here trying to learn when to use the new sledge but also when to keep using your claw.

Now just think about how often web technologies change in contrast to hammer technology and you can see how overwhelming that can feel at times.

metrics are very useful for measuring design’s benefit to the business, they’re not really cut out for measuring user experience.

what’s good for user experience is good for business. But it’s a short step from making that equivalency to flipping the equation: what’s good for the business must, by definition, be good user experience. That’s where things get dicey.

there’s a danger to focusing purely on user experience. That focus can be used as a way of avoiding responsibility for the larger business goals.

There’s qualitative research (stories, emotion, and context) and then there’s quantitative research (volume and data). But there’s also evualative research (testing a hyphothesis) and generative research (exploring a problem space before creating a solution). By my count that gives four possible combos: qualitative evaluative research, quantitative evaluative research, qualitative generative research, and quantitative generative research. Phew!

Applicable to design, since—as Maite Otondo says—research uncovers the reality of today so you can design for the future of tomorrow.

It’s one thing for a department to over-ride UX concerns, but I bet they’d think twice about jeopardising the site’s ranking with Google.

This resonates in my bones.

Jeremy’s comments on Open Prioritization, which is an experiment in crowd-funding prioritization of new features in browsers.

when numbers are used as the justification, you’re playing the numbers game from then on.

He is speaking about monetary justification in arguments, but I saw a corollary in data-driven decisions. Once you make a product decision based purely on data, it becomes hard to ever deviate from or change that decision. “But the data said we should...” is the argument. Or “what does the data say?” becomes the leading question on decision making. Data is a cruel master.

He continues:

You’ll probably have to field questions like “Well, how many screen reader users are visiting our site anyway?” (To which the correct answer is “I don’t know and I don’t care”

Sometimes I wish more product decisions were made on principles and values like this more than the crutch of data.

If you tie the justification ... to data, then what happens should the data change? ... If your justification isn’t tied to numbers, then it hardly matters what the numbers say (though it does admitedly feel good to have your stance backed up)...The fundamental purpose of [your product] needs to be shared, not swapped out based on who’s doing the talking.

Jeremy writing on how so many of our problems are problems of human communication and understanding, not technical problems.

We like to talk about how hard and complex our technical work is, but frankly, it’s a lot easier to get a computer to do what you want than to convince a human.

He continues:

let’s say it is someone in the marketing department who is pushing to have an obtrusive newsletter sign-up form get shoved in the user’s face. Talk to them. Figure out what their goals are—what outcome are they hoping to get to. If they don’t seem to understand the user-experience implications, talk to them about that. But it needs to be a two-way conversation. You need to understand what they need before you start telling them what you want.

I realise that makes it sound patronisingly simple, and I know that in actuality it’s a sisyphean task. It may be that genuine understanding between people is the wickedest of design problems. But even if this problem seems insurmoutable, at least you’d be tackling the right problem.

Sage advice.

An interesting post as always from Jeremy, but this line:

I know that it would make my life as a developer harder. But that’s of lesser importance. It would be better for the web.

Jeremy discusses some of his strategy around presenting code when your audience is more than just developers (or even code beginners):

logic is more important than code. In other words, figuring out what you’re trying to accomplish (and describing it clearly) is more important than typing curly braces and semi-colons. Programming is an act of translation. Before you can translate something, you need to be able to articulate it clearly in your own language first.

I think this is an excellent strategy for making code less overwhelming to people who would otherwise be unfamiliar with it.

Was just doing something similar and feel the same way. When building a prototype, you throw so many best practices to the wind:

Whereas I would think long and hard about the performance impacts of third-party libraries and frameworks on a public project, I won’t give it a second thought when it comes to a prototype. Throw all the JavaScript frameworks and CSS libraries you want at it (although I would argue that in-browser technologies like CSS Grid have made CSS libraries like Bootstrap less necessary, even for prototyping).

Remember, however, that prototypes quite often gain their utility through their ability to be like a piece of paper: you sketch out your ideas quickly with low friction, you learn what you don’t want, then you throw it away.

Build prototypes to test ideas, designs, interactions, and interfaces…and then throw the code away. The value of a prototype is in answering questions and testing hypotheses. Don’t fall for the sunk cost fallacy when it’s time to switch over into production mode.

An thoughtful writeup behind how Jeremy prepares for his conference talks. I like this part about how even a plain text file, which seems open-ended, still enforces a certain kind of linear constraint, whereas a blank sheet of paper and a pencil is truly more open-ended:

I used to do this mind-mapping step by opening a text file and dumping my thoughts into it. I told myself that they were in no particular order, but because a text file reads left to right and top to bottom, they are in an order, whether I intended it or not. By using a big sheet of paper, I can genuinely get things down in a disconnected way (and later, I can literally start drawing connections).

One outcome was to realise that there’s a tendency (in performance, accessibility, or SEO) to focus on what’s easily measureable, not because it’s necessarily what matters, but precisely because it is easy to measure.

Too true.

I think incremental and iterative improvements can be served well by measurements. But vast, innovative improvements and directional changes in product need more than analytics. They need vision and taste from humans.

Here’s a thought? Things that are measurable are like the micro of products, whereas vision and taste are the macro.

Jeremy quoting from and commenting on the new book Flexible Typesetting from A List Apart.

It appears the book nods to the materiality of creating things for the web. Specifically, typography on the web should honor and respect the nature of its medium, which tends towards design being a suggestion, not a mandate. Here’s a quote from the book:

Of course typography is valuable. Typography may now be optional [on the web], but that doesn’t mean it’s worthless. Typographic choices contribute to a text’s meaning. But on the web, text itself (including its structural markup) matters most, and presentational instructions like typography take a back seat. Text loads first; typography comes later. Readers are free to ignore typographic suggestions, and often prefer to. Services like Instapaper, Pocket, and Safari’s Reader View are popular partly because readers like their text the way they like it

As the author states, “Readers [on the web] are typographers, too.”

Data only answers what, not why:

At Booking.com, they do a lot of A/B testing.
At Booking.com, they’ve got a lot of dark patterns.
I think there might be a connection.
A/B testing is a great way of finding out what happens when you introduce a change. But it can’t tell you why.

More:

The problem is that, in a data-driven environment, decisions ultimately come down to whether something works or not. But just because something works, doesn’t mean it’s a good thing.

If I were trying to convince you to buy a product, or use a service, one way I could accomplish that would be to literally put a gun to your head. It would work. Except it’s not exactly a good solution, is it? But if we were to judge by the numbers (100% of people threatened with a gun did what we wanted), it would appear to be the right solution.

Love the picture he paints with the “gun-to-head” example. Though often mistakenly interpreted otherwise, data is only one piece of a multi-faceted story.

Jeremy responding to the commonly-held assertion that the web is a primitive technology because it was just designed for sharing documents.

If the web had truly been designed only for documents, [rich interactive applications] wouldn’t be possible.

Always interesting insights from Jeremy:

I’ve written about seams before. I really feel there’s value—and empowerment—in exposing the points of connection in a system. When designers attempt to airbrush those seams away, I worry that they are moving from “Don’t make me think” to “Don’t allow me to think”.

In many ways, aiming for seamlessness in design feels like the easy way out. It’s a surface-level approach that literally glosses over any deeper problems. I think it might be driven my an underlying assumption that seams are, by definition, ugly. Certainly there are plenty of daily experiences where the seams are noticeable and frustrating. But I don’t think it needs to be this way. The real design challenge is to make those seams beautiful.

As always, insightful progressive enhancement thoughts around service workers vs. web components:

The next question we usually ask when we’re evaluating a technology is “how well does it work?” Personally, I think it’s just as important to ask “how well does it fail?”

Service workers work well and fail well. If a browser supports service workers, the user gets all the benefits. If a browser doesn’t support service workers, the user get the same experience they would have always had. Web components (will) work well, but fail badly. If a browser supports web components, the user gets the experience that the developer has crafted using these new technologies. If a browser doesn’t support web components, the user gets…probably nothing. It depends on how the web components have been designed.

It’s so much easier to get excited about implementing service workers. You’ve literally got nothing to lose and everything to gain.

A great little piece of writing touching on the art of human relationships. It’s based on an experience Jeremy Keith had trying to persuade others about the importance accessibility:

If I really want to change someone’s mind, then I need to make the effort to first understand their mind. That’s going to be far more productive than declaring that my own mind is made up. After all, if I show no willingness to consider alternative viewpoints, why should they?