I was just teaching a workshop at CIID in Copenhagen where we introduced designers of various sorts, industrial, graphic, service, to Processing, generative design, and to the idea of Natural User Interfaces, i.e. the Kinect. I was happy with the results, what the students learned and what they produced (here for instance), but I walked away wondering the same thing I always wonder when I teach non-CS students programming: what’s the difference between thinking about code as a tool for doing things and thinking about code as a tool for thinking? What does that mean for making things and for talking about and teaching people code? Since I write about code, teach workshops, do documentation, these questions are, as they say, relevant to my interests.

Lots of times we, and by “we” I mean “programmers” think of code as a tool for doing stuff, we don’t care about the implementation underneath, we blindly reach into boost::asio, we fire up Rails without actually looking at what ActiveRecord actually does, we just do things. Make a website, a routine phone app, a CRUD application, these are things that I and I suspect many others, often do on auto-pilot. When I use code to think, I find myself usually looking at weird compiler behavior, hidden or little-known features of languages (example). I think about code, about computation, about what it means to think in code when I think in code. Sometimes I think about algorithms, but rarely. Sometimes I think about the behavior of an algorithm or the pattern in a signal or dataset, but then I’m not thinking in code, I’m looking through code, but I’m not really thinking with it, I want it out of the way so I can see what I’m looking at. So there’s really a few different levels of involvement here:

1. Running Code
2. Using Code
3. Thinking Code

And those are interesting things to try to explain to students. I didn’t do a good job of it this time, and I regret that, and I’m going to rectify that mistake next time because, particularly in design and for designers, it’s important to tell people what the tool they’re picking up actually is. When you pick up a library in Processing that has clearly defined behavior, you’re usually doing something like #1: just running code. Maybe you change some colors, some parameters, tweak what things do, off you to see how your thing works. To someone raised on reading Hackers Delight, that’s complete heresy. To someone raised to think of tools as being nothing more than elements of a task, then that’s of course what you do. If you buy a hammer that doesn’t hammer your nails, then you go back to the hardware store and get another one, no? And that sort of makes sense, except that it also cripples you. You end up with the rote permutations on the low-lying fruit of algorithms. You treat programming like you treat Excel. Instead of invention, discovery, and experimentation, you get expressions, behaviors, and pre-defined routines that you can mix and match, but never alter. So, is that wrong? I’m not sure. I teach people to think of code as tools because it gets them started thinking that code is interesting. They can do things with it. They are, without a doubt, horrible programmers, and they will continue to be horrible programmers hamstrung by their tools, for perhaps years, or in all likelihood, forever. They implement things they barely understand, leverage things they don’t appreciate, and run into mistakes that they can’t comprehend. And, I think, that’s probably ok. It’s not a failure of mental capability on their part or failure to communicate on the part of their professors: it’s simply not necessary for being a designer working with interaction.

Thinking about things is using a medium to formulate an expression. Grammar, syntax, norms. These tools for creating novel expressions of the medium itself. Algorithms, data types and containers, device drivers, protocols, fundamental objects of a mode of interaction, I could go on, but these are a few things that strike me as being to code what poetry is to written language. A tool for thinking has codified norms and rules but generally a limited interface because the more complex the interface, the more limited the possibilities for expression. We limit the interfacing mechanics because to do so frees the mind. A tool for making something on the other hand has an intentionally limited interface, because we’re primarily concerned with having blocks of functionality be legible to us. It’s that last word that sums up what I think designers and non-traditional technical people need to have and what I was trying to teach at CIID: code literacy. Code fluency is a vital and profound tool for interaction design, but it’s a necessary one. Code literacy increasingly is a necessary tool, though how exactly that sits at the intersection of “thinking” and just “doing”, how to best fit tools to both of those scenarios, is something that I’ve yet to parse out completely. I’m far from the only one thinking of this. In fact, a great number of people who do interaction design, whether they know it or not, are working on this problem. That’s what makes it a good problem: it’s big, there’s a lot of ways to be wrong and right, and a lot of fruit that can be born from it, both in terms of thinking about how we learn things and thinking about how we think. Which is a long way of saying: I had fun in my workshop, and I’m looking forward to doing it again next year.

