I just added the if statement back (but keeping the interpolate). It actually looks better now!

Do you have a before and after gif or video?

In D18000#387577, @abetts wrote:

Do you have a before and after gif or video?

Not right now, I am not at home at the moment. I can provide a before/after gif later.

Unrelated to your comment:

In D18000#387618, @zzag wrote:

I tested this patch. In general, it doesn't feel consistent with other animations. I suggest to open a new task regarding easing curves before actually changing them.

It is true, that it may be inconsistent with other animations, as it a quicker (longer distance in the same time) animation in comparison.
I was looking around in the Human Interface Guidelines and didn't find a section about motion. We could create a meta task, which covers motion in Plasma in general. In my opinion most animations in Plasma feel a bit old (I am probably used to faster animations mainly from the Material Design Guidelines).

I looked into this here, as this was the first animation I wanted to change.

I really like most animations in Android (Pie) as they feel modern and polished. I may experiment with AOSP-like animations in the future.

In D18000#387577, @abetts wrote:

Do you have a before and after gif or video?

Here you go. It is only 30fps and very small.

The first two are with the old animation. the last three are with the new animation. As I am running on the proprietary nvidia driver it may look choppy, but it runs smooth on my laptop with Intel graphics.

Looks better or at least fine to me. No visual objection.

I don't really think that it looks that different than other animations. If one gets used to it it isn't that strange anymore.

The main problem I see is that it's too rapid, imho. It's not very pleasant to watch how some entity moves too rapidly.

I'd like to see some analysis of what's wrong with the current choice of easing curves, how it can be fixed, and why we picked this easing curve instead of that, so we have a "bigger picture" of what should be done.

I can only speak from experience. I don't know if there are any scientific studies that look at user experience with a focus of animation.

So this is my own opinion:

Animations should be quick and clear. An object should animate in a clearly comprehensible way. That means that an object should not appear out of nowhere. It should rather come from a place the user can't see. As we have four screen borders we could just let the object translate from a screen edge, similar to how one would open a drawer in the real world. Of course this is similar to the Material Design Guidelines as this is about comparing design to the real world. Now to this example:
Let's say we have an application launcher menu in the bottom left of the screen. When I click it I expect it to come out of the lower screen edge on the left. Now thinking in the real world: When I open a drawer it does not fade in and only travel a specific short distance. I can see it open from 0% open to 100% open without any jump. Therefore the application launcher should act like a real drawer. Now let's talk about the timing of the animation. I don't open a drawer in just 150ms like in the slidingpopups effect. These 150ms may be tweaked to a bit longer, while staying snappy. There is a range of time where an animation has the perfect length. But that depends on the distance and easing and should be further investigated.

TL;DR

• Animations should resemble their real world counterpaths (e.g. Sliding Popups -> Opening a drawer in the real world)
• Timing should be investigated
• Timing depends on distance and easing.

I recently set up a proper working environment again and started tinkering with different easings and slide-lengths. I decided to make a compromise between the old animation and the one I proposed before.

So, I've been running your patch for a while and have to admit that disappearing animation looks better. However, I advise you and VDG to analyze (perhaps update hig as well?) our choice of easing curves in default effects, e.g. morphing popups, sliding popups, fade, etc, and based on that pick better curves.

+1, should we land this while HIG animation page and easing curves are being discussed?

@sefaeyeoglu thanks for this patch. We have a set of emerging guidelines for animations in D25343. Can you address the inline comments so we can push this forward?

@sefaeyeoglu would yo like to continue working on this? Or should someone take it over?

Couldn't find time for this either. I will probably start working on this again, when my development environment is set up again.

Cool, let me know if you need a hand with anything, or would like like someone else to take over.

Would you like me to take over this if you're lacking the time?

In D18000#582786, @ngraham wrote:

Would you like me to take over this if you're lacking the time?

Whoops. Looks like I forgot about this. I guess there are people here with more time to work on this than me. Thanks for the reminder, though! I would be happy if you or someone else takes over this.

Ready for re-review.

Video of what I mean

But InQuad for animating from invisible to visible is what we do in other places and it's what we're planning to formalize in D25343. Shouldn't we be consistent?

In D18000#587121, @ngraham wrote:

But InQuad for animating from invisible to visible is what we do in other places and it's what we're planning to formalize in D25343. Shouldn't we be consistent?

I guess we should discuss this there then. Most UI Kits I know of always decelerate a appear animation.

I commented on D25343 about this. Also note the following inline comment. If we decide on (really) "OutQuad" for slide-in and "InQuad" (or "OutQuad" in code), we just need to adjust L467. Maybe we should also add a comment at L506 that the easing curve will be reversed.

The HIG patch landed: D25343. Folks who have requested changes, if you're good with this, can you change your status to Accepted now?

Oh, don't forget to add "[effects/slidingpopups]" to the subject line.