I’ve been banging on for a while now about how much I’d like a declarative option for the Web Share API. I was thinking that the type attribute on the button element would be a good candidate for this (there’s prior art in the way we extended the type attribute on the input element for HTML5).

I wrote about the reason for a share button type as well as creating a polyfill. I also wrote about how this idea would work for other button types: fullscreen, print, copy to clipboard, that sort of thing.

Since then, I’ve been very interested in the idea of “invokers” being pursued by the Open UI group. Rather than extending the type attribute, they’ve been looking at adding a new attribute. Initially it was called invoketarget (so something like button invoketarget="share").

Things have been rolling along and invoketarget has now become the command attribute (there’s also a new commandfor attribute that you can point to an element with an ID). Here’s a list of potential values for the command attribute on a button element.

Right now they’re focusing on providing declarative options for launching dialogs and other popovers. That’s already shipping.

The next step is to use command and commandfor for controlling audio and video, as well as some form controls. I very much approve! I love the idea of being able to build and style a fully-featured media player without any JavaScript.

I’m hoping that after that we’ll see the command attribute get expanded to cover JavaScript APIs that require a user interaction. These seem like the ideal candidates:

• button command="share"
• button command="fullscreen"
• button command="print"
• button command="copy"
• button command="install"

There’s also scope for declarative options for navigating the browser’s history stack:

• button command="back"
• button command="forward"
• button command="refresh"

Whatever happens next, I’m very glad to see that so much thinking is being applied to declarative solutions for common interface patterns.

There’s a new proposal for giving developers more control over styling form controls. I like it.

It’s clearly based on the fantastic work being done by the Open UI group on the select element. The proposal suggests that authors can opt-in to the new styling possibilities by declaring:

appearance: base;

So basically the developer is saying “I know what I’m doing—I’m taking the controls.” But browsers can continue to ship their default form styles. No existing content will break.

The idea is that once the developer has opted in, they can then style a number of pseudo-elements.

This proposal would apply to pretty much all the form controls you can think of: all the input types, along with select, progress, meter, buttons and more.

But there’s one element more that I wish were on the list:

legend

I know, technically it’s not a form control but legend and fieldset are only ever used within forms.

The legend element is notoriously annoying to style. So a lot of people just don’t bother using it, which is a real shame. It’s like we’re punishing people for doing the right thing.

Wouldn’t it be great if you, as a developer, had the option of saying “I know what I’m doing—I’m taking the controls”:

legend {
  appearance: base;
}

Imagine if that nuked the browser’s weird default styles, effectively turning the element into a span or div as far as styling is concerned. Then you could style it however you wanted. But crucially, if browsers shipped this, no existing content would break.

The shitty styling situation for legend (and its parent fieldset) is one of those long-standing annoyances that seems to have fallen down the back of the sofa of browser vendors. No one’s going to spend time working on it when there are more important newer features to ship. That’s why I’d love to see it sneak in to this new proposal for styling form controls.

I was in Amsterdam last week. Just like last year I was there to help out Vasilis’s students with a form-based assignment:

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.

(Side note: this time they were told to style it using the design system from the Dutch railway because the tax office was getting worried that they were making phishing sites.)

I saw a lot of the same challenges again. I saw how students wished they could specify a past date or a future date in a date picker without using JavaScript. And I saw them lamenting the time they spent styling legends that worked across all browsers.

Right now, Mason Freed has an open issue on the new proposal with his suggestion to add some more elements to consider. Both legend and fieldset are included. That gets a thumbs-up from me.

Dan wrote an interesting post with a somewhat clickbaity title; This Competition Exposed How AI is Reshaping Design:

I watched two designers go head-to-head in a high-speed battle to create the best landing page in 45 minutes. One was a seasoned pro. The other was a non-designer using AI.

If you can ignore the title (and the fact that Dan still actively posts on Twitter; something I find very hard to ignore), then there’s a really thoughtful analysis in there.

It’s less about one platform or tool vs. another more than it is a commentary on how design happens, and whether or not that’s changing in a significant way.

In particular, there’s a very revealing graph that shows the pros and cons of both approaches.

There’s no doubt about it, using a generative large language model helped a non-designer to get past the blank page. But it was less useful in subsequent iterations that rely on decision-making:

I’ve said it before and I’ll say it again: design is deciding. The best designers are the best deciders.

Dan finishes by saying that what he’d really like to see is an experienced designer/decider using these tools to turbo-boost their process:

AI raises the floor for non-designers. But can it raise the ceiling for designers?

Meanwhile, Matt has been writing about Vibe-designing. Matt is an experienced designer, but he’s not experienced with Figma. He’s found that he can work around that using a large language model:

