Editie 2007.04

Omdat 500 paar ogen meer zien en weten dan 8, zouden we jullie om hulp willen vragen. Heb je een idee, ken je een goed pand, wil je bij ons intrekken, heb je een 'hot tip'? Mail ons dan alsjeblieft. We zijn nieuwsgierig naar standaard kantoorruimte, maar ook naar creatieve oplossingen. Ook zijn zowel huur als koop realistische opties. Zo lang het maar in Utrecht is ;-)

Een prototype is een uniek tussenproduct, waar later een hele productielijn op afgestemd moet worden (elke Autoshow bevat een hoop van dat soort prototypen). In ons vak zie je prototypes onder andere voor usability tests. Daarbij is het altijd de kunst om het prototype zo goed mogelijk te maken en tegelijkertijd budget en doorlooptijd niet teveel te belasten.

Consequently, one trait of a great prototyper is their ability to read these development processes and adjust their practice accordingly. This article, however focuses on the first point: the abilities of the prototyper. More specifically this article discusses how to improve your ability as a prototyper by discussing the elements of successful prototyping, which can be summarized as prototyping characteristics, techniques and tools. But first let's briefly look at the current state of the art in prototyping.

Current state of prototyping

Why does a prototype method work great for one project and then doing the exact same thing for another project fails miserably? This problem occurs because prototyping is not a monolithic activity, nor does it solve a monolithic problem. Let's just look at the numbers:

• there are at least 20 different development methodologies
• there are at lest 8 different ways to specify prototyping characteristics
• there are at least 15 different techniques of prototypes
• there are at least 115 and counting different prototyping tools

If you look at just these different dimensions, this means that the chances of serendipity matching the right prototyping method to the right tool to the right prototyping needs is something in the range of 1 in 276,000 (20*15*115*8). Current prototyping claims to reduce risk, but at this rate it actually creates it. At these odds, a software development team might as well try the lottery. Let's see how we can reduce these odds into something more predictable. For many of you, especially experience prototypers, you have organically developed some conceptualization of prototyping as I outline below, but it has never been a formal process before.

Prototyping characteristics

