Let's Interact

Make a module. This is the kind of assignment that is always better in retrospect (as this tardy write-up can attest).

Thinking about modules and the arenas in which they frequently appear led me to some interesting insights, not the least of which was a clear idea of the connector I want to build this coming week.

A module encapsulates a functionality within some larger, more complicated system. When properly designed, it can be joined smoothly with existing modules of the same or different types. Modular furniture, trains, pre-fab architecture, object-oriented programming, modulated and demodulated data streams, toys, and space stations are all modular because modularity makes decorating, managing freight, building, coding, communicating, playing, and not dying in a vacuum easier and less error prone, even in the presence of significant future uncertainty. Think back to Powers of Ten—the entire universe is modular!

I started my exploration of modularity by making modules of something homogeneous, which if my notions above are true achieves no added efficiency or ease through modularization. I peeled and sliced a banana such that the slices could be interchanged within the peel. Then I ate it. Not quite the robustness I was aiming for.

I then toyed with creating a code-based exploration of image pixels and letters (by translating one into the other so that an email might be encoded as an image composed of apparently arbitrary pixels), but the spatial advantages of modularity were just too compelling to ignore. You can place a modular couch in a space of any shape! Have a corner? It wraps around it! Straight wall? It becomes a love seat for twenty!

But how does one modularize without atomizing, without simply breaking something big into identical smaller segments? By separating functions the way code does. For some reason, I immediately thought about clothes and those zip-off sleeves from the Eighties. Clothing’s modularity (at least wearable clothing’s) is anatomically constrained. In theory I could make pants that accept as many legs as you care to attach—fun maybe, but not so useful.

Thinking about pant legs got me thinking about the make-up of clothing more generally—and led me to pockets. Most of my pants have at least two sets of pockets: the side ones that are sewn into the garment and the back ones that are sewn on. I carry lots of stuff in my pockets and I don’t ever seem to have enough room, and I prefer the bulge of a full exterior back pocket to the chafing of a stuffed inner one, though I can’t stand carrying things around where I can’t see them and inevitably crush them when I sit too enthusiastically. The answer?

Modular magnetic pockets. They can be attached to any part of any garment using a discreet, low-profile magnetic strip (or wadded up and crazily sewn elastic as in my prototype) that lies flat along the inside and firmly attaches the pocket to the outside.

And if it’s not in use? Just put it in your pocket.

This week’s cinematic challenge was to create the visual equivalent of Hemingway’s terse but complete “For Sale: Baby shoes, never worn,” a microcinematic three-shot story. I composed and shot a story about putting an egg carton with only two eggs left in it in the fridge and opening the next morning to find the two eggs snuggling cozily in adjacent spaces, surrounded by half a dozen quail eggs. Then I read Robert Bresson’s Notes sur le Cinématographe, and it made me think that maybe I shouldn’t force the egg to tell a story but rather to capture the story inherent in the egg.

The Lumiere brothers made evocative and expressive films without camera movement, zooms, sound, or more than about 60 seconds worth of film. To learn how to see again and tell stories again, maybe we should too—at least according to Andreas Haugstrup Pedersen and Brittany Shoot’s Lumiere Manifesto. I am of the mind that their collection of one-minute silent, unedited, and effects-less films requires no such justification, but I’ll answer their call to arms, even if it does smack a little of filming floating plastic bags a la American Beauty.

There are beginnings, middles, and ends throughout my morning routine. They are predictable and irreversible and progress along parallel trajectories. Watching them closely makes me hate mornings even more.

When I semi-glibly stated that the thread that runs through most of my work is a kind of “sublime uselessness,” I hadn’t really thought through the idea of use. When Despina asked me to make something useless, I was sure it wouldn’t take me long. After a week, I’ve revised my thinking.

Something useful is something that has a purpose, that catalyzes an action to bring about a desired result, intentionally or not. That’s a definition I’m happy with. The problem arises when defining its opposite, the absence of utility. The concept seems straightforward enough—something useless is something that has no purpose, something that brings about no desired result. But the very rational nature of our brains makes such a thing impossible. There is no thing, concept, or thought which our brains can conceive to which we cannot ascribe some hypothetical use. Pathological hoarders suffer from an acute sensitivity to the possible uses of things most of us would cast aside—”I might one day need to reread this article” or “I know this pot is broken but what if some day I need shards of pottery for an art project?”

