[taybenlor]

Sorry, I'm not quite sure what you're saying is wrong. I understand your point about physics engines perhaps being the wrong tool here, and I can see that. But the main focus was on how the standard tooling for UI animations is incapable of modelling movement with dynamic "distances" (I put distances in quotes because you could be transitioning colour, height, scale or any other attribute of the object).

[zamalek]

The solution presented is incorrect. I can't explain it any more than what I already said.

While he is correct about the fact that standard tooling doesn't deal with "distances", he must at the same time give the right solution.

By the way, another more direct way to get it right would be to solve S=D/T for T and hand that to the UI framework. I'm not sure what language/framework he is using but here is the general idea:

speed = 10; start = 0; end = 100; time = (end - start) / speed;

circle.left = start; animate duration: time { circle.left = 100 }

Which in itself has very little to do with a physics engine, but won't result in a customer logging a bug about how things are behaving strangely on their 120hz monitor.