Lead by Alexandra Deschamps-Sonsino, CEO and co-founder, the London office (now found at www.tinkerlondon.com) will focus exclusively on offering design services and support education around design, technology and open source. Based on a rich portfolio of work with clients like Arup, BBC R&D, BT Innovation & Design, Nokia & Sony Ericsson Tinker felt that it could make that step and emphasize its London-based roots with the development of a new identity. Graphic designer Claudia Pape and web designer Patrick Tanguay worked with Tinker to rethink its visual identity helped bring it to life.

The Tinker London team is also growing with the involvement of Dr Georgina Voss who will be joining our team as a researcher and project manager.

Tinker’s Milan-based co-founder and CTO Massimo Banzi will be partnering with Gianluca Martino, founder of the PCB manufacturer Smart Projects to lead Tinker’s European activities (still found at www.tinker.it). Their activities will focus on open source hardware design, distribution and community building, a natural extension to their work with the Arduino platform since its launch in 2005 and Tinker’s support of the community.

So we’ve moved everything design and education related on to our brand new website, blog, Twitter feed and Flickr stream. Join us and follow us for more adventures! Keep posted here on tinker.it development on the Tinkerkit and more!

First, a bunch of link parking:

• Group members: Philip Trippenbach, Ivo Gormley, Josh Pickett, Chris Thorpe, Tim Davies, Isabell
• Project documentation at the Rewired State website
• Chris’ blog post
• Philip’s blog post
• Tim’s blog post
• Mention of the game at Gordon Brown’s speech on Building Digital Britain(!)
• Photos

There’s a good bit in the above links about the game’s origin, rationale, and rules, so I’ll just describe it as briefly as (hopefully) makes sense, then rant about my own particular obsessions: game design and physical/digital connections.

Description and Rationale
In The Bump Game, two players race a baby to the delivery date – the baby always moves forward, but the players only move by answering questions about different aspects of pregnancy (included on trivial-pursuit style cards). Players win by reaching the end of the board before the baby.

One of the problems parents face at the beginning of pregnancy is that they need to learn a lot of information quickly. However, it can be hard to wade through all the available information to find what you need. In particular the ‘unknown unknowns’ (the things you don’t even know you need to search for) are difficult to discover. A game can provide a fun, manageable way for expectant parents to orient themselves to the timeline and types of information they will need to know over the coming months.

Serious Game Design
Toward the beginning of the weekend, we had a variety of goals that looked something like:

Serious goals:

• Provide NHS-based information about navigating pregnancy, understanding medical needs, accessing necessary services, and learning parents’ and expectant mothers’ rights and benefits.
• Provide personalised information relevant to players’ specific situations, such as contact information for local health services.
• Provide a clear pathway for players to learn about topics in greater depth, and feed back into the NHS Choices website.
• Allow a variety of avenues for accessing the game, both online and offline.

Game goals:

• Be easy to learn, cooperative, and fun.
• Have a structure that reflects/reinforces the structure and timeline of pregnancy.
• Be a playable game rather than an open-ended interaction. (At least, this part was my obsession.)

I tend to think of games as building upon interaction design. In my mind, some of the markers of a successful interactive piece include a sense of engagement and/or delight, a clear (or at least discoverable) link between cause and effect, and esthetic, intellectual, and/or social interest/appeal. Successful games do all of that, plus they have a goal, a clear (or discoverable) link between actions in the game and attaining that goal, and possibilities for skill, choice, strategy, and/or risk. A successful serious game does all of that, plus it accomplishes an external educational or social goal.

This is enough to make me throw my hands in the air, but we made good headway. After a few design iterations (including a lovely but overcomplicated card-collecting game in which three axes of categorization were used to provide a combination of strategy and chance) and a bit of user research, we whittled the game down into something that made topical sense and could be explained in a few sentences, and then built a structure around it that (as an early iteration) seems playable and enjoyable.

Atoms and Bits
Physical and digital games offer different possibilities that can be quite helpful (relaxed face-to-face play and discussion, larger social networking and history-tracking), and we ended up designing the game for multiple formats – a physical board game that can be handed to someone, online playing pieces that can be downloaded and printed out, and a Facebook version that can be played online.

Because one of the external goals of the game is to help people access information, all versions of the game refer back to the NHS Choices website, primarily by including on each question card a URL (and QR code!) that links to in-depth information about the card’s topic.

Further, the cards are personalized to each player. Currently this is implemented through postcode—you generate cards for your postcode, and all the questions about available services change to include local information. There are also supplementary cards with maps and information about those services. In this way, every player receives a slightly different game that is directly relevant to them—and further receives a set of wallet-sized cards that they become familiar with through game play and then can use as resources.

