Individueel verslag Rick van ‘t Hof (0865896)

  • Ben je gedurende de gehele periode bezig geweest met de ontwikkeling van producten (en wellicht ook weer heel veel weg moeten gooien) en niet alleen in de laatste week? Toon aan dat je hierin Agile hebt gewerkt.

De ontwikkeling van de producten is gestart na de eerste sprintreview. Voor deze tijd is het niet zinvol een basis op te zetten. Ook al was het concept nog niet helemaal concreet, een basis kon wel al gemaakt worden naar aanleiding van onze wireframes. De briefing beschreef heel duidelijk een mobiele oplossing, geïntrigeerd binnen de bestaande app van OPEN Rotterdam. Het klinkt logisch om dan een prototype te realiseren als mobiele applicatie. Zo heb ik ook gedacht. En zo zou de opdrachtgever ook het beste beeld bij ons concept krijgen.

Gaandeweg bleek deze optie te ambitieus te zijn. Het programmeren van een Android app hadden wij zojuist deze periode geleerd en daarom dacht ik dat dit wel moest lukken. Zeker omdat grote delen over te nemen zouden zijn uit een eerder gemaakte opdracht. Ik heb toen ook een start gemaakt met een Android app en een poging gedaan om een kaartje te tonen met wat punten daarop.
Na alleen hier al drie uur mee bezig geweest te zijn, werd mij duidelijk dat ze optie niet realistisch zou zijn. In mijn vorige Android app zijn vele tientallen uren gaan zitten en de uiteindelijke uitwerking was dan ook nog eens vrij basis. Het ontwikkelen van een Android app is om meerdere redenen erg tijdrovend. Een van de belangrijkste redenen is dat het testen van een kleine verandering betekent dat je app ‘gebuild’ moet worden en dit soms wel 1,5 minuut kan duren. Dit betekent dus dat het testen van een wijziging soms veel langer duurt dan deze wijziging zelf. Voor een enkel scherm zijn er vaak al tientallen wijzigingen. Alles bij elkaar opgeteld is dit geen realistische methode om een prototype in te ontwikkelen.

Daar komt bij dat het concept tot aan het eind nog werd bijgesteld. Sommige van deze wijzigingen zouden neer komen op een niet realiseerbaar prototype.

Om toch indruk te kunnen maken op de opdrachtgever met een dynamisch prototype, ben ik een andere weg in geslagen. Ik heb hierbij gekozen om een mobiele website te maken die vrijwel hetzelfde werkt als een app. Hier heb ik meer ervaring mee en is sneller aanpasbaar naar aanleiding van aanpassingen in het concept.
Ook hierin heb ik agile gewerkt. Gedurende iedere iteratie zijn een aantal schermen volledig uitgewerkt. Per iteratie zijn er meer schermen bijgekomen. Tot aan de laatste iteratie is dit goed gegaan.
Bij de laatste iteratie zijn er wijziging naar voren gekomen die effect zouden hebben op alle verschillende scherm. De visuals hiervoor zijn na een week uitgewerkt wat voor mij zou betekenen dat ik nog één week de tijd zou hebben om het gehele prototype te vernieuwen. Daarnaast zijn er ongeveer net zoveel nieuwe schermen bijgekomen als dat er al waren. Wat hierbij ook niet meewerkt is dat ik mij gedurende deze opleiding steeds meer ben gaan specialiseren in back-end. De back-end en tevens de basis had ik zo opgezet en ik weinig onderhevig geweest aan verandering. Het uitwerken van een volledig nieuwe front-end is echter niet mijn sterkste punt. Het zou dan ook niet realistisch geweest zijn om in deze laatste iteratie alle visuals dynamisch uit te werken.

Ik ben niet het type om dan maar te zeggen dat het onmogelijk is en het op te geven. Ik ben echter ook niet het type om er toch verder mee te gaan en prototype half af te krijgen. Dit is een lastig moment geweest, omdat het meestal niet tot dit punt komt.
Gelukkig kwamen Saskia en Iris met een handige last-minute oplossing. Het uiteindelijke prototype is gerealiseerd met een online tool om clickable prototypes te maken. Hierbij kon ik vrij eenvoudig de visuals met elkaar verbinden om het een en ander toch goed te kunnen demonsteren.

