Handschrift van daklozen brengen geld op

Standard

Dit prachtige initiatief ‘Homeless Fonts’ zorgt ervoor dat Spaanse daklozen geld verdienen met hun handschrift dat gewoonlijk enkel dient om op kartonnen bordjes te schrijven. The Arrels Foundation ging met een aantal daklozen aan de slag en digitaliseerde hun handschrift in downloadbare fonts. Die fonts kunnen merken en agentschappen nu online aankopen. De bordjes en handschriften die anders niemand wou lezen, leveren op deze geniale manier plots wél geld op voor de daklozen. Of hoe het internet weer een oplossing biedt voor een fundamenteel probleem.

http://www.homelessfonts.org/

Creativiteit op z’n best voor Creative Fuel

Standard

Voor de nakende Creative Fuel conferentie kreeg Australisch reclamebureau cummins&partners de opdracht een campagne te bedenken om de ticketverkoop te stimuleren. Ze kwamen met deze opmerkelijke spot op de proppen waarin ze het huidige paradigma rond creativiteit duidelijk in vraag stellen.

Cummins&partners bedenken en realiseren ‘The World’s First Crowd Sourced 3D Printed QR Code, Live Streamed Via Go Pro To A Smart Phone Or Tablet Device, Drone Delivery Ticket System Project‘. In het filmpje komt een groepje experten uit de creatieve industrie aan het woord die het idee met de nodige superlatieven kaderen. Daaruit komen een aantal leuke quotes zoals “it’s very hard to find an idea so sometimes we just … don’t”. Ook klanten worden niet gecensureerd: “I don’t understand it but I love it!” ‘Cut the bullshit and focus on creativity‘ is dan ook de toepasselijke slogan van de conferentie waarvoor dit promofilmpje werd gemaakt.

Hilarisch en zeker de moeite waard om 5 minuten van je tijd voor vrij te maken!

Our Mobile Planet

Our Mobile Planet
Standard

Met Our Mobile Planet verschaft Google een krachtige tool om in de smartphone data te duiken. De tool geeft toegang tot data en onderzoek over smartphone gebruik. Het maakt hiermee de resultaten uit hun gelijknamige onderzoek interactief toegankelijk voor het grote publiek. Deze thema’s worden gecovered:

  • penetratiegraad smartphones
  • gedrag (waarom en hoe gebruikt consument smartphone?)
  • activiteiten (wat doet consument op smarthone?)
  • commerce (aankoopgedrag op smartphones)
  • advertising (engagement met mobiele advertenties)

Bovendien kan je de data binnen elk thema nog verder verfijnen en toepassen op 30 verschillende landen. Tenslotte kan je voor elke gewenste gegevensset een handige grafiek exporteren.

Een gigantische hoeveelheid mobiele data dus binnen handbereik. Handig om meer inzicht te krijgen in de mobiele consument en je mobiele strategie op te baseren.

Augmented reality installatie in bushokje

Standard

Leuke augmented reality toepassing van Pepsi Max in een bushokje in New Oxford Street in Londen. Aan de buitenkant van het bushokje bevindt zich een camera die langs de binnenkant van het hokje een real-time beeld geeft van wat er zich buiten afspeelt. Op het eerste zicht voor de mensen binnenin dus gewoon doorzichtig glas tot er plots een meteoriet crasht…

Hoe overtuig je je klant van Scrum?

past-client-marketing
Standard

Vaak is het de realiteit dat klanten waarvoor je werkt, niet willen horen van één of andere project management methodologie zoals Scrum. Ze denken hier immers geen baat bij te hebben en staan vaak twijfelachtig tegenover de werking ervan. Een bureaucratische klant zal bovendien snel denken dat een bureau weer daar is met één of ander middel waarachter ze zichzelf kunnen verschuilen als een resultaat niet behaald wordt. Het is duidelijk: de klant wil de focus op het resultaat en dat gaan we hem dan ook geven!

