Live data from Hacker News

My favourite animation trick: exponential smoothing (2023)

lisyarus.github.io

371–380 of 390 posts

Re: My favourite animation trick: exponential smoothing (2023)

#372

This takes me back to old days of Flash programming and the infamous Robert Penner easing functions. http://robertpenner.com/easing/penner_easing_as1.txt

Glad someone mentioned the Penner functions, that was a godsend in my early flash days.

Re: My favourite animation trick: exponential smoothing (2023)

#373

I like this although I'm going to stick my neck out and say the author is objectively wrong that sqrt is better than cubic for a toggle switch, and that cubic is in fact the better choice for this situation simply because of the way real life toggle switches generally work. Think about the breaker switches on the electrical consumer unit on your house, or the kind of switches you often find on analog synths or other…

Intuitively I too preferred the feel of the cubic function. A mechanical toggle will have some inertia, and I guess that’s what we’re seeing with the cubic approach.

I think the crucial difference is that in real life the toggle starts moving when you start applying force, and snaps at some point. In UI, you've already felt the click on your mouse, so personally I'd expect the UI toggle to snap right away.

Re: My favourite animation trick: exponential smoothing (2023)

#374
post #65

Earlier quoted context omitted.

> It's a technical demonstration So? The justification is still substantive. What would change in a real slider that turns real setting on/off? > delay is also overemphasized That's only true for those slowed down by a factor of 8. Otherwise it's not, I see the exact same issue in real-world sliders on web sites and in apps. > Toggles don't always represent on or off, either But they mostly do, add they do in this ca…

> So? The justification is still substantive. What would change in a real slider that turns real setting on/off? No it's not. Whether or not a design accomplishes its goals is exclusively based on what it's trying to communicate. This is trying to communicate animation curves. > That's only true for those slowed down by a factor of 8. Otherwise it's not, I see the exact same issue in real-world sliders on web sites a…

>This is trying to communicate animation curves.

It's trying to communicate how to, among other things, apply animation curves to UI, just read it: "I use it for ... moving UI elements," "Speaking of UI, say"

I know it's easier to discuss generic things re. some Terra Design Incognita after erasing all of these specific details, but they do exist in the text even if you try to ignore context!

> In the vast majority of instances, these things are done well so they help your eye adjust but don't stick out as animations.

You're substituting assumption for knowledge (they aren't and they do, and I know my experience better than whatever you can imagine about someone else) and an answer to a specific question for yet another generalization. Is Apple part of the vast majority? Check my other comment re. how the fundamental slider flaws appear in that impeccably unnoticeable design

> Most novices can't distinguish poor

And here you go again, incapable of demonstrating the value of a supposedly good general concept to address a general challenge in a case of a slider, instead veering off into an assessment of some generic group that's not present in this conversation.

Re: My favourite animation trick: exponential smoothing (2023)

#375
post #260

Earlier quoted context omitted.

> If you've used CSS transitions you'll have encountered the problem this solves. Okay, my duration is 400ms -- but why 400? Shouldn't it depend on how far it has to move? It seems to me that the "speed" parameter in the exponential function has the same issue, does it not?

If you use the version somebody else here mentioned, “move 90% of the way to the destination in 80ms”, does that make more sense? (I think it’s equivalent, just a change of units.)

But can't you then also change the units on the linear animations? "move 40px/s until you reach the destination"

Re: My favourite animation trick: exponential smoothing (2023)

#376

Earlier quoted context omitted.

> appropriately applied animations Appropriately applied anything is good. I am disputing whether this is an appropriate application. > How conceited of me to not scramble to go grab citations This what not conceited. There is nothing wrong with not having the numbers for something, you should just try to avoid claiming you do if you can't actually find any. The conceited bit was your general attitude. Writing many l…

> Appropriately applied anything is good. I am disputing whether this is an appropriate application. Ok, explain why this animation is not an appropriate application of this animation in a technical demonstration of this animation. > I would likely agree with them. Most software is quite bad, and most of it isn't designed much better. When I say a lot of designers are wasting time on this stuff, I base this on develo…

> Read the comment I wrote initially

This is why I call you conceited – the only reason people can disagree with you is because they are stupid or because they haven't actually read what you said. You seem so confused by the fact that I have read it, and I find it to be unconvincing. You suggest that these switches exist primarily to look pretty, when as I understand it, their main purpose is to communicate that checking them has an immediate effect rather than only after form submission. I don't see them being used like that as much as I just see them jammed in random places, and even when they are I have to wonder if it would make more sense for the UI they are a part of to be made into a form. You dismiss the issue with state identification by saying they could represent "a binary choice between any number of things". The idea that a switch can have more states than just on or off is confusing to me, and that still doesn't help with the issue of determining their state unless you label both sides which is a waste in comparison to the simple checkbox, which draws on the user's existing knowledge from filling in forms on pen-and-paper.

> Copout

I'm sorry that I don't have the opinions you want me to have so that I'm wrong.

Re: My favourite animation trick: exponential smoothing (2023)

#377
post #68

> However, this still looks a bit clumsy due to having a constant speed Does it? Looks much better to me, and preferred to waiting for a animation to be given more time to speedup while looking "smooth" (they seldom seem to be given the same time as instant or linear animations, do they? For some reason we have to be forced to enjoy them in half time). In fact I'd take the "instant toggle" in a heartbeat too. Real li…

