Jeremy Keith's Blog, page 13

Ad revenue

It���s been dispiriting but unsurprising to see American commentators weigh in on the EU���s Digital Markets Act. I really wish they���d read Baldur���s excellent explainer first.

John has been doing his predicatable ���leave Britney alone!��� schtick with regards to Apple (and in this case, Google and Facebook too). Ian Betteridge does an excellent job of setting him straight:

A lot of commentators seem to have the same issue as John: that it���s weird that a governmental body can or should define how products should be designed.

But governments mandate how products are designed all the time, and not just in the EU. Take another market which is pretty big: cars. All cars have to feature safety equipment, which varies from region to region but will broadly include everything from seatbelts to crumple zones. Cars have rules for emissions, for fuel efficiency, all of which are designing how a car should work.

But there���s one assumption in John���s post that Ian didn���t push back on. John said:

It���s certainly possible that Meta can devise ways to serve non-personalized contextual ads that generate sufficient revenue per user.

That comes with a footnote:

One obvious solution would be to show more ads���������a lot more ads���������to make up for the difference in revenue. So if contextual ads generate, say, one-tenth the revenue of targeted ads, Meta could show 10 times as many ads to users who opt out of targeting. I don���t think 10�� is an outlandish multiplier there���������given how remarkably profitable Meta���s advertising business is, it might even need to be higher than that.

It���s almost like an article of faith that behavioural advertising is more effective than contextual advertising. But there���s no data to support this. Quite the opposite. I wrote about this four years ago.

Once again, I urge you to read the excellent analysis by Jesse Frederik and Maurits Martijn.

There���s also Tim Hwang���s book, Subprime Attention Crisis:

From the unreliability of advertising numbers and the unregulated automation of advertising bidding wars, to the simple fact that online ads mostly fail to work, Hwang demonstrates that while consumers��� attention has never been more prized, the true value of that attention itself���much like subprime mortgages���is wildly misrepresented.

More recently Dave Karpf said what we���re all thinking:

The thing I want to stress about microtargeted ads is that the current version is perpetually trash, and we���re always just a few years away from the bugs getting worked out.

The EFF are calling for a ban. Should that happen, the sky would not fall. Contrary to what John thinks, revenue would not plummet. Contextual advertising works just fine ���without the need for invasive surveillance and tracking.

Like I said:

Tracker-driven behavioural advertising is bad for users. The advertisements are irrelevant most of the time, and on the few occasions where the advertising hits the mark, it just feels creepy.

Tracker-driven behavioural advertising is bad for advertisers. They spend their hard-earned money on invasive ad tech that results in no more sales or brand recognition than if they had relied on good ol��� contextual advertising.

Tracker-driven behavioural advertising is very bad for the web. Megabytes of third-party JavaScript are injected at exactly the wrong moment to make for the worst possible performance. And if that doesn���t ruin the user experience enough, there are still invasive overlays and consent forms to click through (which, ironically, gets people mad at the legislation���like GDPR���instead of the underlying reason for these annoying overlays: unnecessary surveillance and tracking by the site you���re visiting).

Onboarding on the Clearleft podcast

Crash!

Did somebody drop something?

Why, yes! It���s a new episode of The Clearleft Podcast. The episode that just dropped is all about onboarding:

How do you introduce users to product features without alienating or patronising them?

It���s a tidy fifteen and a half minutes long, featuring words of wisdom from product designer James Gilyead, content designer Jo Dimbleby, and of course UX designer Krystal Higgins, who literally wrote the book on better onboarding.

I interviewed James and Jo, and used snippets of a talk that Krystal gave at one of our UX events a little while back. Have a listen:

James and Jo talk worked on a project together for Sage where thy prototyped patterns for onboarding users to product features. You can find out more about the project:

The folks at Sage had a hunch that an overview screen might be valuable for their customers. They asked Clearleft to help them test this hypothesis.

Another Clearleftie, Chris How, wrote a chapter for the Customer Onboarding Handbook published by CX Lead. You can get the book and read his chapter called Ongoing Onboarding.

That idea of ongoing onboarding is something James talks about on the podcast, calling it ���longboarding���:

We ended up coining the term longboarding to describe a transition from a new user to an established user.

