Some great ideas for view transitionts in here! Also:
If you look at any of the examples on a browser that does not support them, the pages still function just fine. The transitions are an extra that’s layered on top if and when your browser supports them. Another concrete example of progressive enhancement in practice.
In just a couple of weeks, I’ll be heading to Bristol for Pixel Pioneers. The line-up looks really, really good …with the glaring exception of the opening talk, which I’ll be delivering. But once that’s done, I’m very much looking forward to enjoying the rest of the day’s talks.
There are still tickets available if you fancy joining me.
This will be my second time speaking at this conference. I spoke at the inaugural conference back in 2017 when I gave a talk called Evaluating Technology. This time my talk is called Declarative Design.
A few weeks back, Oliver asked me some questions about my upcoming talk. I figured I’d post my answers here…
Welcome back to Pixel Pioneers! You return with another keynote - how do you manage to stay so ever-enthusiastic about designing for the web?
Well, I’d say my enthusiasm is mixed with frustration. And that’s always been the case. Just as I’ve always found new things that excite me about the World Wide Web, there are just as many things that upset me.
But that’s okay. Both forces can be motivating. When I find myself writing a blog post or preparing a talk, the impetus might be “This is so cool! Check this out!” or it might be “This is so maddening! What’s happening!?” …or perhaps a mix of both.
But to answer your question, the World Wide Web never stays still so there’s always something to get excited about. Equally, the longer the web exists, the more sense it makes to examine the fundamental bedrock—HTML, accessibility,progressive enhancement—and see how they’re just as important as ever. And that’s also something to get excited about!
Without too many spoilers, what can we expect to take away from your talk?
I’m hoping to provide people with a lens that they can use to examine their tools, processes, and approaches to designing for the web. It’s a fairly crude lens—it divides the world into a binary split that I’ve borrowed from the world of programming; imperative and declarative languages. But it’s a surprisingly thought-provoking angle.
Along the way I’ll also be pointing out some of the incredible things that we can do with CSS now. In the past few years there’s been an explosion in capabilities.
But this won’t be a code-heavy presentation. It’s mostly about the ideas. I’ll be referencing some projects by other people that I’m very excited by.
What other web design and development tools, techniques and technologies are you currently most excited about?
Outside of the world of CSS—which is definitely where a lot of the most exciting developments are happening—I’m really interested in the View Transitions API. If it delivers on its promise, it could be a very useful nail in the coffin of uneccessary single page apps. But I’m a little nervous. Right now the implementation only works for single page apps, which makes it an incentive to use that model. I really, really hope that the multipage version ships soon.
But honestly, I probably get most excited about discovering some aspect of HTML that I wasn’t aware of. Even after all these years the language can still surprise me.
And on the flipside, what bugs you most about the web at the moment?
How much time have you got?
Seriously though, the thing that’s really bugged me for the past decade is the increasing complexity of “modern” frontend development when it isn’t driven by user needs. Yes, I’m talking about JavaScript frameworks like React and the assumption that everything should be a single page app.
Honestly, the mindset became so ubiquitous that I felt like I must be missing something. But no, the situation really has spiralled out of control, much to the detriment of end users.
Luckily we’re starting to see the pendulum swing back. The proponents of trickle-down developer convenience are having to finally admit that it’s bollocks.
I don’t care if the move back to making websites is re-labelled as “isomorphic server-rendered multi-page apps.” As long as we make sensible architectural decisions, that’s all that matters.
What’s next, Jeremy?
Right now I’m curating the line-up for this year’s UX London conference which is the week after Pixel Pioneers. As you know, conference curation is a lot of work, but it’s also very rewarding. I’m really proud of the line-up.
It’s been a while since the last season of the Clearleft podcast. I hope to remedy that soon. It takes a lot of effort to make even one episode, but again, it’s very rewarding.
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:
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.
I’ve managed to convince Paul to come out of the shadows for one last heist—it’s gonna be good!
(And Paul shares a discount for 20% off your UX London ticket!)
User research into deceptive design patterns:
Despite our technological advancement and understanding of human nature, it’s still common to see deception in digital products. To understand digital deception (and better define it), we surveyed 536 people to measure and discuss people’s understanding of this matter.
Of course, users can learn over time what prompts work well and which don’t, but the burden to learn what works still lies with every single user. When it could instead be baked into the interface.
I didn’t know the Washington Post had a design system or that the system has this good section on accessibility.
A short list of opinions on typography. I don’t necessarily agree with all of it, but it’s all fairly sensible advice.
If you look at the available evidence, “craft at scale” is mutually exclusive with the kind of rapid and unending growth that’s the baseline expectation for traditional startups and public tech companies.
We’d say that’s obvious in other industries. Budweiser isn’t craft beer. IKEA isn’t heirloom-quality furniture. But we tend to treat software as immune to the typical relationship between quality and quantity.
I like how Luke is using a large language model to make a chat interface for his own content.
This is the exact opposite of how grifters are selling the benefits of machine learning (“Generate copious amounts of new content instantly!”) and instead builds on over twenty years of thoughtful human-made writing.
Stéphanie has gathered a goldmine of goodies:
Articles, resources, checklists, tools, plugins and books to design accessible products
In design, both in the digital and physical worlds, color should never be the sole indicator of meaning. A simple test: if your work was converted to grayscale, would it still be usable?
Andy describes life online with deuteranopia and dispenses some practical advice for designers:
If there’s any uncertainty, adding labels, icons, or textures to each meaningful color of your design will make it accessible to many more people, regardless of their ability to perceive color.
Boom! The Clearleft podcast is back!
The first episode of season four just dropped. It’s all about design transformation.
I’ve got to be honest, this episode is a little inside baseball. It’s a bit navel-gazey and soul-searching as I pick apart the messaging emblazoned on the Clearleft website:
The design transformation consultancy.
Whereas most of the previous episodes of the podcast would be of interest to our peers—fellow designers—this one feels like it might of more interest to potential clients. But I hope it’s not too sales-y.
You’ll hear from Danish designer Maja Raunbak, and American in Amsterdam Nick Thiel as well as Clearleft’s own Chris Pearce. And I’ve sampled a talk from the Leading Design archives by Stuart Frisby.
The episode clocks in at a brisk eighteen and a half minutes. Have a listen.
While you’re at it, take this opportunity to subscribe to the Clearleft podcast on Overcast, Spotify, Apple, Google or by using a good ol’-fashioned RSS feed. That way the next episodes in the season will magically appear in your podcatching software of choice.
But I’m not making any promises about when that will be. Previously, I released new episodes in a season on a weekly basis. This time I’m going to release each episode whenever it’s ready. That might mean there’ll be a week or two between episodes. Or there might be a month or so between episodes.
I realise that this unpredictable release cycle is the exact opposite of what you’re supposed to do, but it’s actually the most sensible way for me to make sure the podcast actually gets out. I was getting a bit overwhelmed with the prospect of having six episodes ready to launch over a six week period. What with curating UX London and other activities, it would’ve been too much for me to do.
So rather than delay this season any longer, I’m going to drop each episode whenever it’s done. Chaos! Anarchy! Dogs and cats living together!
Every day, a new marketing email, Medium post, or VC who will leave Twitter when they’re cold in a body bag tells us that machine learning (ML, which they call AI because it sounds more expensive) is going to change the way we work. Doesn’t really matter what your job is. ML is going to read, write, code, and paint for us.
Naturally, the excitement around ML has found its way into the design systems community. There’s an apparent natural synergy between ML and design systems. Design systems practitioners are tantalized by the promise of even greater efficiency and scale. We wish a machine would write our docs for us.
We are all, every single one of us, huge fucking nerds.
Here’s an aggregator of components from multiple design systems.
Ethan highlights a classic case of the McNamara Fallacy—measuring adoption of design system components.
Oliver asked me some questions about my upcoming talk at Pixel Pioneers in Bristol in June. Here are my answers.
So then the question becomes: how do you most effectively communicate designs, to facilitate the best discussions about those designs? My answer is: lots of little prototypes built with HTML, CSS, and JavaScript.
It doesn’t bother me much that bleeding-edge ML technology sometimes gets things wrong. It bothers me a lot when it gives no warnings, cites no sources, and provides no confidence interval.
Yes! Like I said:
Expose the wires. Show the workings-out.