Journal tags: ar

Picture someone tediously going through a spreadsheet that someone else has filled in by hand and finding yet another error.

“I wish to God these calculations had been executed by steam!” they cry.

The year was 1821 and technically the spreadsheet was a book of logarithmic tables. The frustrated cry came from Charles Babbage, who channeled his frustration into a scheme to create the world’s first computer.

His difference engine didn’t work out. Neither did his analytical engine. He’d spend his later years taking his frustrations out on street musicians, which—as a former busker myself—earns him a hairy eyeball from me.

But we’ve all been there, right? Some tedious task that feels soul-destroying in its monotony. Surely this is exactly what machines should be doing?

I have a hunch that this is where machine learning and large language models might turn out to be most useful. Not in creating breathtaking works of creativity, but in menial tasks that nobody enjoys.

Someone was telling me earlier today about how they took a bunch of haphazard notes in a client meeting. When the meeting was done, they needed to organise those notes into a coherent summary. Boring! But ChatGPT handled it just fine.

I don’t think that use-case is going to appear on the cover of Wired magazine anytime soon but it might be a truer glimpse of the future than any of the breathless claims being eagerly bandied about in Silicon Valley.

You know the way we no longer remember phone numbers, because, well, why would we now that we have machines to remember them for us? I’d be quite happy if machines did that for the annoying little repetitive tasks that nobody enjoys.

I’ll give you an example based on my own experience.

Regular expressions are my kryptonite. I’m rubbish at them. Any time I have to figure one out, the knowledge seeps out of my brain before long. I think that’s because I kind of resent having to internalise that knowledge. It doesn’t feel like something a human should have to know. “I wish to God these regular expressions had been calculated by steam!”

Now I can get a chatbot with a large language model to write the regular expression for me. I still need to describe what I want, so I need to write the instructions clearly. But all the gobbledygook that I’m writing for a machine now gets written by a machine. That seems fair.

Mind you, I wouldn’t blindly trust the output. I’d take that regular expression and run it through a chatbot, maybe a different chatbot running on a different large language model. “Explain what this regular expression does,” would be my prompt. If my input into the first chatbot matches the output of the second, I’d have some confidence in using the regular expression.

A friend of mine told me about using a large language model to help write SQL statements. He described his database structure to the chatbot, and then described what he wanted to select.

Again, I wouldn’t use that output without checking it first. But again, I might use another chatbot to do that checking. “Explain what this SQL statement does.”

Playing chatbots off against each other like this is kinda how machine learning works under the hood: generative adverserial networks.

Of course, the task of having to validate the output of a chatbot by checking it with another chatbot could get quite tedious. “I wish to God these large language model outputs had been validated by steam!”

Sounds like a job for machines.

You know how when you’re on hold to any customer service line you hear a message that thanks you for calling and claims your call is important to them. The message always includes a disclaimer about calls possibly being recorded “for training purposes.”

Nobody expects that any training is ever actually going to happen—surely we would see some improvement if that kind of iterative feedback loop were actually in place. But we most certainly want to know that a call might be recorded. Recording a call without disclosure would be unethical and illegal.

Consider chatbots.

If you’re having a text-based (or maybe even voice-based) interaction with a customer service representative that doesn’t disclose its output is the result of large language models, that too would be unethical. But, at the present moment in time, it would be perfectly legal.

That needs to change.

I suspect the necessary legislation will pass in Europe first. We’ll see if the USA follows.

In a way, this goes back to my obsession with seamful design. With something as inherently varied as the output of large language models, it’s vital that people have some way of evaluating what they’re told. I believe we should be able to see as much of the plumbing as possible.

The bare minimum amount of transparency is revealing that a machine is in the loop.

This shouldn’t be a controversial take. But I guarantee we’ll see resistance from tech companies trying to sell their “AI” tools as seamless, indistinguishable drop-in replacements for human workers.

I know I’m being tease, doling out these UX London speaker announcements in batches rather than one big reveal. Indulge me in my suspense-ratcheting behaviour.

Today I’d like to unveil three speakers whose surnames start with the letter H…

• Stephen Hay, Creative Director at Rabobank,
• Asia Hoe, Senior Product Designer, and
• Amy Hupe, Design Systems consultant at Frankly Design.

Just look at how that line-up is coming together! There’ll be just one more announcement and then the roster will be complete.

But don’t wait for that. Grab your ticket now and I’ll see you in London on June 22nd and 23rd!

The last talk at the last dConstruct was by local clever clogs Anil Seth. It was called Your Brain Hallucinates Your Conscious Reality. It’s well worth a listen.

Anil covers a lot of the same ground in his excellent book, Being You. He describes a model of consciousness that inverts our intuitive understanding.

We tend to think of our day-to-day reality in a fairly mechanical cybernetic manner; we receive inputs through our senses and then make decisions about reality informed by those inputs.

As another former dConstruct speaker, Adam Buxton, puts it in his interview with Anil, it feels like that old Beano cartoon, the Numskulls, with little decision-making homonculi inside our head.

