Multimedia: tussentijds verslag 1 Groep Mediablitz Blog: http://teammediablitz.wordpress.com Anne Everars 1e fase Jan Janssens 2e fase Micha¨el Derde 2e fase 20 oktober 2011 Samenvatting Dit is het eerste tussentijds verslag voor het vak multimedia, van groep Mediablitz. In dit verslag staat een uitgewerkt scenario en storyboard voor een applicatie die de tekortkomingen van Toledo moet wegwerken en hiervan een mobiele versie moet aanbieden. Deze applicatie biedt zowel de bestaande administratieve functionaliteit (cursussen, lessenrooster, documenten,. . . ) als integratie van twitter en blogs aan. De belangrijkste uitdagingen waren om het scenario zo volledig mogelijk uit te schrijven en alle opties te bekijken bij het storyboard. In het scenario moest immers elke functionaliteit aan bod komen, beschreven vanuit het standpunt van het leven een student. Het maken van een storyboard zorgde ervoor dat er al bepaalde keuzes gemaakt moesten worden ivm de interactie tussen de applicatie en de gebruiker. Uit dit project leren wij tot nu toe vooral dat het zeker de moeite waard is om de invalshoek van andere groepjes te bekijken en te leren uit hun feedback. Door te kijken naar andere groepjes hun scenario en storyboard kunnen er idee¨en opgedaan worden voor die groep of voor het eigen project.
1
Idee
Het idee van deze toepassing is om de huidige versie van Toledo te verbeteren en mobiel voor de smartphone te maken. Toledo wordt door velen als te complex en omslachtig beschouwd en hier willen we op inspelen. Het grootste verschil met de gewone Toledo zou dus zijn dat onze applicatie mobiel en eenvoudiger wordt, blogs en twitter integreert en een snel overzicht kan bieden aan de student. Een ander punt is de integratie van gamification, waarbij in onze applicatie de lessen beoordeeld kunnen worden. Het grootste verschil met andere groepen is dat onze applicatie steunt op eenvoud en een intu¨ıtieve gebruikersinterface. Berichten kunnen op een eenvoudige en snelle manier verzonden worden, overbodige functionaliteiten zijn afwezig en het lezen van notificaties kan in een enkele klik. Tijdens de brainstorm zijn enkele idee¨en aan bod gekomen die uiteindelijk geschrapt werden. Een idee was om voor upcoming events automatisch de uurregeling en het traject van een busdienst aan te bieden. Het idee werd weerhouden omdat we ons wilden focussen op de basisfunctionaliteit van een blackboard-applicatie. Zulke extra features zouden het domein van de applicatie te uitgebreid maken. De sterke punten van ons idee zijn de eenvoud en het snelle overzicht. Een bericht (mail, tweet, blog) is in enkele klikken gemaakt, en voor documenten of informatie over emailadressen moet ook heel toledo niet doorzocht worden vooraleer de correcte informatie gevonden is. Het zwakke punt aan onze applicatie is het feit dat het gebruik ervan eerder aanleunt bij de
1
traditionele look-and-feel van een blackboard. Er is geen revolutionair verschil in gebruik. Dit is echter een bewuste keuze, gemaakt vanuit ons eigen standpunt, en die beantwoordt aan onze eigen noden. Een lichtere versie van toledo was voor ons de belangrijkste doelstelling om te bereiken. Uit de feedback van andere groepen, zowel tijdens de pitch als via de blog, hebben we geleerd dat sommige idee¨en al te specifiek neergeschreven waren, en al meer gericht waren op implementatie. De implementatie kan echter een beperking betekenen op het idee, en daarom moeten idee¨en en implementatie los van elkaar bekeken worden, om de creativiteit te bevorderen.
2 2.1
Scenario Beschrijving
Zoals gewoonlijk begint de dag voor Boudewijn met een alarm dat als een bom door kamer raast. En zoals dat voor de meeste studenten wel het geval is, betekent dit meestal dat er nog net genoeg tijd overblijft om snel je kleren –al dan niet van de dag ervoor– aan te trekken, even door je haar te gaan en je tanden te poetsen. Vermits zijn alarm ingesteld was op zijn smartphone, ziet Boudewijn bij het uitschakelen van het oorverdovend lawaai, dat er meldingen zijn van de Toledo-applicatie. Nieuwsgierig als hij is –eigenlijk hoopt hij gewoon dat de professor net laat weten dat de les onverwacht wegvalt-, opent hij de notificatie-inbox waarin alle meldingen volgens prioriteit geordend staan. Tot zijn grote teleurstelling is er geen melding van een verplaatste les. Daarentegen zijn er wel nog enkele interessante twitter- en forumberichten geplaatst, die hij best nog voor de les begint doorneemt. Dit doet hij bijgevolg ook snel even. Tussen de meldingen zit ook een mail van een professor die hij dringend moet beantwoorden. Vervolgens ziet hij ook dat er een deadline bijgekomen is. Gelukkig is deze automatisch aan zijn kalender toegevoegd, zodat hij na de les automatisch (in zijn kalender) kan kijken wanneer hij het beste tijd maakt om eraan te werken. Boudewijn is nu weer helemaal up-to-date met de gebeurtenissen voor de komende uren en maakt zich klaar om te vertrekken. Maar het kon niet anders, dan dat hij iets vergeten is. . . In welk lokaal ging die les nu weer doorgaan? Snel opent hij de Mediablitz-app op zijn smartphone, klikt hij door naar zijn agenda en in een oogopslag ziet hij in welk lokaal de les –die ondertussen over 10 minuten zal starten– zal plaatsvinden. Eenmaal aangekomen in het lokaal, merkt hij dat de professor er nog niet is. “Ideaal,” denkt hij, “net tijd genoeg om te kijken wat we vandaag allemaal gaan leren.” Omdat hij in zijn haast heel de app nog niet had afgesloten, komt hij onmiddellijk in zijn kalender terecht. Door op de les van dat moment te klikken, komt hij automatisch op de vakpagina terecht, waar hij de documenten en slides kan bekijken. Wanneer de professor net binnenwandelt krijgt hij een SMS-berichtje van zijn vriendinnetje om hun afspraak voor die avond te bevestigen. Gelukkig had zijn Toledo-applicatie ervoor gezorgd dat zijn smartphone op stil gezet werd, het moment dat hij het leslokaal binnengewandeld was, anders had dit wel wat gˆenant kunnen worden. Ondanks het feit dat Boudewijn heel hard op had gelet tijdens de les en goede nota’s had proberen nemen, vond hij dat de professor niet genoeg uitleg gegeven had over bepaalde onderwerpen, terwijl andere thema’s ongelofelijk langdradig naar voren gebracht werden. Om de volgende generatie –en misschien zelfs de volgende lessen– te verbeteren, krijgt hij na het buiten wandelen van het lokaal een melding van de applicatie, die hem vraagt de les een rating te geven.
2
Eenmaal hij terug op zijn kot gekomen is, besluit hij de mail die hij die ochtend gelezen had te beantwoorden. Daartoe opent hij opnieuw de Mediablitz-app en gaat hij onmiddellijk naar zijn contactpersonen. In een lijst die per vak geordend is, kan hij op een snelle en eenvoudige manier de professor voor dat vak aanduiden en zo zijn mail naar hem sturen. Hij bekijkt nog snel even de komende lessen en ziet dat hij vandaag niets meer op de planning heeft staan. Hij merkt wel de deadline op die er deze ochtend bij was gekomen. In ´e´en klik opent hij de specificaties (pdf-file van de opdracht) en ziet dat hij dit wel in een weekend kan oplossen. Dat betekent dat hij tijd heeft om weer wat slaap in te halen. Hoera!
2.2
Over het scenario
Uit dit scenario kan men vooral een duidelijk beeld krijgen van hoe de gebruiker interageert met de applicatie. Dit kan voor inzichten ivm het belang van enkele functies zorgen. Sommige functies lijken immers plots heel wat minder belangrijk te zijn. Om deze reden werd in deze fase van het project besloten om helemaal aan het begin van de applicatie het tijdstip tot de volgende les (of volgende deadline) samen met diens locatie voor te stellen, zodat de gebruiker (de student) snel en eenvoudig aan alle nodige informatie kan komen. Op deze manier wordt geprobeerd om het gebruiksgemak te vergroten. Hierdoor staat alles in lijn met het grootste doel van deze applicatie: eenvoudig, zonder veel tools en een snel en duidelijk overzicht. Voor de opbouw van het scenario werd vertrokken vanuit een ruwe opsomming van wat de gebruiker stap voor stapziet of doet. Later werd dit in een concrete, populariserende tekst gegoten. Ons scenario is ook ge¨evolueerd: eerst hadden we een eerder opsommende stijl van functionaliteiten die aangeboden moesten worden. Daarna hebben we deze functies in een eerder populariserende tekst gegoten. Deze tekst schetst het gebruik van de applicatie vanuit het standpunt van het leven van een student. Dit zorgt ervoor dat een duidelijker beeld gecree¨erd wordt van hoe de gebruiker deze applicatie gebruikt en in zijn dagelijks leven past. Het is ook een optie om een scenario te schrijven vanuit het standpunt van een professor, maar dit werd niet gedaan omdat de focus van deze applicatie vooral op de student ligt. Een voordeel van een scenario lijkt ons dat het een basis is om een storyboard op te stellen. Op deze manier kan men op een snelle en eenvoudige wijze de belangrijkste functionaliteiten identificeren. Het scenario schetst hoe de gebruiker interageert met de applicatie. Dit wordt dan in het storyboard visueel geconcretiseerd. Deze werkwijze heeft natuurlijk ook zijn nadelen. Indien een bepaalde functionaliteit of interactie niet vermeld wordt in het scenario, gaat dit bijgevolg ook niet opgenomen worden in het storyboard en hierdoor ook niet in de implementatie. Uit de feedback op ons scenario bleek dat er vooral vragen waren over de concrete invulling van bepaalde functies. In een scenario moet dit echter nog niet gespecifieerd worden. Omdat er weinig inhoudelijke vragen gesteld werden over het scenario leiden we af dat het een goed en duidelijk geschreven scenario was.
3
Storyboard
3.1
Storyboard
Om een duidelijker beeld te krijgen over hoe onze applicatie er gaat uitzien hebben we een storyboard gemaakt op basis van het scenario in sectie 2.1. We hebben niet meer het hele scenario herhaald, maar enkel de interacties tussen de gebruiker en de applicatie vermeld. Volgende illustraties geven aan wat de gebruiker te zien krijgt: • Boudewijn ziet dat er meldingen zijn van de Mediablitz-applicatie.
3
(a) Home scherm van de smart-(b) Meldingen-menu van de smartphone phone
N.B.: het tweede scherm wordt geopend door in het eerste scherm het dropmenu bovenaan open te schuiven. • Hij opent hij de notificatie-inbox waarin alle meldingen volgens prioriteit geordend staan en leest een email.
(c) Notificatie-inbox
(d) Geopende mail
N.B.: het tweede scherm wordt bekomen door op een melding (in dit geval een email) te klikken. • Hij opent de Mediablitz-app op zijn smartphone
4
(e) Home scherm van de applicatie
• Hij klikt door naar zijn kalender en in een oogopslag ziet hij in welk lokaal de les zal plaatsvinden.
(f) Kalender
• Door op de les van dat moment te klikken, komt hij automatisch op de vakpagina terecht, waar hij de documenten en slides kan bekijken.
5
(g) Vakpagina
• Hij krijgt na het buiten wandelen van het lokaal een melding van de applicatie, die hem vraagt de les een rating te geven.
N.B.: het tweede scherm wordt bekomen door in het eerste scherm naar beneden te scrollen. • Terug op kot herinnert Boudewijn zich dat hij nog niet geantwoord heeft op een mail die hij deze ochtend gelezen had. Hij opent opnieuw de Mediablitz-app en gaat onmiddellijk naar zijn contactpersonen. In een lijst, per vak geordend, kan hij op een snelle en eenvoudige manier de professor van het vak aanduiden en zo zijn mail naar hem sturen.
6
(j) Vakkenlijst
(k) Contactenlijst
N.B.: het tweede scherm wordt geopend door in het eerste scherm op een vak te klikken.
3.2
Toelichting
We hebben het storyboard opgesteld met Android in het achterhoofd. In Android worden meldingen van applicaties verzameld en in een pull-down menu op het home-scherm getoond. Wij willen onze app daar graag mee integreren. Daarom stellen de eerste twee schermen van het storyboard het home-scherm van de smartphone voor en het pull-down menu dat een melding bevat van onze app. Vanuit deze melding kan dan meteen onze app geopend worden. In alle schermen is onderaan een balk te zien genaamd “Notificaties”. Dit is een pull-up menu dat de algemene notificatie-inbox opent. Op deze manier zijn de notificaties doorheen de gehele app meteen bereikbaar.
3.3
Evolutie
In een eerste versie was de notificatie-inbox opgenomen in het beginscherm als een icoon, net als Vakken, Contacten en Kalender. Nadat we opmerkten dat Android een ge¨ıntegreerd meldingsmenu heeft besloten we om daarvan gebruik te maken, waarna het storyboard zijn huidige vorm kreeg.
3.4
Voordelen en beperkingen
Voordelen Het grote voordeel van een storyboard is dat het een duidelijk visueel beeld geeft van hoe de app er uiteindelijk zal uitzien en gebruikt kan worden. Het doet nadenken over praktische details die in eerste instantie niet zo belangrijk lijken maar waarvan het nuttig is dat deze van in het begin zijn vastgelegd, zoals bv. de indeling van het beginscherm van de app en de navigatie naar de verschillende subsystemen binnen de app. Beperkingen Een storyboard is beperkt in die zin dat het enkel een beeld geeft van 1 scenario. Als later een ander scenario ondersteund moet worden kan dit mogelijk voor grote veranderingen aan het storyboard zorgen en dus ook voor ingrijpende veranderingen aan de app.
7
3.5
Feedback
De eerste twee figuren waren wat verwarrend: we wilden uitdrukken dat de app voor een deel werd ge¨ıntegreerd in de algemene GUI van de smartphone. Op een Android-toestel bijvoorbeeld komen alle inkomende berichten (SMS, Mail en systeemberichten) samen in 1 meldings-inbox. In die eerste figuren wilden we tonen dat we graag ook een melding van onze app in dat menu laten verschijnen, die dan aangeeft hoeveel ongelezen meldingen onze app bevat. Het was voor sommigen niet meteen duidelijk waar de smartphone-GUI stopte en onze app begon.
4
Besluit
Het belangrijkste wat we tot nu toe geleerd hebben is dat het maken van een scenario en storyboard veel gemakkelijker duidelijk maakt wat de belangrijkste functionaliteit is die de applicatie moet bieden en hoe de applicatie deze functionaliteit zal aanbieden aan de gebruiker. We hadden eerst nog de reflex om een lijst op te stellen van functionaliteit en “nice to haves” en deze dan gradueel implementeren. Het gevaar is dat dan later nog een functionaliteit moet worden toegevoegd die we initieel over het hoofd hadden gezien. Door het opstellen van een scenario is dat risico veel kleiner, omdat er al intensief is nagedacht over de verschillende diesnten die de applicatie moet bieden. De belangrijkste eigenschap die we aan onze applicatie willen geven is eenvoudigheid in gebruik. Terwijl Blackboard zoals het nu is zeer log en complex is en veel interactie vereist, streeft onze app naar gebruiksgemak en interactie. De notificatie-balk die ten allen tijde aanwezig is is daar een goed voorbeeld van: waar je ook zit in de applicatie, via 1 menu kan je onmiddellijk nieuwe meldingen bekijken. Ook probeert de applicatie zoveel mogelijk werk uit de handen van gebruiker te nemen. Een paar voorbeelden is het automatisch toevoegen van deadlines aan de agenda en het automatisch op stille modus zetten van de smartphone tijdens de les. Over deze aspecten van de applicatie zijn we zeer tevreden. Het enige punt dat we misschien anders zouden doen is trachten wat minder de traditionele look-and-feel van Blackboard na te bootsen. De commentaar die we kregen van de andere studenten ging meestal over concrete invulling van functionaliteit, zoals bijvoorbeeld het automatisch aanzetten van de stille modus. Zulke commentaar is altijd nuttig, omdat het ons dwingt argumenten aan te halen voor het nut van de functionaliteit en doet nadenken over de praktische haalbaarheid. Bij het becommentari¨eren van de andere groepen merk je soms interessante ide¨een op qua functionaliteit of vormgeving die dan geheel of gedeeltelijk kunnen worden ge¨ıncorporeerd. Zo wordt de creativiteit sterk vergroot omdat je dan kan voortbouwen op nieuwe ide¨een.
A
Tijdsbesteding
Deze cijfers zijn inclusief het werk geleverd tijdens de les, uitgedrukt in uren. Brainstorm Scenario Storyboard Verslag Eigen blog Blog van anderen
Anne Everars 2 1.5 1.5 3 0.5 2
Jan Janssens 2 1 2 3 1 2
8
Micha¨el Derde 2 1 1.5 4.5 1 2
