Interfaces: Advanced Easing
ericbutton.co
Interfaces: Advanced Easing
1–10 of 10 posts
Re: Interfaces: Advanced Easing
#2Wow. I rejoice that someone is passionate about this UX finery.
Because I'm found at the far end of the stack.
Re: Interfaces: Advanced Easing
#3In most apps, transitions like these tend to be painfully slow. A 300-millisecond transition animation blocks the user just like a blocking system call stops a running process; it forces them to do nothing but stare at your animation, because they can't read or target any UI elements until they've stopped moving.
You wouldn't randomly put "usleep(300000)" in your programs, so why punish your users by blocking them in the same way?
Yes, I understand that it's pretty. But often, I think, as designers we can be so enthralled by the beauty of our creations that we appreciate them as art and forget the perspective of a user who is simply trying to find the answer to a question or get something done.
In the vast majority of situations, no transition is necessary. As a user, I don't want to wait 300 ms to do the next thing. Don't make me wait. If I must wait, keep the delay under 100 ms so that the system feels responsive.
This is Webflow, a website building tool, so its design choices have a bigger impact; they affect the design of many websites. I would argue against making it trivially easy for website designers to force their users to wait. If the user really does want a transition, use a shorter default duration, like 100 ms.
Re: Interfaces: Advanced Easing
#4In most apps, transitions like these tend to be painfully slow. A 300-millisecond transition animation blocks the user just like a blocking system call stops a running process; it forces them to do nothing but stare at your animation, because they can't read or target any UI elements until they've stopped moving. You wouldn't randomly put "usleep(300000)" in your programs, so why punish your users by blocking them in…
[deleted]
Re: Interfaces: Advanced Easing
#5My rule of thumb is that animation is something you only add to your designs when it's already good, and when you really know what you're doing.
If you're relying on animations to hide jankiness or spruce up a design it's probably not going to work. If anything, it will probably make things worse. For example a delayed response to an interaction feels like a slow application, not a smooth one. This is especially true on the web where many animations run on the main thread and compete for resources with whatever is causing slowness.
Re: Interfaces: Advanced Easing
#6In most apps, transitions like these tend to be painfully slow. A 300-millisecond transition animation blocks the user just like a blocking system call stops a running process; it forces them to do nothing but stare at your animation, because they can't read or target any UI elements until they've stopped moving. You wouldn't randomly put "usleep(300000)" in your programs, so why punish your users by blocking them in…
Slow transitions are a pain yes, but many UIs without transitions can be a real pain too. Random stuff opening and collapsing without a subtle transition can be really confusing. It’s definitely not just an aesthetic thing.
In my experience somewhere around 150ms hits the sweet spot of not being too annoying and still easy to track the spatial context of what’s going on.
Re: Interfaces: Advanced Easing
#7In most apps, transitions like these tend to be painfully slow. A 300-millisecond transition animation blocks the user just like a blocking system call stops a running process; it forces them to do nothing but stare at your animation, because they can't read or target any UI elements until they've stopped moving. You wouldn't randomly put "usleep(300000)" in your programs, so why punish your users by blocking them in…
Compliant sites should check the Prefers Reduced Motion media query and turn off animations. MDN says this is intended for people with 'vestibular motion disorders' but I've found it works for impatient people too.
Re: Interfaces: Advanced Easing
#8In most apps, transitions like these tend to be painfully slow. A 300-millisecond transition animation blocks the user just like a blocking system call stops a running process; it forces them to do nothing but stare at your animation, because they can't read or target any UI elements until they've stopped moving. You wouldn't randomly put "usleep(300000)" in your programs, so why punish your users by blocking them in…
Slow transitions are a pain yes, but many UIs without transitions can be a real pain too. Random stuff opening and collapsing without a subtle transition can be really confusing. It’s definitely not just an aesthetic thing. In my experience somewhere around 150ms hits the sweet spot of not being too annoying and still easy to track the spatial context of what’s going on.
Android dev tools let you speed up UI animations. Dropping their time to 25% yielded a phone that felt like it had been given a shot of nitro, and I didn't have any trouble using it.
This "easing" crap just makes devices feel slow, and wastes energy and everyone's time.
Stuff that "moves" when you hover over it is stupid anyway - not compatible with touch screens, can't be printed. I've never looked at a site and been anything other than annoyed by stuff that moves/slides/expands.
There's an extra special place in hell for web designers who screw with the page scrolling to make it "better."
Re: Interfaces: Advanced Easing
#9My main takeaway is "make the whole thing clickable" as several of the animations show missed clicks trying to find the invisible click boundary.
Re: Interfaces: Advanced Easing
#10In most apps, transitions like these tend to be painfully slow. A 300-millisecond transition animation blocks the user just like a blocking system call stops a running process; it forces them to do nothing but stare at your animation, because they can't read or target any UI elements until they've stopped moving. You wouldn't randomly put "usleep(300000)" in your programs, so why punish your users by blocking them in…
Slow transitions are a pain yes, but many UIs without transitions can be a real pain too. Random stuff opening and collapsing without a subtle transition can be really confusing. It’s definitely not just an aesthetic thing. In my experience somewhere around 150ms hits the sweet spot of not being too annoying and still easy to track the spatial context of what’s going on.
There are some situations where a transition is warranted; they're fairly special and rare situations, but I agree with you when you're talking about "random stuff opening and closing".
In broad terms, if the user cannot predict where things are going to move (typically because the position itself reveals new information, such as the data points in a data visualization), then a transition animation is warranted. On the other hand, if the UI responds to a user command by doing exactly what the user expected (such as expanding the children in an outline list when you click to expand), there is no need for a transition.