Programming is an important part of what we do as interaction designers. Be it for prototyping, experimenting or just simplifying things – it’s pretty useful to know your way around coding. And we live in the right time for this kind of development because the tools available are more accessible and more diverse then ever. To give you a little guidance, here’s a summary of the tools/languages we use.

Processing (Java)

Great for general purpose programming. Unobtrusive, fast, and almost endlessly extensible. It is our first choice if we want to quickly sketch something using code. If you’re not into coding already, processing is a great place to start.

OpenFrameworks (C++)

We use OpenFrameworks whenever there’s a lot of computation involved (image manipulation or tracking for example). It’s great especially for installations, because of its speed and its I/O capabilities.

Flash (ActionScript)

Yeah, some people still use this. While we don’t use Flash for web development, it is great as a prototyping tool for both interfaces and installations. The fact that there is a graphical editor included makes it easy to mock up things like transitions or basic interaction. It is also platform independent, so we can develop on a Mac and use it on a Windows computer (the kind of which are often used in installations).

But there is one more aspect for which we love Flash, and that is its handling of text. Both Processing and OpenFrameworks depend on open source libraries to render text. Unfortunately, those libraries are neither fast nor very high quality (probably mostly due to patent restrictions, but that doesn’t matter to the result). Flash has a pretty good and versatile text engine, so it is ideal for the job.

Webkit (HTML/CSS/Javascript)

The glorified new kid. Also a good (and really easy) way to mock up interfaces. One advantage of HTML is that quite often you can transition from prototype to product without rewriting everything. That makes things faster.

We especially love the webkit engine because it can be used everywhere (it’s the rendering engine of Chrome and Safari and is also used in most mobile browsers), has a pretty good feature set (say it with me: 3D Transforms) and also because it has little weird compatibility issues. That makes it great not only for the web, but also for prototyping and – sometimes – installations.

So, while there are other languages we use occasionally (Objective-C, Silverlight…), these are the four most important ones for our everyday work. I’m sure there’s other ways to approach this, but it worked really well for us so far.

I am guilty of owning an iPhone 4S and I’m guilty of being excited about Siri. Recently John Pavlus wrote on Fast Company Design that Siri is the ultimate interface: none. So I’m asking myself: if it is the ultimate thing, why does it still feel so artificial to use? Turns out that usability is not so much about the input technology, but rather about trust.

It’s a bloody command line!

If you break it down, Siri is just a software that handles text input. It knows a certain set of commands that it can act upon. This puts Siri into one box with terminals or other language interfaces like Quicksilver or Enso.

The problem with command lines from a usability standpoint is that they are completely opaque – you do not know which commands the machine understands. Even worse, you have no idea what it will do if a command is misunderstood. That means that a command line is either perfect because it understands everything, or it sucks because it is unpredictable. Alas, I have yet to see a perfect command line interface.

Image by The Oatmeal

Siri is still a magnificent piece of technology. It understands more than any other such system (at least when the input language is set to English) and it can do incredible things. But ultimately, a technology is never judged by its merits, but by its flaws (or the lack thereof). Working flawlessly creates trust. But every misinterpreted result makes Siri a little less trustworthy.

After two and a half years of writing for WEAVE Magazine, we finally managed to smuggle a picture of us, a grill and lots of meat into the new issue!

For the better part of this year I worked on installation projects like Streamflow and Holodeck. But in the last couple of weeks I finally had a classic interface project on my desk again.

This also meant that I got the chance to do some interface sketches again; something I almost forgot could be fun. Here are a few things (re)discovered and found interesting.

The Purpose of Sketching

The only reason why I do sketches (and not start directly with, say, wireframes) is to organize my thoughts. When I think about an interface, I always see a few details very clearly in front of me while the big picture is still blurry. Sketching allows me to organize my thoughts, combine them and create new stuff based on older drawings.

Use a Pen you Like

Everyone has a different style when it comes to bringing thoughts to paper and the pen should support that style. I personally need a rather thick pen for drawing and settled with an Edding 1300 felt marker. It is thin enough to write annotations but also thick enough to force me to ignore details in the beginning.

(Paper) Size Matters

I sketch on A3 paper. It is still managable in its size, yet large enough to accomodate a whole group of sketches. I like to draw interesting details next to the basic layout so that I get a clearer idea of the whole composition.

Start Tiny

My sketches grow as my idea of the interface becomes clearer. While the first sketch might be just 5 by 5 centimeters, the last one might fill a whole A3 sheet.