But Anil posits that it works the other way around. We make a best guess of what the current state of reality is, and then we receive inputs from our senses, and then we adjust our model accordingly. There’s still a feedback loop, but cause and effect are flipped. First we predict or guess what’s happening, then we receive information. Rinse and repeat.

The book goes further and applies this to our very sense of self. We make a best guess of our sense of self and then adjust that model constantly based on our experiences.

There’s a natural tendency for us to balk at this proposition because it doesn’t seem rational. The rational model would be to make informed calculations based on available data …like computers do.

Maybe that’s what sets us apart from computers. Computers can make decisions based on data. But we can make guesses.

Enter machine learning and large language models. Now, for the first time, it appears that computers can make guesses.

The guess-making is not at all like what our brains do—large language models require enormous amounts of inputs before they can make a single guess—but still, this should be the breakthrough to be shouted from the rooftops: we’ve taught machines how to guess!

And yet. Almost every breathless press release touting some revitalised service that uses AI talks instead about accuracy. It would be far more honest to tout the really exceptional new feature: imagination.

Using AI, we will guess who should get a mortgage.

Using AI, we will guess who should get hired.

Using AI, we will guess who should get a strict prison sentence.

Reframed like that, it’s easy to see why technologists want to bury the lede.

Alas, this means that large language models are being put to use for exactly the wrong kind of scenarios.

(This, by the way, is also true of immersive “virtual reality” environments. Instead of trying to accurately recreate real-world places like meeting rooms, we should be leaning into the hallucinatory power of a technology that can generate dream-like situations where the pleasure comes from relinquishing control.)

Take search engines. They’re based entirely on trust and accuracy. Introducing a chatbot that confidentally conflates truth and fiction doesn’t bode well for the long-term reputation of that service.

But what if this is an interface problem?

Currently facts and guesses are presented with equal confidence, hence the accurate descriptions of the outputs as bullshit or mansplaining as a service.

What if the more fanciful guesses were marked as such?

As it is, there’s a “temperature” control that can be adjusted when generating these outputs; the more the dial is cranked, the further the outputs will stray from the safest predictions. What if that could be reflected in the output?

I don’t know what that would look like. It could be typographic—some markers to indicate which bits should be taken with pinches of salt. Or it could be through content design—phrases like “Perhaps…”, “Maybe…” or “It’s possible but unlikely that…”

I’m sure you’ve seen the outputs when people request that ChatGPT write their biography. Perfectly accurate statements are generated side-by-side with complete fabrications. This reinforces our scepticism of these tools. But imagine how differently the fabrications would read if they were preceded by some simple caveats.

A little bit of programmed humility could go a long way.

Right now, these chatbots are attempting to appear seamless. If 80% or 90% of their output is accurate, then blustering through the other 10% or 20% should be fine, right? But I think the experience for the end user would be immensely more empowering if these chatbots were designed seamfully. Expose the wires. Show the workings-out.

Mind you, that only works if there is some way to distinguish between fact and fabrication. If there’s no way to tell how much guessing is happening, then that’s a major problem. If you can’t tell me whether something is 50% true or 75% true or 25% true, then the only rational response is to treat the entire output as suspect.

I think there’s a fundamental misunderstanding behind the design of these chatbots that goes all the way back to the Turing test. There’s this idea that the way to make a chatbot believable and trustworthy is to make it appear human, attempting to hide the gears of the machine. But the real way to gain trust is through honesty.

I want a machine to tell me when it’s guessing. That won’t make me trust it less. Quite the opposite.

After all, to guess is human.

I tried watching a classic Western this weekend, How The West Was Won. I did not make it far. Let’s just say that in the first few minutes, the Spencer Tracy voiceover that accompanies the sweeping vistas sets out an attitude toward the indigenous population that would not fly today.

It’s one thing to be repulsed by a film from another era, but it’s even more uncomfortable to revisit the films from your own teenage years.

Tim Carmody has written about the real hero of Top Gun:

Iceman’s concern for Maverick and the safety of his fighter unit is totally understandable. He tries, however awkwardly, to discuss Goose’s death with Maverick. There’s no discussion of blame. And when they’re assigned to fly into combat together, Iceman briefly and discreetly raises the issue of Maverick’s fitness to fly with his superior officer and withdraws his concern once a decision is made.

I know someone who didn’t watch Ferris Bueller’s Day Off until they were well into adulthood. Their sympathies lay squarely with Dean Rooney.

And I think we can all agree in hindsight that Walter Peck was completely correct in his assessment of the dangers in Ghostbusters.

Oh, and The Karate Kid was the real bully.

This week, George wrote I’ve fallen out of love with Indiana Jones. Indy’s attitude of “it belongs in a museum” is the same worldview that got the Parthenon Marbles into the British Museum (instead of, y’know, the Parthenon where they belong).

Adrian Hon invites us to imagine what it would be like if the tables were turned. He wrote a short piece of speculative fiction called The Taking of Stonehenge:

We selected these archaeological sites based on their importance to our collective understanding of human and galactic history, and their immediate risk of irreparable harm from pollution, climate change, neglect, and looting. We are sympathetic to claims that preserving these sites in their “original” context is important, but our duty of care outweighs such emotional considerations.

We use metaphors all the time. To quote George Lakoff, we live by them.

We use analogies some of the time. They’re particularly useful when we’re wrapping our heads around something new. By comparing something novel to something familiar, we can make a shortcut to comprehension, or at least, categorisation.

But we need a certain amount of vigilance when it comes to analogies. Just because something is like something else doesn’t mean it’s the same.

With that in mind, here are some ways that people are describing generative machine learning tools. Large language models are like…

• …a blurry JPEG of the web,
• …fly-by-wire avionics,
• …drum machines,
• …an octopus.

I am positively giddy with excitement to tell you about some more speakers you can look forward to at UX London 2023:

• Stacey Mendez, Product and Experience Designer,
• Hannah Smith, Director of Operations at the Green Web Foundation,
• Vitaly Friedman, Creative Lead at Smashing Magazine, and
• Trine Falbe, Ethical Design Consultant at Falbe Consulting.

I have more confirmed speakers but I’m going to be a tease and save them for a separate announcement soon. You can expect more of the same: smart, fabulous people with all kinds of design experience that they’re going to share with you at UX London.

But why wait for another speaker announcement? Get your ticket to UX London 2023 now!

I documented a weird bug with web audio on iOS a while back:

On some pages of The Session, as well as the audio player for tunes (using the Web Audio API) there are also embedded YouTube videos (using the video element). Press play on the audio player; no sound. Press play on the YouTube video; you get sound. Now go back to the audio player and suddenly you do get sound!

It’s almost like playing a video or audio element “kicks” the browser into realising it should be playing the sound from the Web Audio API too.

This was happening on iOS devices set to mute, but I was also getting reports of it happening on devices with the sound on. But it’s that annoyingly intermittent kind of bug that’s really hard to reproduce consistently. Sometimes the sound doesn’t play. Sometimes it does.

I found a workaround but it was really hacky. By playing a one-second long silent mp3 file using audio, you could “kick” the sound into behaving. Then you can use the Web Audio API and it would play consistently.

Well, that’s all changed with the latest release of Mobile Safari. Now what happens is that the Web Audio stuff plays …for one second. And then stops.

I removed the hacky workaround and the Web Audio API started behaving itself again …but your device can’t be set to silent.

The good news is that the Web Audio behaviour seems to be consistent now. It only plays if the device isn’t muted. This restriction doesn’t apply to video and audio elements; they will still play even if your device is set to silent.

This descrepancy between the two different ways of playing audio is kind of odd, but at least now the Web Audio behaviour is predictable.

You can hear the Web Audio API in action by going to any tune on The Session and pressing the “play audio” button.

If you’re a western white guy like me, you’re playing life on its easiest setting. If you’re also a designer, then you should get a ticket to UX London. You can probably get work to pay for it. Share this list of reasons to attend with your boss if you have to.

If, on the other hand, you don’t benefit from the same level of privilege as me, you might still be able to attend UX London 2023. We’re running a scholarship programme.

“We” in this case is Clearleft. But as we also need to at least break even on this event, there are only a limited number of scholarship spots available.

Now, if your company were in a position to pony up some moolah to sponsor more diversity scholarship places, we would dearly love to hear from you—get in touch!

If you think you might qualify for a diversity scholarship, fill in this form before May 19th. We’ll then notify you by May 26th, whether you application is successful or not. And if you’re worried about the additional costs of travel and accommodation, I’m sure we can figure something out.

Wondering if you should apply? It’s hard to define exactly who qualifies for a diversity scholarship, but basically, the more your life experience matches mine, the less qualified you are. If you are a fellow able-bodied middle-aged heterosexual white dude with a comfortable income, do me a favour and don’t apply. Everyone else, go for it.

I’ve been redesigning UX London. I don’t mean the website. I mean the event itself.

Don’t worry, it’s nothing too radical. It’s not like we’re changing the focus of the event, which remains a nerdfest for all things design-related.

But there are plenty of other opportunities for tweaking a conference like this: the format, the timings, the location.

For 2023 we’re not changing the location. Tobacco Dock worked out well for last year’s event, although it is very expensive (then again, so is anywhere decent in London). Last year there were a lot of unknowns in play because it was our first time using the venue. It feels good that this year we don’t have to go through quite as much uncertainty.

The most obvious change to UX London this year is the length. The event will last for two days instead of three.

Running a three-day event was a lot of work, so this helps relieve the pressure. It was also asking a lot of attendees. That’s why we also offered one-day tickets. For the people who couldn’t commit to three days at a conference, there was the option to pick and choose.

But that brought its own issues. Instead of everyone having the same shared experience, the audience was a bit fractured.

Now that we’ve slimmed it down to two days, we’re selling the same two-day tickets for everyone. No more single-day tickets; no more partial attendance. Judging by the way ticket sales have been going, this is a very welcome move.

