king talk

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.