Designer / coder, and not the other way around
How I ended up adding FramerJS to my creative toolkit
I’m not much of a coder.
I can read it a bit, I can wrap my head around the concepts, but I’ve never mastered a language.
Don’t get me wrong — I can write you a basic HTML / CSS layout. This much I remember from the rudimentary “digital” portion of my decade old design degree.
Despite occasionally jumping into various Android, iOS, or web language courses, I never see them through.
I have both professional and personal interest in understanding the full creative journey from sketchbook to working software. At One Education we have a small team, and we need to wear a lot of hats. I’m able to grok the concepts behind loops, functions, and various equations. Why am I always ditching this?
It wasn’t until I started experimenting with FramerJS that I began to grasp the answer.
The design degree is the problem.
Not only am I a very visual guy, I’m used to seeing the most immediate results possible from an action. This is what I’ve done for years, I’m used to it, I expect it.
If I can’t make a change and realise the full satisfaction of seeing the effect, then I’m not sticking around. In a world where static design is being replaced by interactive prototypes, my inability to knuckle down and slog through a simple Codecademy course isn’t helpful.
When dealing with external agencies I’ve spent a lot of time trying to convey just how I want an element to slide into place, the rate at which an object should fade away, or the degree of rotation when the user pushes it aside. We usually get there, but the sheer amount of back-and-forth conversation involved is distressing — particularly when you’re paying by the hour.
Even now that we have a very talented in-house front end developer, the journey from “Make it like this!” to “Yes! That’s it!” has far too many instances of “No… more like…” and “Hmm. Not quite.” along the way.
It’s not the developer’s fault.
This stuff is hard to communicate. A basic layout can be drawn on a napkin in moments. The exact timing and feel of how a FAB might behave would take many annotated napkins to describe. My regular tools just weren’t cutting it, and I hate annotated napkins.
As a result, I began to try out a number of other tools. I have rated them in disgusting napkins. Less napkins means less time spent trying to explain things.
In short: less napkins = better.
I began my journey with After Effects. A natural, familiar and safe space for me to begin experimenting. Raised on Adobe tools, I could quickly put together sketches in After Effects that illustrated what I wanted. Sending these to the developer reduced “Not quite right…” instances by a small amount.
Less than I’d like though. Videos are not well known for being interactive, and I was still having to annotate.
“So it does this on repeat forever, but if you click it, then it does this — I play a second video — and it stops doing the other thing on repeat until you click it again.”
Not only that, but unless I documented and conveyed each individual timing value on my own, things weren’t going to look quite right. It’s hard for the developer to know that I meant exactly 0.2 instead of 0.5.
After Effects wasn’t perfect, but it gave me a taste for what we could achieve when I started taking a more direct hand in the matter. If I’m trying to reduce from 10 metaphorical annotated napkins to 1, then After Effects got us down to about 7.
Next I took a crack at solving the problem with UXPin. UXPin has fantastic tools for getting your static layouts together quickly, and linking them together to move between said layouts. Reminiscent of Balsamiq in ease of use, it has a massive library of stuff to drop in — I could draw less, build faster, and assign basic animation when events occurred.
Clicks, page load, and various other options gave me a number of events to work with which in turn triggered a range of simple animations. Rotation, translation, opacity adjustment, but not much else. The setup was heavy with menus, mouse-clicks, fraught with moments where I’d applied the an “interaction” to a button on every page but one. Sometimes the end result was a bit janky too, save something in one place, and it loads slightly off centre.
UXPin is again fantastic for very quickly building a set of linked layouts, but the animation implementation wasn’t going to cut it. Between 5 and 8 annotated napkins, depending on what you want to do.
Hello beautiful.
Pixate promises to be the thing we need. A straightforward, largely code-free tool for creating smoothly animated, interactive prototypes and sketches of ideas. Import sliced up designs as layers, drag and drop a series of commonly used interactions (swipe! long press!) and then link those to easily defined animations.
Sounds pretty great, right? It is pretty great. Unfortunately Pixate also carries a number of the same burdens as After Effects. I need to slice my designs up into individual images to import them manually, and while the produced result is interactive, I still need to provide a alot of the values used for the developer… and it never really felt like I was able to build a project that moves between multiple views.
Hmm. Almost. Not quite.
It’s worth noting that Pixate have recently launched the ability to share code snippets between users, which should massively increase efficiency if the community takes it on. They’re also planning on implementing some form of Photoshop & Sketch integration (why does no one integrate with Illustrator?) Most importantly, there are plans for Pixate projects to export as usable code — something that can be handed straight on to the developer.
I’m absolutely going to be keeping an eye on Pixate, and revisiting it in the future. The current incarnation carries an annotated napkin rating of 4.
At this point I’d whittled my options down to two.
Facebook had recently released Origami 2.0. Photoshop & Sketch integration? Check. Reasonably code-free? Check. Multi-view project examples in evidence? Check. Supposed to output some kind of code? Check. A community to fall back on? Check. Alright, let’s try it out.
After getting through the weird rigamarole of setting it up, registering as an Apple Developer, installing Xcode, I loaded an example project and was confronted with this:
I balked. That “I’m a visual kind of guy” thing was not working in my favour here. This is so messy. I clicked on things, and they didn’t react. The interface was strange and unintuitive, Origami is essentially a very clever Quartz Composer hack, but unfortunately it felt like a hack. The tutorial page linked to 15 minute videos, and I far prefer a written guide I can follow in my own time — particularly when I’m learning in the office. I’m sure it’s my own expectations that caused a problem here, but I didn’t get a lot further.
Napkin rating? Undecided. I ran away.
It’s always in the last place you look…
Still reeling a bit from my experience in Quartz Composer, I turned my sights to FramerJS. Framer was last on my list for one simple reason: code. As mentioned at the beginning of this article, my adventures in coding never last long despite my best intentions.
However… FramerJS ticked a lot of other boxes. A big community, the option to use an open source version, massive flexibility in the project examples, Sketch & Photoshop integration, and it inherently provides information that your developer can parse, if not paste in.
Open an example project in Framer Studio and urgh, code. But… simple code, this is kind of like HTML / CSS, something I have a certain familiarity with. Similar to Pixate, if I change a value here, I immediately see the effect over there.
Integration and immediacy makes it magic.
I got the sense that if I knew what I was doing then I could tweak things very quickly. No complicated menus to click through, a benefit of code.
The CoffeeScript formatting is easy to read, and while some of the functions in the example are alien to me, my brief foray into JavaScript enabled me to read the context around the specifics. This seemed to be a machine I can tinker with and observe. That’s a good sign.
Documentation for Framer is almost too simple. You’re given straightforward examples of small tasks you can perform, and how to perform them, and you’re encouraged to see what happens when you modify them. No videos here, just check out a GIF of the end result alongside a snippet of code and brief explanation. I quickly worked through these, taking the time to type each individual line.
No problem.
With that done, it was time to try and build something of my own. A test of my understanding, nothing fancy, let’s just see if this is viable. Open Sketch.
Shortly after, I have this.
It’s not sexy, but it has potential for playing with moving parts.
The first thing I learned is that an extra minute spent on grouping and naming Sketch layers in an organised fashion, makes a huge difference in Framer.
The second thing I learned, is that importing and re-importing is a cakewalk. Updating a design on the fly without breaking the work I’ve done in Framer is great.
The third thing I learned, is that I can do this.
That last one may seem a bit naff, but it’s important. In previous self-improvement expeditions, there were hills to climb before I reached the point that dealt with visuals. Finicky formatting to learn, rock-paper-scissors text applications to build, none of which I cared about.
Framer was giving me instant feedback about the only things I cared about — the look, feel and experience. That feedback was propelling me onward, it was an “Ah hah!” moment. Instead of feeling like I had to recreate my design, and then animate… it felt like I was building interactions and animations on top of my design.
The sense that I was continuing to create was satisfying.
It only took me a few hours to go from “I’ve never done this before” to “Hey, look what I made!”
The next time I had to illustrate an idea to the front end developer, it took minutes, and he was able to quickly pull all the appropriate values out of my CoffeeScript and apply them to his preferred framework.
I’m impressed.
Over the last couple projects I’ve used Framer for, I’d say it has reduced the metaphorical annotated napkins down to around 2. Maybe even 1.
If you’re getting into the interaction and motion space, I would highly recommend trying it out. If you’ve never dabbled in any kind of code before, you may want to go straight to Pixate.
Even if you’re lacking that technical bent, Framer is worth a shot for the simplicity of integration, implementation and the immediate feedback.
Perhaps you’ll learn a little bit about how you approach tools and learning.
You might even be surprised at how well it removes the devil from the details.
P.S. If anyone out there in Medium land has experience with the tools listed above — I’d love to hear your thoughts on them! Should I try out Origami again? Did I misunderstand Pixate? Let me know ❤
