Hieronder volgt eerst de planning van fase 2. Daarna worden de onderdelen van deze fase (hierboven in bold weergegeven) verder uitgelegd.

Transcriptie

1 Fase 2: prototype versie 1.0, 21 februari 2017 Wat doe je in fase 2? In deze fase ontwikkel je een werkend prototype, dat je vervolgens presenteert aan de opdrachtgevers. Aan het begin van deze fase stel je je plannen bij op basis van de feedback van de assistenten op het rapport van fase 1. Ook vervaardig je het visueel ontwerp van het prototype. Tegelijk hiermee begin je aan de ontwikkeling van het prototype. Als het prototype af is, evalueer je het met een heuristische evaluatie en een gebruikersevaluatie. Op basis van de evaluaties besluit je welke bijstellingen er gemaakt moeten worden. Je doet ook een terugkoppeling aan de oorspronkelijke requirements, en een procesevaluatie. Je rondt fase 2 af met een presentatie en een rapport die je, met het prototype, via Submit inlevert. Hieronder volgt eerst de planning van fase 2. Daarna worden de onderdelen van deze fase (hierboven in bold weergegeven) verder uitgelegd. Planning fase 2 Hieronder een strakke maar haalbare planning. Er zit geen uitloop in, dus plan als het even kan je eigen werk nog strakker! Spreek je teamleden erop aan als ze zich niet aan de planning houden. ma 20 maart (week 8) bijstelling visueel ontwerp planning prototype tussendoor prototype bouwen voortdurend (intern) evalueren ma 27 maart (week 9) prototype afronden expertevaluatie plannen/beginnen gebruikersevaluatie plannen/beginnen eindrapportage plannen tussendoor evaluaties uitvoeren bijstellingen bepalen rapportage opstellen do 6 april (week 10) LET OP: werkcollege verplaatst terugkoppelen prototype aan requirements procesevaluatie presentatie plannen voortgang rapportage 1

2 tussendoor rapportage afronden prototype afronden presentatie voorbereiden ma 10 april (week 11) inloopspreekuur. Dit werkcollege is niet verplicht, maar er is gelegenheid last minute advies in te winnen bij de assistenten do 13 april (week 11): presentatie projecten do 13 april (week 11): inleveren rapport fase 2 + prototype + presentatie via Submit (23:59) Stappenplan fase 2 Hieronder volgen algemene beschrijvingen van de afzonderlijke activiteiten in deze fase. Het is voorstelbaar dat je hier op bepaalde punten van wilt afwijken, omdat jouw project specifieke eisen stelt. Bespreek dit met de assistenten en vraag om toestemming. 1. Bijstellen (1) Ga op basis van de feedback van de assistenten na of je huidige ontwerp nog moet worden aangepast. Voer die aanpassingen door in rapport 1 en eventuele andere ontwerpdocumenten, zodat iedereen precies weet wat die aanpassingen zijn. Je hoeft rapport 1 niet opnieuw in te leveren. LET OP: er is maar heel weinig tijd tussen het inleveren van rapport 1 en het eerste werkcollege van fase 2. We kunnen niet garanderen dat we alle inleveringen al voor dit werkcollege volledig kunnen beoordelen. Er kan dus nog 'nagekomen' feedback komen. Laat dit je niet weerhouden om aan de slag te gaan met fase Visueel ontwerp Het is belangrijk voor de presentatie aan je opdrachtgever dat je prototype een consistente en aantrekkelijke vormgeving heeft. Besteed hier dus de nodige aandacht aan. Maar bedenk wel dat professioneel vormgeven heel tijdrovend is, en dat het streven naar een gelikt uitziend project ten koste kan gaan van andere belangrijke kwaliteiten van het prototype. Houd je design dus simpel. In termen van Benyon ontwikkel je hier voor je product een 'design language' met onder andere: keuzes betreffende, vormen, kleuren en lettertypes een verzameling widgets zoals knoppen, search boxes, sliders, menu's, etc. eventueel andere interactie elementen als touch, gestures of spraakbesturing opmaakregels: hoe voeg je dingen samen? Met dat laatste komen we al in de buurt van de schetsen, wireframes en dergelijke die je voor het basisontwerp gemaakt hebt. 3. Prototype bouwen In principe heb je nu alle elementen verzameld om een prototype te kunnen gaan bouwen. We maken een 'horizontal prototype', waarin alleen de user interface aanwezig is en de feitelijke systeemfunctionaliteit alleen nagebootst wordt. Een 'vertical prototype' daarentegen implementeert wel (een deel van de) systeemfunctionaliteit. Teams die het niet kunnen laten om het voor detaillering gekozen aspect uit te werken als 'vertical prototype', zullen we dat niet verbieden. Maar het leidt niet tot een hogere beoordeling. We zijn in deze fase alleen de geschiktheid van een user interface voor een bepaalde taak aan het bepalen. 2

