In Naar Voren nr.36 geeft Nicoline Wouterlood een duidelijk beeld van de voordelen die “Rich Internet Applications” hebben op het vlak van efficiëntie en bruikbaarheid. Het ontwikkelen van zo’n applicatie is niet zo moeilijk of tijdrovend als gedacht wordt. Een goed functioneel ontwerp is het halve werk.

Aan de hand van een prototype, dat ik verderop bespreek, wil ik demonstreren dat een rich client met eenvoudige middelen te bouwen is. De technologie is niet de bepalende factor. In bijna alle gevallen van een slechte user experience deugt het functionele ontwerp niet. Het interaction design bepaalt immers het gebruiksgemak. Het technisch ontwerp bepaalt ‘slechts’ hoe het functionele ontwerp gerealiseerd wordt.

Om er voor te zorgen dat functionaliteit en technische oplossingen niet door elkaar lopen, is het handig om het functioneel en technisch ontwerp apart te beschrijven. En dat liefst ook door verschillende specialisten te laten doen.

Het eerste deel van het functionele ontwerp: analyse

Het ontwerp begint met een karakterisering van de modale gebruiker en zijn omgeving. Beschrijf in geuren en kleuren hoe enkele fictieve, maar karakteristieke leden van de doelgroep er uit ziet, wat ze doen, wat hen interesseert en wat hun waarden zijn. Alan Cooper bedacht hiervoor het krachtige concept van personas.

Analyseer daarna wat het doel is van deze gebruikers: waarom willen zij jouw applicatie gebruiken. Het doel hangt nauw samen met de doelgroep. Een forum voor hartchirurgen dient een ander doel dan een forum voor singles.

Beschrijf ten slotte het archetype van je toepassing, door de minimale functionaliteit op te sommen. Deze analyse voorkomt dat je voortijdig ontwerpbeslissingen neemt, die creativiteit in de weg staan. Een voorbeeldje: om een racespel te maken, heb ik minstens een voertuig, een parcours, een tegenstander en een finish nodig.

Een originele variatie op het racespel. Ontwikkeld door Laika voor Samsam.

Programma van eisen

Als design tool is het handig om nu alle eisen en wensen in één lijst te zetten, vanuit het perspectief van de doelgroep. Het nemen van beslissingen wordt makkelijker en je hebt een meetlat om de kwaliteit van je ontwerp te beoordelen. Aan een online winkel zou je de volgende eisen kunnen stellen:

• De klant wil informatie die hem ondersteunt bij zijn aankoopbeslissing.
• De klant moet de mogelijkheid hebben om een artikel uit het winkelmandje te verwijderen.

Het tweede deel: synthese

Door de analyse heb je als ontwerper overzicht over de functionaliteit die je moet gaan vormgeven. Ik kies daarbij voor de ‘top down’ benadering. Ontwerp eerst de hoofdstructuur van de applicatie: definieer de belangrijke onderdelen en hun onderlinge samenhang. Werk daarna de functionaliteit van elk onderdeel in detail uit. Het gebruiksgemak zit hem vaak in de kleine dingen:

• Geeft de applicatie goede defaultwaarden?
• Geeft ze duidelijke foutmeldingen met suggesties voor een oplossing?
• Geeft ze de gebruiker een kans om acties ongedaan te maken?
• Gaat ze soepel om met invoer of moet de gebruiker aan arbitraire eisen voldoen?

Het is irritant en het is fout. Ra ra, wat is het?

Het centrale ontwerpprobleem

De combinatie van goede ‘feedforward’ en ‘feedback’ geeft een applicatie ‘rich client experience’. Feedforward is belangrijk voor het bereiken van efficiency. Gebruikers willen vooraf actuele informatie over mogelijke keuzes. Waarom zou een online winkel hen lastig vallen met producten die niet meer leverbaar zijn? Feedback is essentieel voor een goede bruikbaarheid. De user interface moet snel en volgens verwachting reageren op de interactie van de gebruiker.

De problemen die gebruikers ondervinden met internet applicaties hangen nauwelijks samen met de gekozen technologie. Het zijn de standaard ontwerpproblemen van een client-server applicatie; een deel van de software draait op de client, een ander deel op de server. De verbinding tussen beide computers is wat snelheid betreft de zwakke schakel.

Het voordeel van software op de server is enerzijds de snelle toegang tot de database en anderzijds de controle over de machine. Software op de client heeft daarentegen de mogelijkheid tot directe interactie met de gebruiker.

Welk deel van de applicatie op de client draait lijkt een technische keuze. De keuze wordt echter bepaald door de functionele eisen. Om een dienst efficiënt en bruikbaar te maken moet de interactie op de client plaatsvinden, de selectie en bewerking van data op de server. Op deze manier wordt de zwakke schakel het minst belast.

Prototype Rich Internet Applications

Een prototype, dat het bovenstaande illustreert, laat je een kleur uitkiezen voor verschillende onderdelen van een auto. Omdat daarbij niet alleen je eigen smaak belangrijk is, maar ook die van de andere klanten, krijg je direct te zien hoeveel andere klanten voor dezelfde kleur hebben gekozen.

Ik nodig je uit om nu eerst het prototype te bekijken.

Uitvoering van het prototype.

De basis van het prototype is een HTML-pagina met vijf afbeeldingen <img> en een inline frame <iframe>. De afbeelding hebben een transparante achtergrond en worden met behulp van een stylesheet over elkaar heen gelegd. De bovenste afbeelding is voorzien van hotspots door de koppeling aan een image map <map>.

De hotspots reageren op muisbewegingen door tijdens het mouse-over event een andere afbeelding te tonen <area onmouseover="...">. Doordat de hotspot lijkt op te lichten, krijgt de gebruiker feedback.

Kiest de gebruiker een kleur, dan worden er twee scripts uitgevoerd. Allereerst wordt de afbeelding van het betreffende onderdeel vervangen door een plaatje met de gekozen kleur.
imageObject.src = "images/kleurtje.gif";

Daarna wordt de inhoud van het inline frame vervangen.
window.frames.frameName.location.href = newUrl;

De browser geeft de gemaakte keuzes door in het verzoek aan de server. Aan de serverzijde wordt (met perl) een document gegenereerd op basis van voorgaande ‘bestellingen’ die in een gegevensbestand zijn opgeslagen. De browser toont deze verse informatie in het inline frame. Simpel toch?

De interactieve afbeelding bestaat feitelijk uit vijf transparante plaatjes.

Een goed begin

Als functionele eisen bekend zijn voordat er gecodeerd wordt, dan is de implementatie zelden een probleem, vaak wel een technische uitdaging. Mijn ervaring is dat ontwikkelaars daar geen bezwaar tegen hebben. Anders hadden ze wel gekozen voor een carrière in een koekjesfabriek. Achteraf code aanpassen is veel lastiger, tijdrovender en zelden leuk.

• Home
• Artikelen
• Colofon