(Even before announcing any speakers, we had already sold a healthy amount of tickets. That’s probably testament to the great reputation that UX London has built up over the years. I need to make sure I don’t squander that good will. No pressure.)

On the subject of everyone having a shared experience, there’s something about the format of UX London that’s bothered me for a while…

Each day is split into two halves. In the morning, you’ve got inspirational talks. That’s one single track. Then in the afternoon, you’ve got hands-on practical workshops. They happen in parallel.

That makes for a great mix, but the one downside is that the day ends with the audience split across the different workshops.

This year I’m tweaking the format slightly. We’ll still have a single track of talks in the morning followed by multiple workshops in the afternoon, but I’m shortening the workshop length slightly to fit in one last talk at the end of the day. That way, everybody will come back together again after their workshops to participate in a shared experience.

The audience will converge at the beginning of the day, diverge in the afternoon, and this time we’ll converge again at day’s end.

The workshops are a big part of what makes UX London stand out. But they also pose a big design challenge. How do you ensure that everyone gets to attend the workshops they want?

We could make people pick their workshops in advance. But then you end up with the office Christmas dinner party problem—you know the one; everyone has to choose their meal way in advance, and then on the day, no one remembers what they ordered.

Besides, if we make people choose in advance, it’s not fair on people who buy their ticket close to the event.

In the end, using a first-come, first-served strategy on the day has worked out best. But it’s not ideal. You could miss out on attending your first choice of workshop if you’re not fast enough.

This year we’re trying something new. Each afternoon there’ll be a choice of workshops, as always. But this time, it’ll be the same workshops on both days. That way, every attendee gets a second chance to get to the workshops they want. And it’ll help reduce the FOMO—Fear Of Missing Out. It still won’t be possible to attend all the workshops without cloning yourself, but this way, you get to attend half of them.

To recap, here’s the redesigned format for UX London 2023:

• It’s a two-day event on June 22nd and 23rd—there are no individual day tickets.
• There are talks in the morning, workshops in the afternoon, and one final talk at the end of the day.
• The workshops will be repeated each day so nobody misses out on the workshop they want.

The line-up is coming together nicely. I’ve got more confirmed speakers, who I don’t want to reveal just yet. But trust me, you won’t want to miss this!

Oh, and you should probably grab your ticket this week if you haven’t already: early-bird pricing ends on midnight on Friday, February 24th.

This Is My Jam was a lovely website. Created by Hannah and Matt in 2011, it ran until 2015, at which point they had to shut it down. But they made sure to shut it down with care and consideration.

In many ways, This Is My Jam was the antithesis of the prevailing Silicon Valley mindset. Instead of valuing growth and scale above all else, it was deliberately thoughtful. Rather than “maximising engagement”, it asked you to slow down and just share one thing: what piece of music are you really into right now? It was up to you to decide whether “right now” meant this year, this month, this week, or this day.

I used to post songs there sporadically. Here’s a round-up of the twelve songs I posted in 2013. There was always some reason for posting a particular piece of music.

I was reminded of This Is My Jam recently when I logged into Spotify (not something I do that often). As part of the site’s shutdown, you could export all your jams into a Spotify playlist. Here’s mine.

Listening back to these 50 songs all these years later gave me the warm fuzzies.

Push notifications are finally arriving on iOS—hallelujah! Like I said last year, this is my number one wish for the iPhone, though not because I personally ever plan to use the feature:

When I’m evangelising the benefits of building on the open web instead of making separate iOS and Android apps, I inevitably get asked about notifications. As long as mobile Safari doesn’t support them—even though desktop Safari does—I’m somewhat stumped. There’s no polyfill for this feature other than building an entire native app, which is a bit extreme as polyfills go.

With push notifications in mobile Safari, the arguments for making proprietary apps get weaker. That’s good.

The announcement post is a bit weird though. It never uses the phrase “progressive web apps”, even though clearly the entire article is all about progressive web apps. I don’t know if this down to Not-Invented-Here syndrome by the Apple/Webkit team, or because of genuine legal concerns around using the phrase.

Instead, there are repeated references to “Home Screen apps”. This distinction makes some sense though. In order to use web push on iOS, your website needs to be added to the home screen.

I think that would be fair enough, if it weren’t for the fact that adding a website to the home screen remains such a hidden feature that even power users would be forgiven for not knowing about it. I described the steps here:

1. Tap the “share” icon. It’s not labelled “share.” It’s a square with an arrow coming out of the top of it.
2. A drawer pops up. The option to “add to home screen” is nowhere to be seen. You have to pull the drawer up further to see the hidden options.
3. Now you must find “add to home screen” in the list

• Copy
• Add to Reading List
• Add Bookmark
• Add to Favourites
• Find on Page
• Add to Home Screen
• Markup
• Print

As long as this remains the case, we can expect usage of web push on iOS to be vanishingly low. Hardly anyone is going to add a website to their home screen when their web browser makes it so hard.

