Tag Archive | tech

NTR Hieronymus Bosch: an interactive documentary in Micrio

image

Commissioned by the NTR and together with our friends at Fabrique we built the interactive documentary for the transmedia triptych about Hieronymus Bosch by director Pieter van Huysteee. The documentary is called ‘Hieronymus Bosch: The Garden of Earthly Delights’ and affords you to discover this painting in more detail than ever. To be able to discover this image of extremely high resolution, a new engine to zoom and scroll over the painting smoothly had yet to be developed. This engine is called Micrio.

Triptych of a triptych

image

2016 is the year that Dutch town Den Bosch celebrates in the name of Hieronymus Bosch. Not without reason: this world famous master painter died exactly 500 years ago. For this occasion several directors, dancers, designers, componists, art historians and other creatives let Bosch inspire them anew. Director Pieter van Huystee was one of those re-inspired creatives. In collaboration with the NTR he produced a transmedial triptych about Bosch: a documentary, a VR-experience and this interactive documentary which Marcel, Michiel, Tim and Silvy built.

Hieronymus Bosch, The Garden of Earthly Delights

The triptych The Garden of Earthly Delights was extraordinary back in the days because of its almost infinite details. And it has never lost this extraordinarity. Every time you look at this painting again, you will discover and stumble upon new creatures and stories. Because we have built the documentary in Micrio, you can now discover the painting in even more detail than at the Prado in Spain from behind the little fence they’ve put in front of the painting. We worked close together with the NTR, Pieter and music componist Paul M. van Brugge to develop the interactive tour next to the ‘freely explore’ option. The voice of Redmond O’Hanlon guides you through the painting to explore the deepest details and gives you information about the mysterious symbolism behind the strange creatures in this Bosch painting. We’ve also built a (Dutch) Klokhuis-tour for children. You can rediscover this painting here.

Micrio

image

We have worked with big images before for the Rijksmuseum. But, the hi-res image of ‘The Garden of Earthly Delight’ is so extremely big (120.000 x 70.000 pixels) you can’t even download all of it at the same time. That’s why we had to think of something new. Marcel got inspired by this fact and came with Micrio: an online viewer for extremely hi-res images. At the core Micrio is a HTML5-library that streams the biggest images of the internet with minimal effort. From the start it’s developed with performance and minimalism in mind. Because the streaming should be extra smooth on smartphones, tablets and retina-screens too. To make sure a visit to the triptych doesn’t use up all of your mobile data, data usage has also been successfully minimized.

FYI

Micrio has already provoked some attention of its own. At this moment it’s being implemented in several projects we’re working on and it’s already implemented in the renewed website of Museum de Lakenhal. It was on show at Border Sessions 2015. And several Q’ers have built an open image service around it (Dutch article): the Micrio Dashboard. All in all it took a full year to take it from the first prototype to the full blown stable version it is now. How such a simple thought as “This has to be better!” led to a tool that’s now running in several of our Q-projects, is something Marcel hasn’t expected: “This journey has been really cool! I wonder where it goes from now.” (If you have any extremely hi-res images laying around don’t be shy to upload them to Micrio or get into contact with us!)

But for now! Please enjoy the interactive docu and Micrio in ‘Hieronymus Bosch: The Garden of Earthly Delights’.

You might have read this article before. That’s very well possible. Almost two weeks ago we posted the exact same post in Dutch with the launch of the documentary. Since then the interactive documentary has gotten more views and attention we could have possibly hoped for. In just one week the site has reached more than 40.000 views already, after two weeks more than 100.000 and after being on the front page of Reddit since last night we’ve passed 200.000 views. Not only Reddit picked up our interactive documentary, a lot of people are talking about it on social media and several blogs posted articles about it, Colossal for example. The attention thus isn’t only Dutch anymore so we thought it would be helpful for our international audience to translate our piece in English. The picture below is of our extremely proud Marcel, the creator of Micrio, who after a tip it being posted on Reddit last night, is watching on his phone how ‘The Garden of Earthly Delights’ gradually reaches the frontpage.

image

ProDemos’ BinnenhofCheck: why to go with Meteor when your app has to run partially offline

ProDemos’ BinnenhofCheck app is a connected multiplayer quest for high school students around The Hague’s Binnenhof (the oldest House of Parliament in the world, still in use). While that doesn’t sound particularly extraordinary (ahem), the challenge this project encountered is. We built an interactive game with a crucial sidenote: players have no internet access for a considerable amount of time during the session. Meteor proved to be the perfect answer for a case like this.

No internet?

