Fabrique: Hoe technologie het creatieve proces definieert
Marko Kruijer van Fabrique sprak op Campus Party Europe over de rol van technologie in het creatieve proces: “Je hebt creatieve engineers nodig die technologie begrijpen en weten toe te passen. Zij formuleren het probleem en weten wat er technisch gezien wel en niet mogelijk is. Uiteindelijk bepaalt technologie de ervaring van de eindgebruiker.”
Kruijer doorloopt de geschiedenis van het creatieve proces: “Het was vroeger top down. De developer moest gewoon maken wat de creative director had bedacht. Vandaag de dag zie ik juist de bottom up aanpak. De mensen die het product maken, of het nu developers, designers of UX-designers zijn, als ze de technische mogelijkheden kennen, dan zorgt dat voor een beter eindresultaat.” Kruijer geeft iBeacon-technologie as voorbeeld: “We gingen als Fabrique zelf eerst testen. Wat kun je ermee? Blijkt dat een standaard beacon slechts drie afstanden ziet: ver weg, nabij en dichtbij. Dat is dus een beperking. Maar onze engineer ontdekte ook nieuwe mogelijkheden en het hele team profiteert daarvan.”
Campus Party Europa brengt geeks, studenten en ondernemers samen op een vijfdaagse creatief festival met presentaties, hackathons, demo’s, workshops en een drone wedstrijd. Onder de vlag van Dutch Digital Agencies en Dutch Digital Design gaven zeven Nederlandse bureaus een presentatie over design, innovatie en technologie.
Gerelateerde eGuide case
Deel dit bericht
Plaats een reactie
Uw e-mailadres wordt niet op de site getoond
1 Reactie
Sjors Pals
Goed artikel, als developer met een creatieve inslag ervaar ik het zelfde, vanuit de creatieve hoek zie je vaak dat er Mockups worden gemaakt waarin de technische kant niet word bekeken, het gevaar is dat klant vaak onder indruk is en opdracht geeft het uit te werken, zonder hierbij eerst een kleine POC te doen.
Zelf heb ik vorig jaar een interessante POC gedaan met de Amazon Echo (alexa spraaktechnologie), hoewel de techniek prima werkt liepen we tegen een aantal zaken aan, bijvoorbeeld dat wanneer een woord niet begrepen word, je niet een soort van “ruwe” input kan ontvangen wat de gebruiker had ingesproken. Mijn idee was namelijk dat als het woord niet herkent werd, dat ik zelf wel een “ruwe” gok zou kunnen doen op de keuze. Erg beperkend maar ook de conclusie dat iets nog niet werkt, is prima bij een POC, daar is deze namelijk voor!