If you’d like to people to install your progressive web app, you’ll almost certainly need to prompt people to do so. Here’s the page I made on thesession.org with instructions on how to add to home screen. I link to it from the home page of the site.

I wish that pages like that weren’t necessary. It’s not the best user experience. But as long as mobile Safari continues to bury the home screen option, we don’t have much choice but to tackle this ourselves.

Please put your fingers on the desk in front of you and move them up and down rapidly in the manner of a snare drum…

I’m very happy to announce the first four speakers for UX London 2023:

• Imran Afzal, Principal Designer at Co-op Digital,
• Vimla Appadoo, Head of Experience at Culture Shift,
• Daniel Burka, Director of Design at Resolve to Save Lives, and
• Mansi Gupta, Founder of Unconform.

This is shaping up nicely! You can expect some more speaker announcements before too long.

But don’t wait too long to get your ticket—early-bird pricing ends this month on Friday, February 24th. Then the price goes up by £200. If you need to convince your boss, here are some reasons to attend.

I very much look forward to seeing you at Tobacco Dock on June 22nd and 23rd this year!

I’ve mentioned before that I’m not a fan of initialisms and acronyms. They can be exclusionary.

It bothers me doubly when everyone is talking about AI.

First of all, the term 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.

Secondly, there’s the assumption that everyone understands the abbreviation. I guess that’s generally a safe assumption, but sometimes AI could refer to something other than artificial intelligence.

In countries with plenty of pastoral agriculture, if someone works in AI, it usually means they’re going from farm to farm either extracting or injecting animal semen. AI stands for artificial insemination.

I think that abbreviation might work better for the kind of things currently described as using AI.

We were discussing this hot topic at work recently. Is AI coming for our jobs? The consensus was maybe, but only the parts of our jobs that we’re more than happy to have automated. Like summarising some some findings. Or perhaps as a kind of lorem ipsum generator. Or for just getting the ball rolling with a design direction. As Terence puts it:

Midjourney is great for a first draft. If, like me, you struggle to give shape to your ideas then it is nothing short of magic. It gets you through the first 90% of the hard work. It’s then up to you to refine things.

That’s pretty much the conclusion we came to in our discussion at Clearleft. There’s no way that we’d use this technology to generate outputs for clients, but we certainly might use it to generate inputs. It’s like how we’d do a quick round of sketching to get a bunch of different ideas out into the open. Terence is spot on when he says:

Midjourney lets me quickly be wrong in an interesting direction.

To put it another way, using a large language model could be a way of artificially injecting some seeds of ideas. Artificial insemination.

So now when I hear people talk about using AI to create images or articles, I don’t get frustrated. Instead I think, “Using artificial insemination to create images or articles? Yes, that sounds about right.”

I was chatting with my new colleague Alex yesterday about a link she had shared in Slack. It was the Nielsen Norman Group’s annual State of Mobile User Experience report.

There’s nothing too surprising in there, other than the mention of Apple’s app clips and Google’s instant apps.

Remember those?

Me neither.

Perhaps I lead a sheltered existence, but as an iPhone user, I don’t think I’ve come across a single app clip in the wild.

I remember when they were announced. I was quite worried about them.

See, the one thing that the web can (theoretically) offer that native can’t is instant access to a resource. Go to this URL—that’s it. Whereas for a native app, the flow is: go to this app store, find the app, download the app.

(I say that the benefit is theoretical because the website found at the URL should download quickly—the reality is that the bloat of “modern” web development imperils that advantage.)

App clips—and instant apps—looked like a way to route around the convoluted install process of native apps. That’s why I was nervous when they were announced. They sounded like a threat to the web.

In reality, the potential was never fulfilled (if my own experience is anything to go by). I wonder why people didn’t jump on app clips and instant apps?

Perhaps it’s because what they promise isn’t desirable from a business perspective: “here’s a way for users to accomplish their tasks without downloading your app.” Even though app clips can in theory be a stepping stone to installing the full app, from a user’s perspective, their appeal is the exact opposite.

Or maybe they’re just too confusing to understand. I think there’s an another technology that suffers from the same problem: progressive web apps.

Hear me out. Progressive web apps are—if done well—absolutely amazing. You get all of the benefits of native apps in terms of UX—they even work offline!—but you retain the web’s frictionless access model: go to a URL; that’s it.

So what are they? Are they websites? Yes, sorta. Are they apps? Yes, sorta.

That’s confusing, right? I can see how app clips and instant apps sound equally confusing: “you can use them straight away, like going to a web page, but they’re not web pages; they’re little bits of apps.”

I’m mostly glad that app clips never took off. But I’m sad that progressive web apps haven’t taken off more. I suspect that their fates are intertwined. Neither suffer from technical limitations. The problem they both face is inertia:

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

True of progressive web apps. Equally true of app clips.

But when I was chatting to Alex, she made me look at app clips in a different way. She described a situation where somebody might need to interact with some kind of NFC beacon from their phone. Web NFC isn’t supported in many browsers yet, so you can’t rely on that. But you don’t want to make people download a native app just to have a quick interaction. In theory, an app clip—or instant app—could do the job.