All of this together creates a two-way flow between real life and the internet. If the first point of access is online, then the personalization and download&print aspects make it easier to take the game away from the computer and into real life. If the first point of access is the physical game, then the links make it easier to find specific and relevant entry points to online information.

Had a lovely time last week speaking at Disqo’s Making Digital Real evening. Disqo is in the interesting position of being the media consulting arm of GoldenSq a production and special effects company based in Golden Square in the heart of Soho. For the past year, some of our clients have been ad agencies of various kinds and it reminded me of my Amsterdam days working within “web services” company Blast Radius. Based on the really interesting Q&A session we had after the talk, I thought I’d put down a few thoughts about working in the area of physical interaction design that are worth considering if you’re working in an agency and looking to expand your offering or work with people like us.

1. Get people in early
Doesn’t matter if you have a tight deadline, getting someone who knows about the limitations of the physical world, atoms and electricity will save you time and money. That 2h conversation at the pitch stage will make sure your idea is actually easy to implement and give you an idea of budget. The biggest thing to consider as brands start to expand outside the screen is that stuff costs more money than you ever thought was possible. Projectors, printers, hardware, actuators, whatever…costs money and usually isn’t cheap.

2. Accept latency
The internet is fast. So damn fast in fact that people’s expectations about the speed of things applies offline as well. Creating interactions that fast in the physical world is more challenging. Even if your installation communicates with Twitter via an API for eg, you always have to expect a few seconds of delay for the response to happen. (ask Kevin Slavin about that ) Motors are slow things unless you’re willing to put the money into high end engineering. If you’ve been to the Decode exhibition at the V&A, you’ll see lovely interactions that are quite slow and that’s what makes them beautiful. When you’re creating an idea, create it for speed but also for slowness.

3. Innovate in small teams
Building an “interaction design team” inside an agency is tough. People are often torn between what is considered R&D and the paid client work, especially in this economy. Some, like W+K, explore building that skillset with a separate multi-disciplinary group like Platform. I don’t think there’s any particular solution to this problem but innovation often happens in quite small teams. We’re 4 core people in our London office and that’s probably a good enough size. Our peers BERG and RIG downstairs are groups of 3-10 people max. I’ve never met a group of people who called themselves an agency that had less than 15 people on staff. I don’t know that that means they are less innovative, but as Amazon has figured out with their 2 Pizza team strategy:
“Small teams need less process, have few communications challenges, and lower overhead than larger ones. Small teams can get real work done while large ones are still trying to find common understanding about the problem. ”

4. Production vs creation
Often companies like ours aren’t production companies. We have our own creatives and vision and because we know how things are made, doesn’t mean that’s all we do, it actually means we’re more informed than most designers working in agencies. Understanding the difference between someone just doing production and someone who you can have a creative conversation with is an important part of building working relationships and might make the project much richer and interesting. Back to point number 1, I guess.

In anycase, what that event highlighted for me is that this year feels like the first of many where working in a physical way will become part of the palette of skill-sets that agencies in London and beyond will want to develop. It won’t be easy, but it will be worth it and possibly make you innovate along the way! :)

The Processing course was particularly fun. For once, I had time to teach code from fundamentals rather than (as is our usual fast-paced 1-2-day workshop approach) decipher from examples.

It was also a challenge. I’ve always been a sloppy coder, and—up to a point—I like sloppy code. It’s part of the tinkering approach—write some stuff, see what happens, write some other stuff, see what happens. Code yourself into a hole, dig yourself out of it.

But sloppy code doesn’t teach well, so on my end I found myself having to edit and write much cleaner code. More specifically, I had to write code that teaches—which turned out to be something different from good, clean, or optimized code.

As a super simple example, here are two stripped-down if statements, both of which control a shape’s color based on the state of a variable called “filled”.

//ONE WAY:

if (filled == true){
fill(255);
}
else if (filled == false){
fill(0);
}

//ANOTHER WAY:

if (filled){
fill(255);
}
else{
fill(0);
}

Both perform the same task. The second statement is easier to write and edit, and I find it easier to read. However, to understand it, you need a decent grasp of conditional logical structures, what booleans are and how they work, and how if statements evaluate what’s inside the brackets. If you haven’t thought about boolean numbers since you were in school, are unaccustomed to formal logic, and are just learning the difference between assigning values and evaluating expressions, the code is obfuscated.

In contrast, the first statement is clunky, repetitive, and (I think) slower. But it looks more like English and more clearly spells out its own logic. So in explaining how an if statement works, this turned out to be a better place to start.

This feels pedantic, but I found that I needed to consider the implications of each line of example code (whether my own or someone else’s), because any shortcut or syntactical quirk might need to be explained. Sometimes that was fine – the point of the code was to show different syntaxes or different ways to approach similar problems. But other times, small details interrupted or derailed new concepts.

