Monthly Archives: December 2012

Merry Chr-IFTTT-Mas

It’s Christmas morning and I awoke to find a single email in my inbox.


It’s from a service called IFTTT (“if this, then that”) and it is a friendly reminder that, if I want to make a blog post once a week, it’s that time again.  It even helpfully gives me a link to the blogging site, since I’m inclined to have to look that sort of thing up.

I really like the form of this reminder mainly because I made it myself.  It’s a gift from me to me, made possible by IFTTT.  And it’s just what I wanted!

If I were giving out an award for “best attempt so far at an end-user-programming system” award, IFTTT definitely gets a nomination.  It has three of the four attributes that I think are critical:

  1. Relevance.  It lets people control something that actually matters to them in their lives.  In this case, it’s primarily social networking sites.
  2. Simplicity.  The designers have bent over backwards to make creating programs (“recipes”) easy, friendly, and even a little fun.
  3. Universality.  Instead of each social networking site developing its own end-user programming interface, IFTTT is a single system that works for all of them.  That’s key because it means the investment of time and energy a user makes in learning about one site pays off when applying her knowledge to other sites.  It also means that the user can start to mix and match functionality across sites, which isn’t possible if each site’s interface is independent of the others.
  4. Expandibility.  Unfortunately, IFTTT falls short in this category.  The simple form all programs must take is not completely general and it doesn’t take long before a user can think of a perfectly reasonable program that cannot be constructed within the constraints of IFTTT.

I’ll give you a little tutorial to give you a sense of what IFTTT can do.  (It’s a free service, so consider this description an invitation to sign up and experiment.)  The central concept in IFTTT is that of a channel.  To a first approximation, a channel is essentially a web service that you subscribe to.  IFTTT supports 59 channels right now, with maybe one or two added each month.  (I’ve set up 23 of the channels so far, which often means I need to give IFTTT my passwords to these services.  Hmmm, we’ll need to discuss privacy and security issues another time!)


Most sites that are on my radar are included as channels, like youtube, Facebook, Google docs, and Gmail.  There are a bunch of channels that are on the periphery of my awareness that show up as well, things like bitly, Flickr, and Delicious.  Then there are a bunch that I’m utterly oblivious to and in many cases not even sure how to pronounce, like ffffound!, Svpply, Diigo, and Moped.  Aside from making me feel old and clueless, the presence of these channels doesn’t seem to cause any trouble.

An IFTTT recipe consists of filling in the “this” and the “that” in “if this, then that”.  A “this” is filled in with a “trigger” and a “that” is filled in with an “action”.  Each channel includes these two categories of functionality, capturing a piece of what you can do on the channel’s corresponding site.  I think an example will help make things more concrete.  My friend Tim was writing a personal blog for a healthcare technology site.  I didn’t want to miss any of his posts, so I made the following IFTTT recipe:


It checks the company’s blog feed for new posts that include the phrase “tim’s blog” (something that I had noticed was consistent to all of Tim’s articles).  When this trigger from the “Feed” channel fires, it results in an action from the “Email” channel that sends an email to me with a link to Tim’s writing.  This recipe successfully kept me informed of Tim’s posts and, I hope, will let me know if he starts writing again.

Other IFTTT recipes I use on a regular basis include letting me know (via something called Boxcar) whenever my daughter Molly posts a picture on Instagram, posting a status update for my Facebook friends whenever I put up a new video on youtube, and the latest addition that sends me an email reminder every Tuesday that it’s time to blog.  By and large, I’ve found it useful to be able to make these little programs to fine-tune my online life and then not have to think about them.

One recipe that didn’t quite work was my attempt to log temperatures during the day.   (I’m interested in the question of how reliable weather reports are and can never seem to find data that links predictions to the actual weather that happened!)  IFTTT has a clock channel with a trigger that can be made to fire every hour.  It has a weather channel that includes forecast information and current weather conditions.  And, it includes a Google Drive channel that has an action for creating a row at the bottom of a Google spreadsheet to log data.  These are exactly the pieces I need to collect my own weather data!  Unfortunately, IFTTT recipes are combinations of triggers and actions from two channels, not three.  There’s no way to put together the behavior I want.  I’ve contented myself with a recipe that logs the predicted high and low temperature each day at sunrise.


Ok, not completely contented.  In fact, I’m not contented at all.  I want a language that fixes this kind of limitation.  I’ll let you know when I’ve got it.

But, in the spirit of the day, let me just say that I’m a fan of IFTTT.  Not only have I found it interesting as a case study in end-user programming, but I’ve incorporated into my life and I’m glad I did.  Merry Chr-IFTT-mas, everyone!


Welcome to the Future

My name is Michael Littman.  I’m a computer scientist at Brown University and I’ve had the privilege to work with a team of creative and energetic people at Rutgers University on a project we call “Scratchable Devices”.  Welcome to our blog!

The aspiration of the “Scratchable Devices” team is to help move us to a future in which end-user programming is commonplace.  The short version of the pitch goes like this.  We are all surrounded by computers—more and more of the devices we interact with on a daily basis are general purpose CPUs in disguise.  The marvelous thing about these machines is that they can carry out activities on our behalf: activities that we are too inaccurate or slow or fragile or inconsistent or frankly important to do for ourselves.  Unfortunately, most of us don’t know how to speak to these machines  And, even those of us who do are usually barred from doing so by device interfaces that are intended to be friendly but in fact tie our hands.

We seem to be on the verge of an explosion of new opportunities.  There are new software systems being created, more ways to teach people about programming, and many many more new devices that we wish we could talk to in a systematic way.  The purpose of this blog is to raise awareness of developments, both new and old, that bear on the question of end-user programming.  I welcome email from interested readers who have spotted something cool (, although I don’t claim to be able to present anything more or less than my own personal take on what I read.

In the days to come, I will sift through my backlog of interesting tidbits and then maybe we’ll be in a good position to start figuring out what the future could look like.