Using Framer (and only Framer) to Prototype Google Photos on the iPad

8 of 100

My goal is to create 100 prototypes of interactions from some of my favorite apps. I know my way around Framer a little bit, but there is always room for improvement. Using Framer to recreate existing apps should be an effective way to practice and refine my craft.

Nº 8—Google Photos on the iPad


Framer shipped their much-hyped, much-anticipated release last week which introduces some sweet design functionality, like the pen tool and boolean and boolean operations (like for combining shapes). Basically, they have tried to create an application that can be used for all of your design needs and your prototyping needs. Although this particular prototype didn’t need much by way of icon illustration, I was still able to do the entire thing without Sketch. Designing in Framer was delightful.

With regards to the new design tools, the pen tool was probably the most intuitive one I’ve ever used. And the boolean operations actually worked. I mean, Sketch has been farting around with their boolean functionality for almost five years—and I still don’t think it’s quite right.

I used a total of six shapes to make this wifi signal icon for my status bar. Boolean operations for the win!

The only hiccup I experienced was not exactly understanding the Frame tool. I was still thinking of Frames as Artboards, and was temporarily frustrated that I couldn’t ‘target’ the shapes I’d created to be used in code. But I figured it out eventually. If only I’d read the release notes first… 🤔

I created a bunch of boxes for the images, made them all ‘frames,’ named them, and targeted them to be used later in code. I had hoped that there would be an image fill option in the design tool too, but no luck. Still, I was able to take care of it in code, so no big deal.


All I wanted to do with this little prototype was mimic the interaction of tapping into an image. Since I’d named and targeted all of the image containers, I used a for loop to add the state, the interaction, and the animation to each of them. I used the stateCycle property to tap into and out of the detail view.

for img in imgs 
img.states.detail =
x: 0
y: 224
width: Screen.width
height: Screen.width * 0.75
img.onTap ->
this.stateCycle("detail", "default")

I also needed to show the black detail view background, so I created a state for it and added the animation into my for loop as well:

img.onTap ->
detailViewBG.stateCycle("active", "default")

It was at this point that I started to see some bugs in my prototype. All of the images were working as expected, except the first row. For some reason they were expanding into their detail view state, but weren’t returning to their original location and size when I tapped on them again. But the detailViewBG object was fading out, so I knew the image was receiving the tap. It was bizarre. I refactored and added a little conditional complexity, which solved it for me.

for img in imgs 
img.states.detail =
x: 0
y: 224
img.onTap ->
if detailShowing == false
width: Screen.width
height: Screen.width * 0.75
time: 0.08
opacity: 0
detailShowing = true
controls.stateCycle(“hidden”, “default”)

In the snippet above, also with using my boolean variable detailShowing to determine what should happen when an image is tapped, I also realized that in the Google Photos app the user needs to tap the back button to exit the detail view. Tapping the image again in detail view toggles the controls in that view, so I wired it up to do the same thing.

A module was critical to pulling off this prototype so easily. I was able to find a module hosted on Github that did exactly what I wanted to do: fill each image frame with a random image. The this helpful module pulls images from and uses them to fill the specified object with that image. It even allows you to specify a search term, which is helpful if you really only wanted images of food. So, thanks to my for loop, all I needed to add was the single line of code to let the module work its magic:

for img in imgs

At this point, the prototype was done-ish. But there was a minor detail in the transitional animation that wasn’t quite right. My images seemed to be animating to the detail view in a straightforward way. In the actual Photos app, the images almost appeared to be following a curved path as they animtated into place.

As luck would have it, animating along SVG paths is functionality that was released in their newest update. But, as I experimented with it, and then more closely examined what was going on in the actual app, I decided that animating along a path wasn’t what I needed. It seemed like the images in the app were expanding to their full size faster than they were moving to their new position in the detail view. Once I mimicked that behavior, the result was much closer to the real thing.

Regrettably, I would have liked to also include the drag to close functionality, where an image in detail view can be dragged up or down to return to the main view. I ran out of time and my initial efforts were unfruitful. I decided it wasn’t necessary and moved on.

Lesson Learned

Besides all of the great, new experiences with Framer’s recently released design updates, what stood out to me most about this particular prototype was that (at least for me) blocking in a prototype is pretty easy. It’s the refinement and perfecting of all the little things that takes the bulk of the time. It’s like it takes 50% of the time to finish 90% of the prototype. But that last 10% is killer. I could do better at stopping and saying, “It’s good enough. It’s just a prototype, for crying out loud.”

Go Check Out This Prototype

Feel free to download my prototype and poke around in the code a bit (the link is repeated below). But don’t judge me — prototyping isn’t about writing clean, elegant code. It’s about doing just enough to communicate the intended experience.

Tapping into Photos in Google Photos for iPad

One clap, two clap, three clap, forty?

By clapping more or less, you can signal to us which stories really stand out.