3 Blijf tijdens het ontwikkelen van het prototype voortdurend evalueren. Het is heel makkelijk om van je plannen af te wijken, omdat iets handiger lijkt, je iets vergeet, je ontwikkelomgeving waanzinnige mogelijkheden heeft, of wat dan ook. Een goede check is steeds te testen of je de scenario's nog wel na kunt spelen. Aan het prototype voeg je in ieder geval een algemeen beginscherm toe (dat van de site als geheel, bijv. de homepage). Op dit beginscherm staat de keuze die je naar de Use Case(s) brengt. Afhankelijk van de gekozen Use Case(s) kan het nodig zijn nog enkele voorgaande schermen toe te voegen. Al deze toegevoegde schermen zijn alleen 'afbeeldingen' waarop je (alleen) de keuze(s) kunt maken die uiteindelijk tot de betreffende Use Case leidt. Heb je bijvoorbeeld de 'afrekenen van een aankoop op www' Use Case, dan simuleer je een paar schermen (bijv. startscherm winkel, keuze categorie, keuze artikel) waar ergens 'afrekenen' gekozen kan worden, waarna de 'afrekenen' Use Case volgt. M.b.t. de technologie waarmee het prototype gebouwd wordt, wordt in deze cursus geen eisen gesteld. Het is waarschijnlijk het makkelijkst om HTML te gebruiken. Dit is het eenvoudigst, kost het minste tijd (zowel leren als ontwikkelen) en is in de meeste gevallen wel toereikend. Tekortkomingen m.b.t. het 'gedrag' van de applicatie zijn op te lossen door inzet van eenvoudig JavaScript. Tekortkomingen m.b.t. de grafische vormgeving en interactie elementen zijn op te lossen met 'clickbare' images. Lees op hoe je gebruik kan maken van je studenten webruimte. Anders dan hier staat, kun je PHP gewoon gebruiken, zie ook de site van Webtechnologie. Wanneer je andere technieken, frameworks e.d. wilt gebruiken, dien je zelf voor webruimte te zorgen. Gameprotoypes zullen waarschijnlijk een meer 'verticaal' karakter vertonen. Gebruik hiervoor technologie waarmee je vertrouwd bent (Gamemaker, XNA, iets anders...). Voor apps zijn verschillende prototyping omgevingen voorhanden, maar het is waarschijnlijk het gemakkelijkst met HTML 5 en een emulator als aan de slag te gaan. Uiteindelijk gaat het erom dat je interface de interactiviteit heeft die nodig is om je ontwerp goed te kunnen evalueren. 4. Evalueren Twee soorten evaluaties worden uitgevoerd: een heuristische (expert)evaluatie en een gebruikersevaluatie. Let op dat de evaluatie pas plaats kan vinden als het prototype af is. Houd hiermee rekening bij de planning van het werk. Heuristische evaluatie Een heuristische evaluatie is een methode om problemen in de interface te vinden. Een klein aantal evaluatoren test de interface en bepaalt of deze wel in overeenstemming met bepaalde ontwerpprincipes (de 'heuristics'). Heuristische evaluatie heb je al geoefend in Opdracht 2 van het werkcollege. Je gebruikt dezelfde set van design principes, hetzelfde Excel template en uiteraard ook dezelfde procedure. Doe de heuristische evaluatie met 3 personen. Ze voeren de evaluatie eerst afzonderlijk uit, en overleggen dan samen over de definitieve evaluatie van de gevonden problemen. In een ideale wereld wordt de heuristische evaluatie niet door het ontwikkelteam zelf uitgevoerd (je hoort inmiddels te begrijpen waarom...) maar dat is in de werkcollegesituatie niet goed haalbaar (tenzij je hierover keiharde afspraken met een ander groepje weet te maken). De evaluatie mag dus door de eigen teamleden worden uitgevoerd. Denk wel even na over de consequenties voor de taakverdeling. 3