How can I make something useless?

Because every single thing I can think of, including Jorge’s devilish milk stain on white pants, fulfills this particular assignment, everything has a use. The only truly useless thing is that which my mind cannot conceive, but how can I make something my mind cannot apprehend? I can’t, so I do nothing. I make silence.

Conceptually cool, but a cop out. So while technically what I cannot conceive is the most useless thing I can make, I chose instead to unpack the various possible meanings embedded in the “make something useless” directive and combine them into the greatest possible degree of uselessness.

There are degrees of utility. A Swiss Army knife is more useful in most situations than a stale madeleine. Not always. If you’re starving to death, a Swiss Army knife might not be of much use, but I’d argue that considering every possible situation, the set of situations in which a Swiss Army knife’s utility outweighed that of a madeleine would be significantly larger than its opposite.

My goal at the outset was to identify different types of uselessness. My initial impulse was to conflate an object’s uselessness with the inability to extract profit from its production, largely in response to those Winter/Spring Show visitors who watched me heat up ice cubes with a hairdryer to trigger MIDI sound loops of urban noise or leaned over to smell my scratch & sniff television screen only to shake their heads sadly and ask, “So how are you going to make money with it?” That is roughly equivalent to saying that something is useless if no one wants it. That’s all sorts of problematic. Especially since I can (and frequently do) imagine some eccentric art collector finding this aspect of my work highly desirable and worth many buckets filled with money. There’s no accounting for taste, and because every conceivable object/concept has a use, one must assume that at least one person will want it/be willing to pay for it. Neeeext!

What if the emphasis is on make rather than useless? The directive then becomes to take something’s intended use away from it. I glued an empty jar shut. I cut out all the page numbers in a table of contents. I thought about taking the wheels off of my asshole downstairs neighbor’s bicycle. All of these objects retain many secondary uses—the jar can be used as a weapon, the table of contents will serve as toilet paper in a pinch, and the bicycle frame can be melted down and used to make sadistic steel implements with which to torture its owner—but they no longer contain, index, or transport. That seemed like a promising start.

If what is removed in this last case is the principal verb that an object or idea accomplishes, another type of uselessness results from removing an object from the context of its usefulness. A handle that is attached to nothing is useless. Similarly, directions received in a language one doesn’t speak are useless, as are democratic institutions in a society structured around clans.

Then there are closed loops of utility in which a thing reflexively uses itself, minimizing other subjects’ possibilities of finding it useful. A website that destroys itself as soon as you visit it. A candle burning in an empty room. The problem is that this reflexivity threatens to become beautiful, and beauty has all sorts of uses.

Ultimately, it was this realization, along with my visit to the Bauhaus exhibit at MoMA that so gleefully described the fetishization of function to which we still reverently bow almost a century later that led to the final form of my idea, the Porcupencil.

I combined two archetypically useful objects—the pencil and the razor blade—in such a way as to obviate their principal uses without obscuring them, resulting in an object that discourages its own use. I don’t think I made something useless, but I certainly limited the possibility space and context in which it is useful.

And it looks nice too.

I was just thinking about how much I’m looking forward to starting classes again. For some reason, though, I can’t seem to think anything positive for very long. No matter that this past year and a half has been the happiest and most productive of my life or that even the worst day at ITP is better than the best day at any job I’ve ever had, immediately my mind looks for the cracks (minute though they might be), pisses in them, and waits patiently for temperatures to drop below freezing.

So the one thing I really don’t like in class is when people decide that they have something to say and must say it immediately, patient protocol-abiding handraisers be damned. I’m all for impetuousness, just not during class discussions when what you say is no more important than what I say (and certainly not more important than what the instructor says). There are several chronic offenders who are responsible for a fair amount of collective arm strain and lip biting, and it is to them I dedicate CensorMe.

CensorMe is a little Processing app that uses the OpenCV library’s face tracking methods to superimpose a black bar over any eyes it finds in the frame. It also emits a loud beep any time it detects speech. If the government does it, that’s a no no, but self-censorship has always seemed very much de rigueur in the US.

I’d like to encourage a number of my classmates to download it.

(I’m working on an on-line version, but I may have to port it to flash as doing video capture in Java over the web is kind of a nightmare).

