It looks like it uses linear interpolation between the different glyphs, which makes it look a bit jerky. The author might want to try a sinusoidal interpolation so that velocity reaches zero at the key frames and the whole thing thus spends more time dwelling on the legible parts of the animation and looks smoother.
One trick I've noticed to make animations/transitions "snappier" and more natural is to use quadratic/square (power of 2) scaling. For fun I did it on this clock just saving it locally - you can do it by modifying line 140 of `bezier_clock.pde` to square the ratio instead of simply assign it:
animationRatio = ratio * ratio; // can also replace with sqrt(ratio)
Again, just makes it a little bit 'snappier' (remember you have to hit spacebar to turn on continual animation), and scales it so you can determine the numbers a bit more clear earlier in the cycle because of the scaling on (0.0, 1.0]. This is certainly a fun piece of code to play with.
I've updated it with quad, cubic and sinusoidal modes. They all look good. Only problem is that because it's no longer linear, the various points can change at different rates and thus create 'kinks' in the curve. When it's linear, the 'line points' and the associated 'control points' are always in a line locally tangential to the curve (don't know the proper terminology but hopefully you understand).
That shouldn't happen if you do the motion transform uniformly on all axes. It should just be equivalent to changing the speed of time, rather than actually changing the trajectories.
Hi all, I'm the author.
Thanks for all the feedback - really good to hear you like the clock. I've added some more animation easings as per your suggestions.
To clarify: when continual animation is off, each digit only animates for a specified amount of time. I set this at 20 seconds for all but the 'seconds' digits, which animate continually. I thought this looked cooler and they're inessential to reading the time.
I'll try and port it to Apple watch / Android wear when they release their proper watch face SDKs.
Wow, that's awesome. Reminds me of Timely Alarm Clock[1] which I use every day and still tout as probably the single most beautiful Android app ever.
However, for this Bézier clock, it would be more practical if the animation was finished before it had to change again, so that we could read the numbers.
Looks awesome, but tens of seconds need to morph faster. By the time 4 is clearly formed and visible seconds read 48. While continuous motion is aesthetic, it is hard to tell time.
Seems like open is a requirement, since not all the numerals are closed and I'm not sure how one would morph between open and closed spines. Playing around here (http://www.victoriakirst.com/beziertool/ anyone know a similar tool that has bookmarkable results so we can share work?) I'm thinking three control points should be achievable (haven't found a way to make a nice looking 4 yet, but most other numerals aren't that hard to pull off).
Fun. I'd say you should have every number at x/60 or whatever of the way between first and next state, including hour and such, but that would probably just result in a bunch of unrecognizable squiggles.
I'm curious about the code organization: it seems that processing.js contains both the application code for the clock as well as the libraries for interpreting the Processing code. Is that true? Is that the best organization? Would it not be better to have have a processing.js which is the interpreter/libraries and a bezier_clock.js?
Per the Processing.js site, you include the processing.js file and then set an attribute on the canvas showing where to get the PDE file (your code). In this case they set it to: data-processing-sources="bezier_clock.pde"
Why does this need a cookie to function?
I block cookies by default and I get annoyed every time some site requires a cookie for something mundane like displaying the time or playing a game that doesn't even preserve state across browser sessions (like 2048)
edit: 2048 does indeed restore the game, but it should still work without a cookie.
It looks like it uses linear interpolation between the different glyphs, which makes it look a bit jerky. The author might want to try a sinusoidal interpolation so that velocity reaches zero at the key frames and the whole thing thus spends more time dwelling on the legible parts of the animation and looks smoother.