The size of the initial sketches also depends on the pen I use.
The thinner the pen, the tinyer the first sketches should be. This keeps me from trying to figure out every detail in the first sketch and thereby also reduces the fear of doing things wrong.

How do you Sketch?

Do you use similar techniques for sketching or are they completely different? Let me know in the comments!

A prostitute won’t give you free sex just so that she can then charge you for the pillow talk. She won’t give the good stuff away for free.

For some reasons, designers are happy to do so. They create elaborate concepts and plans – sometimes even multiple proposals – pack it all into a high gloss presentation and then hope for the client to be gracious enough to pay them afterwards, when the whole thing needs to be put into practice.

This might work if you are a big agency and you have a lot of time to kill. But it can be lethal for smaller companies or freelancers. If you don’t have a lot of money and resources, you simply can’t afford to do unpaid pitches. Working for free is not going to change your financial situation for the better.

Why do people want pitches, and why is it bad?

1. They don’t know you and they want to make sure that you are worth your money. This means that there is no confidence (and probably limited interest) in your work – which is a bad basis for working together. A good portfolio and some recommendations can turn this ship sometimes.
2. They don’t know what they want and would like to collect ideas upfront. In this case, you’re giving away what you do best upfront. It is pretty common that the winning agency will be told to use some of the ideas of its competitors.
3. They don’t know IF they actually want to do something and they want you to figure out if it is worth it. This is probably the worst form, because more than often it doesn’t even lead to a job for anyone.

In our three years of existence, we never participated in an unpaid pitch. We did two paid pitches in two years – still too many for my taste. We like to charge for our sexy time.

For our latest article in WEAVE magazine, we took a closer look at Microsofts Kinect and how you can do some really interesting things with it. You will learn how to use OpenFrameworks to write an extremely robust and versatile tracker that works great for interactive installations.

Fitts law is one of the most important principles in interaction design. What is it and how does it apply to various types of interfaces?

In 1954 an Ohio State psychologist published a paper named »The Information Capacity of the Human Motor System in Controlling the Amplitude of Movement«. It presented a model for measuring the time it takes someone to hit a certain control of a machine, based on the position of the hand, the distance to the control.

The author of this paper was Paul Fitts and his findings are a key ingredient to every measured user interface design process. It was – and still is – glorified by many designers and engineers, probably most notably by Bruce Tognazzini, the first application software engineer at Apple. He even developed a set of questions about it which he would ask every aspiring software engineer. So what’s so important about it? Let’s have a look.

Design Decisions

Generally speaking, Fitts’ law says that the time to hit a target will increase when it is small and far away, and decrease when it is close and large. You can find the actual formula on Wikipedia. Since the late 70s, this law has been applied mostly to graphical user interfaces, where the mouse cursor replaces a hand.

This simplified many things. There was only one cursor at any given time. It always pointed to an exact pixel location and moved only on a two dimensional plane. This – probably most importantly – didn’t allow the cursor to escape out of its bounds, thereby making the edge rows of pixels practically infinite.

These specializations have been widely used in interface design. They are the reason why the application menus in Mac OS are at the very top, why active corners work, and why it is still so damn hard to hit the tiny x-Button in the corner of your window.

Brave new touch world

In the recent years however, a novel form of interface has flooded the market and the media coverage: the (multi)touch interface. No longer do we have to rely on a single pointer of a mouse, as everyone of us has ten pointers built into our bodies. In a way, this takes us back to the time when Paul Fitts originally published his findings. The adaptions we made to his law in order to fit the mouse interface no longer hold valid. So where does this take us?

What to scrap

First, we need to acknowledge that certain (handy) implications of Fitts law simply don’t exist on touch devices. Probably most prominently the »infinite edge pixel« idea. Most devices are designed in a way that tries to hide the edge between the screen and the surrounding bezel, so you can’t even feel it when your finger glides off the screen.

But even if the screen area of these devices were somehow fenced, it probably wouldn’t help much. This is because there is no onscreen rest position. A mouse is always pointing to a pixel somewhere on the screen. When you click the mouse, there is always a target. This doesn’t hold true for touch devices where you lift your finger away from the screen once you pushed a button.

This means that there is no hover state, which is one reason why many websites feel somewhat awkward on tablets and phones.

Adapt, adopt and improve

