Web apps deserve sexy transitions too!

How we designed and built motion into the new Potluck with Framer and Angular.js

Cemre Güngör
8 min readOct 31, 2013


Earlier this week we released a refreshed design for Potluck, which aims to get you new and interesting things to talk about every time you log in.

Our design process was a little different this time. We wanted to change the core interaction of Potluck, without relying on intrusive overlays or pop-outs to explain new behavior to our users. Instead, we wanted to use motion to infer how the site worked, inspired by the physicality of iOS’s user interface. We had been meaning to add motion to Potluck for a while, unfortunately without much success.

Thanks to a couple new tools we now have at our disposal, namely Angular.js and Framer.js, this time we were able to own up to this goal. I wanted to share our experience designing for the web with motion in mind, hoping to inspire you to do the same.

Why motion?

The biggest change in the new Potluck is that the feed is always fresh. The previous version kept read chats in your feed, and if any of them had new activity, they popped back up. This made the feed stale and pushed new stuff down in your feed. We would sometimes end up with couple page scrolls worth of old stuff before new ones.

To achieve a fresh feed, as soon as you opened one thing, it should move and pave way to the next. However, when prototyping this, we noticed it’s very disorienting to have something you just clicked go away. A transition didn’t help either.

Not a great way to Potluck

Using the site this way led to a constant feeling of missing out because of the way items disappeared. But we really wanted to keep bringing in new stuff. How could we pull this off?

We sketched some ideas to eliminate this feeling. The most convincing one was treating the feed as consisting of physical items, and moving items from the feed into the viewer area, making the action feel more like an open than a disappear. This way we could focus users’ attention to the right place –the content– and the feed would reflect an accurate state.

But before I tell you how that turned out, a backstory…

Why is motion on web is so hard

There are a two reasons we’ve found it hard to add motion to our web app in a meaningful way.

First, prototyping and fleshing out motion ideas before going to production is tricky. Keynote is a good starter, but the interactions and transitions doesn’t feel realistic, and it’s difficult to prototype non-linear scenarios. After Effects and Flash have the same weakness, you’re working with a static screen, not a web page you can scroll and interact with. HTML/CSS prototypes are great, but assembling them by hand and having to coordinate code in two different places (JS and CSS) gets tedious.

Keynote is a good start, but soon becomes too limiting.

Implementing motion on a production web app is tricky as well. Animating data in sites that work with regular server-side page loads is impossible. Client side apps don’t make this trivial either, they require mixing presentation-related code with business logic in the Javascript codebase (which engineers aren’t thrilled about). Moreover, CSS transitions don’t play well with state changes, insertions and deletions: you can’t animate the display property, to begin with.

For these two reasons we always treated motion as an afterthought or a decoration that we added at the last stage of our designs. However, new tools help us integrate motion to our design process. This was the first time we started thinking about motion from the very beginning: we ideated and sketched layouts with transitions in mind, and as soon as we had a wireframe, we tested out whether the transitions worked, iterating towards a visual structure that had a sense of physicality.

Sketching down ideas

How Framer helped us prototype

Framer had been on our radar as a powerful and versatile motion prototyping framework, but having to set up the prototype manually meant it wasn’t much faster than old school HTML/CSS prototypes. Framer has a Photoshop exporter that turns a layered PSD file into a prototype, but at Branch we primarily use Sketch as a mockup tool.

What changed everything for us was the Framer-Sketch plugin that Ale Muñoz started to develop. I contributed to the project to get it in a working state, and suddenly we were able to export layered Sketch files into Framer with a single keyboard shortcut. This meant we could make a replica of our site or app, and easily try out all sorts of crazy interactions on it. Naturally, when something is easy and fun, you tend to do more of it :)

It’s crazy easy.

We started with making a simple wireframe representation of the site in Sketch, converted it to a Framer project, and started experimenting with ways to animate opening and closing items in the feed. As someone with no experience in motion design, prototyping in a forgiving environment taught me a lot. For example, I learned that a transition involving many moving parts becomes easier to grasp when not everything is moving at the same time, that subtle delays help a lot. Likewise, a good easing function makes the animation feel more natural. Thanks to Framer, I was able to flesh out all these details before moving to production.

The first prototype I made: a crude fade between items and no easing.

We discovered some tricks along the way: for example, fading the small card into the large card doesn’t look great, because they have different proportions and content. But we can fake this if we mask each item inside its container and animate quickly enough. Watch it in slow motion:

Testing let us eliminate ideas that would be distracting in use, or just wouldn’t make sense. For example we realized physically moving items into the My Chats section was a little too crazy.

Prototyping with framer helps us get a sense of how motion would play out in a real browser environment. What we end up with isn’t a fake animated mockup– it is a web page where we can scroll and click on things to make them react. The sense of reality made us more confident to move forward with these ideas and actually implement them.

How Angular helped us make it real

Another tool without which this wouldn’t have been possible is Angular. We built the entire Potluck app with this fantastic frontend framework that’s maintained by Google.

Angular is friendly to designers, since it makes it easy for us to add different classes to elements depending on their state, without writing any Javascript. Being able to easily attach classes provides us with one degree of ease when it comes to transitions.

Easily adding classes to elements depending on attributes…
…then animating upon these classes

This is how we make the card fly out from the feed.

A couple CSS animation tips we discovered along the way:

  1. You can animate many elements at once without a performance hit if you animate CSS attributes that can be hardware accelerated. So instead of changing say a left or margin-left attribute to move something, try using a CSS3 transform: translateX. This way the browser doesn’t have to recalculate the page layout during the duration of the animation and can offload the work to the GPU.
  2. CSS transitions are useful to transition something back and forth, but it gets tricky when you want to animate in only one direction. For example, we want the feed cards to pop out, but not pop back in. CSS keyframe animations work great for this. Instead of changing attributes directly on the class we add, we execute a keyframe animation that changes the attributes. When we remove the class, there is no transition backwards.
  3. There is a little-known CSS attribute that makes an element stay in the final animated position even after the animation ends! Check out animation-fill-mode.

In a recent update, Angular also got extensive support for animating the data layer as well, with the ng_animate directive. This means adding or removing items or switching between views with transitions is also much easier. Angular does all the dirty work to make these possible (If you’re curious watch this video).

For example, we used ng_animate for the enter / leave transitions between chats. In this case Angular is smart enough to keep the DOM elements of both chats on the screen at the same time, assign the entering animation to one, and the leaving animation to the other. It’s also smart enough to infer when to remove the leaving element from the DOM by looking at how long the CSS animation lasts.

What’s next?

This was our first serious attempt at adding motion to our web app: we started with a limited scope, just our main feed. We’re planning to improve this core interaction over time, and add transitions to the rest of our site as well. There are still challenges: browser support for animations is not great, and performance is an issue especially with non-webkit browsers.

We think these changes make Potluck not only more useful, but more fun as well. We’re excited about the possibilities and looking forward to seeing more motion on the web.

Head to Potluck.it and check out our new feed with the spiffy transitions mentioned in this post!

What are web apps that integrate motion to their interface the best? My favorite is iCloud.com– I think it’s at the forefront of how fluid web apps can be. Reach out on Twitter at @gem_ray and let us know!



Cemre Güngör

designer turned grumpy pm. co-founder @joinbranch (acq by fb).