So to slightly clarify, this is transitions between two DOM states. It saves you having to keep something in the DOM during an animation. You make the change and DOM elements from before can still be visible during the animation.
They are also working on view transitions between documents, this isn't that. So rather than having to build a SPA in order to animate between "pages" it will be possible to animate those tradition on a traditional server rendered MPA. Looking forward to that one!
> You make the change and DOM elements from before can still be visible during the animation.
Based on my reading of the docs the API gives you a static screenshot of the old DOM and the live new DOM. So if you have any dynamic content on the page it freezes during the transition.
This isn't my experience on iOS / Mac OS. I'm used to seeing videos and animations continue running as they shrink and slide around (IIRC, thanks to CoreAnimation being designed to support exactly this from the outset). The occasions where they pause feel like the exception to the norm.
The platforms/frameworks I use, like WPF, don’t use screenshots when animating changes to whole-scene content replacements.
(Not saying WPF is good overall either, because it isn’t; but despite it being almost 20 years old now there’s still times when it makes me go “oh, neat”)
That's pretty cool, and I wish we got that in the description.
I suspect it'll be a few years before this is stable enough to use though (people will continue with the existing javascript-assisted exit transitions until then)
I wonder if people will even be using this generation of SPAs at that point, or if we'll need something else by then.
After years of using transitions I concluded that there is nothing better than a static (non) transition. Heavy usage of apps/sites with transitions leads to dizziness
I disagree. I like the way YouTube and some apps use motion and quick transitions to indicate which UI components have moved where. The example transitions are way too slow, but I imagine that's intentional to show how the animation paths work.
This should only apply to major components of the UI (such as a video player, or a document, maybe a toolbar that slides to the side of the page), or course. When done well, this makes navigation much more intuitive inside applications.
Every mobile operating system and most desktop operating systems already employ these transitions in their normal use. Most people will only perceive them when they're in the way, but when they're part of a well-deigned UI flow, you probably won't even notice they're there.
I've run my phone with animations disabled for a while, but apps feel much clunkier and broken when all animations disappear.
Even when a page loads quickly (<50ms) and suddenly all the controls and views are somewhere completely different, I need to scan the page again to see where everything went. If I can follow the controls with my eyes, that makes navigation much easier.
If this does get implemented, I expect you will be able to turn these transitions off just like you already can in (mobile) operating systems and some browsers. In fact, if you've already set up your OS to reduce movement, I expect you'll never even be able to see the features being introduced.
They also slow things down. This can be unacceptable for power users, who just want to "get things done". As a practical example, I can't use Apple's "spaces", because they force me to sit through an animated transition when switching between screens/workspaces/whatever. It's fun the first time, but gets really old after a hundred or so.
On apple devices, reduce motion generally just replaces the motion in the animation with a fade in-out. The transition still takes the same amount of time.
100% agree, esp. for power users, but thoughtfully applied transitions can in fact improve the perceived performance. “Thoughtful” is the key word here.
I wish we could just disable transitions completely for spaces, instead of falling back to the crossfade effect.
> They also slow things down. This can be unacceptable for power users, who just want to "get things done". As a practical example, I can't use Apple's "spaces", because they force me to sit through an animated transition when switching between screens/workspaces/whatever. It's fun the first time, but gets really old after a hundred or so.
That's how I feel about MacOS virtual desktops.
You used to be able to configure it so that there was no animation, but they removed that options a while back.
When I got my first color inkjet printer (an HP Deskjet 500C), it came with a booklet called "A guide to using color". That little booklet outlined using color in documents without being over the top and for adding more information rather than haphazardly "decorating".
I still keep that document and revisit from time to time.
I think we need a respected global UI/UX best practices document open for everyone, not unlike MDN.
This is targeted at SPAs, not general web browsing. I've been working on using chrome as a render for a video kiosk type setup, and this feature was exactly what I needed to smoothly do scene transitions. The alternative is to do a bunch of hacking to preload the next batch of content, try to figure out when it is "dom ready" and then use CSS transitions to bring it in.
I think the point of the comment you are responding to was that: no, in fact, the transitions you are talking about would be better off not existing. Like, I watch that video of the UI with all the pieces of that "app" sliding around and I'm thinking "omfg that's annoying and disorienting and will get old extremely quickly".
There is no point in talking about these things in absolutes. Sure, animations can and often times are overdone, but done well they are extremely useful and gives you just the right context on what happens/happened. We are visual creatures who build up a mental model not based on static images, but dynamic interactions. That hover, or overscroll animation gives you essential additional information.
Agreed. The best animations "mean something". As in, if a page swipes left in a transition, it should be to indicate to the user that they're moving forward in a workflow, and the reverse, backwards. Up/down imply the same, but within the same step. If you're in the Western world[*], this can feel very intuitive.
I'm the static HTML type, but one can really smooth out their UX with animations and transitions.
Yeah, and I think that is an incorrect view based on a limited perspective of elements where the user is directly interacting.
What I was talking about using the feature for is passive content. Watch any TV news broadcast, popular Twitch stream, etc. and you'll see that elements or scenes transitioning smoothly is the polish of a good production. A news ticker doesn't just appear, it has a 1 second fade in. The logo isn't always on the screen, it slides in and out periodically from the right.
The problem is that people overdo the transitions when they add them (i.e. make them too long).
This "overdoing" always happends when something new is introduced.
When Windows became able to use multiple fonts in the 90'ies, people used as many fonts as possible on a single sheet of paper. It looked really bad. Over time we got back to use 1 or 2 fonts on a page.
When web got animated GIFs, every page had an animated "work in progress".
Having an API for this is, a bit counterintuitively, good for people who don't like transitions: it means building an extension that turns them off is easy. If websites are implementing transition animations on top of other browser features it's very hard for an extension to recognize them, but not if there's a standard API.
There's some strange backfiring effect where the more presentation capabilities there are, the more I miss the static/dense/minimal presentations of the 80s.
Presentation helps discovering or ramping up to a domain but then your brain goes over that hump and you only care about high density of information.
HN users might be self selecting for this bias towards a dense static design. 1. this website meets those criteria, 2. tech orientated people are power users who prefer the UI to get out of the way.
I don't think I'm that different to the average user. Maybe just more mileage but anyone can evolve and realize what was cute and enjoyable is not required anymore.
I think this comes down to the issues of transition animations or badly implemented ones.
Animated transitions can and do add value where there is a contextual reason for them. You have animations on objects appearing, disappearing or moving, all are different.
- Appearing objects: If you have just clicked or taped something you already know where it is coming from, a very quick animation is what you want at most. Get it on screen quickly.
- Disappearing objects: Again get it off screen quickly, thats what I asked for. However, if for example its "just of the side" (like minimising a window to the Mac Dock) then an animation gives you contextual information of where it is now, so you can bring it back.
- Moving objects: This is where there is the most value in my opinion. It gives you the context of where something has moved to. On iOS safari for example when you tap the bottom right show tabs button, the animation indicates where the previously open tab in in the list, but there isn't an animation for the other tabs appearing, you see them instantly. It's subtle but very effective.
I think a good general rule of thumb is to get new stuff on screen quickly, if I clicked it I know where it's coming from so it really doesn't need a "slow" animation. Moving stuff, show me where it's moved to, thats a good place for an "contextual" animation.
Thank you. I feel less lonely now because I also think page transitions in the majority of cases add nothing but confusion to a site. There are exceptions of course.
I agree. The only usecase i see for a transition animation is the backsliding effect on Ios when you slide back a page. Forward navigating should imho never have an animation. It must show the page in less than 50ms.
I am usually the kind of person to increase the animation speed on my phone too, and I think (while it looks impressive), the example is pretty sluggish to me. But I think, for PWA's this is a huge step-up, as you for example can mimic the backwards-swipe behaviour for page navigation.
It would be great to have an 'rem for css animations' where you don't specify your transition times in seconds but in fractions of a base unit, which might default to 1 second, but can be changed in your browser settings similar to your base font size.
Thankfully I don’t suffer it myself, but due to the way that transitions work in regards with FPS and monitor blanking, they are the same trigger of migraines that fluorescent lights are.
these are just extravagant examples. Optimistic UI updates work best. I don't click links that open/load a fresh new page unless absolutely necessary as theres cognitive resistance stopping me from doing it.
I looked at this and thought "What am I looking at? There's some janky animation as things shift around but what's the bit I'm missing??" and then it slowly dawned on me clicking around a bit more that it must be the poxy animation bit itself.
I mean I guess web consumers are just SCREAMING OUT for this and I've been living under a rock?
Obviously I am old and grumpy but holy crap this is exciting browser development now. Seesh.
I just think it looks neat. I first saw this animation demonstrated by chrome team years ago in some developer conference video, and have been searching whether it's done every couple of months since then.
Sure, if you make seconds-long animations on every interaction, or implement this for blog posts, it's going to be unusable.
But for web apps, short animations in UI transformation make it feel more... held together I guess. Consistent. I like it.
Looks great on my Android phone. On my Linux desktop with a 4k screen, it renders at ~2 fps and looks absolutely horrible. Hopefully this will be fixed!
As someone who disabled transitions wherever noticable on all my operating systems and who avoids IE, sorry I mean chrome or any chromium derivatives, this isnt for me.
However, for users it will affect, can it be disabled.
Does this mean more code must be added to code to cater for browsers that do not implement this API can still the this feature?
How many chrome only APIs already exist and how often do they break sites on spending browsers. Genuine question as I use Firefox, but have never noticed a broken site so I wonder if these fail gracefully or maybe chrome only APIs are rarely used it I don't visit those types of sites....
We can very easily keep backwards compatibility forever at no ongoing cost by layering compatibility mechanisms on top of newer standards. No reason to deprecate <blink> or <marquee> if you can just express them in terms of CSS animations in the default stylesheet. But most of the time it makes sense to pay a bit of maintenance cost because it is worth it to actually improve the ways we access old content rather than just not regressing.
In fact, often backwards compatibility is what keeps things from getting worse because the current environment would have never allowed something as good if it wasn't already entrenched. A good example of this is EMail - big tech has no interest in interopability and aside of upcoming laws forcing them there is no way that a federated communication system like EMail would have any chance today.
To be fair, they were the best example of backwards compatability for decades. They broke some of that with Windows 11 spec requirements, but it's still one of the things Microsoft is quite good at.
Why? Web usb and web serial are awesome for point of sale applications. To interface with scanners, receipt/ticket printers, rfid, …
It’s so much easier to interface all that hardware just from an intranet website, instead of rolling out your own native code to thousands of different devices with different operating systems. We did that in the past, now they all just run chrome.
This mentality of shoving everything in the browser because native is too hard or something is why we're in this mess. The web was invented as a presentation layer for information, not a VM that executes arbitrary remote code and can talk to hardware.
"This mess" being the greatest period of technology in history. Web browsers have become the most important and most empowering tools ever built. I'm really not convinced we should reverse that for some old man unix philosophy rant.
The web is an application platform. It is really the remnants of its history as a document presentation platform that makes it add all these ultra high level declarative features that make up the bulk of the complexity of a browser. Ironically, these features, much more than scripting, also make up the bulk of the attack surface for browser exploits. Features like USB and VR are not the problem, you can just turn them off and everything still works, but one little change to CSS layouting can turn a web page into salad.
We are not building things for the technology sake. The user comes first, usability and accessibility is paramount. That's where we work around. History has shown is that it's easier to teach the browser new tricks than to make native easier to use. I want to:
go to some website => solve problem => finish
without extra steps. As a user I usually really don't care, I just am not interested in the problem and I am already spending too much time with stuff I am not interested in.
If you consider other consequences that result then it can be "weakness" to take an easier path. I won't use ridiculous examples, but many bad things have happened because it was easier.
People aren't doing this on the web for it's ubiquity, they are doing it because application distribution in the non-web ecosystem sucks. And because as bad as HTML and CSS is, native UI frameworks are even worse for most use cases.
If you don't like how all the applications are built on the web, by all means, provide a native alternative that's better.
Microsoft under Ballmer would have loved something like that, and spent a lot of money on trying to beat the web.
We use webusb and webserial in an internal tool as an easy way to distribute a cross platform way to flash an embedded device. It works great for supporting platforms which aren't used by the majority of our developers (Linux). I'm sure there are other ways to write a portable application, but the web route is a lot simpler.
I really hope we never remove these API surfaces from the web API surface.
you could argue that flash fell under this category, but that also perfectly demonstrates how much of the web was made inaccessible as a result of removing it
Transitions and animations on the web are already abused by web developers enough today. The last thing we want is a browser API that automatically applies transitions to the entire DOM.
Prepare for endless frustration as designers start implementing artificial 5 second delays while you wait for a pretty transition between two states of a page.
I don't agree with the common complaint that transitions and animations are just aesthetic fluff. Done right, they give the user additional feedback as to what's going on, e.g. in the example announcement, zooming in on one particular video making it full-screen.
This might be less relevant to power users, but imagine someone accidentally clicking somewhere and suddenly facing a full-screen video. With the transition, it's at least clear what action is happening. It's similar to buttons indicating their state (hovered, pressed, clicked).
The main reason animations can get annoying is that people don't get the timing right (too slow), or really just use them to show off. Some even use transitions to gloss over the slowness of their system, which is infuriating.
2. are power users - most of these design choices are inherently less functional than alternatives
3. understand that these things aren't just "the way they are" but are intentional, explicit things that designers & co. want and will push for over how things used to be as well as the status quo
I am in my 40s, and so are most of my friends. But I'm dating a younger person (20s) and hang out with his peer group on occasion. So, this is anecdata, but I don't think it has anything to do with any age group specifically.
The modern web and app space is just filled with minor annoyances that individually are probably fine but that add up to a sort of aggregation of frustrations and feelings of being manipulated that is hard to put a singular description to. I get this sentiment in both age groups that I have high exposure to. It's not really about hating new trends because we're just old and comfortable with how things are (or were).
That's my feeling lately. A lot of UX lately doesn't seem to be designed to empower or assist the user but to push them into a direction that's good for whatever the company wants.
When one company, that has a culture of incentivising new features over maintenance, has monopoly control over the web you get a lot of new features. The merits of those features is somewhat irrelevant.
I once saw a Google talk about video codecs in Chromium. It included a section where they talked about the life cycle of a video codec.
They apparently introduce video codecs with plans for deprecating and then removing them. Literally breaking all sites on the web which rely on that codec.
That, to me, perfectly encapsulates their philosophy of introducing new features without committing to maintaining them. They don't view the web as something that's worth not breaking, they seem to only value the actively maintained part of the web which has enough resources to stay on top of Google's treadmill.
> They apparently introduce video codecs with plans for deprecating and then removing them. Literally breaking all sites on the web which rely on that codec.
No transition takes five seconds intentionally. What you may be seeing is artificial delay, something introduced to a system to give users more confidence that the system is working correctly. Instant responses for operations perceived to be complex cast doubt on if the operation was done correctly.
Either way, you can disable transitions on your OS already if you dislike them. In fact, you should see this as an improvement to the current situation, as transitions bound to OS animation preferences instead of jQuery .animate() will suddenly disappear for you.
Give developers a standardised interface they can use and they'll use it; give users settings for those interfaces and you can make applications work like you wish with the click of a button.
What an uncharitable view of an entire profession. Is this really HNs attitude towards UX/designers? That if it weren't for them, we would have perfectly usable and fast apps?
Basically, yeah. Welcome to the struggles of being a late 90s/early 2000s sysadmin. When you were doing your job perfectly people hardly recognized you existed and they wondered why they even keep you on the payroll.
The only time people consciously think about UX/design is when something horrific happens like the most recent Gmail redesign or the Netflix autoplay on hover.
I remember this was built in in some browsers back in the days, as transitions between whole pages. Basically the same transitions as in simple presentations (fade, push in from side, reveal as a circle, etc)
This wasn't as much a browser feature, but an artifact of Microsoft using the same mshtml library to power as much of the system as possible in Windows 98 (IE, Explorer, the Office suite, etc). If I remember correctly one of the selling features of Powerpoint at the time was the ability to export to HTML for "portable" presentations.
I think it's a good time to introduce a new button to the browser interface, as the gap between the original "take me back to the previous document" and some new concepts like the one presented here is getting bigger and bigger. But maybe I'm just old?;)
The really exciting part is the next step — providing this for regular navigation across pages. This way you can have the fancy look of single-page JS apps without the heft and complexity of actual single-page JS apps.
There's nothing wrong with companies driving industry standards. That's how it works in other industries as well. As long as they're not there to purely benefit Google or implemented in a way that other browsers cannot replicate, I don't see the problem.
Actually, I think implementing first and standardizing later is how a lot of (dare I say, most?) Web standards came about. And without patents and other IP restrictions, I don't think there's anything wrong with that.
They are also working on view transitions between documents, this isn't that. So rather than having to build a SPA in order to animate between "pages" it will be possible to animate those tradition on a traditional server rendered MPA. Looking forward to that one!