4 Cooperative evaluation Vertel minimaal 3 gebruikers (liefst mensen die OIS niet volgen of gevolgd hebben) wat de bedoeling van de applicatie is en laat ze hier dan mee werken. Volg hierbij de methode van cooperative evaluation zoals ook gebruikt in fase 1. Vergeet een belangrijk ethisch aspect van gebruikersonderzoek niet: deelname is vrijwillig en de gebruikers kunnen op elk moment, zonder opgaaf van redenen, besluiten te stoppen. Het is ook onethisch om dan druk uit te oefenen toch door te gaan (en natuurlijk slecht voor de uitkomsten van je evaluatie). 5. Bijstellen (2) Zoals je wel gemerkt zult hebben: je vindt met de evaluaties wel problemen, maar dit betekent niet dat ook automatisch duidelijk is wat er gedaan moet worden om het probleem te verhelpen. Hiervoor moet je weer terug naar de tekentafel met je ontwerp. Waarschijnlijk is er geen tijd in het project om de resultaten van de evaluaties nog te verwerken in je ontwerp en het prototype. In plaats daarvan doe je het volgende: Bespreek welke conclusies er uit de evaluaties getrokken kunnen worden en leg deze vast. Als er problemen geconstateerd zijn, op welke ontwerpaspecten hebben deze dan betrekking? M.a.w. waar in het ontwerp en waarom denk je dat het misgegaan is? Welke maatregelen denkt het team te kunnen nemen om deze problemen op te lossen? Maak van dit alles een kort en duidelijk hoofdstuk in je rapportage. 6. Terugkoppeling Nu het project zo goed als ten einde is, is het belangrijk het resultaat nog een keer met de oorspronkelijke requirements te vergelijken. Heb je je aan de requirements gehouden of zijn er afwijkingen opgetreden? Heeft het proces geleid tot voortschrijdend inzicht en moeten de requirements nog worden bijgesteld? 7. Procesevaluatie Evalueer als team gezamenlijk (d.w.z. in een fysieke meeting; niet via mail, appgroep of iets dergelijks) het werkproces. Heb je het model van Benyon en de opdrachten kunnen volgen en heeft dat gewerkt? Zou je dingen nu anders aanpakken? Zijn er dingen die je gemist hebt? Hoe hebben jullie als groep samengewerkt en wat heb je daarvan geleerd? Maak een gezamenlijk verslag en neem dit op in het eindrapport. 8. Presentatie Als afsluiting van het OIS project dien je met je groep een presentatie te geven over jullie ontwerp. Het doel van de presentatie is om ons, als opdrachtgever, te overtuigen dat jouw ontwerp het beste ontwerp is. Dat stelt dus hoge eisen: overtuigende, goed onderbouwde inhoud een prototype dat er goed uitziet en goed werkt een presentatiestijl die bij het kritische publiek aansluit De inhoud en indeling van de presentatie staat vrij, maar zorg dat je geen cruciale zaken mist! Je krijgt maximaal 10 minuten de tijd om je verhaal te houden, hierna wordt de presentatie beëindigd. Denk van tevoren dus goed na over wie de presentatie gaat/gaan geven, wat je laat zien en hoe je je profileert. De beste groepen (één per zaal) zullen een prijs winnen voor Beste OIS Ontwerp Rapport Schrijf nu voor de opdrachtgever het rapport 'prototype'. Dit is een onderbouwde beschrijving van het visueel ontwerp, het prototype en de evaluatie daarvan, in een bondig en helder verhaal, 4

5 voorzien van bijlagen. Het primaire doel van het rapport is de opdrachtgever te overtuigen dat je ontwerp goed is. Als dat lukt, verwerf je de vervolgopdracht: het implementeren van het systeem. Belangrijke onderdelen van het rapport zijn: een managementsamenvatting visueel ontwerp beschrijving van het prototype evaluaties en bijstelling, terugkoppeling aan de requirements procesevaluatie Zie voor meer aanwijzingen (gebaseerd op concrete ervaringen met eerdere inleveringen) de pagina Rapportage. 5