He goes one better with the term ���non-boarding���:

Some products you don���t realize have onboarded you. And I think that���s a huge compliment.

Listen to the whole episode to get the full story. And while you���re at it, subscribe to the podcast feed or subscribe on Apple, Spotify, or wherever you get your podcasts.

Headsongs

When I play music, it���s almost always instrumental. If you look at my YouTube channel almost all the videos are of me playing tunes���jigs, reels, and so on.

Most of those videos were recorded during The Situation when I posted a new tune every day for 200 consecutive days. Every so often though, I���d record a song.

I go through periods of getting obsessed with a particular song. During The Situation I remember two songs that were calling to me. New York was playing in my head as I watched my friends there suffering in March 2020. And Time (The Revelator) resonated in lockdown:

And every day is getting straighter, time���s a revelator.

The song I���m obsessed with right now is called Foreign Lander. I first came across it in a beautiful version by Sarah Jarosz (I watch lots of mandolin videos on YouTube so the algorithm hardly broke a sweat showing this to me).

There���s a great version by Tatiana Hargreaves too. And Tim O���Brien.

I wanted to know more about the song. I thought it might be relatively recent. The imagery of the lyrics makes it sound like something straight from a songwriter like Nick Cave:

If ever I prove false love
The elements would moan
The fire would turn to ice love
The seas would rage and burn

But the song is old. Jean Ritchie collected it, though she didn���t have to go far. She said:

Foreign Lander was my Dad’s proposal song to Mom

I found that out when I came across this thread from 2002 on mudcat.org where Jean Ritchie herself was a regular contributor!

That gave me a bit of vertiginous feeling of The Great Span, thinking about the technology that she used when she was out in the field.

I���ve been practicing Foreign Lander and probably driving Jessica crazy as I repeat over and over and over. It���s got some tricky parts to sing and play together which is why it���s taking me a while. Once I get it down, maybe I���ll record a video.

I spent most of Saturday either singing the song or thinking about it. When I went to bed that night, tucking into a book, Foreign Lander was going ���round in my head.

Coco���the cat who is not our cat���came in and made herself comfortable for a while.

I felt very content.

A childish little rhyme popped into my head:

With a song in my head
And a cat on my bed
I read until I sleep

I almost got up to post it as a note here on my website. Instead I told myself to do it the morning, hoping I wouldn���t forget.

That night I dreamt about Irish music sessions. Don���t worry, I���m not going to describe my dream to you���I know how boring that is for everyone but the person who had the dream.

But I was glad I hadn���t posted my little rhyme before sleeping. The dream gave me a nice little conclusion:

With a song in my head
And a cat on my bed
I read until I sleep
And dream of rooms
Filled with tunes.

Hanging punctuation in CSS

There���s a lovely CSS property called hanging-punctuation. You can use it to do exactly what the name suggests and exdent punctuation marks such as opening quotes.

Here���s one way to apply it:

html { hanging-punctuation: first last;}

Any punctuation marks at the beginning or end of a line will now hang over the edge, leaving you with nice clean blocks of text; no ragged edges.

Right now it���s only supported in Safari but there���s no reason not to use it. It���s a perfect example of progressive enhancement. One line of CSS to tidy things up for the browsers that support it and leave things exactly as they are for the browsers that don���t.

But when I used this over on The Session I noticed an unintended side-effect. Because I���m applying the property globally, it���s also acting on form fields. If the text inside a form field starts with a quotation mark or some other piece of punctuation, it���s shunted off to the side and hidden.

Here���s the fix I used:

input, textarea { hanging-punctuation: none;}

It���s a small little gotcha but I figured I���d share it in case it helps someone else out.

Spring drop

This weekend it felt like Spring dropped like an unexpected new album from Taylor Swift or Beyonc��.

The weather turned nice and sunny. The clocks sprang forward an hour. I had my first asparagus of the year. Flowers are flowering. It���s all just very nice.

It���s like the year would like to make up for the disappointing performance in its first quarter and promises much better things for the quarter to come.

I understand now why a major religion would co-opt this time of year for a resurrection-themed shindig.

Goodbye Winter. Hello Spring. Nice to see you again.