Yup, no internet. Because, ProDemos’ WiFi reaches to the door of the Binnenhof, but no further. And, because of security regulations that restrict WiFi at the Binnenhof itself, extending the signal wasn’t an option. “What about 4G?”, I hear you thinking. Sure, there’s 4G coverage at the Binnenhof, but giving 30 tablets 4G subscriptions will cost you. Besides, why spend so much when internet connectivity isn’t really a necessity anyway, because the solution can be so simple?

Meteor’s ‘elevator pitch’

Meteor convinced us rather conclusively, during what you can call a literal elevator pitch. Before this app, we built another Meteor app for ProDemos. During that project, the question of whether the app would still function when connection was temporarily lost came up. Remco was kind of sure it would, and tested it by stepping into the elevator. Because of course: the world of elevators is an offline one. And it did! Without internet connectivity he could still use all the app’s functions. In fact, stepping out of the elevator, the app synced automatically with the server again. That is what makes Meteor so powerful in a case like the BinnenhofCheck. Packages like MiniMongo and autopublish make it so that an app fully runs on the client, even when it’s offline. And then it automatically syncs with the server again when connectivity is back – without you having to set it up to do so yourself. That’s valuable time saved  to spend on user experience instead of trying to fix the problem of the lack of internet.

Latency compensation

Writing your code for the client is clean and simple in Meteor. And because every Meteor client has an in-memory database cache, there is no need to manually cache data to dodge slowness in talking to the server, program detailed invalidation messages to every client when data changes or implement individual RPC endpoints.

The server publishes defined sets of data through publications, and the client subscribes to these sets through subscriptions. When the content of these sets change, the server updates them in the client’s cache too. The client code is extremely simplified, by using its cache as a fast local database. Therefore, for reading the subscribed sets of data, no connectivity to the server is needed. This saves time, and makes the app faster. You can easily make your client even snappier by turning subscriptions on and off to control the amount of data kept in cache and manage the network traffic. Turning one off means it will automatically delete all its data from your cache.

So the server automatically updates subscribed data on the client when data on the server changes. The client, as a MiniMongo, does something similar. When data is changed on the client, for example through an action of the user, it automatically sends a message to the server with a request to change it on the server too. The server checks its allow/deny rules, and when all those rules pass, it changes the data and updates the change to other clients with the same subscriptions too. No need for you to code this yourself.

In short, these methods realize latency compensation, which means you can still use the app locally in full function when connectivity is lost and it automatically updates the server when connectivity is back.

You can read about these techniques in more detail here.

Publications and subscriptions in the BinnenhofCheck

For the BinnenhofCheck app, built by Silvy, Jeroen and Remco, this means MongoDB is the database on the server at ProDemos. And the tablets (the clients) function as MiniMongo. At the start of the quest the supervisor creates a group and session in the dashboard of his or her tablet. This group then receives a code, and with this code the students can add themselves to it on their own tablets. Now the quest can begin. During the quest the tablets are offline, but still run the app in full function. Back at ProDemos, connectivity is back and automatically publishes all the changed data by the students to the server to see who has won the quest. After this, the supervisor presses ‘stop’ to end the session: this automatically archives the subscriptions and deletes the data from the caches of the tablets. Clean and ready to start with another group immediately.

Asset manager package

However, data like text is fine, but you don’t want to upload all the images and videos to the clients every single session. That would be a serious waste of time. So we weren’t there yet. We ended up fixing this by creating two different collections on the server. One for all the text, questions and locations (these types of data are small enough in size to quickly upload and delete every session through the publications and subscriptions) and the other one for the images and videos. For this collection we built an asset manager package. Through scheduled tasks, this collection synchronizes with the clients. You can find this asset manager package here.

We really enjoyed building this app in Meteor for ProDemos and are very proud of the result. If it’s up to us, this case proves building an app in Meteor is the simple solution when you’re facing a similar problem with connectivity in your projects.

PS We think a nice future addition would be to add GroundDB.

PAPER van De Persgroep, een hybride app, maar waarom?

image

Voor de prijs van de Linda, maar dan in plaats van één keer in de maand zes dagen in de week een verse editie. PAPER zit ergens tussen een serieuze krant en een glossy in en is geschreven door De Persgroep. Met veel liefde en plezier hebben wij deze hybride app ontwikkeld. Maar waarom eigenlijk hybride? Waarom niet native?

Het hybride versus native-vraagstuk komt voor ons vooral neer op: waarom moeilijk doen als het makkelijk kan? Het antwoord op die vraag is uiteraard: dat hangt er vanaf.