Hoe pak je het dan aan als je toch met Scrum aan de slag wil? Simpel, je hoeft het niet te zeggen. Je klant hoeft niet op de hoogte te zijn van deze aanpak. Doe wat je wil en pas de basisprincipes van Scrum intern gewoon toe. Je gaat nog steeds met de klant rond tafel zitten, schrijft nog steeds op wat hij denkt nodig te hebben en je maakt nog steeds een inschatting en budget. Het enige wat je aan de klant vraagt, is dat hij een verantwoordelijke kan aanstellen die kan bepalen wat het meeste waarde heeft en dus het eerst moet worden ontwikkeld. Bovendien moet je absoluut ook met je klant een manier afspreken waarbij je de vooruitgang van de werken op regelmatige basis aan hem kan laten zien, met hem kan aftoetsen en bijsturen.

Wat zal er gebeuren? Je klant zal hoogstwaarschijnlijk vanzelf aanvoelen welk machtig instrument hij in handen heeft om controle uit te oefenen over de vooruitgang en deze zelf aan te sturen. Indien die klant een beetje opportunistisch is, zal die zonder het te weten vanzelf meestappen in deze manier van werken door uit zichzelf te laten weten welke functionaliteit eerder mag ontworpen worden en welke gerust naar achter mag schuiven. Wanneer dat gebeurt, is de klus eigenlijk al grotendeels geklaard. Het komt er dan vooral op neer de klant het volledige pakket uit te leggen. Dat is het moment om Scrum juist wél uit te leggen. Het is het moment dat je aan de klant uitlegt dat je overhevelt naar de linkerkant van het Agile Manifesto, namelijk ‘customer collaboration’ over ‘contract negotiation’ en ‘responding to change’ over ‘following a plan’. Customer collaboration houdt bijvoorbeeld in dat je samen met de klant bepaalt welke zaken je eerst aanpakt maar tegelijkertijd ook overeenkomt dat andere zaken hierdoor mogelijks niet of later zullen uitgevoerd worden. Op die manier worden de verwachtingen van de klant beter omkaderd en ontstaat er meer duidelijkheid over de manier van samenwerken.

Conclusie: hoe voer je Scrum in wanneer klanten daar niet helemaal in mee zijn of zelfs afkerig tegenover staan? Gewoon beginnen doen en automatisch zal de klik langs klantenzijde er komen.

Is Agile echt duurder?

1979768_orig
Standard

Bij mijn vorig artikel ‘Waarom moeten we wireframes opgeven en vervangen door rapid prototyping?‘ werd de opmerking gemaakt “het is meestal duurder”. Dit zette me aan tot het schrijven van deze nieuwe post.

Met ‘het’ werd voor alle duidelijkheid verwezen naar de Agile manier van werken. Deze vereist dat je iteratief werkt en per cyclus telkens met meerdere disciplines en dus werkkrachten tegelijk aan de slag bent. Bij het traditionele watervalproces komt elke discipline achter elkaar wat zorgt ervoor zorgt dat je binnen eenzelfde tijdsperiode minder geld uitgeeft.

Het is echter te kort door de bocht om te zeggen dat Agile duurder is. Langs de andere kant dient het statement dat Agile goedkoper is ook wel genuanceerd te worden. In feite zijn we met Agile en waterval, appelen met peren aan het vergelijken. Laten we even deze vraag onderzoeken: ‘Als we een softwareproduct ontwikkelen met een gekende en fixed scope, zal het dan goedkoper zijn om het product in zijn geheel te ontwikkelen door het verkiezen van een Agile boven een watervalaanpak?’ Het antwoord hierop is neen. Maar we kunnen ook niet zomaar deze bovenstaande stelling maken. We maken op deze manier een vergelijking die in de echte wereld niet voorkomt. Als we de stelling ontleden, zien we 2 interessante luiken:

“…met een gekende en fixed scope…”