Who knows?

I love it when I come across some bit of CSS I���ve never heard of before.

Take this article on the text-emphasis property.

���The what property?���, I hear you ask. That was my reaction too. But look, it���s totally a thing.

Or take this article by David Bushell called CSS Button Styles You Might Not Know.

Sure enough, halfway through the article David starts talking about styling the button in an input type="file��� using the ::file-selector-button pseudo-element:

All modern browsers support it. I had no idea myself until recently.

He���s right!

Then I remembered that I���ve got a file upload input in the form I use for posting my notes here on adactio.com (in case I want to add a photo). I immediately opened up my style sheet, eager to use this new-to-me bit of CSS.

I found the bit where I style buttons and this is the selector I saw:

button,input[type="submit"],::file-selector-button

Huh. I guess I did know about that pseudo-element after all. Clearly the knowledge exited my brain shortly afterwards.

There���s that tautological cryptic saying, ���You don���t know what you don���t know.��� But I don���t even know what I do know!

Fidinpamp

If you���re a fan of gratuitous initialisms, you���ll love Google���s core web vitals. Just get a load of the obfuscation in the important-sounding metrics like CLS, FCP, LCP, and more.

To be fair to Google, this is a problem in the web performance world in general. Practioners prefer to talk about TTFB rather than ���time to first byte��� even though both contain exactly the same number of syllables.

The big news in the web performance community this month is the arrival of a new initialism. INP sounds like one of those pseudo-scientific psychologic profiles but it���s meant to stand for Interaction to Next Paint (even if they were to swear off pointless initialisms, you���d still have to pry Pointless Capitalisation from Google���s cold dead hands).

This new metric is a welcome one. It���s replacing first input delay. Sorry, First Input Delay, or FID, one of the few web vital initialisms that can be spoken as a word, making it a true acronym (fortunately fid���s successor, inp, also works as an acronym).

First Input Delay has long outstayed its welcome. It was always an outlier in the core web vitals. It didn���t seem to measure anything actually useful. I know it sounds like it���s measuring the delay until the user can interact with a web page, but when you dive into what it actually does, it���s a mess:

FID measures the time from when a user first interacts with a page (that is, when they click a link, tap on a button, or use a custom, JavaScript-powered control) to the time when the browser is actually able to begin processing event handlers in response to that interaction.

See that word ���begin��� in there? It���s doing a lot of work. First Input Delay doesn���t measure the lag between the user interaction and the browser response; it only measures the lag between the user interaction and the browser beginning to respond. The actual response could take ages, but that lag doesn���t get measured. Unlike the other core web vitals, this metric is very far removed from what actually matters to the user���s experience.

What the fid where they thinking? How the fid did this measurement ever get included in core web vitals in the first place?

Well, feel free to take what I���m about to say as pure gossip, but I have my sources, I trust ���em, and no, I���m not going to reveal ���em���

It���s because of AMP.

Remember Google AMP? An acronym so pointless they eventually just forgot it ever stood for anything?

The AMP project ended up doing incredible damage to Google���s developer relations. By colluding with the search team to privilege the appearance of AMP pages in the top news carousel, Google effectively blackmailed the entire publishing industry into using their format.

In the end, it didn���t work. It was a shit format. All they did was foster resentment and animosity:

AMP seems to have faded away. Most publishers have started dropping support, and even Google doesn���t seem to care much anymore.

It turns out that Google search wasn���t the only team infected by AMP. The core web vitals team also had to play ball.

Originally they had a genuinely useful metric for measuring the lag between input and response. But guess which pages did terribly? That���s right: AMP pages.

Rather than ship an actually-useful measurement, the core web vitals team instead had to include the broken First Input Delay, brainchild of a certain someone on the AMP team.

Now it all makes sense.

So good riddance to FID. Welcome to INP. And here���s hoping it won���t be much longer till we���re finally burying AMP.

Progressive disclosure defaults

When I wrote about my time in Amsterdam last week, I mentioned the task that the students were given:

They���re given a PDF inheritance-tax form and told to convert it for the web.

Rich had a question about that:

I’m curious to know if they had the opportunity to optimise the user experience of the form for an online environment, eg. splitting it up into a sequence of questions, using progressive disclosure, branching based on inputs, etc?