Beleving

Native apps voelen toch altijd nét even wat soepeler. Sexyer. (Ja, zo schrijf je dat blijkbaar. Ziet er toch niet uit?) Er is meer liefde en aandacht nodig om met een hybride app datzelfde niveau van beleving te benaderen. Dat doen we graag, maar waarom moeilijk doen als het makkelijk kan? Punt voor native.

Ontwikkeltijd

Wanneer je voor twee of meer platformen ontwikkelt, kost het ontwikkelen van een native app vaak meer tijd dan het ontwikkelen van een hybride app. Met native heb je immers een codebase per platform, met hybride één. Punt voor hybride.

Maar… dat verschil is in onze ervaring alleen significant wanneer je één interface kunt aanbieden die voor alle platformen werkt. En dat is zelden een goed idee. Vinden wij. Geef dat punt dus maar weer terug. Of…?

Android-apps zien er anders uit dan iOS-apps. En belangrijker: ze werken anders. Daarmee doelen we niet alleen op Apple-fanboys of Google-groupies (of een verdwaalde Windows Phone-aanbidder) die chagrijnig worden als ze een UI pattern van het rivaliserende platform tegenkomen op hun geliefde device. Elke smartphone- of tabletgebruiker is simpelweg gewend aan de standaard interface-elementen van het platform. Het kost de gebruiker minder denkmoeite (Is dat een woord? Bij deze.) als een app zich daaraan houdt. En dat is goed. Je moet dus wel een verdomd goede reden hebben om één en dezelfde interface aan te bieden met je app.

image

De verdomd goede reden voor één interface

PAPER is een magazine. Met een magazine-uitstraling. En een magazine-interface. Net als bij games is het voor een magazine-app als PAPER helemaal niet gek om er anders uit te zien en anders te werken dan de meeste andere apps. Sterker nog, als PAPER met voornamelijk native UI elementen gebouwd zou zijn, dan zou de app een stuk minder sexy zijn.

Kortom, voor PAPER was hybride ontwikkelen significant sneller. Waardoor er voldoende ruimte overbleef om de app zo gelikt mogelijk te maken.

Andere overwegingen

Uiteraard weegt er meer mee. Eén codebase is gemakkelijker te onderhouden dan meerdere. En dat één van de ondersteunde platforms het web zelf is, is natuurlijk ook relevant.

Daarnaast is het ook belangrijk om te kijken naar de (on)mogelijkheden van hybride en native. Het is echter allang niet meer zo dat je met hybride minder kunt, dus dat zit wel snor. Met Cordova kan native functionaliteit gemakkelijk aangesproken worden vanuit JavaScript, ondanks de platformverschillen. Dat hebben we nu bijvoorbeeld met notificaties gedaan en we hebben net de in de platforms ingebouwde manier om artikelen te delen ingebouwd. Dat delen is een mooi voorbeeld van iets dat we dus wél platformspecifiek willen hebben. En dat kan met Cordova.

image

Blije nerds

Voor ons ook erg belangrijk is het meewegen van ontwikkelaarsblijheid. Het ontwikkelen van hybride apps is lang een stuk minder prettig geweest dan het ontwikkelen van native apps. Maar inmiddels is het best wel oké. We hebben ons heerlijk vermaakt met de isomorphische manier van werken van React en Fluxible. (In een notendop: dat betekent dat zowel de server als de client (delen van) de interface kunnen renderen. Net als hoe Facebook dat doet. Zij hebben React dan ook gebouwd.) Cordova lost ook veel op, maar heeft ook nog wel een weg te gaan, als we eerlijk zijn. Cordova kan soms nare, exotische bugs opleveren. En Cordova helpt ook niet als je de performance en beleving optimaal probeert te krijgen. Dat is ook niet zo gek, als je bedenkt dat Cordova nog steeds ondersteuning voor Blackberry met zich meezeult, maar daar frustreert het niet minder om. Het is dus nog niet allemaal rozengeur en manenschijn, maar er is al voldoende reden om blij te zijn.

Daarom dus hybride

In dit geval.

En nu, Apple-fanboys, kunnen jullie lekker PAPER gaan lezen op een Android. Of Google-groupies op een iPad. Maakt toch niet uit, PAPER is op elk platform even fijn.

Geniet ervan.

Happy plees voor nerds

image

Goede programmeurs zijn liever lui dan moe. Benjamin is daar een mooi voorbeeld van. Hij werd er namelijk schijtziek van (pun intended) dat hij opstond om naar de wc te gaan en er dan pas bij de wc achterkwam dat de wc bezet was. Al die tijd: wasted. Dat moet makkelijker kunnen.