Bij de vergelijking tussen Agile en waterval veronderstellen we dat we dezelfde scope hebben bij beide development benaderingen. Maar wie weet de scope? We denken dat we de scope op voorhand weten maar in hoeveel projecten zie je dat het eindproduct ook effectief geworden is wat je in het begin van het project hebt bepaald?

“…het product in zijn geheel…”

Agile gaat over het leveren van een product in stukken waarde, zo snel mogelijk. Er bestaat dus geen “geheel”. Agile focust op het leveren van een waardevol deel, het aanpassen hiervan en vervolgens het leveren van een nieuw stuk.

 

Agile principes gaan haast altijd een ander product opleveren dan wanneer dezelfde business need benaderd wordt met een waterval methodologie. Met andere woorden, met Agile is de kans een pak groter dat je een product bouwt dat de klant en consument echt wil. Zelfs al zijn de product requirements zo voorspelbaar en is er al zoveel geweten van bij het begin, er zijn altijd delen uit de scope die nutteloos zijn of waarvan de waarde niet de investeringskost waard is. 80% van de waarde van je product zit in 20% van de ontwikkeling. Als je dus iets laat vallen van de resterende 80% van je ontwikkeling, dan zal dat slechts invloed hebben op 20% van de waarde van je product.

We moeten bovenstaande stelling dus herformuleren en meer toepasbaar maken op de echte wereld. ‘Zal het voor een bepaalde business need mogelijk zijn om een goedkoper product te ontwikkelen dat aan deze need tegemoet komt met behulp van Agile dan wanneer we een watervalaanpak hanteren?‘ Absoluut!

Agile kan dus zeker geld besparen en, belangrijker nog, Agile zal je helpen het geld waarover je beschikt wijzer te spenderen. Ik geloof er dus wel degelijk in dat je in bepaalde projecten goedkoper uitkomt met Agile, namelijk daar waar de klant je toelaat zelf een oplossing te zoeken voor een of meerdere vooropgestelde user needs of business requirements. Je zal dan met behulp van Agile het minste tijd verliezen doordat je meteen focust op het belangrijkste en zo snel mogelijk het meeste waarde gaat opleveren, daar waar je met een typisch watervalproces te veel tijd gaat verliezen door een te uitgebreide en foute scope op te stellen té vroeg in het proces.

Hoe ik mijn workload beheer

Workload scrumboard
Standard

Mijn collega’s bij Boondoggle hebben zich wellicht al vragen gesteld bij het grote witte blad met post-its dat sinds een paar weken geleden op de werkvloer is opgedoken. Het is mijn nieuwe methode om mijn workload te beheren. En die werkt voorlopig zeer goed!

Wat voor iets is dat?

In feite is het gewoon een simpel scrumboard waaraan ik al mijn taken ophang, 1 taak per post-it. Op die post-it staat de taak in een paar woorden omschreven en staat ook de betrokken klant telkens vernoemd. Het bord bestaat uit 4 kolommen: backlog, to-do, ongoing en done.

Backlog
In de backlog hang ik alles wat in mij op komt, zowel zaken die op korte als op lange termijn moeten uitgevoerd worden. Deze backlog is ten allen tijde geprioriteerd: de dringendste zaken hang ik bovenaan, de minder dringende onderaan. De zaken onderaan kunnen nog heel vaag zijn omschreven, bijvoorbeeld: “onderzoek doen naar bluetooth marketing”. De zaken bovenaan in de backlog moeten daarentegen wél concreet en meteen uitvoerbaar zijn.

To-do
In to-do hang ik alles wat binnen afzienbare tijd moet uitgevoerd worden, zaken die dus eerder snel in handen moeten genomen worden. Ook hier hang ik de taken in volgorde van belangrijkheid, het belangrijkste bovenaan.

Ongoing
Ongoing bevat de taken waaraan in bezig ben. Bovenaan hang ik de post-its waar ik actief mee bezig ben. Onderaan hangen zaken waar ik passief mee bezig ben, wanneer ik bijvoorbeeld wacht op feedback van iemand. In het actieve gedeelte mogen nooit meer dan 3 taken tegelijkertijd hangen. Op die manier dwing ik mezelf de zaken stuk voor stuk, lineair af te werken alvorens ik aan nieuwe taken begin.