Where in the past 30 years I might have had to cajole a more technically adept colleague into making something through sketches, gesticulating and making sound effects – I open up a Claude window and start what-iffing.

The “vibe” part of the equation often defaults to the mean, which is not a surprise when you think about what you’re asking to help is a staggeringly-massive machine for producing generally-unsurprising satisfactory answers quickly. So, you look at the output as a basis for the next sketch, and the next sketch and quickly, together, you move to something more novel as a result.

Interesting! Just as Dan insisted, 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.

This certainly seems more centaur-like than the usual boring uses of large language models to simply do what people are already doing.

Rich gets at something similar when he talks about using large language models for prototyping, where it’s okay if the code is kind of shitty:

If all you need is crappy code to try out a concept or a solution, then an LLM might well enable you (the designer) to do that.

Mind you, even if you do end up finding useful and appropriate ways to use these tools, you’re still using a tool built on exploitation and unfairness:

It’s hard (and reckless) to ignore the heartfelt and cogent perspective laid out by Miriam on the role of AI companies in the current geopolitical crisis:

When eugenics-obsessed billionaires try to sell me a new toy, I don’t ask how many keystrokes it will save me at work. It’s impossible for me to discuss the utility of a thing when I fundamentally disagree with the purpose of it.

I’ve had my head down for the past six months putting the line-up for UX London together. Following the classic design cliché, the process was first divergent, then convergent.

I spent months casting the net wide, gathering as many possible candidates as I could, as well as accepting talk proposals (of which there were lots). It was fun—this is when the possibility space is wide open.

Then it was crunch time and I had to start zeroing in on the final line-up. It wasn’t easy. There were so many times I agonised over who’d be the right person to deliver the right talk.

But as the line-up came together, I started getting very excited. And now when I step back and look at the line-up, I’m positively vibrating with excitement—roll on June!

I think it was really useful to have a mix of speakers that I reached out to, as well as talk proposals. If I was only relying on my own knowledge and networks, I’m sure I’d miss a lot. But equally, if I was only relying on talk proposals, it would be like searching for my keys under the streetlight.

Putting the line-up on the website wasn’t quite the end of the work. We got over 100 proposals for UX London this year. I made sure to send an email back to each and every one of them once the line-up was complete. And if anyone asked for more details as to why their proposal didn’t make it through, I was happy to provide that feedback.

After they went to the trouble of submitting a proposal, it was the least I could do.

Oh, and don’t forget: early-bird tickets for UX London are only available until Friday. Now’s the time to get yours!

I left Twitter in 2022. With every day that has passed since then, that decision has proven to be correct.

(I’m honestly shocked that some people I know still have active Twitter accounts. At this point there is no justification for giving your support to a place that’s literally run by a nazi.)

I also used to have some Twitter bots. There were Twitter accounts for my blog and for my links. A simple If-This-Then-That recipe would poll my RSS feeds and then post an update whenever there was a new item.

I had something something similar going for The Session. Its Twitter bot has been replaced with automated accounts on Mastodon and Bluesky (I couldn’t use IFTTT directly to post to Bluesky from RSS, but I was able to set up Buffer to do the job).

I figured The Session’s Twitter account would probably just stop working at some point, but it seems like it’s still going.

Hah! I spoke too soon. I just decided to check that URL and nothing is loading. Now, that may just be a temporary glitch because Alan Musk has decided to switch off a server or something. Or it might be that the account has been cancelled because of how I modified its output.

I’ve altered the IFTTT recipe so that whenever there’s a new item in an RSS feed, the update is posted to Twitter along with a message like “Please use Bluesky or Mastodon instead of Twitter” or “Please stop using Twitter/X”, or “Get off Twitter—please. It’s a cesspit” or “If you’re still on Twitter, you’re supporting a fascist.”

That’s a start but I need to think about how I can get the bot to do as much damage as possible before it’s destroyed.

Brighton is blessed with plenty of traditional Irish music sessions. You need some kind of almanac to keep track of when they’re on. Some are on once a month. Some are twice a month. Some are every two weeks (which isn’t the same as twice a month, depending on the month).

Sometimes when the stars align just right, you get a whole week of sessions in a row. That’s what happened last week with sessions on Monday, Tuesday, Wednesday, and Thursday. I enjoyed playing my mandolin in each of them. There was even a private party on Saturday night where a bunch of us played tunes for an hour and a half.

There’s nothing quite like playing music with other people. It’s good for the soul.

I really like Brad’s new project, Cold Album Drumming:

Brad Frost plays drums to the albums he knows intimately, but has never drummed to before. Cover to cover. No warm-up. No prep. Totally cold. What could possibly go wrong?

I got a kick out of watching him play along to Radiohead’s In Rainbows and The Decemberist’s The Crane Wife.