In that situation, app clips aren’t a danger to the web—they’re polyfills for hardware APIs that the web doesn’t yet support!

I love having my perspective shifted like that.

The specific situations that Alex and I were discussing were in the context of museums. Musuems offer such interesting opportunities for the physical and the digital to intersect.

Remember the pen from Cooper Hewitt? Aaron spoke about it at dConstruct 2014—a terrific presentation that’s well worth revisiting and absorbing.

The other dConstruct talk that’s very relevant to this liminal space between the web and native apps is the 2012 talk from Scott Jenson. I always thought the physical web initiative had a lot of promise, but it may have been ahead of its time.

I loved the thinking behind the physical web beacons. They were deliberately dumb, much like the internet itself. All they did was broadcast a URL. That’s it. All the smarts were to be found at the URL itself. That meant a service could get smarter over time. It’s a lot easier to update a website than swap out a piece of hardware.

But any kind of technology that uses Bluetooth, NFC, or other wireless technology has to get over the discovery problem. They’re invisible technologies, so by default, people don’t know they’re even there. But if you make them too discoverable— intrusively announcing themselves like one of the commercials in Minority Report—then they’re indistinguishable from spam. There’s a sweet spot of discoverability right in the middle that’s hard to get right.

Over the past couple of years—accelerated by the physical distancing necessitated by The Situation—QR codes stepped up to the plate.

They still suffer from some discoverability issues. They’re not human-readable, so you can’t be entirely sure that the URL you’re going to go to isn’t going to be a Rick Astley video. But they are visible, which gives them an advantage over hidden wireless technologies.

They’re cheaper too. Printing a QR code sticker costs less than getting a plastic beacon shipped from China.

QR codes turned out to be just good enough to bridge the gap between the physical and digital for those one-off interactions like dining outdoors during a pandemic:

I can see why they chose the web over a native app. Online ordering is the only way to place your order at this place. Telling people “You have to go to this website” …that seems reasonable. But telling people “You have to download this app” …that’s too much friction.

Ironically, the nail in the coffin for app clips and instant apps might’ve been hammered in by Apple and Google when they built QR-code recognition into their camera software.

I had a 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.”

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

It also made me stop and think about how amazing it was that we were having the call in the first place. I remembered Arthur C. Clarke’s predictions from 1964:

I’m thinking of the incredible breakthrough which has been possible by developments in communications, particularly the transistor and, above all, the communications satellite.

These things will make possible a world in which we can be in instant contact with each other wherever we may be, where we can contact our friends anywhere on Earth even if we don’t know their actual physical location.

It will be possible in that age—perhaps only 50 years from now—for a man to conduct his business from Tahiti or Bali just as well as he could from London.

The casual sexism of assuming that it would be a “man” conducting business hasn’t aged well. And it’s not the communications satellite that enabled my video call, but old-fashioned undersea cables, many in the same locations as their telegraphic antecedents. But still; not bad, Arthur.

After my call, I caught up on some email. There was a new newsletter from Ariel who’s currently in Antarctica.

Just thinking about the fact that I know someone who’s in Antarctica—who sent me a postcard from Antarctica—gave me another rush of feeling like I was living in the future. As I started to read the contents of the latest newsletter, that feeling became even more specific. Doesn’t this sound exactly like something straight out of a late ’80s/early ’90s cyberpunk novel?

Four of my teammates head off hiking towards the mountains to dig holes in the soil in hopes of finding microscopic animals contained within them. I hang back near the survival bags with the remaining teammate and begin unfolding my drone to get a closer look at the glaciers. After filming the textures of the land and ice from multiple angles for 90 minutes, my batteries are spent, my hands are cold and my stomach is growling. I land the drone, fold it up into my bright yellow Pelican case, and pull out an expired granola bar to keep my hunger pangs at bay.

Forms on the web are an opportunity to make big improvements to the user experience with very little effort. The effort can be as little as sprinkling in a smattering of humble HTML attributes. But the result can be a turbo-charged experience for the user, allowing them to sail through their task.

This is particularly true on mobile devices where people have to fill in forms using a virtual keyboard. Any improvement you can make to their flow is worth investigating. But don’t worry: you don’t need to add a complex JavaScript library or write convoluted code. Well-written HTML will get you very far.

If you’re using the right input type value, you’re most of the way there. Browsers on mobile devices can use this value to infer which version of the virtual keyboard is best. So think beyond the plain text value, and use search, email, url, tel, or number when they’re appropriate.

But you can offer more hints to those browsers. Here are three attributes you can add to input elements. All three are enumerated values, which means they have a constrained vocabulary. You don’t need to have these vocabularies memorised. You can look them when you need to.

inputmode

The inputmode attribute is the most direct hint you can give about the virtual keyboard you want. Some of the values are redundant if you’re already using an input type of search, email, tel, or url.