Done
Alle taken die afgerond zijn, gaan naar done. De taken in done laat ik een week hangen. Op die manier kan ik op het einde van de week zien hoe ik mijn tijd juist verdeeld heb, stof voor eventuele analyse.

Waarom werkt dit systeem voor mij?

Deze manier van werken laat me toe mijn hoofd leeg te maken. Ik ben vaak met zoveel losse dingen tegelijk bezig dat ik al snel het overzicht verlies. ‘s Nachts gebeurde en gebeurt het soms nog dat ik plots wakker word en me realiseer dat ik iets vergeten ben. Oorzaak daarvan was dat ik niet genoeg structuur had en te veel zaken uit mijn hoofd deed. Nu heb ik altijd een post-it blok naast me liggen en wanneer iets in me opkomt, schrijf ik dat meteen van me af en plak ik het op mijn bord. Ook ‘s avonds of ‘s nachts schrijf ik de taken meteen op zodat ik er tot de volgende morgen niet meer aan hoef te denken. Zodoende heb ik mijn hoofd leeggemaakt van wat ik moet doen en weet ik dat het ergens aanwezig is en ik het automatisch en tijdig zal oppikken. Het enige wat ik moet doen, is zorgen dat het bord altijd klopt. Dat doe ik door elke morgen aan het bord te gaan staan en een status op de maken, een zeer eenzame daily stand-up zeg maar.

Waarom post-its en niet gewoon een online app die automatisch met al je devices synchroniseert? Ik heb in het verleden tools geprobeerd als Wunderlist, Toodledo, Jira, Outlook tasks en het zetten van taken in mijn agenda. Deze systemen werkten voor mij gewoon niet. De backlog met taken werd zeer snel onoverzichtelijk en ik begon steeds weer daarnaast taken op te schrijven op post-its en papier. Het werken met papieren post-its werkt duidelijk wel voor mij. Dat is volgens mij omdat enerzijds de drempel nog lager is (het is zeer gemakkelijk met een stift iets neer te krabbelen en op te hangen) en anderzijds is het nog leuk ook! Bovendien biedt een scrumboard verschillende perspectieven in je to-do-lijst die je in een specifieke to-do-tool niet hebt.

Hoe wil ik dit verder uitbouwen?

Wat momenteel nog ontbreekt, is een tijdsinschatting per taak. Nu zijn de taken op zich wel opgelijst en weet ik wat ik eerst moet opnemen. Met een tijdsinschatting zou ik ook een goed zicht kunnen krijgen op de haalbaarheid van alle geplande taken. Dan zou ik meteen kunnen bepalen wat wel en niet meer zal lukken op een dag, week of zelfs maand.

De taken die ik na een week uit de done kolom haal, gooi ik vrijwel meteen in de vuilbak. Ik zou hier ook een mini-analyse kunnen op uitvoeren om te zien op welke klanten of op welk soort taken ik het meest van mijn tijd spendeer. Dan zou ik misschien constateren dat ik mijn tijd efficiënter moet benutten. Het werken met verschillende kleuren per klant, zou nu al visueel meteen duidelijk kunnen maken hoe de huidige verdeling in grote lijnen zit.

In de ongoing kolom zitten nu nog vaak 3 taken tegelijkertijd. In principe zou ik dat nog verder moeten beperken tot maximaal 1 taak. Het zou immers niet mogen dat ik aan meerdere taken tegelijk bezig ben. Maar toegegeven, het is meer uit luiheid zodat ik niet telkens moet rechtstaan en naar mijn scrumboard moet stappen;)

Suggesties?

Zien jullie nog zaken die ik anders en beter zou kunnen aanpakken het systeem efficiënter te maken en mijn werk te vergemakkelijken? Suggesties zijn altijd welkom!

Waarom moeten we wireframes opgeven en vervangen door rapid prototyping?

