ITP Had A Haunted House

ITP had a Haunted House last night, and I did my best to add to the awesomeness.  Specifically, I borrowed an idea from David Bowie's 1997 stage installation, and decided to project some faces onto amorphous "head" type shapes.  My fellow ITP'ers were kind enough to indulge me with some awesome footage, and the result was some disembodied, creepy looking weirdness!  Thanks to Meredith for the pics...

Physical Computing: Reaction To Visual Intelligence

Donald Hoffman's "Visual Intelligence" manages to take a relatively conventional concept (that our brain "tricks" us into perceiving much of what we deem "real"), and illustrates it through the novel venue of amputees.  By using the amputees' sensation of phantom limbs, Hoffman creates a tangible and realistic illustration of the disconnect between the physical and the mental world.

While Hoffman's examples do a great job at illustrating the concepts, the concepts themselves aren't exactly novel.  It's a well known fact of many simple schoolyard tricks that the brain can be easily tricked into misperceiving "reality".  Watching movies, smelling one thing while eating another, combining hot and cold sensations - all of these things can allow us to trick our nervous system into perceiving things that aren't "really" there.

In the end, this fact is obvious, but perhaps overlooked because it is so common:  the best thing we can do moving forward is to try and consider how we are really perceiving the world around us, and enlist this as we make choices in design.

Visualizing Data: Reaction To Karsten Schmidt

Karsten Schmidt describes himself as a "Computational Designer", and the description is apt:  most of his design projects are driven by code and generative algorithms.  In stark contrast to Aaron Koblin, who uses small amounts of data from a wide range of individuals, Schmidt uses programatic iterations that generate similarly unique data sets.

The generative nature of Schmidt's work definitely separates it from Koblin's more "techy" work:  While Koblin's pieces simply use data sets with modern visualizations, Schmidt's generate their own data.  In the end, this results in the pieces (which could potentially be seen as more robotic or inhuman) actually having more in common with Koblin's human created data sets.

This conclusion about Schmidt's work brings to mind a number of interesting questions in the area of data, technology, and intelligence.  Specifically: what is interesting about data, and where are its most interesting sources?  Moreover, if data is real or generated, does that make a difference, and what is it about the presentation that gives it a more human feel?

To my mind, Schmidt's work unquestioningly draws attention to the fact that artificial, generated data can be every bit as human as real data sets, perhaps moreso.  Considering it further, this may be a result of the fact that generative data is "growing" in much the same way a group of humans "grow" a widely dispersed data set.  In the end, perhaps it is the life of the data, rather than its end points, that truly define how it is perceived.

Visualizing Data: Reaction To Aaron Koblin

In looking at Aaron Koblin's work, the pieces seem to be divided into two categories:  those that use amazon's mechanical turk to generate data, and those that simply create visualizations of large data sets.  While the visualizations certainly have their appeal, I have to say that I prefer the amazon mechanical turk projects.

The mechanical turk generated data sets not only provide novel visualizations, but also novel ways of generating the data that led to them.  Seeing how data sets that are created at a micro level are still inexact is an interesting analogy for how larger projects can have an inexact nature to them.  What's more, Koblin's visuals are compelling and unexpected.

By contrast, the visualizations that depend on external data seem to suffer from a forced feel of trying to hard to be futuristic or "different", but in fact ending up being cliche.  The idea of mapping flight patterns or telephone lines has been done a million times, while the "House Of Cards" video is utterly reminiscent of needle pads that fit-form to represent shapes.

Out of all of the pieces, my favorite is probably the sheep market:  the representations are novel and humorous, the data collection interesting, and the representation enjoyable to navigate.  In short, it presents some serious concepts about data generation in the modern world while at the same time giving them a humanistic feel.

If anything, that is the shortcoming in Koblin's less enticing work:  the absence of humanity and a feeling of overly-conscious attempts to be futuristic and technologically advanced.  Part of this reaction to Koblin's work is probably driven by over exposure to faux-futurist imagery, but it's also a result of the fact that Koblin's more human works are simply more novel and easier to relate to.

Physical Computing Week Seven Lab: Multiple Serial Output

Building on last week's serial lab, this week took the same principles and applied them to multiple, rather than a single, serial data source.  In this case we took a circuit containing two analog and one digital sensor, and sent the output to a Processing script.

Here's a picture of the circuit - as you can see, there are two analog inputs (the potentiometers) and one digital input (the push button).  As was noted in the lab, this set of inputs represents the same inputs as a typical one button mouse.



As such, the inputs were used to control a circle on screen, with the push button turning the circle on and off.  You can see this control at work in the video above.


After getting the script working with a streaming serial input, we then rewrote the arduino side to wait for a handshake before it started sending data.  Once it received the handshake, it would send only one set of data, until it received a request for another set.  This serial behavior can be seen in the video above.


As mentioned at the top of the lab, the principles put to work here are very similar to the ones from last week's lab, but simply expanded to allow for multiple inputs.  This, in turn, allows us to use the Arduino's serial output in a far more versatile and productive manner.

Physical Computing: Real World Technical Observations

This week we were asked to go into the "real world" and observe people interacting with devices, and see how it met with our expectations.  I did just that, but unfortunately had very little to report in terms of results:  Everywhere that I went, people seemed to use devices or interfaces exactly as expected.

I spent some time near an ATM, by the entrances to some buildings, and near some subway metrocard machines.  In all cases, it seemed that the users knew how to use the devices on hand, and simply went through the motions, often almost intuitively.  There are two explanations that I can attribute this two in relation to last week's readings.  

First, it may simply be that people are smarter than the "bad design" critics give them credit for.  Put differently: just because something is poorly designed doesn't mean it's unusable.  It's just that it's sort of a hassle, but that people are adept enough to figure it out.  Take the case of a PC:  I used Windows perfectly well for years.  Now that I use OS X, I'm far happier, but my ability to function hasn't particularly changed.

The second explanation is that it's simply a case of learned behavior:  in a city like New York, people tend to have routines and typical day to day actions.  It may simply be that the people I observed have overcome poor design because they've become so accustomed to it - now they simply function as normal, and envelop the poor design in their routine.

I think the reality is that it's probably some of both:  Very few poor designs are unfathomable, but they could be somewhat challenging at first.  However, after the 100th time using a door or an ATM, very few functional humans are going to keep making the same mistake.  That being said, the reality is that if there were more, better design, it might simply make people's lives easier.  This might in turn lead to happier people, and then - who knows!

Physical Computing Week Six Lab: Serial Output

Through no fault of ITP's, this week's lab was perhaps the most redundant task I've undertaken since starting the program.  This is largely due to the fact that when I started working at Dolby Laboratories, my first sizable task was to write almost the entire software stack for serial communciation on the Dolby Digital Cinema system.  As such, doing so in a basic manner on the arduino/processing platform ended up being pretty trivial.  That being said, it was fun to see it working, and to discover that processing and Dolby use the same serial back end libraries - RXTX!

Because of my strong familiarity with the material, I designed a relatively simple circuit employing a potentiometer to send analog data over the serial port.

Doing a read on this data was also relatively straightforward, allowing it to be piped into a graph in processing, which can be seen above.


Yay!  Serial communication!