In order to get to the right prototype you have to specify it correctly. Current literature has just one characteristic: fidelity and it is usually, only high or low. However, there are many more important characteristics. These characteristics are not all so simple and straightforward, but some are. For example, take the prototyping speed: you either have a lot of time for the prototype or you are in a rush. On the other hand, the prototype style is harder to typify: some prototypes can be strictly narrative or strictly interactive, but most prototypes combine the two. However it is important to specify what you want to narrate versus what you want to be interactive. Keeping this in mind, below is a short list of important prototyping characteristics (for the complete list see the book, "Effective Prototyping for Software Makers" on Amazon or on bol.com:

1. Audience: Internal/external - the stakeholders who will view or use the prototype; not necessarily the same as the end user of the software. There could be multiple audiences which means you will require to create a prototype on multiple levels.
2. Stage: Early/midterm/late - the stage in the software creation and development process in which prototyping takes place. This determines how much flexibility in the design you have, the later the less flexibility.
3. Speed: Rapid/diligent - how much time do you have to create your prototype.
4. Longevity: Short/medium/long - how long a prototype will be used; is it a quick throwaway or something that will be used throughout the software creation process?
5. Style: Narrative/interactive - the style of participation the defined audience is expected to take, either passive (narrative) or active (interactive).
6. Interaction Design Fidelity: Far from being a binary high/low, the fidelity can be set along a continuum of very high to very low and across many different content types (i.e. Interaction, Information and Visual content).
7. Information Design Fidelity
8. Visual Design Fidelity

Now, given this complexity of the prototype specification it becomes clear that using the same prototype specs from one project to another is doomed to failure, out of sheer statistical improbability: no one company no one software needs the identical set of prototyping characteristics. Every prototype is different. And every prototype may call for a different prototyping remedy, or in other words a different prototyping technique.

Prototyping Techniques

The prototyping characteristics help determine the appropriate technique. Just to give some simplified examples:

So here are already two different prototyping techniques one would use just during the beginning of a software creation process. By using a thoughtful and analytical specification you can establish which prototyping technique you need. Depending on your skills, your organization and your resources, you may wish to use a different tool or variety of tools to get the job done.

Prototyping Tools

A prototyping tool should be chosen on essentially three criteria: the needs of the prototype, the skills of the prototyper, and the requirements of the company or organization.

- The needs of the prototype

It is true that some prototyping tools are better suited for certain prototypes than other tools. However, I specifically reject the notion that a company, or worse a practitioner, should specialize in a single prototyping tool: there should be a whole array of tools for the whole array of prototyping techniques. For example, if you are going to create a storyboard prototype, powerpoint or keynote would be the ideal tools. They have so much built in functionality that are the most suited to storyboards. On the other hand, for high fidelity wireframes, Photoshop or Illustrator could be ideal. For web applications that need to be interactive, Dreamweaver would be a better tool. In short the lesson is fit the tool to the needs of the prototype.

- The skills of the prototyper

As mentioned above, certain prototyping tools are more suitable for certain prototyping techniques. Nevertheless, that alone does not dictate the choice. There is always the human factor: the prototyper. Let's take our wireframe example. If a prototyper is an expert in Fireworks or even Visio it would make no sense to dis-empower their talents by forcing them to use another tool. If a user knows another tool extremely well, their competency in that tool can often make up the difference that it may not be perfectly suited to the prototyping task, especially if the other tool would require a steep learning curve.

- The requirements of the organization

Last but not least it also makes no sense to make a prototype in flash, if it needs to be shared and iterated on by other team members, who have neither flash skills nor copies of flash on their computer. On the other hand it could make sense to make a prototype in Keynote, when no one has Keynote but they do have powerpoint. This is because Keynote can save the prototype in powerpoint format, so it can be shared and edited by other team members.

In conclusion

Effective prototyping requires much more in-depth analysis than simply copy pasting successes. It is important to take into consideration the full complexity of specifying a prototype correctly. Likewise it is also incumbent on the prototyper to understand the many different prototyping techniques they can employ in a given project. Lastly it is also important to use the appropriate tool for the method and the people using that prototype. To effectively prototype, there are many more considerations to making a successful prototype than just simply copying previously successful prototyping practice; it requires just as careful an analysis as the act of creating software.

Author Contact

Author Bio

Jonathan Arnowitz has over 20 years experience in designing user experiences. He is currently a user experience architect at Google. Jonathan started out designing interactive multimedia software. In 1991 Jonathan moved to the Netherlands where he was an Interaction Design Consultant for over 10 years. In 2002 he returned to America, where he worked as a Senior Interaction Designer for PeopleSoft and then as User Experience Architect for SAP Labs where he worked on designing, training, and implementing User Experience Patterns for the next generation of SAP Applications. Jonathan is also a volunteer for ACM/SIGCHI where among other things he was the co-founder of the DUX conference (Designing for User Experiences), co-editor in chief of Interactions Magazine and most recently the Design Community co-chair for CHI2008. Jonathan is also the author of the book, Effective Prototyping for Software Makers, published by Morgan-Kaufman/Elsevier.

Wat is Processing?

Processing is een taal die eigenlijk bedoeld is voor mensen die plaatjes, animatie en interactie willen programmeren. Het is ontwikkeld door kunstenaars en ontwerpers (van MIT) als een alternatief op vergelijkbare multimedia authoring omgevingen als Macromeda Director, Flash en RealBasic. Pakketten die bedoeld zijn als productie omgeving voor data visualisatie, en informatie communicatie. De makers waren enthousiast over Java, maar vonden de performance over het algemeen erg traag. Zij hebben zelf de snelle Java objecten eruit gevist, en dit open source beschikbaar gesteld.

De taal is in eerste instantie ontworpen om de basis te leren van computerprogrammeren en hier zelf verder in te groeien. Anders dan in andere authoring omgevingen zijn de normale "knop" en "slider" niet als standaardcomponentjes opgenomen. Hier spreekt dan toch weer de context van waaruit de taal is ontworpen: Ultieme vrijheid om je structuur te kunnen bouwen zoals je die zelf voor ogen hebt. En met als hoofddoel: Data visualisatie. In pakketten van Adobe vind je allerhande interfaceknoppen uit velerlei systemen, die zullen voor de simpele voorbeeldjes zelf in Processing gemaakt moeten worden. Zelf zie ik dit als een mooie vingeroefening om met de taal bekend te geraken. Maar er zijn ook al erg veel bijdragen van andere mensen die een setje tools (en bibliotheekjes) voor je beschikbaar gemaakt hebben, die je zo "out of the box" kunt gebruiken. Op dit moment wordt Processing voornamelijk gebruikt door studenten, kunstenaars, ontwerpers, onderzoekers en hobyisten.

Werken met Processing

Processing bestaat eigenlijk voor de gebruiker slechts uit een verklarende woordenlijst en een texteditor. Vanuit deze teksteditor kun je de programma's compileren. Deze omgeving waarin is dus erg simpel opgebouwd. Een handige feature om je code netjes te ordenen, en een syntaxcheck om je code te controleren moeten je hierbij op weg helpen. (En deze geeft ook wel duidelijk aan wat je fout doet.) Bij Processing kun je ook gebruik maken van Quicktime en OpenGL. Bij alle mogelijkheden van de taal zijn ook voorbeelden getoond en je kunt snel en gemakkelijk een voorbeeldje gebruiken. Het uitbouwen van een voorbeeld vraagt wel wat tijd en programmeerkennis, en hierbij blijkt wel dat de taal eigenlijk geschikter is voor mensen met eerder opgedane programmeer ervaringen dan voor leken.

In de Processing editor programmeer je Sketches, en wanneer een Sketch naar jouw idee af genoeg is, dan kun je dit als applicatie voor Mac OSX, Windows en Linux exporteren, maar wanneer je gebruik maakt van Mobile Processing, dan kun je ook Java applicaties voor telefoons maken (dit is voor telefoons waar ook gewone javagames op draaien). Zie ook mobile.processing.org Er is ook al een YoutubePlayer in Mobile Processing gemaakt, en een cheater voor Sudoku's.

Wanneer je je sketch exporteerd, verzameld Processing alle benodigde snelle Java componenten, en maakt de applicatie voor je. De bibliotheekjes die anderen schrijven zijn meestal complex van aard, maar hebben wel een gemakkelijke manier om aan te spreken en zijn zo naar eigen goeddunken in te zetten. Bij de bibliotheekjes is altijd uitleg gegeven over de functies, gedragingen en mogelijkheden van de componentjes.

Je kunt ook gemakkelijk applets maken die in iedere browser werken. Omdat Processing op java gebaseerd is, is het ook gemakkelijk uitbreidbaar. Met de gesimplificeerde Java-taal maak je je eerste programmaatjes en wanneer deze omgeving niet voldoende uitkomst biedt kun je zelf de andere krachten van Java gemakkelijk toevoegen. Ofwel je voegt je eigen nieuwe componenten toe, ofwel voeg je het component dat iemand anders wellicht al gemaakt heeft toe.

Welke mogelijkheden biedt Processing?

Eerlijkheidshalve moet ik bekennen dat ik Processing alleen nog maar als hobbyist heb beoefend. Vroeger was ik groot fan van Macromedia Director en Flash. Wanneer je erg veel verschillende objecten gebruikte in Director, dan wilde aan performance nog wel eens iets te wensen over blijven, en tevens was het in Director altijd lastig om met de Xtra's koppelingen naar hardware en naar degelijke databases te maken. Daar waren voor Director geen goede oplossingen. En dit is in Java altijd goed geregeld geweest. Processing biedt hier echter gemakkelijkere en toegankelijkere oplossingen voor dan Java dat voor mij doet. De performance van appjes zoals bijvoorbeeld Sodaplay.com maakte Java ook zeker interessanter als prototype platform dan Director of Flash. (Hier komt overigens binnenkort een nieuwe versie van online: Sodaplay 2.0). Processing is echter een gratis omgeving waarin meer innovatie toevoegd aan een product dan met Flash of Director mogelijk is. Adobe pakketten hebben naar mijn mening toch een geslotener karakter en kunnen niet gemakkelijk uitgebreid worden door een open source community.

Java zelf biedt veel mogelijkheden zoals object georiënteerd programmeren, kant en klare componentjes, en goede herbruikbaarheid van eerder geschreven objecten, veel standaard koppelingen met verschillende database systemen en goede documentatie. En deze elementen zijn natuurlijk allemaal meegenomen in Processing. Ik ga verder niet alles opnoemen wat je allemaal kunt gebruiken binnen Processing. Maar mijn indruk is dat je vrijwel alles wat je met kunt bedenken, ook met behulp van Processing gemaakt kan worden, en de volgende voorbeelden illustreren dit denk ik ook.

Processing voorbeelden:

• Tube map travel times Processing voorbeeld
  Bekijk een afstandsmeter eens op een andere manier dan alleen maar op tijd met deze vinding van Tom Carden. Afstanden in London met de metro anders bekeken.
• Superglow van Toxi Processing voorbeeld Er is ook een experimentele versie in van de renderengine Sunflow voor Processing zie ook Sunflow op Sourceforge. Deze engine is werkelijk haarfijntjes.
• Geluid opnemen vanuit je browser met de ESS bibliotheek(microfoonaansluiting nodig): Processing voorbeeld
• Base 26 Processing voorbeeld
  Mooie 3D visualisatie om relaties tussen de letters van (alle) engelse woorden te visualiseren. Typ een letter om te zien welke woorden hiertoe behoren en zie met welke letter(s) deze letter vaak voorkomt.
• 3D processing van live video op Youtube
  Boeiend voorbeeld als je denkt aan de video van The white stripes "I fell in love with a girl"
• Visualisatie van de dynamiek van haar. Processing voorbeeld
• Typologie met NextText objecten. filmpje op Vimeo
  Het volgende filmpje illustreerd het gebruik van de NextText Objecten voor Processing.




Arduino en Processing

Een bibliotheek met mogelijkheden wordt ook aangeleverd door de open source hardware community van Arduino. Arduino heeft sensoren en andere zg. 'input' apparaatjes gemaakt. Dit zijn printplaatjes met ingangen (en uitgangen) voor sensoren. De Arduino printplaatjes worden geleverd met een interface naar Processing. En dat levert een heel groot aantal leuke en interessante projecten op:

• Mano dei mario filmpje op vimeo
• Hello My name is E Eindexamenproject van HKU-KMT studenten in het EMMA jaar projectwebsite
• Mirror 2007 QT filmpje van de spiegel van Daniel Rozin(bitforms) of Peg Mirror2007 QT filmpje van de spiegelvan Daniel Rozin
• Fluidforms:
  Door je eigen houten vorm in elkaar te boksen maakt iedereen zijn eigen unieke model lamp of voor $89,- een peper en zoutstel met Design with your fists of je eigen unieke Peper en zoutstel
• Botannicalls Men zou beter voor ze moeten zorgen projectwebsite

Verder dan Arduino: Natebu

Natebu is een examenproject van André Huber en Roland Broennimann. Studenten op de Zwitserse Universiteit de Academy of Art and Design. André in Industrieel Ontwerp en Roland in Media Arts. Op hun blog kun je hun project volgen om eigen sensoren te maken. Natebu Blog

Commercieel gebruik van Processing

MovingBrands een ontwerperstudio uit Londen heeft een aantal geweldige werken gerealiseerd voor verschillende partijen.
• London College of Fashion's stand op de fashion week 2007 QT filmpje
• De KEF MUON high end speaker presentatie in Italië QT filmpjeFlickr
Een laaste voorbeeld (wederom van Karsten Schmidt (aka Toxi):
• Hierbij is een filmpje gemaakt voor een viral voor de audi TT. Hiervoor is een virtuele windtunnel voor de audi TT in Processing (en java) gemaakt. Lees er meer over en bekijk het voorbeeld

Meer over:

Processing, Mobile Processing, Processing leerboeken, Arduino, Arduino hardware, Weblog Ben Fry (Bedenker Processing) en zijn proefschrift "Computational Information Design",Weblog Casey Reas (Bedenker Processing) en zijn thesis "Organic information design"

• Wat ouder stuk met de titel "The Analysis and Prototyping of Effective Graphical User Interfaces"
• Rapid software prototyping
• Jakob Nielsen over prototyping
• A Designer's Guide to Prototyping Ajax
• 121 pagina's met prototyping op Boxes and Arrows
• Met Powerpoint kun je ook prototypen
• Axure is momenteel hot om mee te prototypen
• En vergeet Visio niet. Gotta love the 'save as html' functionaliteit.

Func internet integration heeft Stroomt gevraagd voor ThiemeMeulenhoff het interactieontwerp voor een toetsenbank te maken.

De toetsenbank is een grote verzameling vragen waar docenten zelf hun toetsen uit kunnen samenstellen. Om docenten hierbij te helpen levert ThiemeMeulenhoff zelf een aantal standaardtoetsen. Deze toetsen kunnen vervolgens worden ingeroosterd en online worden afgenomen. Studenten kunnen niet alleen de toets maken, maar in een door de docent geplande inzageronde ook worden bekeken. Eigen antwoorden kunnen zo worden vergeleken met de ideale antwoorden.

In korte tijd is in nauwe samenwerking met zowel ThiemeMeulenhoff als Func een ontwerp gemaakt voor de gehele toetsenbank. Frismedia verzorgt de vormgeving.

Stroomt helpt OHRA bij de verbetering van online aanvraagformulieren en aanverwante diensten en procedures.
Hierbij is Stroomt betrokken als adviseur en ontwerper. Stroomt reviewt de online aanvraagformulieren voor diensten op gebruiksvriendelijkheid waarbij wordt onderzocht of de bestaande gevraagde gegevens niet gemakkelijker (lees: korter en duidelijker) kunnen worden gepresenteerd aan eindgebruikers.

In totaal worden voor meerdere typen eindgebruikers procedures ontworpen. Waarbij hier onder eindgebruikers, nieuwe klanten, bestaande klanten én medewerkers worden verstaan. Bij dit verbeterproces zijn naast online aanvraagstraten ook callcentre aplicaties betrokken. Stroomt maakt hierbij deel uit van het team dat interactie ontwerpen oplevert ter ondersteuning van de (ver)werkprocedures.