5554106918_8ed1b0bdf6_o
Standard

Jarenlang hebben we ons voorgehouden dat wireframes een essentieel onderdeel zijn van het designproces. Ze waren bedoeld om content te positioneren, componenten te ordenen op een pagina en interacties op gedetailleerde wijze te omschrijven. In een traditioneel watervalmodel zijn wireframes één van de initiële documenten die een groot deel bepalen van de structuur, de content, het design en het development. In een typisch proces worden wireframes gecreëerd en aan de designer gegeven die ze ‘mooi’ maakt. Die opgesmukte wireframes worden vervolgens aan de developer doorgegeven die ze omzet in een werkende applicatie.

De valkuilen van wireframes

Té vroeg té veel informatie

Deze éénrichtingsstroom zorgt er voor dat er veel problemen in de communicatie opduiken. Teamleden die verderop in het watervalproces aan bod komen, hebben het gevoel dat ze beperkt worden in hun beslissingsrecht omdat alles reeds beslist is op voorhand. Een designer gaat in essentie gewoon een laag verf over de wireframes gieten waardoor zijn probleemoplossende capaciteiten niet benut worden. Het grote probleem is dus dat wireframes té vroeg in het proces té veel informatie verschaffen. Wireframes zijn dikwijls het eerste wat de klant te zien krijgt en waar hij op aftekent. Hierdoor kunnen designers en developers nadien niets meer veranderen of toevoegen waardoor hun creativiteit onvoldoende kan benut worden.

Mensen lezen geen documentatie

Omdat wireframes statisch zijn, zijn ze niet geschikt om interacties te demonstreren dus ter compensatie worden deze interacties grondig beschreven. Afhankelijk van de complexiteit en omvang van de scope van het project, worden wireframes als deel van de functionele specificatie serieus voorzien van documentatie zodat de teamgenoten later in het proces goed weten wat van hen verwacht wordt. Het grote probleem hier is dat mensen geen documentatie lezen. De werking van complexe interacties proberen te omschrijven, is bovendien erg moeilijk. Designers en developers gaan die aantekeningen lezen en op hun manier interpreteren. Soms correct, soms niet correct.

Snel verouderd

Nadat de wireframes bij de designers langs geweest zijn, geven zij ze opnieuw samen met hun designs door aan de developers. Deze krijgen een gigantisch pakket aan documentatie maar tegen de tijd dat deze wireframes de developers bereiken, zijn ze alweer verouderd. De wireframes worden snel outdated en worden oneindig veel herzien waardoor diegenen op het einde van de waterval meer en meer gedistancieerd geraken van diegenen in het begin.

Rapid prototyping

Beschouw rapid prototyping als een alternatief om de communicatie tussen de verschillende disciplines te optimaliseren. Rapid prototyping is gebaseerd op vier fundamentele principes:

Creatie is een gedeelde activiteit
Effectieve producten en diensten vereisen betrokkenheid en communicatie van iedereen door de zaken in vraag te stellen, de evalueren en te creëren.

Creëer enkel wat nodig is
Je hebt net genoeg nodig om klanten -of gebruikersfeedback te verzamelen zonder hen te overrompelen met onnodige details.

Creëer systemen, geen pagina’s
Benader de zaken op een holistische manier in plaats van te focussen op één enkele pagina. Dit laat toe om een reeks modules te creëren die kunnen hergebruikt worden over de hele site.

Creëer zo weinig mogelijk afval
Focus je op wat echt belangrijk is voor je applicatie. Je wordt betaald om iets waardevols te creëren, dat doe je alleen wanneer je je aandacht niet laat afleiden door details.

Voordelen rapid prototyping