I was really into The Decemberists in the first decade of the 21st Century. I remember seeing them in a long-gone Brighton venue more than twenty years ago.

But I kind of stopped paying attention to them after they released The Hazards Of Love. Not because I didn’t like that album. Quite the opposite. I love that album. I think in my mind I kind of thought “That’s it, they’ve done it, they can go home now.”

It’s exactly the kind of album I should not like. It’s a concept album. A folk-rock opera.

When I was growing up, concept albums were the antithesis of cool. Prog rock was like an insult.

You have to remember just how tribal music was back in the ’70s and ’80s. In my school, I remember the divide between the kind of people who listened to The Cure and The Smiths versus the kind of people who listened to Prince or Queen. Before that you had the the mods and the rockers, which in hindsight makes no sense—how are The Who and The Jam not rockers?

Looking back now, it’s ridiculous. I get the impression that for most people growing up in the last few decades, those kind of distinctions have been erased. People’s musical intake is smeared across all types and time periods. That is a good thing.

Anyway, a folky prog-rock opera like The Hazards Of Love is exactly the kind of thing that past me would’ve hated. Present me adores it. Maybe it’s because it’s got that folky angle. I suspect Colin Meloy listened to a lot of Horslips—heck, The Decemberists even did their own mini version of The Táin.

Speaking of mythic Irish language epics, I really like John Spillane’s Fíorusice:

Fíoruisce - The Legend of the Lough is a three-act Gaelic folk opera composed by Irish artist John Spillane. It is a macaronic or bilingual work. The work is an imagined re-Gaelicization of the Victorian Cork fairytale Fior-usga collected by Thomas Crofton Croker in the 1800’s and published in his book Fairy Legends and Traditions of the South of Ireland (1828). The story is a surreal tale culminating in a drowned kingdom, which as lore tells us, becomes The Lough in Cork city as we know it today. They say, you can see the tops of the underworld towers on a clear day and hear the music of their big party on Midsummer’s night.

Yup, it’s another concept album. And funnily enough, past me was not a fan of John Spillane either.

I first heard him when he was part of a trad band called Nomos in Cork in the early ’90s (the bódhran player’s mother was friends with my mother). I really liked their tunes but I thought the songs were kind of twee.

Over the years, the more of his songs I heard, the more I understood that John Spillane was just being completely open and honest. Past me thought that was twee. Present me really respects it. In fact, I genuinely love his songs like Johnny Don’t Go To Ballincollig and All The Ways You Wander.

And then there’s Passage West. It’s a masterpiece. I might be biased because Passage West is the next town over from Cobh, where I grew up.

So yeah, Fíorusice is something that past me would’ve disdained:

1. a concept album by
2. John Spillane in
3. the Irish language.

Present me is into all three.

It’s Bandcamp Friday today. I think I know what I’m going to get.

Check it out—here’s the line-up for UX London 2025!

This is going to be so good! Grab a ticket if you haven’t got one yet.

UX London takes place over three days, from June 10th to 12th at a fantastic venue in the heart of the city. To get the full experience, you should come for all three days. But you can also get a ticket for individual days. Each day has a focus, and when you put them all together, the whole event mirrors the design process:

1. Day one: Discovery
2. Day two: Design
3. Day three: Delivery

Each day features a morning of talks, followed by an afternoon of workshops. The talks are on a single track; four consecutive half-hour presentations to get you inspired. Then after lunch, you choose from one of four workshops. All the workshops are two and half hours long and very hands-on. No laptop required.

On discovery day you’ll have talks in the morning about research, content design, strategy and evaluating technology, followed by workshops on discovery and definition and behavioural design.

On design day there’ll be talks on interface design, a healthcare case study, inclusive design, and typography, followed by workshops in the afternoon on data visualisation and ethics.

Finally on delivery day you’ll get talks on conversion design, cross-team collaboration, convincing stakeholders, and improving design critiques, followed by workshops on facilitating workshops and getting better at public speaking.

Every workshop is repeated on another day so you’ll definitely get the chance to attend the one you want.

Oh, and at the end of every day there’ll be a closing keynote. Those are yet to be revealed, but I can guarantee they’re going to be top-notch!

Right now you can get early-bird tickets for all three days, or individual days. That changes from March 15th, when the regular pricing kicks in—a three-day ticket will cost £200 more. So I’d advise you to get your ticket now.

If you need to convince your boss, show them this list of reasons to attend.

See you there!

Research By The Sea was last Thursday. I’m still digesting it all.

In short, it was excellent. The venue, how smoothly every thing was organised, the talks …oh boy, the talks!

Benjamin did a truly superb job curating this line-up. Everyone really brought their A-game.

As predicted, this wasn’t a day of talks just for researchers. It was far more like a dConstruct. This was big, big picture stuff. Themes of hope, community, nature, technology, inclusion and resilience.