Deze oplossing voelde voor mij wel wat MT onwaardig. Ik ben daarbij wel van mening dat het voor deze situatie de beste oplossing is geweest. Het concept heeft bij ons meer aandacht nodig gehad dan het prototype. Daardoor is hier minder tijd voor geweest.
Ons dynamische prototype is naast het clickable prototype wel blijven bestaan om bepaalde onderdelen beter te kunnen demonsteren. Daar zit voor mij wel een leermoment in. Het maken van het clickable prototype was vrij eenvoudig en daarom is het verstandig dit een volgende keer te maken vóór een eventueel dynamisch prototype. Dan staat er alvast iets klaar om te kunnen demonstreren en kunnen eventuele onderdelen die meer verduidelijking nodig hebben alsnog uitgewerkt worden.

  • Hoe is de keuze voor het gebruikte ontwikkelplatform en de gekozen taal tot stand gekomen en ben je er achteraf gelukkig mee?

De keuze voor Android was zoals al aangeven omdat dit nog vers in mijn geheugen zat. Daarbij zou een app het mogelijk maken om het invoeren van de locatie live te demonstreren.

Het dynamische prototype is uitgewerkt met wordpress als CMS. Dit om verschillende redenen. Allereerst is wordpress een heel degelijk CMS dat makkelijk uit te breiden is. De basis van wordpress (blogs) lijkt veel op de basisfunctionaliteit van ons concept. Hierbij zijn de blogposts onze verhalen. Verder heb ik wordpress gekozen omdat ik goed bekend ben met het CMS, maar nog niet met het ontwikkelen van een custom thema. Ik heb dit aangegrepen om hiermee te kunnen experimenteren omdat wordpress in het bedrijfsleven een groot aandeel heeft en het mij daarom in mijn persoonlijke ontwikkeling zou kunnen helpen.

Invision is gekozen op basis van de ervaring van Saskia en Iris. Er is in de laatste sprint niet meer voldoende tijd geweest om uitgebreid onderzoek te doen naar verschillende mogelijkheden. Daarbij bleek Invision zo gebruiksvriendelijk, dat dit een ideale oplossing was.

De platformen zijn een prima keuze geweest en ik heb daar dan ook geen spijt van. Zoals eerder al gezegd is de volgorde van uitwerking wel een mindere keuze geweest.

  • Hoe heb je jullie prototype en deelonderdelen getest?

De functionaliteit van de deelonderdelen hebben wij als team getest door overal doorheen te klikken en simpelweg te kijken of alles naar behoren werkt.
Het inhoudelijke testen van het concept hebben we gedaan door enkele bekenden en familieleden door ons prototype heen te laten klikken. Mogelijke onduidelijkheden in de visuals hebben we daarmee eruit kunnen halen.
Verder leek onze probe vrij veel op ons uiteindelijke concept wat betreft het soort verhalen en reacties. Daaruit zijn ook veel belangrijke punten gekomen die uiteindelijk in ons concept zijn verwerkt.

Zie voor het testen ook dit bericht.

Het eindproduct is te vinden in twee verschillende vormen, zie daarvoor dit bericht.

  • Hoe heb je je verkregen inzichten (onder andere uit het doen van research) vertaald naar relevante ontwikkelrichtlijnen?
    Welke zijn wel toegepast in het prototype en welke zijn afgevallen? Licht je keuzes toe.

De meeste inzichten zijn voortgekomen uit de research naar het gebruik van google maps en wordpress. Ondanks dat Android een product van google is, bleek het niet heel eenvoudig een Maps kaartje te verwerken in een Android app. Ik heb er meerdere blogs voor doorgelezen, maar veel vragen bleven daarbij onbeantwoord. Het inzicht daarbij was dus vooral dat dit geen geschikte oplossing was voor ons prototype.
De implementatie van Google Maps binnen WordPress bleek een stuk eenvoudiger. Voor veel van de mogelijkheden staan voorbeelden online. De documentatie was prima en dat maakte dat het eenvoudig was om deze implementatie aan te pakken.

