Hacken is een verhaal vertellen
“Vlinders krijg je! Elke keer dat het verhaal vordert, de app een update krijgt en elke keer dat ‘bert de snert cat’ vervangen wordt met een product uit de API.” Samen met vier collega’s ‘hackten’ we er op los tijdens de Dutch Open Hackathon en kwam ik tot een inzicht. Hacken is iets voor iedereen die graag verhalen vertelt en niet bang is om dat te vertellen in code, apps en presentatiekracht.
Onze missie
Natuurlijk was de bedoeling van de Dutch Open Hackathon om ‘wat leuks’ te doen met de API’s van Albert Heijn, Schiphol, Transavia.com, TomTom, KLM, My Order (Rabobank), Philips Hue en het liefst een combinatie van zoveel mogelijk. En dat is precies wat ons team “Hack To The Future” heeft gedaan. We hebben een platform gebouwd in de cloud met koppelingen met al die API’s en er een app bij ontwikkeld. De app scant barcodes, luistert naar de locatie en iBeacons en signaleert zelfs, zodat Philips Hue lampen van kleur veranderen.
Hacken met een verhaal
Het doel van het hacken werd al snel duidelijk. Je moet in een korte tijd ‘het juiste’ maken en vooral: in een goede volgorde, zodat je het belangrijkste eerst maakt en toekomt aan de details. Het zijn juist de details die het ‘m doen, net als bij het schrijven van een verhaal. In ons geval hadden we twee hoofdrolspelers: de buurvrouw en de buurman. Eén doel: ze samenbrengen, en wat plottechnieken om het verhaal tot een goed einde te brengen.
Het verhaal van de buurvrouw en ‘Send Marty’
Het doel van de app ‘Send Marty’ is buren bij elkaar brengen door ze elkaar kleine missies te laten geven. De buurvrouw is bijvoorbeeld vergeten pindakaas te halen voor haar beroemde gebakken bananen en heeft geen tijd meer om zelf naar de AH te gaan. Ze scant de pot pindakaas en maakt een missie aan met de ‘Send Marty’-app (met hulp van de AH-API). Natuurlijk staat ze zelf garant voor de kosten (dat kon bijna in de My Order-API).
Omdat de app ‘weet’ dat de buurman onderweg naar huis langs de AH én de buurvrouw rijdt, ontvangt de buurman een bericht op zijn TomTom én op zijn mobiel met het verzoek of hij – als hij toch onderweg naar huis is – even een pot pindakaas kan oppikken. De buurman accepteert de missie en rijdt langs de AH. Intussen krijgt de buurvrouw een signaaltje via de app en een kleurverandering van de Hue-lamp duidt aan dat de opdracht is aangenomen.
In de AH wordt de buurman via een iBeacon-spoor geholpen naar het schap met de pindakaas. Hij scant de pot, er is een match en de buurman kan naar de kassa. De caissière heeft de My Order-garantie van de buurvrouw gezien en de buurman mag doorlopen. Inmiddels wordt de Hue-lamp bij de buurvrouw oranje en ze weet: de pindakaas is onderweg.
Bij aankomst ‘tikken’ de buurman en buurvrouw hun mobieltjes tegen elkaar en de transactie is rond. Om de missie te belonen zijn er talloze mogelijkheden: misschien nodigt de buurvrouw de buurman wel uit voor zo’n heerlijke gebakken banaan, of wordt het doen van ‘missies’ rendabel door de buurman te belonen met ‘karmapunten’ of zelfs korting. Misschien betaalt de buurvrouw zelfs wat extra.
Deus ex machina
Het ‘ware’ hacken zit ‘m voornamelijk in het testen van de plottechnieken. Bijvoorbeeld: kunnen we de buurvrouw een pot pindakaas laten scannen met de app? Kunnen we de buurman onderweg naar huis een opdracht geven via de TomTom? Kunnen we via iBeacons de locatie van de verse pot pindakaas verraden in de Albert Heijn en natuurlijk: kunnen we de buurvrouw op de hoogte houden via haar Philips Hue-lamp?
Randvoorwaarden
In twee dagen hebben we stukje bij beetje gebouwd aan ons verhaal en steeds geprobeerd de grenzen van de API of techniek op te zoeken. Belangrijk waren ook de structuur en de voorwaarden: we wilden natuurlijk graag dat het verhaal klopte en bleef werken, dus er moest worden voorzien in zowel een design van de app als een fijne hackomgeving. Daar hebben we diverse diensten van Amazon en Cloud 9, een online development-tool, voor ingezet. Zo konden onze schrijvers snel en effectief aan ons verhaal bouwen.
Grenzen zijn er om verlegd te worden
Maar wat doe je als een deel van je verhaal niet werkt? Een gevleugelde uitspraak bij het team was “Niet mokken, maar mocken”. Mocken is ‘net doen alsof’ met API’s. Je bouwt een nep-API die het juiste gedrag vertoont. Dat werkt natuurlijk niet altijd en soms is de API complex, maar er is altijd een oplossing te vinden.
De ware ‘hack to the future’
Een API werkt niet altijd zoals gewenst en dat is precies waar een hackaton voor is. De API-bouwers willen zien hoe de API gebruikt wordt en inzicht verkrijgen in hoe zij hem nog beter kunnen maken.
Om toch het verhaal te kunnen vertellen, hebben we sommige API’s niet geïmplementeerd, maar wel verteld hoe het eigenlijk zou moeten werken. De TomTom-API is daar een voorbeeld van. Die is eigenlijk bedoeld om ‘missies’ te sturen aan een vloot van werknemers in auto’s. Het leek ons juist interessant om consumenten elkaar zo’n opdracht te laten sturen. Nu maar hopen dat TomTom het oppikt.
Het geheim
Al dat matchen van missies, mensen en locaties en daarover bijna realtime te communiceren via apps is ons het meest meegevallen. Door het verhaal sluitend te maken waren we in staat om veel technische problemen te tackelen.
Hacken is verhalen vertellen. Of je nu direct gaat coderen, met papier aan de slag gaat, of een filmpje maakt, dat doet er niet toe. Het omzetten van een verhaal in iets wat iemand kan beetpakken, is fantastisch!
Kern van een goed verhaal is volgens mij dat er ook mensen echt op zitten te wachten. Bij bovengenoemd scenario vraag ik me echt af wie dat is. Nodeloos ingewikkeld.
Hi Pieter, Goed punt! De missie voor de teams op de Dutch Open Hackaton was het integreren van zoveel mogelijk API’s zodat iedereen lekker kon rammelen aan de mogelijkheden van API’s. We zijn daar lekker mee losgegaan en hebben veel ontdekt. Het verhaal zal denk ik wel hetzelfde zijn, maar eenvoudiger worden omdat veel dingen ‘automagisch’ moeten voelen. In een èchte narative zal je minder aandacht besteden aan dat soort non-momenten.