Tags: pr

I must admit, when Jake told me he was leaving Google, I got very worried about the future of the View Transitions API.

To recap: Chrome shipped support for the API, but only for single page apps. That had me worried:

If the View Transitions API works across page navigations, it could be the single best thing to happen to the web in years.

If the View Transitions API only works for single page apps, it could be the single worst thing to happen to the web in years.

Well, the multi-page version still hasn’t yet shipped in Chrome stable, but it is available in Chrome Canary behind a flag, so it looks like it’s almost here!

Robin took the words out of my mouth:

Anyway, even this cynical jerk is excited about this thing.

Are you the kind of person who flips feature flags on in nightly builds to test new APIs?

Me neither.

But I made an exception for the View Transitions API. So did Dave:

I think the most telling predictor for the success of the multi-page View Transitions API – compared to all other proposals and solutions that have come before it – is that I actually implemented this one. Despite animations being my bread and butter for many years, I couldn’t be arsed to even try any of the previous generation of tools.

Dave’s post is an excellent step-by-step introduction to using view transitions on your website. To recap:

Enable these two flags in Chrome Canary:

chrome://flags#view-transition
chrome://flags#view-transition-on-navigation

Then add this meta element to the head of your website:

<meta name="view-transition" content="same-origin">

You could stop there. If you navigate around your site, you’ll see that the navigations now fade in and out nicely from one page to another.

But the real power comes with transitioning page elements. Basically, you want to say “this element on this page should morph into that element on that page.” And when I say morph, I mean morph. As Dave puts it:

Behind the scenes the browser is rasterizing (read: making an image of) the before and after states of the DOM elements you’re transitioning. The browser figures out the differences between those two snapshots and tweens between them similar to Apple Keynote’s “Magic Morph” feature, the liquid metal T-1000 from Terminator 2: Judgement Day, or the 1980s cartoon series Turbo Teen.

If those references are lost on you, how about the popular kids book series Animorphs?

Some classic examples would be:

• A thumbnail of a video on one page morphs into the full-size video on the next page.
• A headline and snippet of an article on one page morphs into the full article on the next page.

I’ve added view transitions to The Session. Where I’ve got index pages with lists of titles, each title morphs into the heading on the next page.

Again, Dave’s post was really useful here. Each transition needs a unique name, so I used Dave’s trick of naming each transition with the ID of the individual item being linked to.

In the recordings section, for example, there might be a link like this on the index page:

<a href="/recordings/7812" style="view-transition-name: recording-7812">The Banks Of The Moy</a>

Which, if you click on it, takes you to the page with this heading:

<h1><span style="view-transition-name: recording-7812">The Banks Of The Moy</span></h1>

Why the span? Well, like Dave, I noticed some weird tweening happening between block and inline elements. Dave solved the problem with width: fit-content on the block-level element. I just stuck in an extra inline element.

Anyway, the important thing is that the name of the view transition matches: recording-7812.

I also added a view transition to pages that have maps. The position of the map might change from page to page. Now there’s a nice little animation as you move from one page with a map to another page with a map.

That’s all good, but I found myself wishing that I could just have those enhancements. Every single navigation on the site was triggering a fade in and out—the default animation. I wondered if there was a way to switch off the default fading.

There is! That default animation is happening on a view transition named root. You can get rid of it with this snippet of CSS:

::view-transition-image-pair(root) {
  isolation: auto;
}
::view-transition-old(root),
::view-transition-new(root) {
  animation: none;
  mix-blend-mode: normal;
  display: block;
}

Voila! Now only the view transitions that you name yourself will get applied.

You can adjust the timing, the easing, and the animation properites of your view transitions. Personally, I was happy with the default morph.

In fact, that’s one of the things I like about this API. It’s another good example of declarative design. I say what I want to happen, but I don’t need to specify the details. I’ll let the browser figure all that out.

That’s what’s got me so excited about this API. Yes, it’s powerful. But just as important, it’s got a very low barrier to entry.

Chris has gathered a bunch of examples together in his post Early Days Examples of View Transitions. Have a look around to get some ideas.

If you like what you see, I highly encourage you to add view transitions to your website now.