image

Eureka!

Connected toiletten. Nooit meer naar de wc als er al iemand op zit, nooit meer onzekerheid óf er iemand op zit. Jij bent misschien hard bezig met je connected huis, wij met ons connected office. Onder het genot van pizza en de Apple Keynote bouwden Benjamin, Chris en Jeroen afgelopen maandagavond twee connected toiletten en een splinternieuwe API. Ergens tussen het boren, kabels langs de deur trekken en stroom aftappen door, dacht Chris: “Hé, ik was toch software engineer?”. Nee, manusje van alles, Chris. Manusje van alles.

image

De techniek

Éen wc heeft een proximity sensor in het deurslot om te checken of de wc bezet is. De ander heeft in plaats van een proximity sensor een micro switch in het deurslot: één probleem twee oplossingen. De Electric Imps zetten via een API (een node.js server) de hue lampen die we voor de wc’s hebben hangen op groen bij vrij en op rood bij bezet. Deze API poept uit (kon het niet laten, sorry) of toilet 1 of 2 beschikbaar is of laat een lijst zien met alle toiletten en hun beschikbaarheid. Nu hoef je echt nooit meer onnodig van je plek af. Opgelosssst!

image

Slack

Zodra de API geslackt was, gingen de Q’ers los. Sjoerd had bijvoorbeeld binnen no time een hele nuttige Slack integratie, namelijk het command: /ikmoetnodig. Zo kun je als je nodig moet direct in Slack zien waar je heen kunt als de nood het hoogst is. Wie weet bestaat er binnenkort ook een command om een toilet te reserveren, ook een idee vanuit Slack. De hue lamp bij de gekozen wc kan dan bijvoorbeeld oranje knipperen, zodat iedereen ziet dat jij voorrang hebt. Minder ethisch verantwoord misschien is het idee om ook een geursensor in te bouwen en met een paars knipperende lamp de potentiële toiletbezoeker te waarschuwen: “Ja, dit toilet is vrij, maar betreden op eigen risico.”

image

Maar even zonder dollen

Poep-en-pieshumor is zonder twijfel retegrappig, maar dat betekent niet dat onze connected toiletten niet serieus nuttig zijn. Niet alleen is het een leuk project om na werktijd met je collega’s te bouwen, maar het bewijst ook dat je met programmeren alles makkelijker en dus beter kunt maken. De mogelijkheden zijn oneindig: API all the things! En als je die API opengooit blijken de mogelijkheden die anderen zien nog verrassender en oneindiger (is dat een woord?).

Onze next step: connected lift. Als je naar huis gaat heb je vaak haast om je trein nog te halen. Je pakt je tas snel in, maar daar sta je dan. Bij de lift. En die komt maar niet. Waarom niet de lift alvast roepen terwijl jij je tas inpakt? Over efficiëntie gesproken!

Maar in de tussentijd, iemand geïnteresseerd in connected toiletten?

Girls in Tech hackathon

image

Afgelopen weekend was het zover. De enige echte Girls in Tech hackathon. Jullie hadden het vast nog niet door, maar hackathons die vinden wij leuk. Meer dan leuk, eigenlijk. En deze was extraspeciaal leuk: een hackathon, niet alleen voor vrouwen, maar wel met de bedoeling de wereld van programmeren en hackathons wat toegankelijker te maken voor vrouwen. Meer diversiteit. Dat is alleen maar toe te juichen. En daarom gingen Mark en Kr=10 (aka Kristin, noob) erheen. Ook omdat het een kans was om te knutselen met hue. Dat ook.

Girls in Tech

De hackathon was goed geregeld. Kr=10 was vooral onder de indruk van het gebouw middenin Amsterdam waar ze de hele dag mochten programmeren. Afgeleid door het plafond. Ze heeft het er nu nog over. Het eten was ook om over naar huis te slacken en Kr=10 en Mark vonden dus een nieuw publiek voor TimL’s bananentijd. Bananentijd? Ja om 15.00 uur, elke dinsdag, iedereen een banaan @ Q. Mét soundtrack. Net ook weer. Dan weet je dat.

image

Maar er werd natuurlijk niet alleen maar gekeken en gegeten. Er werd ook serieus geprogrammeerd. Deze dag werd onder andere gewerkt met Philips hue API, BigQuery en tools als Google AppEngine en Firebase. Voor hulp liepen er mentoren van Google, Philips, The Next Web en Bottlenose rond. Daarnaast kon je aan de slag met een starterskit met drie hue lampen en een bridge, een box gekoppeld aan een hairstyler van Philips en een box gekoppeld aan een Wake Up light. De meesten kozen voor de starterskit, zo ook Mark en Kr=10.

