|
Sparkle pushes at the boundaries of what is accepted as the "normal" way of doing things. It explores new ways to add computation and programmability to all kinds of everyday objects and surfaces. We've put a lot of thought into its design, and here we explain its raisons d'être. |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Everything is getting computational: nowadays its rare to go 1 day without seeing a new design for ambient computing (etextile, computational walls or paper, etc), and there is a growing library of systems, techniques, and interaction scenarios. The past decade witnessed an explosion in the number and variety of designs that incorporate computation into articles of clothing, jewelry, and other accessories. Some of my favorites include a belt that turns on specific vibrating motors to indicate which way is North (northpaw); a sonar jacket that vibrates to help its blind wearer avoid walls (bats have feelings too); a wirelessly controlled dress that extends stage lighting to the performer's outfit (mysterious night flower); and wallpaper that allows users to control lights, heaters and other devices by touching and manipulating decorative elements (living wall). These are just a few of the many wonderful examples of the pervasive computation movement, but they give some idea of the proliferating research in tangible interfaces human-computer interaction ( TEI, CHI, etc). 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:
We have seen recent projects like Amarino, IOIO, MicroBridge, 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
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
LilyPad Arduino is a pioneering wearable e-textile technology developed by Leah
Buechley and cooperatively designed by Leah and SparkFun. It features unique
aesthetics (color, roundness, sewable tabs with holes, etc.) that has inspired
our own designs. It comes with a large development library and
can be used to create very elaborate and complex projects. Sparkle, on the
other hand, allows you to make intermediate-level designs, with little of
the overhead and time investment that comes with using a more complex system.
They are both useful approaches, and which one you use depends on your
particular needs, budget, and experience.
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.
Once you hook up your circuit, programming with Sparkle is a matter of changing a few sliders or writing a few short lines of code. Consider this complete Sparkle program for responding to data from an accelerometer (or any other sensor for that matter):
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.
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||