De aanpak van wordpress vergde wat meer tijd. Het lijk mij handig te beginnen met een basis thema. Dan zou ik dit thema kunnen aanpassen naar onze wensen. Dit bleek minder eenvoudig dan verwacht. Er zijn vrijwel geen basisthema’s die écht basis zijn. Veel van deze thema’s bevatten bijvoorbeeld al veel CSS. Dit maakt het lastig om zelf een eigen stijl in te bouwen. Ik heb ook nog de mogelijkheid bekeken om het vanaf de grond af op te bouwen. Deze mogelijkheid is toch afgevallen omdat het meer tijd zou kosten om uit te zoeken wat er allemaal nodig is om een thema aan de praat te krijgen, dan het aanpassen van een basis thema.
Voor een volgende keer ga ik mijn tijd direct steken in het uitzoeken van een thema opbouwen vanaf de grond. De mogelijkheden in het aanpassen van een compleet zelfgemaakt thema zijn uiteindelijk veel groter.

  • Heb je jouw rol optimaal kunnen inzetten in het team? Licht toe met specifieke voorbeelden. Wat ging goed? Wat had beter gekund? Verwijs hiervoor ook naar depeerassessments. Wees kritisch naar je eigen functioneren.

Ik ben van mening dat ik mijn rol meer optimaal in had kunnen zetten als wij nog een MT’er in het team hadden gehad. Dan hadden we beter de rollen kunnen verdelen en beide beter kunnen focussen op ons eigen deel. Ik vond het lastig om vrijwel alleen maar front-end te realiseren. Het voelt hierbij voor mij enigszins alsof ik mijn team hierin teleur heb gesteld.
In de peerassesments zijn zij juist tevreden over mij. Ik vermoed dan ook dat ik vooral mijzelf teleur heb gesteld door te hoge eisen te stellen. Ik had graag het dynamische prototype verder uit willen werken, maar dat was niet realistisch en dat is jammer.
Verder vind ik wel dat ik mij goed heb ingezet, actief heb deelgenomen aan discussies en goed heb bijgedragen met ideeën. Er is een teamlid die dit anders ziet en mijn ideeën inbreng matig vond. Ik ben erg goed in out-of-the box denken en daarom vermoed ik dat zij dit zo gezien heeft omdat sommige ideeën minder binnen het kader van de opdrachtgever vielen. Persoonlijk vond ik sommige ideeën te gewoontjes en werd er niet altijd naar mij geluisterd als ik met iets nieuws kwam. Uiteindelijk denk ik dat dit verloop er vooral mee te maken heeft gehad dat wij elkaar als groep nog maar net kende. Aan het eind van het project verliep alles veel soepeler.

Een punt dat het noemen waard is, is dat teamleden noemen dat ik soms wat afwezig leek. Ik denk dat dit inderdaad enkele keren zo geweest is. Dit heeft waarschijnlijk te maken gehad met weinig slapen en vroeg starten. Ik had wat langer nodig om op te starten. Dit heeft mij later wel gemotiveerd om aan mijn team te bewijzen dat ik mij goed wilde inzetten voor dit project. De laatste paar weken verliepen dan ook een stuk beter en geloof daarmee ook het vertrouwen van mijn team te hebben teruggewonnen.

Verdere inbreng van mij is ook te vinden op de blog. Zo heb ik bijgedragen aan het doen van deskresearch en het concepten.

  • Hoe verliep jouw contact met de opdrachtgever/partner? Hoe heb je alle belanghebbenden betrokken bij je werkzaamheden? Wat heb je daar voor gedaan/gemaakt? Beschrijf specifieke situaties en licht toe met voorbeelden. Wat ging goed? Wat had beter gekund?

Het contact met de opdrachtgever verliep prima. De contactmomenten heb ik dan ook vaak aangegrepen om nog net even wat meer feedback te verzamelen dan waar de opdrachtgever zelf mee kwam. Dit was bijvoorbeeld het vragen naar de integratie van ons concept binnen de huidige applicatie. Dat zijn vragen die alleen de opdrachtgever kan beantwoorden en ik zag het dan ook als mijn verantwoordelijkheid om antwoord te krijgen op dit soort vragen.

Verder heb ik ook mijn team betrokken bij elke fase van het prototype. Dit hebben zij ook zo beschreven in de peerassesments. Ik vond het belangrijk hun mening te weten als het ging om bepaalde onderdelen in het prototype of de vorm van het prototype zelf. Als ik ook niet met mijn team had overlegd over de vorm van het prototype, dan hadden we nu ook geen clickable prototype kunnen opleveren in deze vorm.

 

Testen