Samantha hue

En het resultaat mag er wezen. Helemaal Q in de wereld van domotica en Internet of Things, bouwden Mark en Kr=10 in één dag Samantha hue, aangenaam. Samantha, hue dus, luistert naar je en geeft je wat je nodig hebt. Ze laat je namelijk weten wat voor weer het is, waar dan ook. Wie wil dat nou niet? In de toekomst wil je dat je huis je uit zichzelf dingen geeft die je nodig hebt. Daar zijn we met Samantha hue weer een stukje dichterbij. Je vraagt en je krijgt.

image

Hoe dan? Nou, Samantha hue laat je hue lampen het weer visualiseren met gebruik van de Philips hue API. De speech recognition API in Chrome is gebruikt om Samantha hue te laten luisteren en begrijpen wanneer je vraagt naar het weer in een bepaalde plek. Zij haalt de weersinformatie uit de API van OpenWeatherMap en laat dit zien door je hue lampen op geel te zetten voor zonnig weer, grijsblauwig voor bewolkt en blauw met wit grijze flitsen voor regen. Als je de starterskit tot je beschikking hebt, kun je het ook even zelf proberen met deze repository. En anders kan je de (hele korte) demo bekijken.

Kortom, dé weatherapp die je wilt. Vet werk, Mark en Kr=10!

Functional Programming in Swift workshops

image

Functioneel programmeren en Swift. Beide heul erg hot en happening. Sommige Q’ers werken er allang mee, maar zo’n beetje heel Q wilde toch wel meer weten. Dus gaf ChrisE twee workshops. Chris? Nee, ChrisE. Maar Chris was er ook bij. Niet te verwarren met Christiaan. (Volg jij de Chrissen nog? Nee? Dat kan wel: volg Chris, ChrisE en Christiaan.)


image

Chris, E dus, is oud-Q’er en schreef samen met Florian Kugler en Wouter Swierstra het boek Functional Programming in Swift. ChrisE kwam speciaal voor ons overgevlogen uit Berlijn. Dat was niet alleen leerzaam, maar ook ouderwets gezellig.

Q42 mocht van ChrisE’s talenten gebruik maken tot en met 2007. Hierna ging hij de wijde wereld in. Inmiddels woont hij in Berlijn en werkt hij voor zichzelf. Je kent hem misschien van objc.io, Deckset, UIKonf of z’n blog. Of van zijn kersverse boek dus, wat voor ons de aanleiding was hem uit te nodigen.

image

Swift is swift

Swift werd op WWDC 2014 door Apple bekend gemaakt. Het is dé nieuwe programmeertaal voor iOS. De opvolger dus van Objective-C. Wat vooral interessant is, is de swiftness van Swift in populariteit. Er wordt wel vaker een nieuwe programmeertaal bekend gemaakt, maar hoe snel Swift is opgenomen door programmeurs is opvallend. In één kwartaal sprong Swift van plek 68 naar plek 22 in de RedMonk Programming Language Rankings. Dat is een sprong van 46 plekken! 46! Deze lijst kent gemiddeld vooral stijgingen van 5 tot 10 plekken. RedMonk voorspelt dan ook dat Swift de volgende keer in de top 20 van programmeertalen zal staan. Holy moly!

image

Functioneel programmeren

Ook hier is Swift snel opgepakt en we bouwen er al verschillende apps mee. Neemt niet weg dat je er nog meer over kunt leren. Maar de workshop ging niet eens zozeer om Swift, vooral om functioneel programmeren. Iets wat een paar Q’ers al jaren fanatiek in de hobbysfeer doen en ook steeds meer toepassen in ons dagelijks werk. En waarmee ze ons inmiddels vrijwel allemaal razend benieuwd hadden gemaakt. Eén workshop was dan ook niet genoeg. Dat moesten er dus twee worden.

image

ChrisE: “Functioneel programmeren is heel veel werken met types. Dat is waarom ik Swift zo cool vind. Opeens konden we op iOS met types gaan werken. Met functies. En dingen als generics. Als het compilet dan werkt het.”

Als je meer wilt weten over functioneel programmeren in Swift, lees dan ChrisE’s boek, haal hem over ook bij jou een workshop te geven of bekijk dit filmpje:

Of doe het alledrie, dat hebben wij gedaan. :-)