I like it when people come over. Apparently in New York, you don’t just drop by someone’s house, not like you do in Shanghai at least. Everything here requires several weeks worth of planning, confirming, and elaborate bad wine bringing. I miss having people drop in for dinner or at least to talk for a bit. So I built myself a virtual hosting setup.

Now, this isn’t virtual hosting in any sort of technical sense. I’ve simply realized that people drop in on me unannounced all the time on the web. Looking through my server logs, I can see that people stop by all the time, and even though at least five percent of the time it appears they’re trying to hack my site, I’d still like for them to stay a while, to make themselves at home.

To this end, I repurposed the setup of my L.A.M.P. project to turn on a light and a radio any time my site has a visitor.

Here’s what it looks like (minus radio):
Before I get into a technical discussion, I wanted to note the pure visceral effect of having the light and the radio turn on when I’m sitting at home, reading quietly in the living room with a mug of soup. Because if I’m home and it’s not the middle of the night, that’s probably what is happening as you read this. It doesn’t exactly feel like a physical presence—it’s more like the feeling of unexpectedly receiving a letter from a really good friend or hearing the sounds of breakfast being made on a Sunday morning from your bedroom. It’s like the shadow of a presence rather than the presence itself. You don’t feel alone but neither do you feel like someone has invaded your personal space. After the first couple of times, once you’ve grown used to it and the startle wears off, it’s reassuring, almost warming, not feelings I’ve ever associated with my website before!

This conversion from virtual to real, from web to real world is a powerful and compelling trope of interactive design. It is a tangible interface, like where the surface of the ocean meets the air, one that is generally impermeable but one where it’s fun to play. People have become accustomed to weightlessness in cyberspace and these sorts of projects remind them of gravity. One of my favorite projects in this vein is Jonah Brucker-Cohen’s Alerting Infrastructure, a web hit counter that works by activating a drill that damages the foundations of a building every time someone visits a website. A sufficient volume of visits could in theory bring the building down!

Hollywood took this idea to its (il)logical extreme in 2008’s Untraceable, a film in which Diane Lane hunts a killer who connects his victims to a live web feed so that each hit on the site accelerates their demise—we are the murderers!

It should be noted in passing that this movie rivals the sublime technical absurdity of the fine collection of films/tv shows featured here:

How it works

Though it is probably going to sound complicated, the basic setup is pretty easy (see the sketch at the top of this post for a diagram). The lamp and radio are plugged into an outlet just like this one, which is in turn connected to an Arduino and Ethernet shield. The Arduino queries a remote php script over the web about once every two seconds (the latency of the relay that turns the outlet on and off is close to one second, so there’s not much point in querying more frequently). The php script checks the first column of a single-row, two-column MySQL database that stores the state of the system (on or off) and a timestamp indicating when it was last updated. It then translates the response (0 or 1) into on or off.

But how does the MySQL database know when someone is visiting my website, I hear you ask? That was the tricky part. My initial impulse was to use the onUnload method in Javascript, until I realized that would mean that each separate page a visitor viewed would count as a visit. Chris Sung suggested a brilliant alternative: having a Javascript on each page in my domain hit a php script that records a timestamp every half second or so. Each time the php script runs, it first checks the last timestamp. If the last timestamp and the most recent timestamp are within a couple of seconds of each other, then there’s obviously someone viewing my page and the script will change the state of the system from off to on in the database. If not, then it simply replaces the last timestamp with the newest and leaves the system status off. This method has the added benefit of only triggering the light/radio in response to human visits. Because search engine robots and most spiders scrape the site rather than loading it in a browser, the Javascript is never executed!

Just for fun, I also added a TextMark that allows me to check if someone is home even when I’m not by texting “anybodyhome” to 41411 and a dashboard (pictured at the top of the post) to quickly check the visitor statistic that most matters to me as a host—the length of each visit.

I like word games, I won’t lie, so I was pretty chuffed when I came up with the idea of creating a lamp that runs LAMP (Linux, Apache, MySQL, and PHP—one of the predominant acronyms behind the scenes on the web, both because of its robustness and its appealing freeness).