Wij hebben onze prototypes getest door enkele vrienden en familieleden door onze scenario’s te laten lopen. Deze testpersonen zijn een representatieve greep uit onze doelgroep. Verschillende vrienden die uit huis wonen vallen onder de een persoons huishoudens en vrijwel alle testpersonen komen uit omgeving Rotterdam.

De usability test die wij hebben uitgevoerd is een user test. We hebben de testpersonen aan de app geïntroduceerd en hen vrij gelaten om het een en ander uit te zoeken en te proberen.

Doel
Het doel van deze test is het achterhalen van kleine bugs, het nalopen van de flow en de algemene functionaliteit van de app testen. Hiermee willen wij bereiken dat Happy Happenings zo ver mogelijk klaar is om direct in gebruik te nemen.

Scenario’s

  • Het is zaterdagmiddag. Je zit samen met een vriendin op haar balkon. Het is namelijk heerlijk weer. Je gezellig te kletsen onder het genot van een wijntje. Jullie besluiten echter dat jullie zin hebben om iets te gaan doen. Je hebt de applicatie van Open Rotterdam op je telefoon staan. Jullie besluiten om op deze app te kijken om op zoek te gaan naar een leuk, klein evenement waar jullie deze middag naar toe kunnen gaan.
  • Je loopt op een zondagmiddag over de Swanmarket in Rotterdam. Je hebt het naar je zin en besluit om dit met anderen te delen. Je pakt je telefoon erbij en maakt een foto en bedenkt een pakkende titel. Je opent de app, zoekt je locatie en kijkt of hier al een evenement is en anders voeg je deze toe.

Het doorlopen van deze scenario’s heeft raakvlakken met de meeste van onze functionaliteiten.

Resultaten

Beeldmateriaal van enkele van onze tests:

Schermafbeelding 2015-06-28 om 14.01.44

 

Het resultaat van de tests is over het algemeen positief. Testpersonen gaan moeiteloos door de app heen en vinden veel van de functionaliteiten. Veel van de gebruikte knoppen spreken dan ook voor zich, zoals ‘voeg een happy happening toe’. De standaard functionaliteit werkt dus naar behoren.

Wat voor de testpersonen minder opvalt zijn de extra’s. Extra’s zoals de gamification die onze app bevat. Het is ook logisch dat gebruikers over het algemeen niet vanzelf verborgen functionaliteiten vinden. Dat is de huidige situatie, de gamification is in eerste instantie verborgen. Voor een prototype is er nog niet veel aan de hand, zeker omdat de belanghebbenden de functionaliteit wel al uitgelegd hebben gekregen. Voor het uitbrengen zou het echter verstandig zijn om bijvoorbeeld een splashscreen (opstartscherm) toe te voegen met wat de app inhoudt. En in het menu een about scherm voor overige toelichting.

Gebruikers van apps hebben vaak de neiging overal op te klikken en daarom zou het bijvoorbeeld ook een toevoeging kunnen zijn alle onderdelen inderdaad klikbaar zijn. Als voorbeeld het groene smiley punt in een account. Als hier op geklikt wordt dan kan dit een pop-up openen met de betekenis ervan.
Deze klikervaring zal nog in het clickable prototype worden verwerkt.

 

Planning

Nu het concept wat meer concreet is, is het voor ons mogelijk om een onderverdeling en planning te maken. De onderverdeling is gebaseerd op de optimale benutting van de verschillende disciplines.

De feedback van de opdrachtgever is bijvoorbeeld direct te vertalen naar taken voor de verschillende teamleden:

  • Rick: Applicatie integreren in een bestaand platform open Rotterdam, niet teveel een submerk ervan maken
  • Saskia: De hele stijl op een positieve manier weergeven en vormgeven, onder andere de Google maps pagina. Zodat men weet waar de app voor gebruikt kan worden.
  • Wendy: Scheiding tussen burgerjournalisten en gebruikers goed onderzoeken, misschien met ranking – rekening houden met deze twee verschillende lagen
  • Iris: Persona’s maken, scenario schrijven

In het algemeen zijn de rollen als volgt verdeeld:

  • Saskia en Iris: Vormgeving applicatie met toepassingen
  • Rick: Ontwikkeling applicatie prototype clickable demo
  • Wendy: Communicatieplan

Daarnaast is het nog onze wens om een uitleg filmpje te maken, waarvan nog niet bepaald is wie dit uit gaat werken.