“But wait,” I hear you cry, “this isn’t supported in any public-facing browser yet!”

To which, I respond “So what?” It’s a perfect example of progressive enhancement. Adding one meta element and a smidgen of CSS will do absolutely no harm to your website. And while no-one will see your lovely view transitions yet, once browsers do start shipping with support for the API, your site will automatically get better.

Your website will be enhanced. Progressively.

Update: Simon Pieters quite rightly warns against adding view transitions to live sites before the API is done:

in general, using features before they ship in a browser isn’t a great idea since it can poison the feature with legacy content that might break when the feature is enabled. This has happened several times and renames or so were needed.

Good point. I must temper my excitement with pragmatism. Let me amend my advice:

I highly encourage you to experiment with view transitions on your website now.

Back in November of last year I announced that UX London would be returning in 2023 and that I’d be curating the line-up again. That’s where I’ve been putting a lot of my energy over the last six months.

The line-up is complete. If I step back and try to evaluate it objectively, I’ve gotta say …hot damn, that’s a fine roster of speakers!

Imran Afzal, Vimla Appadoo, Daniel Burka, Trine Falbe, Vitaly Friedman, Mansi Gupta, Stephen Hay, Asia Hoe, Amy Hupe, Paul Robert Lloyd, Stacey Mendez, Ignacia Orellana, Stefanie Posavec, Hannah Smith, and David Dylan Thomas.

Take a look at the complete schedule—a terrific mix of thought-provoking talks and practical hands-on workshops.

On day one, you’ve got these talks:

• Designing your design process,
• Thinking differently about digital sustainability,
• Let’s choose empathy,
• The lies we tell ourselves about design systems, and
• What if people weren’t the product? Building a web that loves humanity.

Then on day two:

• The necessity and practice of women-centric design,
• Time team: Documenting decisions and marking milestones,
• User experience beyond screens,
• Can designers save lives? Not by themselves, and
• Ghosts in the machine: AI, design, and ethics.

And that’s just the talks! You’ve also got these four excellent workshops on both days:

• Practical, ethical design,
• Designing for complex UIs,
• Strategies for creating and evolving design systems, and
• Dataviz sketching session.

That’s a lot of great stuff packed into two days!

In case you haven’t guessed, I am very excited about this year’s UX London. I would love to see you there.

As an appreciation for you putting up with my child-like excitement, I’d like to share a discount code with you. You can get 20%—that’s one fifth!—off the ticket price using the code CLEARLEFT20.

But note that the standard ticket pricing ends on Friday, May 26th so use that code in the next week to get the most bang for your buck. After that, there’ll only be last-chance tickets, which cost more.

Looking forward to seeing you at Tobacco Dock on June 22nd and 23rd!

I was up in Edinburgh for the past few days at the Design It; Build It conference.

I was supposed to come back on Saturday but then the train strikes were announced so I changed my travel plans to avoid crossing a picket line, which gave me an extra day to explore Auld Reekie.

I spoke at DIBI last year so this time I was there in a different capacity. I was the host. That meant introducing the speakers and asking them questions after their talks.

I’m used to hosting events now, what with UX London and Leading Design. But I still get nervous beforehand. At least with a talk you can rehearse and practice. With hosting, it’s all about being nimble and thinking on your feet.

I had to pay extra close attention to each talk, scribbling down potential questions to ask. It’s similar to the feeling I get when I’m liveblogging talks.

There were some line-up changes and schedule adjustments along the way, but everything went super smoothly. I pride myself on running a tight ship so the timings were spot-on.

When it came to the questions, I tried to probe under the skin of each presentation. For some talks, that involved talking shop—the finer points of user research or the design process, say. But for the big-picture talks, I made sure to get each speaker to defend their position. So after Dan Makoski’s kumbaya-under-capitalism talk, I gave him a good grilling. Same with Philip Lockwood-Holmes who gave me permission beforehand to be merciless with him.

It was all quite entertaining. Alas, I think I may have put the fear of God into the other speakers who saw me channeling my inner Jeremy Paxman. But they needn’t have worried. I also lobbed some softballs. Like when I asked Levon Sharrow from Patagonia if there was such thing as ethical consumption under capitalism.