Puns aside, the idea is simple: I wanted to give people (especially strangers) remote control over a physical object in my house. My initial goal was to implement a RESTful interface for as many different channels of user interaction as possible, and to that end, I built a PHP script that will accept input from as many sources as I could think of and a single web front-end that displays the results.

--INSTRUCTIONS--

Open http://chinaalbino.com/UN/light.php

1) Scenario: You're in my house
     Use the light switch!

2) Scenario: You're on the internet
    -Run the Processing sketch that
      allows you to switch the light.
    -Use the web interface directly.
    -Send dengdengalex[at]gmail an
     email with 0, 1, or 2 in the body.
          0 turns the light off,
          1 turns the light on,
          2 tells you the light's status

3) Scenario: You're on a mobile device
     -Send an email as above.
     -Text "alexlight" followed by a:
          0 to turn the light off,
          1 to turn the light on,
          2 to get the light's status

Following this fabulous tutorial, I built an Arduino-controllable power outlet. Though I chose a lamp, the system can accommodate anything that can be controlled either with an on/off switch or a relay.

There is a php script that is triggered every couple of seconds by the Arduino which records the state of the switch connected to the outlet and another script that changes that state when it receives input (via web, text message, Processing, or email) and displays the state information on a web page. The final script runs in the background on the server polling for new email.

There are a couple of little fixes that I probably won’t get around to but I will mention so I won’t forget them, the most significant being the meta refresh method I’m currently using to check for the light’s status on the web page. I know I could call a php script in the background using AJAX, I just haven’t figured out how yet, so in the interim, I’m reloading the whole page every two seconds. Because it’s so small, the user probably won’t notice, at least not until his browser crashes.

The other major problem is email. There’s a bit of a lag. If it weren’t for my sucky hosting company, I’d be able to run a cron job on the server to check for new email every five seconds or so, but my host limits me to running jobs every fifteen minutes or on a specific minute of each hour. I tried several workarounds (putting fifteen minutes-worth of looping in the script so that it runs the entire time before it is next called => crashed the server; adding the same job 60 times, one for each minute => the server ends up synchronizing the jobs and calling about a quarter of them every fifteen minutes).

I am hideously behind in my documentation, so much so that I didn’t have anything up in time for the first day of the Winter Show. Which turns out to have been kind of a blessing, as I hadn’t really devoted much time to thinking about the project beyond trying to get it working. Which is uncharacteristic for me, though this project has been nothing if atypical.

The projects [1][2] I submitted to previous shows were polished and worked exactly as intended but were complicated to explain. They came with highly polished spiels that explained the hows and whys and, at least in my mind, completely airtight rationalizations for their existence.

But smells don’t bend to the will as easily as wire and LEDs. They’re invisible, often uncooperative, and, as I learned yesterday, highly subjective. The beauty for me of Scratch&Sniff has been the ease of its explanation (partly because the concept is simple: it’s a scratch and sniff television screen, and partly because I just haven’t had time to rationalize its construction beyond “wouldn’t it be cool if”) coupled with the growth of its meaning and interpretation while watching it in use.

In the past I’ve been afraid of allowing too much human element into my work. Both T.H.A.W. (a synthesizer interface that used a hairdryer and “melting” ice cubes) and Al-Gorithm (the paper output of a computer program written for a human being) minimized the subjective experience of the viewer/participant. They were both hermetic systems. You could like them or not, but you couldn’t really argue about how they worked or your role within them.

Scratch&Sniff on the other hand eschews all discourse in favor of an extremely simple concept that the viewer’s experience validates (or doesn’t, depending on the viewer). As at every show, the people I’ve spoken to have fallen into the three rough camps they always seem to:

1. The Wowers: “This is so cool, how did you do it?”
2. The Insiders: “This reminds me of a project by x at y, and have you thought about z?”
3. The Skeptics: “What is the point of a smelly TV? How are you going to monetize it?”

The fascinating thing, though, has been how many people have taken issue with the project based not on how it works but on the smells themselves. “This smells like air freshener, not grass.” The technology vanishes! And what exactly does your TV smell like when you scratch it, I want to ask.

Another surprising thing has been the trepidation with which people approach scratching the screen (“Can I really push hard? Won’t it hurt the screen?”) coupled with the brute force to which they subject the obviously delicate surrounding foam core.

In any case, really interesting. I will post more once I get caught up with my documentation (and sleep) in the coming week.