Een snel prototype zal het team toelaten om snel te itereren, sneller designbeslissingen te valideren en sneller feedback te verzamelen. De vroege fases van rapid prototyping zouden in HTML, CSS en Javascript moeten gecreëerd worden met weinig of geen opmaak. Door hoofdzakelijk op content en functionaliteit te focussen, wordt onze aandacht (en die van onze klant) niet afgeleid. Naast een betere klantencommunicatie, verbetert rapid prototyping ook de werking binnen het team. Door rapid prototyping meteen naar de front-end te verschuiven, zullen verscheidene disciplines moeten samenwerken en kunnen mensen van elkaar leren en kennis met elkaar uitwisselen.

Rapid prototyping past helemaal binnen het agile-plaatje. Simpele richtlijnen voor prototyping komen neer op deze vier stappen die constant tegelijk zouden moeten gebeuren:

Strategie
De UX-strateeg en/of business analyst heeft initiële conversaties om de business requirements en gebruikersbehoeften te definiëren. Zij zetten hun ontdekkingen om in user research, creëren artifacts zoals user stories, een contentstrategie en persona’s. Deze informatie wordt gebruikt om design beslissingen te nemen.

Structuur
Wireframes bestonden vroeger om structuur te creëren. Dit kan nu gedaan worden door te schetsen. Schetsen zijn een krachtig instrument en iedereen kan het. Schetsen zou freeform moeten gebeuren. Het doel is om snel concepten te kunnen visualiseren en samen met het team te kunnen bespreken vooraleer ze in code worden omgezet.

Design
Structuur en design zouden afzonderlijk moeten tot stand komen. Design kan best niet in volledige mockups gemaakt worden. We willen enkel de minimaal noodzakelijke artifacts produceren (zo weinig mogelijk afval). Creëer style tiles die kleuren, typografie, texturen en het merk definiëren zonder te veel in detail te gaan. Details kunnen immers de conversatie met de klant verstoren omdat er op zaken kan gefocust worden die in feite niet belangrijk zijn (bvb de grootte van het logo).

Interacties
Wanneer schetsen afgerond zijn, kunnen ze omgezet worden in HTML, CSS en Javascript. In de vroege fase van het prototype is design niet aan de orde. Dit laat ons toe om de discussie te centraliseren rond interacties, informatiestroom en toegankelijkheid. De hele site kan gemaakt worden in grijze kaders zonder enige esthetica. Wanneer de afzonderlijke stukjes van het design systeem afgerond worden, kunnen deze via CSS aan het prototype gekoppeld worden.

 

De primaire concepten achter rapid prototyping helpen ons om minder in de traditionele hokjes te denken maar om de cross-disciplinaire collaboratie te bevorderen en alle teamleden de opportuniteit te geven om deel te nemen aan het designproces. Snelle prototypes laten het team toe om een design-idee en zijn interacties te ontdekken en te valideren en de afval en time-to-market te reduceren. Het is een handige tool dat een krachtigere manier levert om design-oplossingen te ontdekken en communiceren.

Je iPhone panoramische foto’s laten maken, helemaal op zichzelf!

cycloramic_large_verge_medium_landscape
Standard

Vandaag zag ik bij een collega een demonstratie van een vrij revolutionaire app! Cycloramic maakt panoramische foto’s en filmpjes zonder dat je daarbij je iPhone hoeft vast te houden. Deze handsfree functie werkt wel enkel op iPhone 5/5S.

screen568x568Hoe werkt het?
Je zet je iPhone gewoon recht op een glad oppervlak en je drukt op start. De iPhone zal vervolgens met behulp van trillingen 360 graden ronddraaien en een panoramisch beeld maken, in video of foto. De app maakt daarbij handig gebruik van de trilfunctie van het toestel en weet die zo aan te spreken dat het toestel zonder omver te vallen een perfecte cirkel maakt.

Mijn ervaringen met de app zijn top! Niet alleen maakt de app haarscherpe beelden, het kan ook een filmpje exporteren van 15 seconden, handig om op Instagram te zetten. De app zonder handsfree functie werkt ook op Android en iPhone 4/4S maar dat het toestel helemaal op zichzelf draait, daarvoor downloaden we de app toch vooral!

Downloaden kan je hier:
App store
Google Play

