Gold plating, da’s het syndroom waarbij een mens blijft doorwerken lang voorbij het punt dat extra moeite ook genoeg extra toegevoegde waarde creëren—mensen die wél opgelet hebben tijdens de cursus economie kunnen daar ongetwijfeld iets met marginale teenoftander tegen plakken, en Cournot of watnog boven halen.
Dan is iemand een wireframe aan het maken, en beslist hij om het in html te maken voor het gemak, en natuurlijk ook omdat het op die manier aanschouwelijker wordt dan enkel in beeldjes.
En dan zit hij een uur aan de css van de header te werken, omdat hij besloten heeft dat now as good a time as any is om eens met Yahoo! User Interface Library aan de slag te gaan.
…maar neen! Wat zeg ik! Als ik het allemaal in vieze tabellen en frames had gedaan, dan zou het veel en veel langer duren om het later nog aan te passen! En een uur of zelfs een paar uur werk is niets in het grotere schema der dingen, vooral als het mij (ons) op langere termijn àl dat werk gaat uitsparen!
En trouwens, wat een geluk dat die dingen van Yahoo! echt wel degelijk in mekaar zitten: het gaat echt wel redelijk snel vooruit als ik bijvoorbeeld gewoon maar naar hier te grijpen heb als ik tabs nodig heb, of naar alhier als ik zou beslissen om de open- en dichtklappende panels in mijn wireframes ook écht te animeren.
Ahem. Zó ver ga ik niet gaan, denk ik. Want dan zitten we, vrees ik, heel erg dicht op de de eeuwige dooddoener: hoe abstract of hoe concreet moeten die wireframes zijn? Het eeuwige gewrongen zitten tussen algemeen genoeg om geen discussies te hebben in de zin van “jamaar ik zou dat font toch iets groter willen en is dat wel het juiste rood?” en toch specifiek genoeg dat het duidelijk is hoe alle dingen in elkaar zitten en met elkaar interageren…
Reacties
5 reacties op “Wireframes”
Misschien is wireframng wel helemaal niet de beste oplossing? Misschien moet je het uitschrijven in dichtvorm en uitbeelden adhv expressieve dans? Zo van: “..en michel gaat nu de user interface dansen op de x-de van Beethoven”. Ik zou betalen om te komen kijken 🙂 Vooral die geanimeerde tabs lijken me wel wat.
Wireframes moeten *zo lelijk mogelijk* zijn.
Van zodra je er een kleurtje in steekt, krijg je inderdaad opmerkingen als ‘ik hou niet van rood’.
Het enige belangrijke is de ‘flow’: hoe wordt er van punt X naar punt Y geklikt.
Ooooh… Bart, Bart, Bart.
Dat is de discussie nu net precies: als ze zo lelijk mogelijk zijn en ze worden gepresenteerd aan klanten die van niets weten, dan kan het zijn dat het allemaal al op voorhand verloren is.
En dan kun je je helemaal uitputten in uitleg, dat het allemaal niets uitmaakt hoe het er uitziet, dat het alleen maar om de flow van scherm naar scherm gaat, en om welke stukken informatie op welk scherm getoond worden: maakt allemaal niets uit.
Dan zit je met een kamer vol mensen die zich zitten op te winden: hebben we dààr geld voor betaald? Mijn dochter / neef / kennis / bakker kan beter! Wat zeg ik, ik kan beter!
Hoe, “het gaat om de interactie en niet om het uitzicht”? Hoe, “de layout is op dit ogenblik nog niet van belang”?
HOE WILLEN JULLIE DAT WIJ EEN OORDEEL VELLEN ALS HET ER ZO AFZICHTELIJK UITZIET???
Het is, zoals ik zei, een fijne lijn betreden. De tussenoplossing die ik meestal volg, is de (of een) bestaande huisstijl nemen, en op basis daarvan verder werken. Dus als het zou gaan om een nieuwe applicatie voor pakweg de VRT, zou ik het prototype of de wireframe in de huisstijl van pakweg Canvas of één maken.
Dat zou dan vertrouwd genoeg zijn dat niemand zich vragen stelt bij het uitzicht. Wat, helaas uit bittere ervaring, niet het geval is met de standaard lo-fi-wireframes die de boekskes zeggen dat we zouden moeten maken.
En wat als je (zoals bij ons meestal het geval is) een totaal nieuwe huisstijl moet maken?
Dan creëer je totaal foute verwachtingspatronen bij de presentatie van de wireframes.
Je hebt uiteraard gelijk over de reactie – als je die ‘lelijke’ wireframes zonder meer op de klant loslaat.
Wat helpt, zoals altijd, is kadering en communicatie. Bij het begin van het proces alle stappen uitleggen (éérst wireframes, dan layout, dan integratie etc.). Vooraleer we aan de wireframes komen, voorbeelden tonen (van andere projecten, over de verschillende stappen). Vooraleer we de wireframes tonen: opnieuw uitleggen (‘het is géén layout’).
De discussie blijft uiteraard; maar dit is voor ons de juiste aanpak gebleken.
Er is natuurlijk niet één wonderoplossing. Als alles ideaal kan verlopen, en als alle beslissingnemers kunnen uitgelegd worden oe het precies zit, dan is het geen enkel probleem om een zwartwit-ding te doen.
Maar als het te presenteren is aan een kamer vol topmanagement, waarvan de helft voor een namiddag in België is en vandaag tien beslissingen heeft te nemen, of in het algemeen als de beslissingnemers niet van relatief dichtbij betrokken zijn, dan doe ik het eerder met een bestaande stijl.
Er hangt natuurlijk ook enorm veel af van hoer de nadruk verdeeld is over inhoud, interactie en opmaak.