I hate animations like that because they are intentionally slowing down the UI. I already clicked it, why are you spending several milliseconds to update your state? Animations, or anything else really, should only be used to improve things. Ask what the problem is, not what cool solution I should implement. It's ok to go to town if the page is artistic , like your blog, but if I'm filling out a form? Get your art ou…

Just because the switch takes time to move doesn't mean the new state doesn't take effect. I would expect the state to change immediately then the animation runs.

Re: My favourite animation trick: exponential smoothing (2023)

#378
post #292

Earlier quoted context omitted.

It's delaying the feedback I use to know if I clicked correctly.

You know that as soon as you see the first frame of movement

That's a very small change that's a lot harder to see.

Re: My favourite animation trick: exponential smoothing (2023)

#379
post #322

Earlier quoted context omitted.

How do you enter text then? Do you re-implement the text box because input text is part of a form? Check boxes work just fine without a form btw: https://stackoverflow.com/a/50012963

I'm not saying you CANNOT use a checkbox outside of a form. I'm saying they gradually became different UX widgets that serve different purposes. You can use pretty much any widget to store a boolean state. A select? It works. Radio buttons? Works. Checkbox? Of course. Typing "1" or "0" in a text input limited to integers between 0 and 1 inclusive? Why not. But semantics matter, and so does the principle of least surp…

No, users put up with whatever is thrown their way. Glitchy menus, pages that take forever to load, unresponsive timelines, you name it. I don't think a check box would be as controversial as you believe.

Re: My favourite animation trick: exponential smoothing (2023)

#380

Earlier quoted context omitted.

> Appropriately applied anything is good. I am disputing whether this is an appropriate application. Ok, explain why this animation is not an appropriate application of this animation in a technical demonstration of this animation. > I would likely agree with them. Most software is quite bad, and most of it isn't designed much better. When I say a lot of designers are wasting time on this stuff, I base this on develo…

> Read the comment I wrote initially This is why I call you conceited – the only reason people can disagree with you is because they are stupid or because they haven't actually read what you said. You seem so confused by the fact that I have read it, and I find it to be unconvincing. You suggest that these switches exist primarily to look pretty, when as I understand it, their main purpose is to communicate that chec…

>>> Appropriately applied anything is good. I am disputing whether this is an appropriate application.

>> Ok, explain why this animation is not an appropriate application of this animation in a technical demonstration of this animation.

>

Thought so.

> the only reason people can disagree with you is because they are stupid or because they haven't actually read what you said.

What I initially said is based in common industry practice and backed up by papers from academia, independent usability organizations like the Nielsen Norman group, and plenty of other independent entities. It's not secret-- lots of info is a quick google search away. It's nuanced. Lots of the info is in literature about accessibility-specific topics like designing for people with cognitive problems of various stripes, low vision, photosensitive epilepsy and similar conditions, motion sickness, and all sort of other less common neurological considerations. The default state of UI design is not adding anything unless it adds something specific and justifiable and doesn't kill any other sort of accessibility. Lots of interfaces violate those rules. Lots of interfaces are not designed by UI designers. Pointing to bad practices in those interfaces isn't an indictment of UI design or any of the practices that UI designers have. Your refusal to acknowledge all of this doesn't oblige me to gather empirical evidence to defend it.

I also wouldn't go gather a list of citations to defend the concept of OO programming to a crowd of non-or-slightly-technical designers subconsciously influenced by groupthink and a few clojure evangelists they'd worked with, citing code they saw in shitty wordpress plugins and ignorantly insisting OOP was the problem. Right, surely it would have been good code otherwise.

In this comment section, literally zero of the very critical people, you included, has responded with anything aside from some combination of personal preference, developer folk wisdom, and off-base assumptions, all buttressed with mistaken confidence. If you refuse to correct that with all of the info at your fingertips, that's your problem, not mine.

> I'm sorry that I don't havee the opinions you want me to have so that I'm wrong.

Ok let's break this down. A copout is avoiding responsibility for something, and in rhetoric, it's when you avoid addressing a direct point with nonspecific challenges to the premise, or by changing the premise to something that will still let you be right.

For example, "Surely if you stumbled upon a bunch of designers making sweeping, arrogant, unsupported declarations about software development and the incompetence of developers, you'd trip over yourself to gather any evidence they demanded to prove your point when you corrected them on their foundational misgivings. Surely you wouldn't just tell them to go google it for themselves."

This is a very cut-and-dried statement. Here's your verbatim response:

"I would likely agree with them. Most software is quite bad, and most of it isn't designed much better. When I say a lot of designers are wasting time on this stuff, I base this on developers doing the same thing."

Rather than addressing the clear premise of how you'd respond to sweeping, arrogant, and unsupported criticism by arrogant laypeople, you change the premise to one where those designers are making criticisms you agree with. It completely avoids the obvious point, which is that you obviously wouldn't feel the need to cite your arguments in the face of baseless criticism from laypeople.

Go ahead and protect your ego by pretending I disregarded your legitimate response. Limber yourself up for some sort of 5 layer deep mental gymnastics about my being the one that was really changing the premise, or the like. But you're clearly not interested in honestly evaluating the veracity of anything you're saying, so I'm done here.

Most professionals get irritated when randos that think they're experts make a bunch of BS criticism of their professional practices. But developers are unique in that they get equally rankled by implications that knowing how to code doesn't give them expertise in everybody else's fields, too.

Post reply on HN