I had fun, but I was also aware of that fine line between being clever and being an asshole. Even though part of my role was to play devil’s advocate, I tried to make sure I was never punching down.

All in all, an excellent couple of days spent in good company.

Hosting was hard work, but very rewarding. I’ve come to realise it’s one of those activities that comes relatively easy to me, but it is very hard (and stressful) for others. And I’m pretty gosh-darned good at it too, false modesty bedamned.

So if you’re running an event but the thought of hosting it fills you with dread, we should talk.

There are two kinds of time-travel stories.

There are time-travel stories that explore the many-worlds hypothesis. Going back in time and making a change forks the universe. But the universe is constantly forking anyway. So effectively the time travel is a kind of universe-hopping (there’s a big crossover here with the alternative history subgenre).

The problem with multiverse stories is that there’s always a reset available. No matter how bad things get, there’s a parallel universe where everything is hunky dory.

The other kind of time travel story explores the idea of a block universe. There is one single timeline.

This is what you’ll find in Tenet, for example, or for a beautiful reduced test case, the Ted Chiang short story What’s Expected Of Us. That gets straight to the heart of the biggest implication of a block universe—the lack of free will.

There’s no changing what has happened or what will happen. In fact, the very act of trying to change the past often turns out to be the cause of what you’re trying to prevent in the present (like in Twelve Monkeys).

I’ve often referred to these single-timeline stories as being like Greek tragedies. But only recently—as I’ve been reading quite a bit of Greek mythology—have I realised that the reverse is also true:

Greek tragedies are time-travel stories.

Hear me out…

Time-travel stories aren’t actually about physically travelling in time. That’s just a convenience for the important part—information travelling in time. That’s at the heart of most time-travel stories; informaton from the future travelling back to the past.

William Gibson’s The Peripheral—very much a many-worlds story with its alternate universe “stubs”—takes this to its extreme. Nothing phyiscal ever travels in time. But in an age of telecommuting, nothing has to. Our time travellers are remote workers.

That book also highlights the power dynamics inherent in information wealth. Knowledge of the future gives you an advantage that you can exploit in the past. This is what Mark Twain’s Connecticut yankee does in King Arthur’s court.

This power dynamic is brilliantly inverted in Octavia Butler’s brilliant Kindred. No amount of information can help you if your place in society is determined by the colour of your skin.

Anyway, the point is that information flow is what matters in time-travel stories. Therefore any story where information travels backwards in time is a time-travel story.

That includes any story with a prophecy. A prophecy is information about the future, like:

Oedipus will kill his father and marry his mother.

You can try to change your fate, but you’ll just end up triggering it instead.

Greek tragedies are time-travel stories.

Spring is arriving. It’s just taking its time.

There are little signs. Buds on the trees. The first asparagus of the year. Daffodils. Changing the clocks. A stretch in the evenings. But the weather remains, for the most part, chilly and grim.

Reality is refusing to behave like a fast-forward montage leading up to to a single day when you throw open the curtains and springtime is suddenly there in all its glory.

That’s okay. I can wait. I’ve had a lot of practice over the past three years. We all have. Staying home, biding time, saving lives.

But hunkering down during The Situation isn’t like taking shelter during an air raid. There isn’t a signal that sounds to indicate “all clear!” It’s more like going from Winter to Spring. It’s slow, almost impercetible. But it is happening.

I’ve noticed a subtle change in my risk assessment over the past few months. I still think about COVID-19. I still factor it into my calculations. But it’s no longer the first thing I think of.

That’s a subtle change. It doesn’t seem like that long ago when COVID was at the forefront of my mind, especially if I was weighing up an excursion. Is it worth going to that restaurant? How badly do I want to go to that gig? Should I go to that conference?

Now I find myself thinking of COVID as less of a factor in my decision-making. It’s still there, but it has slowly slipped down the ranking.

I know that other people feel differently. For some people, COVID slipped out of their minds long ago. For others, it’s still very much front and centre. There isn’t a consensus on how to evaluate the risks. Like I said:

It’s like when you’re driving and you think that everyone going faster than you is a maniac, and everyone going slower than you is an idiot.

COVID-19 isn’t going away. But perhaps The Situation is.

The Situation has been gradually fading away. There isn’t a single moment where, from one day to the next, we can say “this marks the point where The Situation ended.” Even if there were, it would be a different moment for everyone.

As of today, the COVID-19 app officially stops working. Perhaps today is as good a day as any to say Spring has arrived. The season of rebirth.

The most cartoonish misrepresentation of progressive enhancement is that it means making everything work without JavaScript.

No. Progressive enhancement means making sure your core functionality works without JavaScript.

In my book Resilient Web Design, I quoted Wilto:

Lots of cool features on the Boston Globe don’t work when JS breaks; “reading the news” is not one of them.

That’s an example where the core functionality is readily identifiable. It’s a newspaper. The core functionality is reading the news.

It isn’t always so straightforward though. A lot of services that self-identify as “apps” will claim that even their core functionality requires JavaScript.

Surely I don’t expect Gmail or Google Docs to provide core functionality without JavaScript?

In those particular cases, I actually do. I believe that a textarea in a form would do the job nicely. But I get it. That might take a lot of re-engineering.

So how about this compromise…

Your app should work in a read-only mode without JavaScript.

Without JavaScript I should still be able to read my email in Gmail, even if you don’t let me compose, reply, or organise my messages.

Without JavaScript I should still be able to view a document in Google Docs, even if you don’t let me comment or edit the document.

Even with something as interactive as Figma or Photoshop, I think I should still be able to view a design file without JavaScript.

Making this distinction between read-only mode and read/write mode could be very useful, especially at the start of a project.

Begin by creating the read-only mode that doesn’t require JavaScript. That alone will make for a solid foundation to build upon. Now you’ve built a fallback for any unexpected failures.

Now start adding the read/write functionally. You’re enhancing what’s already there. Progressively.

Heck, you might even find some opportunities to provide some read/write functionality that doesn’t require JavaScript. But if JavaScript is needed, that’s absolutely fine.

So if you’re about to build a web app and you’re pretty sure it requires JavaScript, why not pause and consider whether you can provide a read-only version.

Robin penned a little love letter to the details element. I agree. It is a joyous piece of declarative power.

That said, don’t go overboard with it. It’s not a drop-in replacement for more complex widgets. But it is a handy encapsulation of straightforward progressive disclosure.

Just last week I added a couple of more details elements to The Session …kind of. There’s a bit of server-side conditional logic involved to determine whether details is the right element.

When you’re looking at a tune, one of the pieces of information you see is how many recordings there of that tune. Now if there are a lot of recordings, then there’s some additional information about which other tunes this one gets recorded with. That information is extra. Mere details, if you will.

You can see it in action on this tune listing. Thanks to the details element, the extra information is available to those who want it, but by default that information is tucked away—very handy for not clogging up that part of the page.

<details>
<summary>There are 181 recordings of this tune.</summary>
This tune has been recorded together with
<ul>
<li>…</li>
<li>…</li>
<li>…</li>
</ul>
</details>

Likewise, each tune page includes any aliases for the tune (in Irish music, the same tune can have many different titles—and the same title can be attached to many different tunes). If a tune has just a handful of aliases, they’re displayed in situ. But once you start listing out more than twenty names, it gets overwhelming.

The details element rides to the rescue once again.

Compare the tune I mentioned above, which only has a few aliases, to another tune that is known by many names.

Again, the main gist is immediately available to everyone—how many aliases are there? But if you want to go through them all, you can toggle that details element open.

You can effectively think of the summary element as the TL;DR of HTML.

<details>
<summary>There are 31 other names for this tune.</summary>
<p>Also known as…</p>
</details>

There’s another classic use of the details element: frequently asked questions. In the case of The Session, I’ve marked up the house rules and FAQs inside details elements, with the rule or question as the summary.

But there’s one house rule that’s most important (“Be civil”) so that details element gets an additional open attribute.

<details open>
<summary>Be civil</summary>
<p>Contributions should be constructive and polite, not mean-spirited or contributed with the intention of causing trouble.</p>
</details>