GUI Design met XP was een van de BesprokenOnderwerpen tijdens XpBijeenKomst6 is er gediscussieerd over hoe het ontwerpen van GUI's te integreren. Hier een samenvatting, interpretatie en aanmoediging tot verdere discussie -- WillemVanDenEnde

Met name degelijk opgeleide UsabilityEngineers zouden misschien moeilijk te integreren kunnen zijn. De xp literatuur tot nu toe biedt weinig aanknopingspunten, en de snelle iteraties zouden veranderingen die de programmeurs maken moeilijk bij te benen maken.

Een Usability specialist zal vaak een UsabilityMethode willen toepassen. Veel van deze methoden (zoals die van JakobNielsen bijvoorbeeld) gaan behoorlijk uit van BigDesignUpFront (ook wel bekend als BDUF). Er wordt een nogal TopDown proces voorgesteld, waarbij wel (net als in XP) veel betrokkenheid van de gebruikers danwel belanghebbenden wordt gevraagd. Bijvoorbeeld doormiddel van UsabilityLabs, Focus groups en RAD Workshops.

Een probleem dat door een paar deelnemers werd ondervonden was, dat zij een usability engineer hebben die vooral "denkt in concepten" en minder is geinteresseerd in "hoe de functionaliteit wordt gerealiseerd". Dit uitte zich onder meer in de wens van de usability engineer om voor optimale usability de meest geavanceerde GUI controls te gebruiken. Deze controls bestaan vooralsnog alleen op papier, en zouden dus door de ontwikkelaars speciaal moeten worden gebouwd.

De kosten van stories in een nu te plannen iteratie van de deelnemers zouden voor 80 procent aan de GUI gerelateerd zijn, en maar voor twintig procent aan "functionaliteit" bevatten. Een van de oorzaken hiervan is dat de usability expert is pas later bij het project betrokken is geraakt, en dat de UserInterface hiervoor zo eenvoudig mogelijk is gehouden (DoTheSimplestThing). De nadruk lag op het ontwikkelen van een degelijke "kern" (ApplicatieModel ?) van de applicatie.

Een andere deelnemer vertelt over hun afdeling usability: Zo af en toe komen ze langs, en dan moet alles anders. Later komen ze vaker langs, en moet alles vaker anders... Tegen de deadline komen ze nog vaker langs... Vaak hebben deze usability personen wel gelijk, maar de regelmaat en omvang van de wijzigingen is frustrerend. Een van de problemen is dat de usability mensen niet bij het ontwikkelteam zitten, maar op hun eigen kamers op hun eigen afdeling en er is daardoor gebrekkige communicatie.

Andere citaten:

onze usability persoon wil het liefst nu al weten wat we over een jaar willen hebben, zodat hij daar alvast over na kan denken

de interface is nog steeds niet helemaal consistent. Op verschillende momenten van de groei van een applicatie zijn er andere interactiemodellen nodig.

Er is tijd nodig om ontwikkelaars en usability engineers bij elkaar te brengen (en het is dus niet handig om de usability engineers pas halverwege het project binnen te halen).

De ButtonCrisis van de jaren 90 herhaalt zich als het gaat om web design Met de ButtonCrisis wordt bedoeld de tijd dat er weinig standaard componenten waren om GUIs mee te maken. Borland leverde bij voorbeeld met zijn windows ontwikkelomgevingen aparte

OkButton

en

CancelButton

mee (met respectievelijk een groen vinkje en een rood kruisje naast de tekst getekend) zodat de consistentie van verschillende applicaties binnen een windows omgeving te wensen overliet. Een mogelijke oplossing hiervoor (in Java) is om Swing Clients te distribueren met een handig (standaard) distributiemechanisme. O.A. sun toont hiervoor initiatief.

Refactoring van Client applicaties in Swing is moeilijk. Bij voorbeeld het veranderen van de volgorde van LayoutManagers is lastig. Het zou soms handig kunnen zijn om een componentje een eigen GUI te geven (als in 'componentje.draw()' )

*De genericiteit van GUI toolkits / raamwerken staat haaks op sommige zeer gedetailleerde en specifieke usability eisen. Door deze eisen moeten er veel uitzonderingssituaties worden geprogrammeerd, waardoor de logica snel in complexiteit toeneemt.

De kwaliteit van extra GUI componenten die kunnen worden gedownload van Internet of gekocht van commerciele aanbieders zoals KlGroup of ProtoView is slecht. In eerste instantie lijken ze redelijk te werken, maar na een jaar intensief gebruik komen de beperkingen echt wel aan het licht. De belangrijkste klachten zijn veel defecten, slechte documentatie en componenten zijn niet HondertProcentJava. Door dat laatste wordt portabiliteit een issue (en je hebt zeker geen WriteOnceRunAnywhere).

Het is vervelend om altijd nee te moeten zeggen tegen je usability expert, dus op een gegeven moment houdt je op met vertellen dit zijn de GUI componenten, en daar moet je het mee doen en ga je mee denken over het maken van maat componenten.

Het inpassen in een iteratief proces is lastig, GUIs iteratief ontwikkelen zeker. Moet je aparte GuiStories laten schrijven door de klant / gebruiker? Is een fulltime GuiOntwikkelaar overkill? Moet je soms een losse GuiIteratie inplannen (of meer), waarin alleen aan GuiStories wordt gewerkt? Is de UsabilityExpert dan een vertegenwoordiger van de klant, de gebruikers of van de ontwikkelaars ?

Kortom, vragen genoeg dus.