De komende weken zullen we de verschillende onderdelen van het concept uit gaan werken.

Concept: Happy Happenings

Na de conceptpresentatie hebben wij ons concept wat concreter uit kunnen werken. Happy Happenings werkt als volgt:

Happy Happenings is hét format voor vrolijke, positieve verhalen in omgeving Rotterdam. Gebruikers en burgerjournalisten kunnen evenementen delen met OPEN Rotterdam. Open Rotterdam pikt er elke dag een aantal verhalen uit die worden uitgelicht binnen de eigen applicatie in een speciaal tabje voor de Happy Happenings. De gebeurtenissen worden getoond in een Google Maps kaartje (en in een lijst). Klikken op een gebeurtenis toont een pagina met weinig info over de gebeurtenis of het evenement om gebruikers nieuwsgierig te maken.

De populairste happening wordt aangekondigd op de Facebook pagina van Open Rotterdam en zij kunnen apparatuur winnen om nog beter een happy happening te laten zien.

Voor iedere Happy Happening is er een pagina met een titel, locatie en optioneel een afbeelding of video.

Onderaan deze pagina kunnen gebruikers reacties plaatsen om zo meer informatie over het evenement te delen of te verzamelen.

Het Happy Happenings concept bestaat uit twee onderdelen:

  • De integratie in de bestaande Open Rotterdam app
  • Het invoeren van de verhalen via bijv. Facebook

Het invoeren van de verhalen behoeft verder geen ontwikkeling, enkel een uitleg/verheldering.

De integratie binnen de bestaande app bevat 3 pagina’s:

  • Google Maps kaartje met locaties van verhalen
  • Lijstje met verhalen
  • Detailweergave van een verhaal inclusief reacties

Hieronder een eerste grove schets van de te ontwikkelen pagina’s:

FullSizeRender 10

 

Achievements
Een ander onderdeel van het concept is het behalen van bepaalde achievements. Gewone Rotterdammers kunnen binnen de Happy Happenings leren om burgerjournalisten te worden. De burgerjournalisten hebben de rechten om direct verhalen te plaatsen zonder tussenkomst van een redactie.

Het worden van een burgerjournalist is een leerproces. Gebruikers die veel positieve content bijdragen op bijvoorbeeld facebook of in de reacties zullen naar verloop van tijd dus het recht krijgen om burgerjournalist te worden. Het is de bedoeling dat een gebruiker zo leert hoe verhalen ontstaan, wat mensen graag lezen of zien en hoe actief geschreven kan worden.

Conceptpresentatie

Voorafgaand aan de conceptpresentatie was het een moeilijke weg naar een definitief concept. De verschillende andere ideeën zijn te vinden op onze trello onder de ideeën lijst.

De presentatie zoals gegeven aan de opdrachtgever is te vinden in de volgende PDF:
Conceptpresentatie

De opdrachtgever was erg positief en zag dat wij inspeelde op de behoeftes van OPEN Rotterdam en waar zij op het moment mee bezig zijn.

Feedback en mogelijke verbeterpunten vanuit de opdrachtgever zijn:

  • Applicatie integreren in een bestaand platform open Rotterdam, niet teveel een submerk ervan maken
  • De hele stijl op een positieve manier weergeven en vormgeven, onder andere de Google maps pagina. Zodat men weet waar de app voor gebruikt kan worden.
  • Scheiding tussen burgerjournalisten en gebruikers goed onderzoeken, misschien met ranking – rekening houden met deze twee verschillende lagen
  • Persona’s maken, scenario schrijven

Engagment onderzoek

Hoe krijg je mensen zo ver om de applicatie te gebruiken?

Het ontwikkelen van een applicatie of een oplossing in het algemeen voor OPEN Rotterdam staat in directe verbinding met de gebruikers. Een dergelijke oplossing valt of staat met de hoeveelheid gebruikers. Dit is uiteraard wel relatief, in verhouding tot de markt. 200 gebruikers kan voor de ene app een succes zijn, terwijl het voor een andere app echt ondermaats is.

OPEN Rotterdam richt zich specifiek op Rotterdammers en is op zoek naar een oplossing om de burgerjournalistiek beter te integreren binnen OPEN. Dit is een vrij specifieke groep mensen. De oplossing is dus niet gericht op een miljoenenpubliek, maar moet wel deze doelgroep goed aanspreken.