When Fitts first developed his theories, there obviously were no GUIs as we know them today. He formed his theories based upon experiments in three dimensional space – the same environment our modern touch devices live in. Not only does this mean that the basic math behind Fitts law is still valid, it was really developed for these kinds of devices.

Especially target size is still very important. While it was crucial in mouse based interfaces to be large enough in order to be easily targeted, it now needs to be even larger so the finger of the user doesn’t cover it completely (thus preventing visual feedback).

The distance between the current position and the target also stays with us, though it needs to be adapted a little. First of all, the »current position« can be one of two things: the position of the last control that has been pressed, or the rest position of the hand. For example, when using a dial pad where you need to push several buttons in a sequence, proximity of the buttons to each other is more important than proximity to the rest area. In the case of an RSS reader with its next/previous buttons, being easily reachable from the rest position is paramount.

Conclusion

What separates useful theories from the less useful is that they are universal. Fitts law is one of those theories. Even though technology has taken many turns since its discovery more than half a century ago, the core ideas are still valid. Bruce Tognazzini was absolutely right to make Fitts law a mandatory question in every job interview. And you should be able to pass that test if you want to be an interaction designer.

Photo by Jesse Bikman

Knifflige Rätsel, schräge Charakteren, ausgefeilte Dialoge und eine möglichst komplexe Geschichte, davon lebt ein Adventure. In erster Linie geht es darum Rätsel zu lösen um am Ende an Ruhm, Ehre, Reichtum oder die große Liebe zu gelangen. In diesem Genre ist Köpfchen gefragt und auch eine Vorliebe für detailreiche Geschichten aber wie baut man eine solche Geschichte am besten auf? Um eine neue Geschichte zu erschaffen, sollte man zunächst die wichtigsten Eckpunkte des Geschehens festlegen. Dabei können die W-Fragen hilfreich sein:

Wer? – Definieren des Hauptcharakters
Wer soll der Held in der Geschichte sein? Was zeichnet ihn aus? Was sind seine Stärken und Schwächen? Um den Helden der Geschichte genau zu definieren sollte man eine Persona mit seinen Vorlieben, Wünschen etc. erstellen.

Wer noch? – Definieren der anderen Personen
Wer ist der Bösewicht der Geschichte? Wen trifft der Held auf seinem Weg? In welcher Beziehung stehen diese Personen zum Helden? Auch hier Hilft das erstellen weitere Personae für die Nebenrollen.

Wo und Wann? – Definieren einer Zeitperiode und eines Ortes
Zu welcher Zeit spielt die Geschichte? Wo spielt die Geschichte? Wo herkommt der Held? Wo will er hin? Es ist wichtig den Handlungsort genauestens zu beschreiben. Das Anfertigen einer Karte oder verschiedener Skizzen zu den einzelnen Schauplätzen kann helfen die Orientierung zu behalten.

Was? – Definieren eines Ziels
Was möchte der Held erreichen? Was für eine Aufgabe hat der Held? Was ist seine Bestimmung? Bevor man die genauen Ereignisse in der Geschichte näher beschreibt sollte man den Anfang, den Höhepunkt und das Ende der Geschichte definieren.

Wie? – Definieren des Geschichtsverlaufes
Wie schafft es der Held sein Ziel zu erreichen? Welche Rätsel muss er lösen? Wie kommt er weiter? Um zum Hauptziel zu gelangen, muss der Held verschiedene Zwischenziele erreichen.  Diese sollten nun Stück für Stück festgelegt werden.

Anwenden der W-Fragen auf klassische Adventures:

The Secret of Monkey Island

Wer? Guybrush Threepwood vs. LeChuck
Wo? Karibik, Monkey Island
Wann? Blütezeit der Piraterie
Was? Guybrush möchte Pirat werden
Wie? Er muss drei Prüfungen bestehen

Edna bricht aus


Wer? Edna vs. Dr. Marcel
Wo? Irrenhaus
Wann? Gegenwart, Vergangenheit
Was? Edna will ihre Erinnerung zurück
Wie? Aus der Irrenanstalt fliehen

Sam & Max – Hit The Road


Wer? Sam & Max vs. den rest der Welt
Wo? Amerika
Was? Möchten verschwundenen Yeti finden
Wie? Spurensuche an verschiedenen Schauplätzen

Das Formen einer Geschichte
Hat man nun die groben Eckdaten festgelegt, ist es an der Zeit die Geschichte zu einem Ganzen zusammen zu setzen. Jede Geschichte teilt sich in drei Abschnitte: Einleitung (Prolog), Hauptteil, Schluss (Epilog).

Zu Beginn der Geschichte muss ein schneller, möglichst dramatischer Einstieg erfolgen. Die Motivation des Helden, welche ihn in sein Abenteuer treibt, muss zu diesem Zeitpunkt klar erkenntlich sein.

Nach dem Vorwort folgt die Reise/Entdeckungsphase des Helden, das eigentliche Spiel. In diesem Abschnitt geht es darum dass der Spieler die Geschichte hinter seinem Helden stückweise kennenlernt und damit immer mehr emotional mit dem Helden verbunden wird. Die Rätsel die der Spieler mit seinem Helden löst führen ihn immer näher zum Ziel. Außerdem sollte der Spieler für jedes Rätsel eine Belohnung erhalten. Das kann eine neue unbekannte Umgebung, eine neue Person oder ein Stück der Gesamtgeschichte sein.
Im Laufe der Geschichte können sich die Motivationen des Helden immer wieder ändern. Er will aus einer Gefahrensituation entkommen, er will reich werden, er will das Mädchen haben. Man sollte deshalb immer die Bedürfnisse seines Helden im Hinterkopf haben um die Geschichte glaubwürdig zu gestalten (Maslows Bedürfnispyramide).

Die letzte und wichtigste Phase des Spiels ist das Ziel. Sie entscheidet darüber wie die Bewertung des Spielers über die Geschichte ausfällt. Am Ende des Spieles kann es zum Happy End und zur Aufklärung der Geschichte kommen, muss es aber nicht. Erreicht der Held sein Ziel beispielsweise nicht kann am Schluss der Geschichte zumindest eine Erkenntnis für den Helden stehen.

Grundsätzlich kann ein Adventure nie zu tragisch, traurig, ausgefallen oder verrückt sein. Alles was den Spieler an die Geschichte fesselt ist erlaubt und sollte überzeugt eingesetzt werden.

Wait, what?

Saying that you »have to« do something is mostly an excuse – and a pretty lame one. By doing so, you avoid committing yourself to anything. You say that some external force (your boss, your wife, your dog) is making you do something – and if you don’t, there will be consequences.

Here’s the main problem I have with this approach: If you »have to« do something, it doesn’t say anything about wether or when you are actually going to do it. All you are doing is attributing some importance to the thing you »have to« do.

Also, the consequences of not doing something remain unstated. On every level, you are avoiding to get specific about the thing you allegedly »have to« do. And trying to substitute it with »I will« every time this comes up has made me aware of that.

Ultimately, switching from »must« to »will« forces you to make decisions. You either commit yourself to something or you don’t. It eliminates the weird middle way anymore. No more importance without action.

Do you think you »have to« do something? Will you actually do it?

Inhabitants of northern Germany, rejoice! We are bringing our workshop CODE = DESIGN to Hamburg on June 10th. Together we will dive into the world of generative design. We’ll introduce you to creative coding and get you started with creating your own visual experiments.

We are offering this workshop in association with PAGE and WEAVE magazine, so they are handling all registration and payment issues. We are excited about the opportunity to visit Hamburg. See you there!

Sign up here!

In ancient times, there were no professions. Every human being (or at least every family) was ultimately responsible for his or her own survival. This included hunting for food, making clothing and creating tools in order to do so.

Now that was some time ago. Nowadays we live in a super specialized society. Globalization made it necessary for people and businesses to get into ever smaller niches. Generalists have become rare.

And that’s mostly a good thing! You don’t want your plumber to be your doctor and vice versa.

Anyway, when it comes to the creative industries, specialization can become a real pain in the ass. We have managers that do nothing but manage, designers that have no idea how production works and programmers that don’t waste a single thought on the user.

Which brings us to the three reasons why you are better off as a generalist

1. It is more than enough (most of the time)

Let’s be honest: for most jobs in design, you don’t have to be a super-specialist in your field. You don’t have to be Linux kernel hacker to code a decent prototype. You don’t have to be Picasso to sketch out your ideas.

Certainly, there will be tasks where 100% of the obtainable knowledge in a field will be required. But in the design field, that is the exception.

2. Different angles

Our brain is much more than a simple storage device. It instantly creates connections between the things it learns. It constructs stories out of facts.

Now, if you only work within a single and super-specific field, your brain just hasn’t that much stuff to create those connections. And if you work in the creative field, your work ultimately depends on those connections.

3. Be an integrator

In today’s design world, it rarely happens that the whole creation process is being carried out by a single person (specialization, remember?). So you’ll have to deal with people from different professions no matter what.

A generalist view of this process makes you the integrator in the team. You are the one, that sees the big picture.

Be special by being nothing special

Being a generalist might sound risky in theory, but it has huge advantages in reality. Leonardo Da Vinci was a generalist. So were Leibniz and Archimedes. They all expanded their profession by not only taking glimpses into other fields, but by thoroughly studying them. If you dare to do the same, you are in good company.

This years overall winner at the Europrix Festival is the Whispering Table. A round black table, empty white dishes – nothing special at first sight. Approach the table and touch the dishes. You will quickly discover that they start to tell you personal stories about the symbolic meaning of food and rituals, related to four unique festivities celebrated by people of distinct cultures. By changing their position on the table and their distance to each other, you reveal new stories.

TheGreenEyl used different sensors and microelectronics for each module. Apart from the technical aspect, the most important part of this installation is you, interacting with this devices.

Finally, our new game for iPad is available on the App Store. We call it Quasar Touch, and it takes you into a world of dark emptiness, where your only objective is to protect a source of light.

We like the simple gameplay that can change rapidly from easy to challenging. The soundscape has been generously provided by russian artist x3d5.

Quasar Touch has been created using OpenFrameworks (which is increasingly replacing Processing as my weapon of choice for creative coding).

We’d love to hear what you think about Quasar Touch! Let us know in the comments.

If you follow this blog, you know that we are sometimes giving lectures and workshops at universities. Since then, we’ve been asked over and over to hold a similar workshop for non-students as well. And we are going to do exactly that.

On November 18/19, we will meet with ten participants in order to explore the possibilities of code as a design tool. We’ll learn how to get started with coding and how to use it to create stunning artworks.

If you are unsure about how code could possibly be of interest for a designer, just look at the corporate design of decoded conference.

It would be great to see some of you at the workshop! More information and a registration form can be found on the workshops website (German).

In my time as a designer I met more than many people who considered themselves perfectionists. Even today, when I am interviewing job applicants, this dreaded word comes up frequently. Why is it dreaded? Because I believe that a perfectionist is either extremely unproductive or disingenuous about himself.

I’d like to show you why I think this is a problem and how to overcome it.

Why Perfectionism Doesn’t Help

Consider this: the wheel is one of the oldest inventions of mankind. It dates back several thousand years and has since seen many iterations, adaptions and modifications. Still, we are improving it even today. All of humankind has not been able to create the »perfect« wheel in thousands of years. So who are we to think we can create perfection in a much more complicated field with infinitely less time at our hands? This is where perfectionists are disingenuous.

But just for the sake of argument, let’s assume that we are serious about our ambitions. If we want to create a perfect solution to a problem, we are implying that we know every possible solution to this particular problem. Otherwise, how would we know that there is no better solution? Once again, we are bullshitting ourselves – and this doesn’t even take into account that we might have misunderstood the problem in the first place. Even approximating something like perfection would take forever – quite literally. And that’s why perfectionists are unproductive.

Fear of the Less Than Perfect

I believe that many designers are perfectionists out of fear. Namely out of the fear that what they do is not good enough for the broad public. We know that a big part of our profession is solving problems, but we tend to forget that this comes with an obligation to deliver the results. Thankfully, often we have clients and their deadlines reminding us that we can’t have a work-in-progress-excuse forever. But what if our client is sloppy about enforcing deadlines or if we are working on self-commissioned projects? In that case, are always in danger of falling for the temptation of perfectionism.

A Change in What You Think

In order to overcome our self-deception of perfectionism, we need to change our mindset. We need to overcome the fear of public rejection – mainly because it is mostly a product of your fantasy. Think about it like that: whenever you decide to not release something, you are not helping people who might need it. And guess what: the people you are helping are a lot more likely to give you money or credit than those you don’t help. Dave Navarro actually has a whole booklet on this topic and explains it better than I could.

A Change in What You Do

When you have let this thought into your brain, the next step is to actually start producing something tangible. Another aspect of many perfectionists is that they are only perfectionists in theory. That means that they want to solve every little detail upfront in a concept. If you are that type of person, it is likely that you already found out that this strategy doesn’t work. I certainly have.

So whenever you find yourself in the infinite loop of perfectionism, think of the wheel again. You won’t start with a perfect product. But think of the way that history might have turned if the inventor of the wheel had withheld his invention until he could make it perfect.