I was disappointed also. I wrote up a (unpublished) paper [1] on this topic once; the gist is that physics presents both an opportunity and a huge challenge for UI.
Ever tried to play really old games like Worms 1 on anything faster than 100MHz? They are "framerate locked" which means that a higher framerate makes everything go faster. So if you used that function on a 120hz display everything would run at twice the speed (assuming it's designed to run on 60hz). This is why things like Dos Box let you run at a lower emulated CPU frequency: so that you can slow things down so that these games are playable.
In terms of UI animation the most sensible thing to use is Euler Integration (pronounced "oiler").
Euler Integration is based off of Distance = Speed / Time. Basically what you need to do is remember the "last time" the function was called (using a high resolution timer) and find the difference between that and the current frame. This gives you the "Time" in Euler Integration, your "Speed" should be a fixed constant (e.g. 1 pixel per second). Then simply add Distance / Speed to your current X value.
Things git a tad bit complicated to ensure that you don't "overshoot" your target position, but it's nothing simple high-school algebra can't solve (that's the nice thing about Euler Integration, it's all high school Mathematics and Physics).
Techniques like ease-in/ease-out are easy to do (using the difference in distance between the current point and starting/ending points use base your speed off of that), all using high school algrebra.
I wouldn't bother with Verlet or Runge-Kutta: it is just UI animation after all - you aren't going for very accurate results like games do. "Real" physics engines also have the problem of not being able to guarantee deterministic results.
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).
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;
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.
I'm not sure I buy the premise, but that may just be a failure in the explanation. The author claims it's "more real" but provides little in the way of an explanation as to why this is so. It doesn't feel any more "real" to me. I feel like the author is trying to explain something, but I'm not sure what that is.
TL;DR: If a transition changes values that are dependent on dynamic user input you get an unrealistic effect where small differences take as long to transition as large differences (because transitions usually have a fixed duration).
The problem isn't in timing functions. It appears whenever the "distance" involved in a transition is dynamic (rather than specified by the designer/developer).
a bit related, i remember a couple years ago complaining that jquery's "slow" and "fast" as shorthands for preset durations was misleading because when animating on a wide screen, "slow" ends up being quite fast compared to a narrow screen width. you are never really defining the animation rate, as was implied. this is of course due to the fact that everything is based on a fixed duration being passed into the supplied easing function.
Exactly. In a certain way, you could call jQuery UI effects a very limited physics engine.
I don't think the author is saying everyone should use a physics engine now. I think he means that we should use real-world physics as a guide to making more realistic animations, be it with a simple effects library or a full-fledged physics engine.
This is wrong. The "feel" of an animated interface is an entirely creative/artistic/subjective thing, and its overall success is down to the sensitivity of the animator, not the underlying mechanism. There's always going to be a place for both time and speed based simple animations, as well as animations based off easing equations, physics engines and everything in between. We use whatever feels and looks right for the job at hand. To say that we'll achieve better results by stopping using duration/easing equations and only using speed is overly simplistic and, I'm sorry to say, rather naive.
You're right. I went overboard with my conclusion, the intention was to focus attention on the fact that using a single tool results in lots of similar results and to highlight the flaws in that tool. There are plenty of other tools we could use, not just the one.
I think parent was referring to more on the role of a physics engine in UI, not on physics engines in general. There are plenty of those, but how many UI toolkits are provide real physical animation? As in....the infamous TAT Foldout UI Demo:
Seems like a part 2 with more complex animations would be needed.