Long Description

The Media Lab gets a lot of visitors. People bring in friends and family, sponsors send representatives, and others just wander in off of the street. The Glass Ingrastructure is designed to help anyone quickly and effectively explore the kind of work being done in the building without having to bother us. Basically, grad students really just don’t like talking to people if they can avoid it.

The system is made up of about 30 giant touch screens, wired to mac minis and RFID readers. They are located throughout the Media Lab’s old and new buildings, and display maps, projects, and other applications.

When I arrived the Glass Infrastructure had a fairly linear interface. Each screen displayed a rotating list of nearby projects based on where it was placed. Our goal was to redesign the entire thing, building on the systems already set up. We had a pretty large team too (about nine people) working on various parts of the product.

We wanted to reflect the relationship between people and projects without overwhelming the user. There also needed to be a way for people carrying RFID tags to “favorite” different projects, and view a list of their favorites on the bottom of the screen. After weeks of discussion and thrown out designs we came up with the molecule interface.

I spent most of my time working on client side middleware, middle learning a bit more about jQuery at the same time. The backend was a RESTful API that worked with the database in addition to some fancy Natural Language Processing (NLP) tech which automatically found project relationships based on their descriptions.

The design that we came up with is still in use today, and the Glass Infrastructure has become a core part of the visitor experience at the Media Lab. We have also set up a few screens in other parts of the world (Spain, for instance) so that sponsor companies can have a window into the work being done here.

Technologies

• jQuery
• CSS3

Papers, Posts and Press

• The Glass Infrastructure: Using Common Sense to Create a Dynamic, Place-Based Social Information System (Havasi, 2011)

Testimonials

You know what would be better than asking me? Going over and prodding that screen over there.
– Media Lab Grad Students

This was my final project in How to Make Almost Anything. The idea was originally an artistic/troll project: I wanted to create a modern day printing press. You would line up the letters, spread the ink, and press it onto paper. The message would go on the paper as you would expect, but the type blocks would secretly be digital, and the message would also go directly onto Twitter.

I decided to change course because, while that application was a nice statement about legacy media, it seemed that abstracting the interaction might be more useful. It turned out that group members had talked about the idea of connecting more things to the internet and using Twitter as a way for those things to communicate long before I had arrived.

I wanted to be able to swap out sensors, so I designed three types of circuit:

• A hub which did the communication with the Python that sent out tweets.
• Chain-able receivers which could be connected together, allowing for any number of sensors to be added.
• Sensor modules which could be plugged into receivers. These would be responsible for measuring whatever the sensor measured and triggering the hub to send tweets.

I made four sensor modules. I started with a simple four-state button that you could set to hold a static value (e.g. “happy, sad, bored, excited”). Then I moved onto using a light sensor, a temperature sensor, and then I wrapped up with a proximity sensor. This kit was enough to warrant a mascot (the pet rock I had created as an earlier project) and tape the proximity sensor on his head. He talked about all sorts of things, like when people walked by, or when he felt lonely, or when it got too dark.

Behind the googley eyes, sensors would trigger events when their readings changed significantly. After an event trigger, the hub would then ask all of the modules to share their messages to the world, and those messages would be passed to a Python script over USB. The Python would then send it to Twitter.

Honestly, I spent most of my time learning to make the circuits (and make them modular), so I wasn’t able to implement the full vision. That vision would have included wireless functionality, direct communication with Twitter (bypassing python), a more robust set of logical operators (e.g. “count the number of people that entered a room”), additional sensors, and far more pithy quotes.

Basically what I wanted it to look like was Twine, which came a year later from the two Info Eco alums who had originally explored this space.

Posts and Press

• My How to Make Almost Anything blog post

Technologies

• C
• Milling Machines (to create the traces)
• Sensors, solder, and microcontrollers
• Python

Testimonials

What is this, some kind of party? Don’t you know the neighbors are trying to sleep?
– Your living room

Long Description

This started as simply a fun way to play with a laser cutter. Actually, it ended that way too. In fact, it never really drifted from that status. However, carving pumpkins with a laser had some interesting challenges.

Laser cutters usually burn away material like acrylic or cardboard to slice pieces out of a flat material. This is great because the laser has a focal point where the clean cut will happen. If you are out of focus then the burned hole will either be too big or it won’t cut the material at all. If you’re working with a flat plane you can focus it in one spot and be fine.

If you are carving into a cylinder (for instance a can of baked beans), then you don’t have a common height to focus onto! Fortunately for me, the laser cutter at the Media Lab has a lathe attachment. With a lathe you simulate a flat plane by converting the y axis into rotation (meaning you could “spin” an object instead of having the laser actually move forward and backward).

Pumpkins aren’t cans of baked beans, pumpkins are spherical. The lathe only lets me rotate on one axis, which means that the X axis varies in height too. I found a really good solution to the problem, which was to ignore it and carve anyway. It worked, although I lost detail the further I went from the middle. Meh.

Before you can even pick out a pumpkin you need to take an image and break it into four layers (I used Adobe Illustrator to do this). Each layer will represent a different brightness, since it will be a different cut depth. You don’t need to use four layers — you could be boring and just use one, for example. I used four because deep down it just felt right.

It’s hard to predict the depth of a cut once you do your second pass, because the area around the laser point will often vary in height depending on how many cuts have happened. For instance if you were to carve the shape of a doughnut, the middle part of the doughnut might begin to sag, which means that additional cuts could accidentally hit the outskirts of the center. Tiny details have to be deeper (e.g. brighter) or they will be blasted away on later cuts.

More could be done — e.g. automatic generation of layers based on pumpkin color calibration (carve the pumpkin with varying depths, take a photo of the lit pumpkin, and match it to the photo you want to carve). We’ll see what happens!

Posts and Press

• My overview
• New Scientist

Technologies

• Lasers
• Adobe Illustrator

Testimonials

Halloween, it’s about time
– Tychus Findlay

Wall Paper allows users to explore information by navigating through physical space.

This demo has undergone several iterations but the overall architecture has remained consistent: there is a browser-based client (JavaScript / HTML / CSS) separated across eight windows, a server (NodeJS) which listens for position updates and manages state, and a sensor component (Python / C) which does the actual position tracking.

The first iteration used infrared (IR) sensors and Arduino to track about 10 points evenly distributed across the eight displays. This provided approximately one data point per screen. A “newspaper” was spread across the screens so that each one displayed a section title. To read a given section you would walk up to the appropriate screen. The sensors would detect you, pass that detection onto the client, and an article from the screen’s section would fade in an article for you to read.

The second iteration replaced the IR sensors with a Microsoft Kinect, resulting in a much higher resolution depth map. Instead of the 10 depth points I now had access to closer to 1000, and I could track positions far more consistently. The interface was also replaced to display a bar-chart representing 20 years of reporting by the New York Times. Each month had a bar broken into four colors representing coverage of “Afghanistan,” “Iraq,” “Wall Street,” and “Protests.” You could walk up to a part of the screen to learn about a specific month, and as you got even closer you could see headlines for each of the four content types scrolling across your section of the display.

Of course, it was also used to mess with people. There was a time when the content would get smaller as people walked closer.

Technologies

• Arduino
• C
• HTML / CSS
• jQuery
• NodeJS
• Python

Testimonials

So what you’re saying is that this project has failed both in terms of user experience, and in terms of graphic design?
– Henry Holtzman