Prototyping UI for the Internet of Things with FramerJS, Parse and IFTTT


There’s something magical about something that just works. Too often, the ideas that fascinate us catch fire and burn hot while they are novel, only to burn out before they are realized or fully understood.

Recently, I had one of these ideas — and through a contrived set of really impractical implementations I have something to show! Now, I guess I’m writing this because I thought I could explain it to you guys, but I’m not entirely sure how that’s going to work out. I have a hard time understanding a lot of it myself, so I’ll provide quite a few links to reference material I used.

A few of the concepts used to make this happen involve Framer modules, http requests and a basic understanding of JSON, server-side javascript, creating recipes with IFTTT, and a bit of patience. Before getting into how any of this gets put together, I recommend checking out George Kedenburg’s article on using Parse and Framer if this is your first time doing so.

For disclosure’s sake, I’m not affiliated with any of the products mentioned in this post, they’re just what I ended up using to make this thing happen.

what’s going to happen

I set out to make a single purpose utility app for controlling an internet connected light switch I bought a year or so ago (it’s a Belkin WeMo light switch in case you’re wondering). However, you can use any sort of device (or service) that IFTTT has listed.

I decided to use Framer.js to prototype this idea simply because it’s a tool that I already know and use for interaction design professionally. The goal was for user interactions in the prototype to be able to control my lights. Here’s a flow chart that demonstrates what happens in the finished concept:

— Framer sketch serves as the user interface

— Parse stores the current state of the light switch in a database

— Framer sends a signal to Parse when the switch is turned on and off, and server-side code on Parse forwards the signal to IFTTT

— IFTTT tells the light switch to turn on or off based on the signal from Parse

— IFTTT sends a signal back to Parse when I use the physical switch to make sure the state is always up to date in the prototype (more on this later in the IFTTT: issues section)

setting up the interface

The first part to getting this thing off the ground for me was setting up the UI. I drew up some components in Sketch and imported them into Framer Studio for the visuals. I use the Facebook shortcuts module for framer — this allows you to refer to layers created when importing visuals from Sketch without the import prefix. I’m not going to go in depth here, but it’s why you wont find any import prefixes in my code.

I needed my UI to work when the light switch is tapped, but also wanted the switch to be draggable to explore a UI concept of enhanced dimensionality. To do that, I recycled some of Framer master Koen Bok’s code.

You’ll find on lines 4, 9, and 19 the three main functions here that let you separate out click and drag events to trigger different functions!

connecting to Parse

You can refer back to the flow chart earlier at this point — what we need to do is make sure the UI in the prototype reflects the actual state of the lights. You know those 3-way switches that always get mixed up when two switches in your house control the same lights? Check out the cover image — this is already a nightmare in my apartment. We’re going to make sure that doesn’t happen.

This is the only reason we actually need to integrate with Parse for this prototype — we need a super fast way of making sure the UI is in sync with the actual lights when the prototype is loaded. To do that we will refer to a database that keeps track of this, no matter where our prototype is running.

I won’t detail how to get Parse up and running, since George already did a much better job than I can hope to in this article.

Assuming you’ve set up your Parse project, here’s how we tell Parse that the lights should be on from inside of our Framer prototype:

If this part is getting tricky, I’d agree with you — head over to the article I’ve linked above which does a much better job at articulating how this works!

Here’s what my Parse database looks like after the code is up and running. The selected box is the value we’re updating. The “returned” box is for IFTTT to update, but more on that later.

talking to IFTTT: setup

The reason we’re able to make this project happen is because of the recent capability that IFTTT added, called the “Maker” channel. This allows anyone to use a POST or GET web request as a trigger for an IFTTT recipe. Here’s the documentation on IFTTT, and here’s the syntax to use.

Let’s talk architecture for a second — our prototype isn’t talking directly to IFTTT because it needs to know whether the lights are on or off. I’ve found that it’s faster to get a response from Parse than IFTTT, so that’s why I’ve set up a database on Parse that keeps track of this state.