The answer is yes, very much so. Progressive disclosure was a very clear opportunity for enhancement.

You know the kind of paper form where it says ���If you answered no to this, then skip ahead to that���? On the web, we can do the skipping automatically. Or to put it another way, we can display a section of the form only when the user has ticked the appropriate box.

This is a classic example of progressive disclosure:

information is revealed when it becomes relevant to the current task.

But what should the mechanism be?

This is an interaction design pattern so JavaScript seems the best choice. JavaScript is for behaviour.

On the other hand, you can do this in CSS using the :checked pseudo-class. And the principle of least power suggests using the least powerful language suitable for a given task.

I���m torn on this. I���m not sure if there���s a correct answer. I���d probably lean towards JavaScript just because it���s then possible to dynamically update ARIA attributes like aria-expanded���very handy in combination with aria-controls. But using CSS also seems perfectly reasonable to me.

It was interesting to see which students went down the JavaScript route and which ones used CSS.

It used to be that using the :checked pseudo-class involved an adjacent sibling selector, like this:

input.disclosure-switch:checked ~ .disclosure-content { display: block;}

That meant your markup had to follow a specific pattern where the elements needed to be siblings:

...

But none of the students were doing that. They were all using :has(). That meant that their selector could be much more robust. Even if the nesting of their markup changes, the CSS will still work. Something like this:

.disclosure-container:has(.disclosure-switch:checked) .disclosure-content

That will target the .disclosure-content element anywhere inside the same .disclosure-container that has the .disclosure-switch. Much better! (Ignore these class names by the way���I’m just making them up to illustrate the idea.)

But just about every student ended up with something like this in their style sheets:

.disclosure-content { display: none;}.disclosure-container:has(.disclosure-switch:checked) .disclosure-content { display: block;}

That gets my spidey-senses tingling. It doesn’t smell right to me. Here’s why���

The simpler selector is doing the more destructive action: hiding content. There’s a reliance on the more complex selector to display content.

If a browser understands the first ruleset but not the second, that content will be hidden by default.

I know that :has() is very well supported now, but this still makes me nervous. I feel that the more risky action (hiding content) should belong to the more complex selector.

Thanks to the :not() selector, you can reverse the logic of the progressive disclosure:

.disclosure-content { display: block;}.disclosure-container:not(:has(.disclosure-switch:checked)) .disclosure-content { display: none;}

Now if a browser understands the first ruleset, but not the second, it’s not so bad. The content remains visible.

When I was explaining this way of thinking to the students, I used an analogy.

Suppose you’re building a physical product that uses electricity. What should happen if there’s a power cut? Like, if you’ve got a building with electric doors, what should happen when the power is cut off? Should the doors be locked by default? Or is it safer to default to unlocked doors?

It’s a bit of a tortured analogy, but it’s one I’ve used in the past when talking about JavaScript on the web. I like to think about JavaScript as being like electricity���

Take an existing product, like say, a toothbrush. Now imagine what you can do when you turbo-charge it with electricity: an electric toothbrush!

But also consider what happens when the electricity fails. Instead of the product becoming useless you want it to revert back to being a regular old toothbrush.

That’s the same mindset I’m encouraging for the progressive disclosure pattern. Make sure that the default state is safe. Then enhance.

What the world needs

I was having a discussion with some people recently about writing. It was quite cathartic. Everyone was sharing the kinds of things that their inner critic tells them. We were all encouraging each other to ignore that voice.

I mentioned that the two reasons for not writing that I hear most often from people are variations on ���I���ve got nothing to say.���

The first version is when someone says they���ve got nothing to say because they���re not qualified to write on a particualar topic. ���After all, there are real experts out there who know far more than me. So I���ve got nothing to say.���

But then once you do actually understand a topic, the second version appears. ���If I know about this, then everyone knows about this. It���s obvious. So I���ve got nothing to say.���

In both cases, you absolutely should be writing and sharing! In the first instance, you���ve got the beginner���s mind���a valuable perspective. In the second instance, you���ve got personal experience���another valuable perspective.

In other words, while it seems like there���s never a good time to write about something, the truth is that there���s never a bad time to write about something.