En voor wie het nog steeds niet gelooft:

iBeacons: wat zijn ze en wat kunnen ze betekenen?

Standard

iBeacon sensorEr wordt de laatste tijd meer en meer gesproken over de iBeacon technologie van Apple en hier en daar duiken er leuke projecten op die de technologie op een interessante manier toepassen. iBeacon is op zich niet brand new. Apple gaf het al een kleine vermelding tijdens de introductie van iOS7 in juni 2013. En eigenlijk is iBeacon gewoon gebaseerd op de bluetooth marketing technologie die in 2006 enorm gehyped werd maar die nooit echt van de grond kwam. Nu probeert Apple het met een nieuwe verpakking te herlanceren en vooralsnog blijkt dat nog te werken ook.

Wat zijn ze en hoe werkt het?

ibeaconiBeacons (of gewoon beacons als we niet specifiek over de Apple-variant spreken) zijn gewoon draadloze sensoren die je in een bepaalde ruimte hangt en die constant signalen uitsturen naar smartphones die in de buurt komen en uitgerust zijn met de BLE (Bluetooth Low Energy) technologie. Dit, gecombineerd met de juiste software, biedt heel wat interessante mogelijkheden. Zo kunnen shops speciale aanbiedingen op hun voorbijkomende klanten afvuren, kunnen klanten in de shops persoonlijk benaderd worden en meer informatie krijgen wanneer ze langs bepaalde producten wandelen, kunnen klanten aan hun boodschappenlijstje herinnerd worden wanneer ze op een bepaalde locatie aankomen,…

Vooral voor de retail sector lijken de beacons enorme voordelen te kunnen bieden maar daarnaast zijn er ook tal van mogelijkheden weggelegd voor openbare locaties zoals ziekenhuizen, luchthavens, musea,…

Beperkingen

Het is duidelijk dat deze beacon-technologie niet in elke context kan gebruikt worden en zeker niet om potentiële klanten meteen te kunnen bestormen met allerlei promotionele boodschappen. Daarvoor moet eerst aan een aantal randvoorwaarden voldaan zijn:

  • Signalen van iBeacons kunnen enkel opgevangen worden door devices die hun bluetooth hebben aanstaan en BLE-compatibel zijn (bij iPhone is dat reeds vanaf iOS7 en iPhone 4S)
  • Gebruikers moeten een app geïnstalleerd hebben die de iBeacon signalen opvangt en converteert naar een boodschap
  • Gebruikers moeten de location permissions hebben geactiveerd voor deze app welke fungeert als opt-in om berichten te kunnen ontvangen.

De mogelijkheden moeten dus vooral gezien worden op permanente fysieke touchpoints zoals winkels, musea, publieke plaatsen met elk hun eigen mobiele app. Beacons zijn totaal niet geschikt voor tijdelijke installaties die worden opgetrokken met de bedoeling zoveel mogelijk toevallige voorbijgangers aan te spreken.

Leuke toepassingen

We zien meer en meer leuke toepassingen opduiken de laatste tijd. Hieronder enkele opvallende.

Het reclamebureau Prophets installeerde beacons in een museum en maakte voor dat museum een bijhorende mobiele app. Op die manier wordt aan het museumbezoek een digitale laag toegevoegd dat een meerwaarde creëert voor de bezoeker. Meer info vind je hier.

PayPal is ook op de kar gesprongen en pakt uit met handenvrije betalingen. Je loopt een shop binnen, de PayPal beacon detecteert meteen dat je in de shop bent aangezien je de PayPal app op je smartphone hebt staan. Bij de betaling van je aankoop, volstaat het om te zeggen dat je met PayPal betaalt en je kan zo weer naar buiten stappen. Meer info hier.

Het bedrijf inMarket heeft het Mobile to Mortar platform ontwikkeld dat gebruikers instore reminders verstuurt over hun boodschappenlijstje. Als ze een brood moesten kopen, zullen ze een melding krijgen wanneer ze de bakker binnenlopen,…