While it’s probably possible to write functionality in Framer to talk to IFTTT directly, I’m using one of Parse’s features called Cloud Code to store that function — there’s a lot of theory here around how much lag we’re introducing to this scenario, but I’ll leave that to the experts.

What is Cloud Code? It’s basically a place where we can store and run javascripit functions by storing the code on a server. To get it set up, I recommend reading this section of the documentation on Parse!

talking to IFTTT: sending & receiving

Here’s what I’m looking at on Parse by this point. I have three simple javascript files — main, iftttOff, and iftttOn. Here’s main:

Here’s iftttOn — its a single function to send the request to IFTTT. The blurred out area is the key you will find from IFTTT when you create an account, enable the Maker channel, and visit this link. Sorry, I don’t want you guys turning my apartment into an epileptic nightmare.

And here’s iftttOff — another single function. The only difference from iftttOn is in the URL string — this is what IFTTT looks for to identify what request it is receiving.

To note: I’ve noticed that the key required for communication with IFTTT can change, and I’m not sure what’s up with that. If your code stops working, doublecheck the key on your IFTTT account to make sure it is still accurate!

IFTTT: issues

There have been a couple less than ideal experiences of working with the Maker channel in IFTTT. Most of these can probably be traced to the fact that it’s only a week old, but others may speak to restrictions that many of us “makers” will run into if we’re looking for a fast and reliable platform to interact with.

Don’t get me wrong — the channel is seriously awesome in its ability for a code noob like myself to start dabbling in the world of cross-device and cross-service experiences to be aware of each other!

Here’s the main issue I’m currently faced with: the original goal of the prototype was to have an app-based experience that reflects my lights at all times. To do that reliably, we need to know if the lights are actually on or off; otherwise, the switch will show the wrong state.

We can track the changes made by the prototype, but this doesn’t take into account if I’ve actually pressed the switch on my wall. Currently, when I set up a recipe on IFTTT to update our Parse database, the recipe won’t run immediately. When the recipe does run, it’s generally 7–10 minutes later, and every queued trigger gets run at that time.

I got a couple of courtesy strobe light shows before figuring this out. While I didn’t receive any complaints from my neighbor, I’m sure they were pretty curious.

Enter the other capability of the Maker channel — sending requests!

IFTTT: sending a response back to Parse

Regardless of the issues I’ve faced, the capability to send a request back to Parse does exist, and maybe you’ll have more luck with this than I did. Here’s how IFTTT allows you to trigger an event back to your Parse database:

The three parts that you need to pay attention to here are: Application ID, Javascript Key, and Object ID. In the URL string, you can replace the all caps strings with the keys found in your Parse project on the Settings/Keys page.

The last part is the Object ID — in this example, the string at the end of the URL is 3fdMr4Iivg. This ID references the single item in my Parse database which I’ll embed again here:

You’ll notice that I’m updating a field called “returned” instead of “status” — the field we’re referencing in our Framer prototype. I’ve set this up as an example for this documentation, and because of the previously mentioned lag that IFTTT takes to send a response to Parse.

wrapping up

There’s a ton of extra documentation for Parse if you’re looking for help while using any javascript environment — it proved very useful for me, and I hope it can for you too!

Framer.js has some fantastic documentation and examples for those interested in prototyping. It’s integration with Sketch and Photoshop is a truly magical experience for visual and experience designers looking to get more involved in the world of interaction and motion design.

Similarly, the framer.js Facebook group has been a fantastic resource for those curious about prototyping in general. Come on over and ask a question if you’re interested in getting involved.

If I’ve missed anything (which I most likely have), hopefully the links in this guide can point you in the right direction.

ok, now it’s your turn!

Get the Framer project or the full source.

Thanks for reading, and I hope you’ll come back and post your experiments back to the community on Facebook. Get in touch on Twitter if you want to know more

Like what you read? Give Rich Zarick a round of applause.

From a quick cheer to a standing ovation, clap to show how much you enjoyed this story.