How should cancelled animations behave?

Question

How should an animation behave when it is cancelled/changed?

For example, let's say I have a button in my application that triggers the visibility of a tool panel. When the panel is shown, an animation slides it into view; when it is hidden, it slides off screen. To make the movement more realistic, the animation eases in/out (it accelerates at the start and slows down at the end).

What should happen if the user clicks the toggle button when the panel is halfway in view? Should the "slide in" animation:

• A: simply continue to fully show the panel, with the "slide out" animation queued behind it?
• B: stop immediately and start the "slide out" animation?
• C: decelerate its movement, then switch to the "slide out" animation?

If B or C, how long should the partial "slide out" animation take? If the full animation takes 200ms, should it be re-timed proportionally (100ms if the panel is halfway on screen), or should it still take up the full 200ms cycle (resulting in a slower movement of the panel as it slides out)?

Answer 1

Option A won't work. It's a slow response, and users might even think that their command wasn't received at all. Options B and C are actually quite similar.

What you're trying to do is give the user an immediate response (as in B), while preserving the rules of physics (option C). In the physical world, slowing down when approaching a target has to do with associated gains in accuracy. When you're cancelling a movement there's no need to be accurate, so the changes can be quite abrupt (and in extreme cases quick decelaration can be indistinguishable from stopping immediately). In the physical world the relevant variables would be speed, mass, and force.

Try B first. If it feels too abrupt or unnatural, you'll probably need to slow down before moving the other way. I agree with Gary that testing with users would be a good idea.

Answer 2

I would think B is the option to go with. By clicking again the user has effectively said, "Don't do that", so there's no reason to decelerate.

With regards the timing of the slide out animation, I think proportional timing will feel the smoothest - humans are remarkably good at getting a gut-level feel for when the timing is right or wrong, and proportional would feel right.

Of course, if available, testing a couple of different ways with users and getting feedback would be ideal.

Answer 3

I think C would look the cleanest. It shouldn't annoy the user as long as it decelerates quickly.

Answer 4

I think that C is the way that most users would expect the panel to behave. Make a gentle deceleration and move it in the other direction with the same speed as initial speed. 200 ms isn't allot, and it's a good idea that the user can see the panel move away so he/she understands where it went.

If possible, keep the button close to the actual slide out panel to take advantage of the proximity expectations that uses often has - "I do something here - hence the effect should show nearby". An example is the Windows button - when you press it the Windows menu raises above it - not on the other side of the screen...