Het Stroomt Journal

Editie 2007.04

~ Stroomt huishoudelijk

De hele crew

Stroomt zoekt weer een ontwerper

Welke user interface designer / interactieontwerper / user experience designer (onderstrepen welke je van toepassing vindt) komt in onze zandbak meespelen?

Zie Werken bij Stroomt. Interessant voor jezelf misschien?

Help, we willen een nieuw huis!

Help Stroomt aan een passend thuis

Stroomt zit hartstikke goed op de Vondellaan. Goed kantoor, goed bereikbaar. Nou hebben we alleen de komende jaren een wat ruimer jasje nodig. Daarom kijken we om ons heen. De gouden tip?

Denk je mee?

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 ;-)

~ Inhoudelijk: Over Prototyping

Prototyping

Wat is Prototyping?

We halen Wikipedia er weer even bij: "Prototyping is the process of quickly putting together a working model (a prototype) in order to test various aspects of a design, illustrate ideas or features and gather early user feedback." En waar is dat handig voor?

Jip en Janneke:

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.

Effective Prototyping

Prototyping Effectively

Written/selected for Stroomt by Jonathan Arnowitz, Google Inc.

Jonathan Arnowitz is part of the User Experience Platform team at Google, where he is the head of the User Experience Pattern efforts and the User Centered Design Expert Center.

Effectively Prototyping? Who ineffectively prototypes? Unfortunately just about everyone: current prototyping practice relies on two serendipitous factors:

  • the self-created abilities of the prototyper
  • the maturity of the software development process

In the second point: you could be an expert prototyper, however, if a software development team does not have their act together, then the game is lost before its begun. -> Game, prototype, match

How it's played:

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:

Characteristic Storyboard Interactive Coded
1. Audience: Internal/external Internal: Development Team External: Venture Capitalists, financial backers
2. Stage: Early/midterm/late Very early dev is not started Very early dev is not started (!?)
3. Speed: Rapid/diligent Very short time frame (1 day) Long time frame (4 weeks)
4. Longevity: Short/medium/long Used throughout early to mid development Needed for an important presentation
5. Style: Narrative/interactive Narrative Mostly interactive, but a narrative style demo
6. Interaction Design fidelity Low to early to tell high, it must look like we know what we are doing
7. Information Design Fidelity Medium, we have some domain specialists in the team Medium, the VC’s don’t know the domain but it should look credible
8. Visual Design Fidelity Very low Very high, need to impress

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

Jonathan Arnowitz Contact info Effective Prototyping Blog

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.

Low Fidelity?


High Fidelity?

Boek:Processing

Processing

Door Menno

"What can you do with New York City's newest and largest blank canvas , a 120 by 12 foot video wall at IAC's new world headquarters designed by Frank Gehry." Was de vraag die studenten in New York voorgeschoteld kregen op The Interactive Telecommunications Program aan de New York University. Enthousiast om deze uitdaging aan te gaan en studenten de unieke mogelijkheid te bieden met dit scherm te experimenteren was het project "Bigger Screens" opgezet, om te spelen en worstelen met het mogelijkheden van dit nieuwe platform. Voor de docenten was het doel interactie met grote schermen leren aan studenten. Het bleek dat Processing hiervoor is ingezet als basis om alle ideeŽn te visualiseren. Zie ook het filmpje op Vimeo en de projectpagina. Er blijkt veel meer met dit taaltje te kunnen, en dit vond ik allemaal erg interessant en ben erin gedoken..
Wat is processing?

..om los te gaan met fysieke interfaces!

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:

Prototyping links

Links naar meer over Prototyping

Kun je er geen genoeg van krijgen?

~ Actuele Projecten

Thieme Meulenhoff en Func

ThiemeMeulenhoff en Func

ThiemeMeulenhoff is een van de drie grootste educatieve uitgeverijen in Nederland en maakt deel uit van PCM-Uitgevers. ThiemeMeulenhoff maakt inspirerende leermiddelen die een effectief middel zijn in de dagelijkse onderwijspraktijk.

ThiemeMeulenhoff probeert ook optimaal gebruik te maken van internet. Eén van de partijen die dit voor ThiemeMeulenhoff realiseert is Func. Wat deed Stroomt?

Wat Stroomt deed:

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.

Toetsenbank

OHRA

OHRA

OHRA is van huis uit direct writer en vormt de directe divisie van Delta Lloyd Groep. Het streven van de Delta Lloyd Groep is om als financieel dienstverlener binnen enkele jaren ťťn van de meest toonaangevende bedrijven in Noordwest Europa te zijn. OHRA biedt verzekeringen en financiële diensten ook online aan en deze zijn veelal 24 uur per dag af te sluiten.

OHRA wil dit laatste proces verder verbeteren en heeft Stroomt gevraagd hier extra capaciteit voor te leveren.
Wat doet Stroomt?

Wat Stroomt doet:

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.

Op onze website vind je meer recent werk.

Wanneer er een nieuwe uitgave uitkomt melden we dat per mail. Op de hoogte blijven?

Geen interesse meer? Laat dat even weten, dan verwijderen we je uit de verzendlijst.

Ook voor andere zaken kun je natuurlijk gerust contact met ons opnemen.

Bezoek ook onze site:
www.stroomt.com