So write! Share! Publish!

Then someone in the discussion said something I always find a bit deflating. They said they had no problem writing, but they���re not so keen on publishing.

���After all���, they said, ���the world doesn���t need yet another opinion.���

This gets me down because it���s hard to argue with. It���s true that the world doesn���t need another think piece. The world doesn���t need to hear your thoughts on some topic. The world doesn���t need to hear what you���ve been up to recently.

But you know what? Screw what the world needs.

If we���re going to be hardnosed about this, then the world doesn���t need any more books. The world doesn���t need any more music. The world doesn���t need art. Heck, the world doesn���t need us at all.

So don���t publish for the world.

When I write something here on my website, I���m not thinking about the world reading it. That would be paralyzing. I do sometimes imagine that one person is reading it; someone just like me who hasn���t yet had this particular thought, or come up with that particular idea.

I���m writing for myself. I write to figure out what I think. I also publish mostly for myself���a public archive for future me. But if what I publish just happens to connect with one other person, I���m glad.

So, yeah, it���s true that the world doesn���t need you to write and share and publish. Isn���t that liberating? You���re free to write and share and publish for yourself.

Schooltijd

I was in Amsterdam last week. Usually I���m in that city for an event like the excellent CSS Day. Not this time. I was there as a guest of Vasilis. He invited me over to bother his students at the CMD (Communications and Multimedia Design) school.

There���s a specific module his students are partaking in that���s right up my alley. They���re given a PDF inheritance-tax form and told to convert it for the web.

Yes, all the excitement of taxes combined with the thrilling world of web forms.

Seriously though, I genuinely get excited by the potential for progressive enhancement here. Sure, there���s the obvious approach of building in layers; HTML first, then CSS, then a sprinkling of JavaScript. But there���s also so much potential for enhancement within each layer.

Got your form fields marked up with the right input types? Great! Now what about autocomplete, inputmode, or pattern attributes?

Got your styles all looking good on the screen? Great! Now what about print styles?

Got form validation working? Great! Now how might you use local storage to save data locally?

As well as taking this practical module, most of the students were also taking a different module looking at creative uses of CSS, like making digital fireworks, or creating works of art with a single div. It was fascinating to see how the different students responded to the different tasks. Some people loved the creative coding and dreaded the progressive enhancement. For others it was exactly the opposite.

Having to switch gears between modules reminded me of switching between prototypes and production:

Alternating between production projects and prototyping projects can be quite fun, if a little disorienting. It���s almost like I have to flip a switch in my brain to change tracks.

Here���s something I noticed: the students love using :has() in CSS. That���s so great to see! Whereas I might think about how to do something for a few minutes before I think of reaching for :has(), they���ve got front of mind. I���m jealous!

In general, their challenges weren���t with the vocabulary or syntax of HTML, CSS, and JavaScript. The more universal problem was project management. Where to start? What order to do things in? How long to spend on different tasks?

If you can get good at dealing with those questions and not getting overwhelmed, then the specifics of the actual coding will be easier to handle.

This was particularly apparent when it came to JavaScript, the layer of the web stack that was scariest for many of the students.

I encouraged them to break their JavaScript enhancements into two tasks: what you want to do, and how you then execute that.

Start by writing out the logic of your script not in JavaScript, but in whatever language you���re most comfortable with: English, Dutch, whatever. In the course of writing this down, you���ll discover and solve some logical issues. You can also run your plain-language plan past a peer to sense-check it.

It���s only then that you move on to translating your logic into JavaScript. Under each line of English or Dutch, write the corresponding JavaScript. You might as well put // in front of the plain-language sentence while you���re at it to make it a comment���now you���ve got documentation baked in.

You���ll still run into problems at this point, but they���ll be the manageable problems of syntax and typos.

So in the end, it wasn���t my knowledge of specific HTML, CSS, or JavaScript APIs that proved most useful to pass on to the students. It was advice like that around how to approach HTML, CSS, or JavaScript.

I also learned a lot during my time at the school. I had some very inspiring conversations with the web developers of tomorrow. And I was really impressed by how much the students got done just in the three days I was hanging around.

I���d love to do it again sometime.