Supercharge your Framer prototype with Firebase, pt.1
This is a follow-up series to
’s Using Parse to power up your Framer prototypes and Give your Framer prototypes a better memory. Both articles are, by the way, warmly recommended as an intro to this post.One thing that will immediately catch your eye over at
’s articles is the sad news thatUnfortunately as of Jan. 28th, 2016, Parse is no longer accepting new users and the service will sunset on Jan 28th, 2017.
The King is dead
With the well-beloved Parse now slowly sailing into the sunset, the
Google-owned Firebase stepped in quite aggressively, and I’d say successfully so, trying to secure Parse’s former spot as the go-to
Backend-as-a-Service.
These services, in case you’re wondering, offer app developers a range of backend features, often including push notifications, user authentication and, most importantly, a database to store app data on.
“But why would I, a designer and Prototyper, even care about such services?”
After all, we’re working on frontend stuff, things people directly interact with, right? Why would you ever need a BaaS for that? Well, …
My quest to become a true(?) Full Stack Prototyper
To make my point, please allow me to tell you a short story. Almost to this day a year ago, I was asked to prototype some sort of messaging app, think Successful Messaging App X meets Successful Messaging App Y, to — bluntly put — see if it’s fun and therefore worth developing.
So I did my usual prototyping thing: Started off with some wireframing, followed by designing a rough mockup of a visual interface and finally made some of its elements interactive by using Framer. You know the drill.
In the end, the prototype would let you input text, enclose some other stuff by using some custom interactions and to “send” the message. I was pretty happy with the result and at the time and we internally thought that it did a solid job of capturing the concept and the overall spirit of the app. So we moved ahead and presented the prototype to our client.
At that meeting, we then all collectively agreed that, while some of the unique interactions were kinda fun, they were not fun enough to justify putting some serious money behind it. Long story short, we shot it down and decided to move resources to other, more interesting projects of that client.
Here’s the kicker, though: The prototype we presented really shouldn’t have been used to make that decision, as it didn’t actually include the core interaction of any messaging app: Communication, you know, sending and receiving messages with real context. Now, while you could “send” your fake message, no matter how long you’ve waited, Jane Doe would never ever respond. And needless to say, in that regard it was as much fun as talking to a wall. It’s like judging the performance of a race car by its look.
So, maybe it had the potential to become the next Snapchat (unlikely) or
Yo (more likely; by the way, do you even remember Yo?), but we just weren’t able to see “it”, as the prototype simply didn’t allow us to properly try and field test it. And isn’t that what we’re actually paid for?
Yup, I’m personally guilty of this potential $20bn prototyping fuck-up by making wrong decisions in regards of of scope and execution and for keeping my mouth shut about it like a true coward. The point I’m trying to make is:
As a Prototyper, you can’t “just fake” or flat out ignore the core interaction, just because it’s out of your comfort zone.
But that’s exactly what I did. In my defense, though, I didn’t know any better at the time. Getting a prototype to actually send and receive messages seemed almost impossible to do, especially considering the very limited resources that were allocated to this prototype. And to be honest, the possibility of making it (kinda) work for real didn’t even cross my mind back then.
Sure, somewhere in the back of my head I knew Parse (and later Firebase) would allow me to do exactly that, but the sheer volume of its documentation alone scared me off — after all, it was tailored to Full Stack Programmers, not Prototypers. What I, and I know for a fact I wasn’t the only one, was looking for, was a backend solution that was lightweight, easier to use and more in line with Framer’s lingo and logic.
For some reason though, little to no progress was made in that area since
’s original articles. Considering all the great possibilities of such a prototyping-friendly backend solution, I thought that was a real pity, so — despite my modest programming skills — I decided to something about it myself.Prototype the “impossible”, delight — with the power of data
Fast forward a year and all it takes to include communication between multiple devices is a five minutes setup and about
two lines of “database” code, using my freshly released Firebase module:
Framer + Firebase is a really strong combination, allowing you to do stuff you haven’t even dreamed of before, like the actually working messaging prototype I’ve blabbered about above, or the world’s first(?) bubble popping MMO, as seen below:
But it’s also great to “just” delight your testers or clients by adding some unexpected gems to your prototypes, like persistent Like-counts, user-data and session states. Small, interactive bits that make your prototype appear more like the real deal, effectively blurring the line between a prototype and the finished app:
- Working on a crowd-geotagging app?
Use the Firebase module to load, save and sync map pins between all your testers, in realtime. - That social network thingy you’re working on?
How about making that sign-up, login and onboarding work for real? And while you’re at it, why not let your testers actually post and share their content? (Yes, even base64-encoded images!)
Or use the module for something else entirely, like:
- Remote control
Let a prototype control another prototype, running on a different device or form factor (think phone ↔ TV companion apps). - Behavior analytics
Track user interactions for quick and precise behavior analytics, answering burning questions like “How long did it take our testers on find that new button?”. - Reusable assets
Save and load project assets (e.g. brand colors, spring values, layer properties, etc.) to Firebase and use them across multiple prototypes. No out-of-the-blue rebranding will make your prototypes look dated again.
And I’m sure that’s not even the proverbial tip of the iceberg of what you could use this module for.
Intrigued?
Then hop over to Github and give it a spin! Can’t wait to see how you’ll use Firebase to supercharge your Framer prototype® 😜
Thanks for making it all the way down here! I’d really appreciate your feedback on this article and the module. Also, please don’t hesitate to get in touch with me in case you’re stuck at some point — I’ll be happy to help.
Special thanks to
, , , , and for their early feedback on the Module and this article. You guys rock!If you have suggestions for topics you’d like me to include in Part II, I’d love to hear them.
You can reach me via Twitter, Facebook or Slack.
PS: Coming up next is a Particle Module, with the rather ambitious goal of bridging physical- and On-Screen-prototyping (think IoT, car dashboards, etc.) and a Facebook Graph module, which allows users to log in and retrieve personal data from — you guessed it — Facebook.
PSS: I’m currently looking for internship opportunities with companies serious about prototyping.
