These BobbleHeads are offered by MoMA as an extra token for people that buy access to the live stream of the Armory Show closing event: a live performance by mexican chill wave band Neon Indian. In addition to this, the collection of generated BobbleHeads will be projected on stage during the performance.

Aside from it being an interesting fundraising participation system, momaarmoryshow.org is an excellent example of a seamless, low-effort online transaction experience. I would probably spend a lot more money on digital content if other online stores made shopping as easy and pleasant as momaarmoryshow.org does.

I designed most of the BobbleHeads based on dead celebrity artists (Frida, Picasso, Warhol, Louise Bourgeois, etc.), together with a couple of celebrities from pop culture, one science celebrity, and a monster made from body parts of several cadavers. This flickr link features the complete BobbleHead collection in the form of a wallpaper, including a famous superhero that didn’t make it to the website for obvious copyright reasons.

Here are the two BobbleHeads I made so far:

Update: Mud’s post in the BuzaMoto blog.

I was recently talking about how different interaction models determine differences in communication, and how interesting it is for me to look at scenarios where a group of humans is restricted to use non-conventional channels to communicate with each other. Like putting two persons in a room and have them play a game where all they can do is make drawings to each other. Blackboard, paper, whiteboard, it doesn’t matter. Their communication will not be very efficient this way, but they will get very creative at drawing, and maybe come across some ideas that they would have never explored any other way.

More recently, Buzamoto launched a cool iPad app called Pendipity that offers a similar functionality to tinyDoodle, only better. It features a more advanced, yet very simple, drawing interface, and it implements a seamless chatting experience using a Node.js server. In terms of space, the difference between both systems is clear. When someone initiates a shared Pendipity session, the system will look for another available user to create a drawing team of two, and TinyDoodle is an open space where anybody can access the same drawing at any given time. So tinyDoodle is like a public blackboard, and Pendipity is like a shared notebook where every visitor is paired with someone else to draw on a single page of the notebook at a time. In Pendipity, a different session means a different drawing. In tinyDoodle, there will always be the same single drawing, around thirty something mb long at this point. The drawing is so dense, you actually have to watch it in chunks to make sense of it.

The following image is a collaboration Buza and I made on Pendipity. We didn’t find out we were drawing together until later, when we talked about it by chance. The idea of collaborating with somebody close to you without knowing who they are is bizarre, to say the least.

As the project website describes, the drawings should be created based on these rules:

 Use a white A4 sheet and a ballpoint pen.
 Draw a closed shape on the paper.
 Repeat the shape inside the original shape until there is no space left at its centre.
 Repeat the shape outside the original shape until it touches one side of the paper.
 Choose the distance so that you can make at least 50 iterations on the paper.
 Try to repeat each iteration in exactly the same way.
 Sign the drawing in its upper right corner in landscape format.

Note the semantic difference between “based” and “following” when you substitute the former with the latter. It is the difference between suggestion and command, and in this case it gives the participants a lot of room for interpretation. Most participants——myself included——chose to draw around the original shape both inside and outside. But that makes it hard——if not impossible——to keep the further iterations faithful to the original shape. Even though it is easier to draw instances of the same shape if you don’t have to wrap them around the original, only two participants have chosen to do that so far, and it is interesting that both of them used triangles.

I explored a number of options before submitting my choice. I wanted to do something that featured some behavior I believed had some degree of originality, but I also wanted to stay away from formal intricacies or technical conundrums. I decided to look for ambiguity in the idea of “closed shape” not by finding a tricky way to define “closed” but by finding a simple way to make the idea of “interior” relatively unclear. By drawing a line with a few self-intersections I produced enough ambiguity to have a some choices about the interior of the shape. The number eight for example, is it a circle with a twist or is it two circles tangent to each other? From a two dimensional point of view, it can be either one, and the choice you make about which one it is will inform the way you choose to repeat it. I drew the original shape one way, but a minute later I preferred to pretend I drew it differently.

This exercise in Telematics and participation is just one out of many—Amodal Suspension by Ralfael Lozano-Hemmer and Absolut Quartet by Jeff Lieberman & Dan Paluska immediately come to mind—but it stands out in a particular way that is relevant to some of the work we were doing back in the PLW a few years ago. UndefPrint is only open to participants that can write code. The general public is excluded. At least a bit of knowledge of Javascript and computer science is required to get anything out of UndefPrint. The idea that code is a mode of expression in a way similar to simple speech, doodling, or any other gesture that can be performed in public is not new, but it is an important one, because it puts code next to activities that come naturally to most humans—like speech or hitting on a keyboard to produce sounds—even when coding doesn’t come naturally for anybody. Perhaps in the future we will be able to speak code—and math—the way we can sort out objects in a crowded room. One can only hope.

Here is the code that draws the pattern in the image above, the fifth in my series of submissions:

for (i=0;i<=pWidth();i++){
  for (j=0;j<=pHeight();j++){
    pSymbolB(219+(Math.floor(Math.sin(j*i))%3));
    pPixel(i,j);}}

And, some fooling around with triangular patterns:

Did I ever mention how much I like simple nested for-loops?

Featured illustration: Who’s there by eomsco.

The following are some selected frames I chose from the movie.

This is where you click to trace:

This is a happy cat:

However, when thinking about experience and interaction, overwhelming your subjects with too much input can become a problem, and it is especially hard to design experiences that can be interaction rich and at the same time make sense. The world and our perception are a perfectly balanced system where everything seems coherent and accessible to our senses, at least most of the times, but when it comes to manipulate tools with a specific goal in mind, narrowing interaction down to the minimum gives us the advantages of focus and control. When drawing for example, every single artist in history has used the single point touch of the charcoal, pencil, pen or brush over a flat surface, performing a slightly different gesture, but just as limited, than the one imposed by the mouse. When creating a drawing with the pencil or the mouse, the differences come from the reactions of the material (paper or similar for the pencil, and computer for the mouse), and not from the devices. A mouse can be given the shape of a pencil, and used over a pressure sensitive display, it responds to the drawing gesture just as a pencil would.

Because of this reason, and because the human drawing gesture is a perfect source for random input, we have introduced mouse input into oGFx. There are several different ways to draw in oGFx. The drawing gesture can be mapped from screen coordinates to 3D coordinates in the OpenGL context or 2D coordinates in the Quartz2D context. We started by making the raw screen coordinates available to the python interpreter, so the decision of what to do with them could be taken by the programmer of the drawing experience.

I wrote a few scripts that map the screen coordinates to Quartz2D coordinates, adding some behavior to the strokes, a simple implementation of the Bresenham line algorithm, and a low resolution canvas. I have been working with simple drawing tools for a while, and I found oGFx to be a refreshing platform to experiment with, specially because of the four following reasons: I can change the definitions in a script without having to stop the program (or even stop drawing), I can draw and navigate around a drawing in 3D at the same time, I can apply and remove CoreImage filters on the fly, and I can project the action of drawing over history. Even though all these reasons are some of the important features of oGFx that we have been using from the beginning, they were not combined with hand drawing until recently.