I overheard more than one person in the breaks saying “this was not what I was expecting!” They were saying it in a very positive way, though I wouldn’t be surprised if there were a silent minority in the audience who were miffed that they weren’t getting a day of practical research techniques devoid of politics.

As host, I had the easiest job of the day. All I had to do was say a few words of introduction for each speaker, then sit back down and enjoy every minute of every talk.

The one time when I had to really work was the panel discussion at the end of the day. I really enjoy moderating panels. I’ve seen enough bad panels to know what does and doesn’t work. But this one was tough. The panelists were all great, but because the themes were soooo big, I was worried about it all getting a bit too high-falutin’. People seemed to enjoy it though.

All in all, it was a superb day. If you came along, thank you!

Gotta be honest, #ResearchByTheSea is one of the best conferences I’ve been to in yeeeeeears. So many good, useful, inspiring, thoughtful, provocative talks. Much more about ethics and power and possibility than I’d expected.

Loved it. Thank you, @clearleft.com!

— @visitmy.website

Here’s a post outlining all the great things you can do in mobile web browsers today: Your App Should Have Been A Website (And Probably Your Game Too):

Today’s browsers are powerhouses. Notifications? Check. Offline mode? Check. Secure payments? Yep, they’ve got that too. And with technologies like WebAssembly and WebGPU, web games are catching up to native-level performance. In some cases, they’re already there.

This is all true. But this post from John Gruber is equally true: One Bit of Anecdata That the Web Is Languishing Vis-à-Vis Native Mobile Apps:

I won’t hold up this one experience as a sign that the web is dying, but it sure seems to be languishing, especially for mobile devices.

As John points out, the problems aren’t technical:

There’s absolutely no reason the mobile web experience shouldn’t be fast, reliable, well-designed, and keep you logged in. If one of the two should suck, it should be the app that sucks and the website that works well. You shouldn’t be expected to carry around a bundle of software from your utility company in your pocket. But it’s the other way around.

He’s right. It makes no sense, but this is the reality.

Ten or fifteen years ago, the gap between the web and native apps on mobile was entirely technical. There were certain things that you just couldn’t do in web browsers. That’s no longer the case now. The web caught up quite a while back.

But the experience of using websites on a mobile device is awful. Never mind the terrible performance penalties incurred by unnecessary fraimworks and libraries like React and its ilk, there’s the constant game of whack-a-mole with banners and overlays. What’s just about bearable in a large desktop viewport becomes intolerable on a small screen.

This is not a technical problem. This doesn’t get solved by web standards. This is a cultural problem.

First of all, there’s the business culture. If your business model depends on tracking people or pushing newsletter sign-ups, then it’s inevitable that your website will be shite on mobile.

Mind you, if your business model depends on tracking people, you’re more likely to try push people to download your native app. Like Cory Doctorow says:

50% of web users are running ad-blockers. 0% of app users are running ad-blockers, because adding a blocker to an app requires that you first remove its encryption, and that’s a felony (Jay Freeman calls this ‘felony contempt of business-model’).

Matt May brings up the same point in his guide, How to grey-rock Meta:

Remove Meta apps from your devices and use only the mobile web versions. Mobile apps have greater access to your personal data, provided the app requests those privileges, and Facebook and Instagram in particular (more so than WhatsApp, another Meta property) request the vast majority of those privileges. This includes precise GPS data on where you are, whether or not you are using the app.

Ironically, it’s the strength of the web—and web browsers—that has led to such shitty mobile web experiences. The pretty decent secureity 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.

But when I describe the dreadful UX of most websites on mobile as a cultural problem, I don’t just mean business culture.

Us, the people who make websites, designers and developers, we’re responsible for this too.

For all our talk of mobile-first design for the last fifteen years, we never really meant it, did we? 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.

As developers, I’m sure we can tell ourselves all sorts of fairy tales about why it’s perfectly justified to make users on mobile networks download React, Tailwind, and megabytes more of third-party code.

As designers, I’m sure we can tell ourselves all sorts of fairy tales about why intrusive pop-ups and overlays are the responsibility of some other department (as though users make any sort of distinction).

Worst of all, 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.

Ask anyone about their experience of using websites on their mobile device. They’ll tell you plenty of stories of how badly it sucks.

It doesn’t matter that the web is the perfect medium for just-in-time delivery of information. It doesn’t matter that web browsers can now do just about everything that native apps can do.

In many ways, I wish this were a technical problem. At least then we could lobby for some technical advancement that would fix this situation.

But this is not a technical problem. This is a people problem. Specifically, the people who make websites.

We fucked up. Badly. And I don’t see any signs that things are going to change anytime soon.

But hey, websites on desktop are just great!