However, the current paradigm for pervasive computers exhibit an intriguing "blind spot", one that is rarely discussed: namely, how all these devices can be (re)programmed, by the end-user, in the same physical context of use. In essence, our interactions with computation is increasingly moving away from the desktop computer, but we're still writing programs for pendants, bracelets, skirts and walls from the computer. The context of use has become physical, yet the context of creation remains virtual, within the confines of the glass tube.

My first inkling about the need for a different way to write and distribute programs came from a 2005 summer collaboration with Jean-Baptiste Labrune and Vincent Roudaut on a series of color changing artifacts. Essentially, we embedded microcontrollers, sensors, and tri-color LEDs into various (tiny) objects: rings, pendants, bracelets, hair pins, and so on. Our intent was to add a little bit of computation to small everyday objects, to make them glow or make sound in response to changes in ambient temperature or light; to make them capable of storing small bits of information; and to have them communicate with each other and possibly with smart elements embedded in walls.

As our portfolio grew, I found it irritating that despite all our effort to make these devices tiny, self-contained, and cheap, we would still need to add "useless cruft" like USB or Bluetooth support in order to talk to it. It was no consolation that you could use plain old RS232: some of our designs didn't have space for a crystal, voltage inverter, and certainly not the port itself.

My rant: "This pendant already has a way to detect light, temperature, or sound. Can't we just use those to send new programs? USB is not a simple protocol and you need a beefy microcontroller just to talk to the computer. All I want to do is change the timing of the light patterns! What if I wanted to change the program on the fly, and I didn't have my computer and programming environment with me? Would I have to lug my laptop around just in case I wanted to reprogram my pendant? Ridiculous!"

I felt strongly that just as small embedded computers need no longer sit on a desktop, the act of programming can and should take place in a variety of settings and physical spaces as well. We should be able to augment or replace running programs "in situ" with programs scattered throughout the environment. There is no reason we can't imagine bits of programs represented in paintings or a favorite book cover, encoded in stockings, "barcoded" into floor tiles, beamed from necklaces, or embedded in songs. Some of these ideas were explored with the code road, a robotic car that reads and executes bar-coded instructions spread around a room.

There are some fascinating scenarios that are suggested by this approach to programming: as you pass a particular spot in an art gallery, perhaps your dress downloads and runs a program previously embedded by the artist into a painting. Want to change the color-changing patterns of your pendant on your way out to a party? Tell your smart pendant how to change colors using your phone. You want your shoe to tell you which way is North, or to change color with the number of steps you've taken? Whistle a new program to it. These are the sorts of ways I wanted to interact with wearables, not the old traditional model which involves fishing out a cable, connecting it to a computer, and writing in a language designed for a different computing era.

Sparkle is a very early exploration of this style of programming, and there are 4 goals that continue to influence design decisions:

• ambient programming: it must be programmable from a variety of sources, including mobile devices, with no installation or wires,
• "low tech" programming: instead of high-tech and computationally intensive methods like Bluetooth or USB, programs should be encoded with visible light, sound, or motion, which leave open the possibility of embedding programs into physical media like tapestries, railings and paintings
• small size and low cost: it should be as small as possible so it will be used in all sorts of interesting objects, some of which we cannot yet imagine
• easy to use: we believe you should spend your time and effort on the design, and not on the electronics

We have seen recent projects like Amarino, IOIO, , and the Android Open Accessory Kit, which enable you to program things from certain mobile phones. However, you still need a USB port and/or Bluetooth module; you still have to install a development platform into your phone; and still have to fiddle with low-level details like registers, ports, and bits.

By contrast, Sparkle programming is done right from a web browser, with nothing to install, using visible light, in a high-level language suited for the task. These properties allows it to be tiny, ubiquitous, cheap, simple to hookup, and easy to use. It works with any smartphone and any graphical web browser.

Picture credits: Lilypad Arduino and ruler from SparkFun Electronics
 
 
 

This first table shows what you would need for a basic project that flashes 5 lights in a programmable pattern. Sparkle uses a 3V watch battery, and internally boosts this to 5V. Lilypad uses either AAA or lithium ion, and requires an external power supply/booster.  
 

This second table shows what you would need for an intermediate-level project that senses something in the environment (temperature, light, motion, etc) and turns on lights in response. In this case, you would need to use smart lightboards for Sparkle instead of plain LEDs that LilyPad uses.  
 

(always
  (if (> sensor 5)
    (twinkle 2)))

The smart sensors and the high-level language enable you, the designer, to think in high-level terms, and not at the low-level of bits and bytes.

With other devices like Arduino, Lilypad, etc., hooking up was just the beginning. Now you may need to devote significant time to learn about about port manipulation, pulse width modulation, voltage dividers, analog-digital converters, and a whole host of technical jargon that you may not be interested in.

Of course it is useful to learn about such things, but it should not be an obstacle course to your finished design. This is useful for several reasons: you may have a limited amount of time to make a project; you are teaching a younger audience and need something that works without delving into details; you may want to focus more on design, not on embedded programming and electronics.

To make an analogy: one needn't learn about memory allocation or hypertext transfer protocol before writing a blog. If learning those details are central to what you want to do, then by all means dive in, but if they are only a means to an end, they should not be front-and-center in your creative process.