2f:T416,{ const context = DOM.context2d(width, height); let oldNow = Date.now(); // let x = goRight ? leftEdge : rightEdge; // const destX = goRight ? rightEdge : leftEdge; // let v = 0; while (true) { const dt = (Date.now() - oldNow) / 1000; [mutable xConventional, mutable vConventional] = stepper(dt, mutable xConventional, mutable vConventional, destXConventional, k, b, precision) context.clearRect(0, 0, width, height); context.beginPath(); context.arc(mutable xConventional, height / 2, radius, 0, 2 * Math.PI); context.fill(); /* context.moveTo(x, 0); context.lineTo(x, height); context.stroke(); */ // drawLine(context, { x: mutable xConventional, y: height / 2 }, { x: mutable xConventional + k * (destXConventional - mutable xConventional) / 10, y: height / 2 }, 5, 'blue'); // drawLine(context, { x: mutable xConventional, y: height / 2 }, { x: mutable xConventional - b * (mutable vConventional) / 10, y: height / 2 }, 2, 'red'); oldNow = Date.now() yield context.canvas; } }30:T69f,# Where Does the Conventional Interface Come From? So I lied a bit. There is a sense in which the conventional API is orthogonal. It describes orthogonal features of the underlying spring system, namely how stiff the spring is (tension) and how much friction there is resisting the spring's movement (friction). Designers typically argue that this nice mapping onto the physical system itself makes the interface natural, perhaps even intuitive. By manipulating the system's properties directly, you can rely on your intuition for how such systems operate. Additionally, spring animations often arise in opposition to more traditional animation APIs that use total duration (e.g. 1s) and an easing curve (e.g. easeIn) to specify an animation. Such animations are more rigid than dynamic ones like springs, because they do not clearly specify what an animation should do if/when it is interrupted. However, I believe we have thrown the baby out with the bath water. By rejecting duration and curve, some designers have argued that because we can't define the duration and curve for _all_ possible executions of an animation, we shouldn't specify them for _any_. **My central provocation in this article is why not specify duration and curve for the _typical_ case, i.e. when the animation isn't interrupted, and then let interrupted cases gracefully extend the default behavior? Especially when such interfaces seem quite natural for dynamic animations, too.** In doing so, we need not lose naturality. However, instead of appealing to the orthogonality and naturalness of an underlying system, we instead appeal to the orthogonality and naturalness of the _emergent behavior_ of that system.31:T9c6,# What About... ## Didn't X Already Do This? Probably yes! The interface I'm proposing isn't new (in fact it's based on equations you'd find in an intro physics course that covered springs), but I would like to see it used more often. ## Overdamped systems? An overdamped system is one where the springiness "percentage" is less than 0 (i.e. the damping ratio is greater than 1). It's really difficult to compute the settling time of an overdamped system, and they act very similarly to exponential decay systems. You might as well just use exponential decay directly, which has an easy-to-compute settling time and a simpler differential equation. ## Overshoot %? This was proposed for React Motion: https://github.com/chenglou/react-motion/issues/265. You have to choose two of overshoot %, duration, and damping. (You can add more factors as well, but you always have to choose two.) In my opinion, damping is more intuitive than overshoot % since it controls how "springy" the animation feels. ## Frequency Response? https://medium.com/ios-os-x-development/demystifying-uikit-spring-animations-2bb868446773 Proposed by Apple. Frequency response is the frequency of the system without damping. This is *really* weird, because the "natural frequency" of the damped system is actually *different* from the frequency of the undamped system, so it is hard to map the frequency response to the output. I would argue that natural frequency is better, but this is just the inverse of the max overshoot time. Plus overshoot time makes sense for critically damped systems whereas the natural frequency of such a system is infinity. ## Settling Time for Underdamped? Settling time is pretty hard to approximate well for underdamped systems. Also it's very sensitive to your chosen precision (is a spring settled when it's velocity is 0.1? 0.001? 0.0001?) whereas overshoots aren't. ## Natural Frequency? This is essentially one over the damping ratio. **(TODO: check that...)**. This is more cumbersome, because common values are distributed weirdly. The damping ratio is more intuitive. ## First Time to Target? Not as perceptible as max overshoot when looking at the resulting animation. It's really easy to tell by eye when the max overshoot happens. It's much harder to tell when the system first reaches its target. Max overshoot also nicely separates the animation into a "time-to-get-there" phase and the "settling" phase. Arguably this one does, too. TODO: how complicated is the computation?32:[] 2d:{"title":"","cells":[{"id":998,"value":"outline\n\n1. header with little demo piece\n2. some context for spring animations. specifically set up the \"naturalness\" argument here\n3. What does it mean for an API to be natural?\n5. philosophical argument about APIs: separate user-facing and system interfaces. what is \"naturality\" really?\n6. implementation: separate system- and user-facing APIS. balance between intuition and simplicity of implementation. picking implementations that are straightforward and tractable","pinned":false,"hidden":false,"mode":"md"},{"id":1131,"value":"This post provides some constructive criticism for libraries. My hope is that I can present a better interface, not drag them over the coals.","pinned":false,"hidden":false,"mode":"md"},{"id":0,"value":"# A More Intuitive Spring Animation API","pinned":false,"hidden":false,"mode":"md"},{"id":505,"value":"viewof overshootTimeBanner = Inputs.range([0.1, 3], {value: 0.3, step: 0.1, label: \"Overshoot Time (s)\"})","pinned":false,"hidden":false,"mode":"ojs"},{"id":878,"value":"viewof springiness = Inputs.range([0, 100], {value: 60, step: 10, label: \"Springiness (%)\"})","pinned":false,"hidden":false,"mode":"ojs"},{"id":521,"value":"// https://observablehq.com/d/3f7c401b5a6fc4ac\nviewof goRightBanner = {\n const form = html`