Voor het succes van een dergelijke oplossing bestaat geen succesformule. Er zijn echter wel bepaalde richtlijnen die de kans op succes substantieel verhogen.

Ongeacht of de oplossing binnen het CMS van OPEN Rotterdam wordt gerealiseerd, moet de app gebruikers generen. Vooral gebruikers is een keyword, dit omdat het aantal downloads niets zegt over het verdere gebruik van de app.
Om de app bijvoorbeeld downloads te laten genereren is de snelste weg het kopiëren van een bestaande succesvolle oplossing (Lim & Bentley, 2012). Het aantal downloads is een momentopname. Er kunnen op een dag duizenden downloads zijn, maar de volgende dag wordt de app al niet meer gebruikt. Voor OPEN Rotterdam is dit geen optie, zij zijn op zoek naar een lange termijn oplossing met dagelijkse gebruikers.

Een andere weg voor meer kans op succes is gericht op de aangeboden content. Een app kan goed in elkaar zitten en er gelikt uit zien, maar met content van slechte kwaliteit of zelfs onvoldoende content, kan een app nog steeds falen. Het succes van de app is dus mede afhankelijk van de kwaliteit en kwantiteit van de aangeboden content (Eom & Kim, 2013). Uiteraard geldt dit niet alleen voor apps, maar voor vrijwel ieder platform dat content aanbiedt.
In het geval van OPEN Rotterdam is er een tweedeling. Enerzijds is er de gegenereerde content door de journalisten, anderzijds is er de content of de mogelijkheden die de oplossing zelf biedt.
Om de te verspreiden verhalen succesvol te maken moeten de journalisten waardevolle content genereren. De journalisten kunnen makkelijker waardevolle content genereren als de oplossing dit aanbiedt op een geschikte manier.

Wat een geschikte manier is, is zeer specifiek voor OPEN Rotterdam. Iedere burgerjournalist is anders en interpreteert nieuws op een andere manier. Er zijn dus wel basis stappen die in een bepaalde richting wijzen voor kans op een succesvolle oplossing. Om meer kans op succes te garanderen behoeft de oplossing voor OPEN Rotterdam een gerichter onderzoek. Dit onderzoek zal in het vervolg van deze module worden uitgevoerd en dieper ingaan op wat mensen aan zou kunnen sporen om de mogelijke oplossing te gebruiken.

Bronnen
Eom, S., Kim, J.H. (2013). Public smart phone app success factors: comparative case study on public apps of Seoul city government. In Proceedings of the 7th International Conference on Theory and Practice of Electronic Governance (ICEGOV ’13), Tomasz JANOWSKI, Jeanne HOLM, and Elsa ESTEVEZ (Eds.). ACM, New York, NY, USA, 285-288.

Lim, S.L., Bentley, P.J. (2012). How to be a successful app developer: lessons from the simulation of an app ecosystem. In Proceedings of the 14th annual conference on Genetic and evolutionary computation (GECCO ’12), Terence Soule (Ed.). ACM, New York, NY, USA, 129-136.

Even voorstellen: Team Juicy!

DSC_0091_cropTeam Juicy bestaat (van links naar rechts) uit:

  • Saskia Doets (visual designer)
  • Iris Heemskerk (interaction designer)
  • Rick van ‘t Hof (prototyper)
  • Wendy Lanser (marketeer)

Om elkaar beter te leren kennen hebben wij als team Rotterdams nieuwste aanwinst bezocht: de Martkhal. De Markthal is een bron van verhalen. Met de vele kraampjes, verschillende mensen en bijzondere elementen op het plafond is er altijd wel een interessant verhaal te vinden in de Markthal. Hieruit is ook de teamnaam ontstaat. Bij de sapbar waar team Juicy een sapje bestelde, vertelde de sapmaker dat hij alle sapjes van vers fruit maakt. De sapmaker was al vanaf 5 uur ‘s ochtends bezig met sapjes maken. Vervolgens hebben wij nagedacht wat het vervolg van zijn verhaal zou kunnen zijn. Staat hij bijvoorbeeld zelf de hele dag sapjes te maken of neemt iemand het over?
De teamnaam is uiteindelijk ontstaat tijdens het drinken van deze sapjes. Wij gaan zorgen voor sappige verhalen, daarom dus ook: Team Juicy!