In a class, this is a solvable problem–one person can effectively curate how examples build on each other, and can provide an ‘official’ pathway which students can use, vary from, and refer back to.

But a lot of Processing and Arduino learning happens outside of a classroom, without any external curation. People learn from example code, source code, tutorials, and reference documentation. And—a nice side effect of a healthy open source community—there is a lot to learn from, and may possibly entry points. But—especially for a newcomer—finding useful entry points can be tricky.

Part of coping with this is simply an aspect of self-guided learning—identifying likely next steps and knowing when to plod through the murk versus when to cut and run are important skills for teaching oneself any subject. But as I’ve been thinking about how code can itself be a medium for communication and teaching, I’ve been wondering how this fits into the asynchronous and multiple-path structure of learning in open source communities—especially ones like Processing and Arduino that specifically support beginners.

Public service organizations know this. Take a look at the hardened buttons, displays and controls in a transit system. Anything the public might encounter is beefed up to the max, because if it can break or be broken, it will. And yet, they are out there, those BSODs and broken interactions. There are two high-visibility art installations at Heathrow T5 right now, that have been “down” for a while. Interactives can be brittle in public spaces and, like transit companies, Museums inevitably have to cope with this. Many digital art pieces are one-off, specialty installations and might be around for a few months at most. It’s a shame when they don’t even last for this short duration. Just recently, I went to the digital art exhibition Decode at the V&A, featuring “the latest developments in digital and interactive design”. True to form, a couple of the pieces were out of action, sidelined and waiting for maintenance. There was one piece which I’m not sure ever really worked properly. But this is not an indictment of the exhibition, the artists, or curators at the V&A. Much of the work was innovative and aesthetically engaging. Rather, I’m highlighting the need for a culture of stewardship that we tend to forget about at the so-called cutting edge of the design community. When you’re busy doing the cutting, it’s easy to lose sight of the long view of the lifespan of the work.

There’s a tension between the desire to “expect it to work” versus the need for “design innovation”, and getting the balance right on limited resources is a challenge. Large companies have been using management approaches like the 6-sigma DMADV method or the ISO 9001/9002 standards for quality of production and servicing since they emerged 80’s. These methods yielded substantial cost savings and increased quality control. But the adopters of these standards and techniques continue to be global producers – multinational firms with mass markets. They’re making millions of widgets for WalMart and have margins to spare. Design firms tend to be smaller, and those who contract for bespoke designs and one-off interactive experiences have yet to seriously adopt these approaches. Lack of internal resources and budgets limit what can be done.

Indeed, there’s not even yet a mature enough culture of stewardship in the digital design community to address these issues. We must continue to innovate – design means seeing things in new ways and discovering the possible – but being aware of the problem is critical for improving the quality of what is delivered in the end. We must think about the long term, about the unexpected departures, plan for them, bid for them.

We try to educate our clients that digital interactive experiences must be reliable, but that means they require maintenance and service level agreements, in a word: stewardship. As any brand designer will tell you, good stewardship is key to maintaining brand value. And digital interactive work is no different. Perhaps it’s a bit premature to set such high expectations in a newly emerging arena, but I think those people who do will be the ones who stick around and who continue to deliver for their clients and their clients’ customers.

Try this code:

int count;
void setup() {
  Serial.begin(9600);
  Serial.println("Here are some random numbers");
  for (count=1; count<=10; count++) {
    Serial.println(random(100));
  }
}
void loop() {
}

I get the numbers 7, 49, 73, 58, 30, 72, 44, 78, 23, 9. You probably did too. Not very random.

Generating truly random numbers in electronics isn’t easy. There are all sorts of problems to solve – where to get the random numbers from. How to make sure they really are even and fair.

We often have need for truly random numbers on Tinker.it! projects, so we wrote a library to do just that. We’ve released it so that others can use it too. TrueRandom is downloadable from our Google Code pages.

So lets try that again, with TrueRandom installed.

#include <TrueRandom.h>

int count;
void setup() {
  Serial.begin(9600);
  Serial.println("Here are some random numbers");
  for (count=1; count<=10; count++) {
    Serial.println(TrueRandom.random(100));
  }
}
void loop() {
}

Much better.

We’re looking at using this library for games, ESP experiments, fortune telling, cryptography (generating keys, challenges and nonces) and automatically allocating unique serial numbers (UUID, Ethernet MAC addresses). We’d love to know what you use it for.

++ Lirec, an EU funded project on emotional and digital companions and robots is looking for an evangelist. A nice part time gig for someone who is passionnate about robots and a great speaker.

++ We’ve been hard at work with the lovely people from BBC R&D working on Next Generation Remote Controls.

Recently, as part of an iPhone development project I’ve been working on with the Institute of Zoology and Birkbeck, I had a need for an audio line in adapter so that we’d be able to record stereo audio from an audio sensor. The application tags audio data with GPS information as part of a citizen-scientist data collection project.