But there might be occasions where you want a keyboard optimised for numbers but the input should also accept other characters. In that case you can use an input type of text with an inputmode value of numeric. This also means you don’t get the spinner controls on desktop browsers that you’d normally get with an input type of number. It can be quite useful to supress the spinner controls for numbers that aren’t meant to be incremented.

If you combine inputmode="numeric" with pattern="[0-9]", you’ll get a numeric keypad with no other characters.

The list of possible values for inputmode is text, numeric, decimal, search, email, tel, and url.

enterkeyhint

Whereas the inputmode attribute provides a hint about which virtual keyboard to show, the enterkeyhint attribute provides an additional hint about one specific key on that virtual keyboard: the enter key.

For search forms, you’ve got an enterkeyhint option of search, and for contact forms, you’ve got send.

The enterkeyhint only changes the labelling of the enter key. On some browsers that label is text. On others it’s an icon. But the attribute by itself doesn’t change the functionality. Even though there are enterkeyhint values of previous and next, by default the enter key will still submit the form. So those two values are less useful on long forms where the user is going from field to field, and more suitable for a series of short forms.

The list of possible values is enter, done, next, previous, go, search, and send.

autocomplete

The autocomplete attribute doesn’t have anything to do with the virtual keyboard. Instead it provides a hint to the browser about values that could pre-filled from the user’s browser profile.

Most browsers try to guess when they can they do this, but they don’t always get it right, which can be annoying. If you explicitly provide an autocomplete hint, browsers can confidently prefill the appropriate value.

Just think about how much time this can save your users!

There’s a name value you can use to get full names pre-filled. But if you have form fields for different parts of names—which I wouldn’t recommend—you’ve also got:

• given-name,
• additional-name,
• family-name,
• nickname,
• honorific-prefix, and
• honorific-suffix.

You might be tempted to use the nickname field for usernames, but no need; there’s a separate username value.

As with names, there’s a single tel value for telephone numbers, but also an array of sub-values if you’ve split telephone numbers up into separate fields:

• tel-country-code,
• tel-national,
• tel-area-code,
• tel-local, and
• tel-extension.

There’s a whole host of address-related values too:

• street-address,
• address-line1,
• address-line2, and
• address-line3, but also
• address-level1,
• address-level2,
• address-level3, and
• address-level4.

If you have an international audience, addresses can get very messy if you’re trying to split them into separate parts like this.

There’s also postal-code (that’s a ZIP code for Americans), but again, if you have an international audience, please don’t make this a required field. Not every country has postal codes.

Speaking of countries, you’ve got a country-name value, but also a country value for the country’s ISO code.

Remember, the autocomplete value is specifically for the details of the current user. If someone is filling in their own address, use autocomplete. But if someone has specified that, say, a billing address and a shipping address are different, that shipping address might not be the address associated with that person.

On the subject of billing, if your form accepts credit card details, definitely use autocomplete. The values you’ll probably need are:

• cc-name for the cardholder,
• cc-number for the credit card number itself,
• cc-exp for the expiry date, and
• cc-csc for the security again.

Again, some of these values can be broken down further if you need them: cc-exp-month and cc-exp-year for the month and year of the expiry date, for example.

The autocomplete attribute is really handy for log-in forms. Definitely use the values of email or username as appropriate.

If you’re using two-factor authentication, be sure to add an autocomplete value of one-time-code to your form field. That way, the browser can offer to prefill a value from a text message. That saves the user a lot of fiddly copying and pasting. Phil Nash has more details on the Twilio blog.

Not every mobile browser offers this functionality, but that’s okay. This is classic progressive enhancement. Adding an autocomplete value won’t do any harm to a browser that doesn’t yet understand the value.

Use an autocomplete value of current-password for password fields in log-in forms. This is especially useful for password managers.

But if a user has logged in and is editing their profile to change their password, use a value of new-password. This will prevent the browser from pre-filling that field with the existing password.

That goes for sign-up forms too: use new-password. With this hint, password managers can offer to automatically generate a secure password.

There you have it. Three little HTML attributes that can help users interact with your forms. All you have to do was type a few more characters in your input elements, and users automatically get a better experience.

This is a classic example of letting the browser do the hard work for you. As Andy puts it, be the browser’s mentor, not its micromanager:

Give the browser some solid rules and hints, then let it make the right decisions for the people that visit it, based on their device, connection quality and capabilities.

A few years ago, I wrote about how much I enjoyed the book Aurora by Kim Stanley Robinson.

Not everyone liked that book. A lot of people were put off by its structure, in which the dream of interstellar colonisation meets the harsh truth of reality and the book follows where that leads. It pours cold water over the very idea of humanity becoming interplanetary.

But our own solar system is doable, right? I mean, Kim Stanley Robinson is the guy who wrote the Mars trilogy and 2312, both of which depict solar system colonisation in just a few centuries.

I wonder if the author might regret the way that some have taken his Mars trilogy as a sort of manual, Torment Nexus style. Kim Stanley Robinson is very much concerned with this planet in this time period, but others use his work to do the opposite.

But the backlash to Mars has begun.

Maciej wrote Why Not Mars:

The goal of this essay is to persuade you that we shouldn’t send human beings to Mars, at least not anytime soon. Landing on Mars with existing technology would be a destructive, wasteful stunt whose only legacy would be to ruin the greatest natural history experiment in the Solar System. It would no more open a new era of spaceflight than a Phoenician sailor crossing the Atlantic in 500 B.C. would have opened up the New World. And it wouldn’t even be that much fun.

Manu Saadia is writing a book about humanity in space, and he has a corresponding newsletter called Against Mars: Space Colonization and its Discontents:

What if space colonization was merely science-fiction, a narrative, or rather a meta-narrative, a myth, an ideology like any other? And therefore, how and why did it catch on? What is so special and so urgent about space colonization that countless scientists, engineers, government officials, billionaire oligarchs and indeed, entire nations, have committed work, ingenuity and treasure to make it a reality.

What if, and hear me out, space colonization was all bullshit?

I mean that quite literally. No hyperbole. Once you peer under the hood, or the nose, of the rocket ship, you encounter a seemingly inexhaustible supply of ghoulish garbage.

Two years ago, Shannon Stirone went into the details of why Mars Is a Hellhole

The central thing about Mars is that it is not Earth, not even close. In fact, the only things our planet and Mars really have in common is that both are rocky planets with some water ice and both have robots (and Mars doesn’t even have that many).

Perhaps the most damning indictment of the case for Mars colonisation is that its most ardent advocate turns out to be an idiotic small-minded eugenicist who can’t even run a social media company, much less a crewed expedition to another planet.

But let’s be clear: we’re talking here about the proposition of sending humans to Mars—ugly bags of mostly water that probably wouldn’t survive. Robots and other uncrewed missions in our solar system …more of that, please!

I posted 1057 times on adactio in 2022.

That’s a bit more than in 2021.

November was the busiest month with 137 posts.

February was the quietest with 65 posts.

• I blogged 91 times during the year.
• I shared 382 links.
• I posted 583 notes.

That included about 237 notes with photos and 214 replies.

I published one article, the transcript of my talk, In And Out Of Style.

I watched an awful lot of television but managed to read 25 books.

Elsewhere, I huffduffed 130 audio files and added 55 tune settings on The Session in 2022.

I spoke at ten events.

I travelled within Europe and the USA to a total of 18 destinations.

My trip to California went well. It was bookended with a few days in San Diego on either end. I relished the opportunity to hang with family and soak up the sunshine.

In the middle was my outing to San Francisco for An Event Apart. There were some great talks: Krystal talking about onboarding, Miriam blowing my mind with cascade layers, Eric diving deep into the :has() selector, and David closing out the show with a superb call to arms.

I gave my talk on declarative design at the very start of the event, just the way I like it. I was able to relax and enjoy all the other talks without having mine on my mind.

The talk went down well. I thought maybe I might have the chance to repeat it at another An Event Apart sometime in 2023.

But that won’t happen. An Event Apart has closed its doors:

Seventeen years ago, in December 2005, we held our first conference in Philadelphia. The event we just held in San Francisco was our last.

Whenever I was invited to speak at An Event Apart, I always responded in the affirmative and always said it was an honour to be asked. I meant it every time.

It wasn’t just me. Ask anyone who’s spoken at An Event Apart. They’ll all tell you the same thing. It was an honour. It was also a bit intimidating. There was a definite feeling that you had to bring your A game. And so, everyone did. Of course that just contributed to the event’s reputation which only reinforced the pressure to deliver a top-notch presentation.

I’m really going to miss An Event Apart. I mean, I get why all good things must come to an end (see also: dConstruct), but it feels like the end of an era.

My first time speaking at An Event Apart was in 2007. My last time was in San Francisco this month.

Thank you, Eric, Jeffrey, Toby, Marci, and the entire An Event Apart crew. It has been my privilege to play a small part in your story.

2007

Chicago

Be Pure. Be Vigilant. Behave

2008

San Francisco

Pattern In The Process

2009

Boston

Future Shock Treatment

2010

Seattle, Boston, Minneapolis, Washington DC, San Diego

Paranormal Interactivity

2011

Seattle, Boston, Atlanta, Minneapolis, Washington DC, San Francisco

Design Principles

2012

Austin

The Spirit Of The Web

2013

Atlanta, Washington DC, Chicago, Austin, San Francisco

The Long Web

2014

Seattle, San Diego, Chicago, Orlando, San Francisco

Enhance!

2015

Seattle, Austin, San Francisco

Resilience

2016

Seattle, Boston, Orlando, San Francisco

Resilience, Evaluating Technology

2017

Seattle, Denver

Evaluating Technology

2018

Seattle, Boston

The Way Of The Web

2019

Seattle, Chicago, San Francisco

Going Offline

2020

Online

Design Principles For The Web

2021

Online

The State Of The Web

2022

Online, San Francisco

In And Out Of Style

Declarative Design