Zooming out of lists animates more slowly than zooming in

I brought this up in another topic but didn’t want to take that one too far off its track.

My (minor) complaint was the animation to zoom out/move up the hierarchy is slower than zooming in/moving down the hierarchy. I will be the first to admit the difference is small and some folks might not even notice. It’s not a deal-breaker for me and I will totally understand addressing it being pretty low priority.

I took a screengrab to show what I mean. Using the iOS Photos app editor, I determined the zoom in time to be ~0.5 sec and the zoom out time to be ~0.7 seconds. Like I said, a small difference. (Or, at ~40% longer, a fairly large difference. :smile:)

Anyhow, here’s the screengrab converted to GIF:


1 Like

Appreciate the screen recording and timing of this. I think it’s definitely possible, the animations are tuned largely with springs vs. timing so will take a look at this next time. The original animations were probably made… 7 years ago :scream: and left unchanged until the recent spring tightening. So we have to re-remember some of this stuff when we next look again.

I will say they hold up quite well for 7 year old animations :slight_smile: Still feels modern and fresh.

BTW are you pinching to back out? Very curious if you try the back button what you think of it over time. (And to motivate you… that back button overlay will fade out and disappear unless tapped over the first 15 uses of it.)

Gave it a try with a list of ~200 elements vs just a couple (and everything checked off cleared).

Definitely noticeable that the opening animation takes more time, which you’d expect I guess. But yeah, for me opening a list takes more time than closing them.

Maybe you could “cheat” for bigger lists, and only load the visible area first and then load the rest while the animation plays and the list opens? (I know nothing about how this works, so sorry if it’s a stupid idea.)

I am. Honestly, I didn’t even see that back arrow. Using the arrow vs. pinching doesn’t seem to make a difference.

I also made a 288 item list that is slightly slower to close than to open. Same with moving from the lists screen to the top level: slightly slower moving up than down. It’s interesting that espenhk is seeing the opposite.

Btw, you say that back button overlay fades unless we use it over 15 times. Is there a way to make it fade once we go past the 15? Because I did that while testing timing and, now that I notice it, I’d rather it not be there.

Oh to be clear the behavior is the semicircle area initially starts more opaque, but fades out to invisible (unless tapped) across the first 15 taps. So during onboarding it is always visible onscreen. And currently, it always shows when you tap as visual feedback. (We can probably consider toning down the latter a bit.)

Ah, okay, gotcha. I’ll probably just tune it out again, as long as a list can be scrolled up past it so it’s not blocking the bottom items. Which a quick test shows is the case. :+1: