May 19, 2014
Framer 3.0 released last week! Hell yeah. New site, new docs, amazing amazing new examples to play with and learn from. My favorite new feature is the state machine which is going to be a huge improvement in organizing animations and stateful interactions. There are a ton of other updates, from under-the-hood changes to the animation engine to wide-ranging syntactical improvements. The changelog breaks it down better than I could. And everything is pretty much backwards compatible with Framer 2.0 projects.
Well, pretty much. I decided to upgrade a project from 2.0 to 3.0 earlier tonight and ran into a few small issues. Hopefully this’ll help save you a few minutes if you ever need to do the same. More hopefully, you won’t ever need to upgrade; unless you’re actively working on a project and dying to use the new 3.0 features, I can’t see any good reason to mix the old and the new.
Framer Generator puts files in a different place
In Framer 2, when you run Framer Generator all of the sliced images were exported into /images, with a corresponding views.
Framer 3 places everything to do with your export from Framer Generator in a separate /imported/
There’s no more PSD object
Which makes sense, since half of Framer’s user base probably works in Sketch anyway. But if you have a Framer 2.0 project you probably have plenty of references to the PSD object to deal with. Luckily, you can just add this to the top of your app.js:
var PSD = Framer.Importer.load("imported/yourprojectname”)
As long as you’ve used the newest version of Framer Generator to re-create your assets in the locations above, this is all you need.
draggable is now a real thing
I learned how to make things draggable from this article from Cemre Gungor. Dragging was undocumented and kind of weird and somehow he figured it out.
Now Framer 3.0 makes it easy to enable dragging on any layer, but the 2.0 workaround also throws errors once you upgrade.
// this doesn't work anymore someLayer.dragger = new ui.Draggable(someLayer); // replace it with this someLayer.draggable.enabled = true; // and you don't have to do this someLayer.dragger.on(Events.DragStart, function() ... // because now these events are standardized someLayer.on(Events.DragStart, function() ...
Spring animations are, um, different
There’s an innocuous little line in the changelog: “Animation spring initial velocity behaves a bit different.” I previously wrote about my love for the spring method and whilst that love has not waned, like any relationship I’m having to adapt to change. AND IT ISN’T EASY.
As far as I can tell, the velocity value is now much more sensitive, and larger values have a tremendous impact to the point that any animation where I used velocity values over, say, 100 is pretty much unusable. For example,
spring(400,30,500') used to be a nice dampened bit of subtlety and now springs forth like a coiled king cobra. I got somewhat close to it by turning velocity way down and dialing back everything else a bit to
'spring(300,25,10)'. While I haven’t quite figured out a rule of thumb, I’m going to play around with animations more this week.