Strangely (or perhaps I didn’t dig around the interwebs long enough) I didn’t find many resources for a home-brew line-in adapter and the ones I found were pretty vague and hard to follow. So Peter and I put our heads together and rolled our own. It’s a fairly straightforward circuit, but has a little twist, because the iPhone OS is smart enough to detect what’s plugged into the stereo jack. (The diagram above is a lot more clear than anything I found.) This particular project only required a left channel audio input to the monaural iPhone mic, but if you wanted to route both left and right channels to the mic, that’s represented by the dashed line.

The resistor+capacitor network provides a pull-up that the iPhone is looking for to detect whether you’ve got a standard stereo headset plugged in or whether you’ve got a microphone (i.e., iPhone) headset and can take a phone call with it. This particular circuit is tuned for the audio sensor we’ve been using, but is about the right spec for most audio recording purposes and works fine with the audio recording app that ships with the iPhone. The parts cost about £3 and I whipped one up in about 10 minutes!

++ Post by Mark Pilgrim on the hopefully not-so-likely Tinkerer’s Sunset.

++ Freedom to Tinker site run by Princeton’s Center for Information Technology Policy, a research center that studies digital technologies in public life.

++ Swissnex SFOis a space, a service, and a platform for the exchange of knowledge and ideas in science, education, art, and innovation.

++ We were told Sorting Things Out was quite good by the lovely Elisabeth Goodman.

This weekend I stopped by the RCA Work in Progress show (featuring Design Interactions among others) and the Kinetica Art Fair. Both certainly had their high points, and here are a few of my favorites:

David Benque’s Acoustic Botany, RCA
This caught my eye, and then I was charmed by the idea. It is a concept piece considering bioengineering as a medium for cultural expression – in this instance, engineering plants and insects into musical instruments. Nut-tree cellos, lilypad speakers, termite-mound pipes, and the like.

Acoustic Botany

The designs extrapolated well from existing natural shapes, and I like that the concept posits experimental biology as another of the many fields of human endeavor in which cultural expression is a strong and natural counterpart to practical benefit.

Steffen Fiedler’s Instruments of Politeness, RCA

iPhone motions

Next to this display of not-quite-gears was an iPhone cradle and a motor. When you attach one of the jigs and run the motor, the phone is shaken in a way characteristic of the labeled gait.

While the project itself is about how people can make polite, contextual lies in remote communication, what struck me was somewhat beside the point—I liked the shapes of the different gaits. I’ve seen some over-engineered answers to the question of what an emotion or type of movement might look like, and these were nice antidotes—simple and legible, and they rang true.

Margaret Michel’s Tree, Kinetica
There were several pieces at Kinetica that I liked quite a lot, but this was my favorite: a motorized tree that uses its branches to draw its own leaves.

Tree

Very simple in execution, and the metaphor hangs together beautifully.

But What Is Missing?

I was glad to see the two shows in juxtaposition. The RCA show was concept-heavy, while Kinetica emphasized mechanical and built objects, and each filled in some of the other’s gaps. But as usual I left feeling somehow dissatisfied, and not entirely sure why.

Part of it, I think, is that interaction design, especially in the realm of physical computing and digital art, is a new enough field that we’re all still working things out. We haven’t completely determined what the major themes are, and we keep revisiting the same concepts with incrementally improved sophistication. The technologies themselves are in such flux that there’s a lot of overlap between learning a new tool, developing new ways to use that tool, inventing another tool entirely, and making meaningful statements about how that tool is affecting or may affect our lives.

Perhaps as a consequence, physical interactive works often focus on function and/or concept, with esthetic decisions coming in at the last minute, if at all. On a good day, there’s time to hide the electronics in a box. On most days, the explanatory text is essential for viewers to figure out what’s going on.

And this is where at least some of my dissatisfaction lies. It’s not even that we’re making bad esthetic choices; we’re just not making choices at all.

With the right underlying structures, you can get far with no esthetic decisions. There’s something inherently beautiful in a functional machine; add some algorithmic structures that mimic natural processes, and you can’t go far wrong. But it’s not the same as designing the form to go with the function, much less using that design to illustrate or enhance the story a work tells.

Before I left the RCA show, I went downstairs to see the architecture, and I was instantly jealous. As I walked into this strange carnival of maquettes and shadow boxes, I had no idea what any of it meant, but I wanted more. This, I thought, is what we need.

Architecture Student Work

Or, more accurately, this is what we need to start bringing together. We need to spend time with architecture, puppetry, fabric crafts, furniture design, wood- and metal-working. We need to look at different ways to embody stories and emotions in our physical objects, and bring that earlier into the process of learning new technologies, making new technologies, and trying to make sense of what it all means.