Languages old school nerds like:

C
Perl
Python
Go

Languages old school nerds hate:

C++
Ruby
Java

Languages new school nerds like:

C++
Ruby
Javascript

Languages new school nerds hate:

Perl
Java

Random technote post:

Doing blob tracking with a kinect using Processing is surprisingly hard, as I’ve discovered today in the CIID Generative Design workshop I’ve been running, the below shows the trickery required to buffer RGB images from the kinect and then doing blob tracking on them:

import SimpleOpenNI.*;
import hypermedia.video.*;

SimpleOpenNI  kinectLib;
OpenCV opencv;

void setup() {
  
  kinectLib = new SimpleOpenNI(this);
  
  opencv = new OpenCV(this);
  
  if(kinectLib.enableRGB() == false) {
    
    println(" can't open RGB ");
    exit();
    return;
    
  }
  
  opencv.allocate(640, 480);
  size(640, 480);
  
}


void draw() {
  
  kinectLib.update();
  
  background(122);
  
  // copy the RGB image into opencv
  opencv.copy(kinectLib.rgbImage(), 0, 0, 640, 480, 0, 0, 640, 480);
  opencv.threshold(80);
  
  opencv.absDiff();
  
  image(opencv.image(), 0, 0, 640, 480);
  
  Blob blobs[] = opencv.blobs(10, width*height/2, 10, true, OpenCV.MAX_VERTICES*4 );
  
  fill(255);
  for(int i = 0; i< blobs.length; i++) {
    rect(blobs[i].rectangle.x, blobs[i].rectangle.y, blobs[i].rectangle.width, blobs[i].rectangle.height);
  }
}

Here's the somewhat unintuitive part: to save the image in memory, because the blobs() method (and findContours() underneath it) mangles the image, we do this:

void keyPressed() {
 
 opencv.copy(kinectLib.rgbImage(), 0, 0, 640, 480, 0, 0, 640, 480);
 opencv.threshold(80);
 opencv.remember(OpenCV.BUFFER); 
  
}

The OpenCV library has a restore() method that is supposed to handle un-mangling the image buffer, but it doesn't seem to work with buffered images, only ones captured from a Capture source.

By Alex Mclean This is really wonderful stuff which I would recommend to any/every one

More info here

http://thefactoryfactory.com/mtagger/

Chindogu is almost like the doppelganger of the well designed interaction. (Note to pedants: yes, I know that the o in Chindogu is supposed to have a line over the top, but WordPress isn’t playing along).

Chindogu is the Japanese art of inventing ingenious everyday gadgets that, on the face of it, seem like an ideal solution to a particular problem. However, chind?gu has a distinctive feature: anyone actually attempting to use one of these inventions would find that it causes so many new problems, or such significant social embarrassment, that effectively it has no utility whatsoever. Thus, chindogu are sometimes described as “unuseless” – that is, they cannot be regarded as ‘useless’ in an absolute sense, since they do actually solve a problem; however, in practical terms, they cannot positively be called “useful.”

There are actually rules for what can and cannot be a chindogu

1. The invention must be useless

2. The invention must be real, and more than a concept.

3. The invention must be created for daily use

For instance:

In a way, the chindogu is an interesting lens to think about interaction design through: needs improperly addressed. A lot of interaction design, what people actually do in day to day work, is try to make non-needs useful: you don’t really need this service but make the website easy to use. You don’t really need the 10 new features on this washing machine but you can make the features easy to access. You don’t really need this new social media sharing whatever site but make it easy to integrate it with the rest of your life. The chindogu is actually attempting to meet needs rather than create demand, it simply does it in a way where the interaction is so difficult that the need can’t be met, but in looking at these things, you can see the interactions, the actual points where the people and the objects meet, very clearly, because they’re so bizarre and so poorly thought out. It actually reminds me quite a bit of what I see in a lot of student interaction design projects and in heavily technology driven design solutions: actual needs, the sorts of things that you see and think, late-night infomercial style,: “yes, you’re right, that is a problem”, and then solutions to them which are so incoherent, so poorly thought through, that they verge on chindogu-ness. The complementary problem, is just as interesting: objects and touch-points with well thought-out interactions but incoherent or non-existent needs. I wonder if a well thought out but useless interaction is useful in a way that a poorly thought out useless interaction isn’t, if by demonstrating how something that can be done well, it has merit beyond its failure to meet the needs of its users or its producers?

As a quick diversion from CIID I found one of these in the backyard and decided to investigate a little bit.

Pulled it down and brought it into school kind of excited that I found some municipal sensors array, maybe something that the landlord put up?

I took a look at the underside trying to figure out whether I could find the humidity and temp sensor used, that was the thing I was really curious about, but I couldn’t see it without ungluing the board, which I didn’t want to do. Actually, turns out it’s this: The RTGn318 which actually goes along with one of these:

Not the most exciting thing and I just yanked one of my neighbors thermometer sensors. Oops. I went back home at lunch and put it back in its place with the batteries in and nothing disturbed. Hopefully no one missed it too much while it was gone.

So, I went to see it a few nights ago and have been trying to organize my thoughts on it, slowly, whilst doing my thesis and getting, no hyperbole, sicker than I’ve been before. If this post is incoherent, I blame viral activity, not my own failings. So in short, you already know whether you’re going to like this or not. Did you like Helvetica? Then you’ll like it. Not, then not. Pretty straightforward. There’s nothing completely surprising or particularly heavy historically or otherwise being thrown about, the selection of places that they focus on: Bogotá, NYC, Rio, Beijing, Johannesberg, Delhi, Santiago, Brasilia, and Copenhagen. You can guess what each of these cities stories is about too, I’d bet: Bogotá: Reinvention; NYC:Jane Jacobs; Rio:Favelas; Johannesberg:Townships; Delhi:slums; Brasilia:Unliveable; Beijing: Over-development; Copenhagen:bikes. The one surprise is Santiago Chile, which is about Elemental‘s Lo Barnechea social housing project. If you don’t know it, check it out, it’s a very eloquent demonstration of small scale collaborative urban development.

There’s one thing in it that’s quite interesting though: here’s the only place technology really gets mentioned:

That’s the control center in Rio. When I say “that’s the only place technology gets mentioned” I mean anything that’s not roads, buildings, parks. It’s interesting that the only thing that can be a way of making smart things for cities is the old Rand Corp style Master Control War Room. I don’t think that’s Hustwists fault, I think it’s cultures fault. When a culture obsesses about big screens, sweeping power, surveillance, it’s quite natural that that’s going to get in the way of how we think, so, we’ve all seen this:

So of course it’s natural that sometimes when we think of technology re-making how we design cities, some of us might think of things like this. But that means that small things, light things, flexible things, simple solutions utilizing existing infrastructure, get ignored, because when we think of “cities + tech” we think of IBM style huge screen/rooms. And that misses a huge range of possible interventions that municipalities, private entities, and citizens can implement point. Most people who do technology related stuff don’t make stuff that has a giant master control center or even that needs one or even that would know what to do with one. And when you assume that that the only way that can get done is to make giant command center style things, it misses most of what people really want: small local services, instant update, small stuff, about when they are, where they’re going, and what’s going on. That’s actually stuff that a lot of people are really good at doing and that I still haven’t seen put to use in service coordination, in city planning, in rebuilding, in zoning, in any of the things that are actually really important but that generally don’t get much attention from residents. Tech can be simple, small, light, and cheap stuff and it can make real differences. /end_soapbox

Other thoughts: Former mayor of Bogotá Enrique Peñalosa is a remarkable man. I know little about him other than what he says during the interview, but that was uplifting, inspiring, and, dare I say it, visionary.

Trailer: