My favourite animation trick: exponential smoothing (2023)
21–30 of 390 posts
Re: My favourite animation trick: exponential smoothing (2023)
#22Re: My favourite animation trick: exponential smoothing (2023)
#23A lot of these don’t seem to work on my iPhone and Firefox.
Re: My favourite animation trick: exponential smoothing (2023)
#24Also, that page uses 100% of the CPU in Firefox.
Re: My favourite animation trick: exponential smoothing (2023)
#25Re: My favourite animation trick: exponential smoothing (2023)
#26> Animations are not just a fancy visual thing, they help the user understand what’s going on. Instead of teleporting the toggle indicator to its new position, let’s move it smoothly Unfortunately it is, just a fancy thing that too often makes it worse or just focuses on the wrong thing. Like in this case, what exactly is "going on" that requires this visual delay? It looks worse vs the original instant response, why…
That's the whole point. That's why the primary use of sliders on desktop is opt-out of something no user really wants.
This is often combined with scroll windows with some sliders offscreen and invisible scroll bars.
Re: My favourite animation trick: exponential smoothing (2023)
#27You never get there with exponential smoothing. It takes infinite time to asymptotically approach the goal. Also, that page uses 100% of the CPU in Firefox.
Text selection also doesn't seem to work... is it all Canvas maybe?
Re: My favourite animation trick: exponential smoothing (2023)
#28> Animations are not just a fancy visual thing, they help the user understand what’s going on. Instead of teleporting the toggle indicator to its new position, let’s move it smoothly Unfortunately it is, just a fancy thing that too often makes it worse or just focuses on the wrong thing. Like in this case, what exactly is "going on" that requires this visual delay? It looks worse vs the original instant response, why…
While in small doses it's a bit nice to affirm to the user they didn't blink while the state changed, it adds significant complexity. Nearly every one of the animations in that website flicker and the map rendering actually has a bug where it doesn't stop jittering back and forth very visibly indefinitely. Definitely makes me not want to implement stuff like this.
Re: My favourite animation trick: exponential smoothing (2023)
#29> Animations are not just a fancy visual thing, they help the user understand what’s going on. Instead of teleporting the toggle indicator to its new position, let’s move it smoothly Unfortunately it is, just a fancy thing that too often makes it worse or just focuses on the wrong thing. Like in this case, what exactly is "going on" that requires this visual delay? It looks worse vs the original instant response, why…
I usually dislike animations. I used to disable transitions whereever possible, as they made the UIs feel sluggish. And I still do.
But working on the project made me for the first time really appreciate in practice how much amimations help with understanding. I paid a high price in complexity to add transitions whenever the state of the visual graph changes, and suddenly it was really obvious what was happening. Commits and whole branches were sliding into their new position, and I would go "a-ha! I see" instead of "wtf just happened, what am I looking at now?".
EDIT: Fair warning, it's heavily WIP https://gitlab.com/indigane/visual-git
Re: My favourite animation trick: exponential smoothing (2023)
#30> Animations are not just a fancy visual thing, they help the user understand what’s going on. Instead of teleporting the toggle indicator to its new position, let’s move it smoothly Unfortunately it is, just a fancy thing that too often makes it worse or just focuses on the wrong thing. Like in this case, what exactly is "going on" that requires this visual delay? It looks worse vs the original instant response, why…
Nothing. It's a technical demonstration. The delay is also overemphasized to make the difference more apparent.
> The this is the fanciness that detracts from solving the major flaw of these sliders: you can't easily tell whether it's off or on
That's because they don't represent anything. Toggles don't always represent on or off, either-- they could represent a binary choice between any number of things.
> Unfortunately it is, just a fancy thing that too often makes it worse or just focuses on the wrong thing. > It looks worse vs the original instant response, why does the user need to care about intermediate movement of this binary toggle?
Putting aside the functionality that animations can add, because others have addressed it, even "feel" does matter to most users. Many people would choose soft-close cabinets over regular spring loaded hinges even if noise wasn't a concern. You'd never see them in a commercial kitchen, though-- people just move too fast and that extra bit just gets in the way. It would be rather absurd for someone in a professional kitchen to assume home cooks have the same requirements and use cases for cabinets that line cooks do. Similarly, people who spend most of their days doing technical things using technical tools made by and for technical people interpret interfaces differently than most people. To developers, UIs are a little part of an application to expose the functionality to users, and the less distance between the application and the user, the better. But more often than not, that approach yields results far more useful to someone with a working mental model of how software operates under the hood. To most people,the UI is the application, and the application is an appliance. Having smooth interactions that 'feel' nice to use are much more desirable.
As someone with a good amount of professional experience both as a developer and a designer, I'm consistently surprised by how quick so many developers are to assume their personal usage habits, osmosis-gained knowledge from projects, and folk wisdom about design trumps the expertise of seasoned credentialed professionals in the field. The reason most end-user-facing FOSS projects (that don't have foundation-funded UI teams like Blender or Mozilla) are used almost exclusively by other developers is because non-technical users usually find the experience unpalatable at best, and unusable at worst.