Tag Archive | app

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.

Watson: eindelijk écht naar de bioscoop als blinde of slechtziende

We houden ervan om het internet toegankelijk te maken voor iedereen. Soundfocus houdt ervan om films toegankelijk te maken voor iedereen. Reden genoeg om de handen ineen te slaan, met als resultaat: Watson, een app waarmee blinden en slechtzienden volop kunnen genieten van alle Nederlandse films. Zowel in de bioscoop als op televisie.

Slecht- of helemaal niet zien in de bioscoop

Dat is heel vervelend, want tot nu is de bioscoop weinig toegankelijk voor dit publiek. Probeer de Titanic maar eens te volgen met je ogen dicht. Natuurlijk zeggen de stemmen wel wat, maar die achtergrondgeluiden kunnen net zo goed van een vliegtuig zijn in plaats van een indrukwekkend schip. Dat wil je natuurlijk niet pas doorhebben als dat schip tegen een ijsberg vaart. Dat voelt toch een beetje als te laat. (“Huh? Vliegen ze zo laag dan? Oh, wacht…”)

De gewone voorstellingen zijn moeilijk te volgen voor veel blinden en slechtzienden. Gezellig naar de bioscoop gaan is daarom voor hen allesbehalve gewoon. Dat is niet omdat zij het niet zouden willen, want zij willen niets liever dan gewoon mee kunnen doen in de samenleving.

De oplossing is audiodescriptie

Soundfocus maakt audiodescripties bij allerlei video’s, ook films. Audiowat? Audiodescriptie. Dat is de audio die je hoort om het beeld te beschrijven en dus de manier om de film ook visueel uitgedaagd goed te kunnen volgen. Maar om deze audiodescripties voor nieuwe films mogelijk te maken, zijn samenwerkingen met filmmakers nodig. De situatie tot nu is dat heel af en toe een film van audiodescriptie kan worden voorzien en heel af en toe er dan een bioscoop is die zo’n film ook nog draait. Zo’n bioscoop is echter niet altijd in de buurt. Kortom: niet elke film is te ervaren door dit publiek. Als de film dan gedraaid wordt is de afstand vaak nog een belemmering én het is een speciale voorstelling, dus tegelijk met je scherpziende vrienden gaan, is er vaak ook niet bij.

Wanneer audiodescriptie toegankelijk zou zijn tijdens de reguliere voorstelling in de bioscoop kunnen ook blinden en slechtzienden weer gezellig mee naar de film. In Nederland is het belang hiervan te lang onderschat geweest (in Engeland bijvoorbeeld is audiodescriptie al veel meer mainstream). We hopen daar met Watson verandering in te brengen en dat meer filmmakers (ook internationale) de samenwerking aan zullen gaan.

Onder de motorkap

Watson gebruikt audioherkenning om de audiodescriptie van de film gesynchroniseerd af te spelen. Dat wil zeggen dat de app luistert naar de audio van de reguliere voorstelling en aan de hand van die audio bepaalt waar in de film je bent. Vanaf dat punt speelt de app via je koptelefoon de audiodescriptie bij de betreffende film af. Dit betekent dus dat je gewoon met je goedziende vrienden naar de reguliere voorstelling kunt en met de app de film goed kunt volgen. In welke bioscoop dan ook, ook wanneer de film op televisie speelt, en bovendien zonder dat je haviksoogvrienden daar last van hebben.

We hebben Watson gekoppeld aan een closed source fingerprinting library van pHash. Daardoor herkent de app het ook wanneer je tien minuten te laat de film binnenwandelt en begint die gewoon met de audiodescriptie op het juiste punt in de film. In de eerste versie deden we dat server-side, maar dat performde niet optimaal en in de bioscoop heb je niet altijd internet. Om deze problemen te voorkomen werkt het nu gewoon in de app zelf, dus ook als je offline bent.


We hebben zelf meegetest in de bioscoop en ervoeren dat wanneer je een film met audiodescriptie “kijkt” je zelf vrij bent om het beeld in te vullen. Vonden we stiekem als visueel onuitgedaagden best vet! Dus als jij wel eens een film niet wil zien, omdat je bij het boek je eigen invulling hebt gegeven, ‘bekijk’ dan eens een film met Watson. Lekker met je ogen dicht.

Je kunt de app vanaf nú nú nú downloaden voor iOS en Android.

‘Bashing’s’ Datavisualization as Information Intervention

bashing cover
Living in the era of Big Data, data visualization is booming in science, marketing and journalism. In this article I want to show that this booming phenomenon is also relevant to politics and social matters. As in that it is being used to enable a saver world. I will do this by discussing the mobile App ‘Bashing’ which is designed to raise community and political awareness for homophobic violence. In order to discuss this app critically, I will analyze it using Lisa Parks’ critique on a data visualization by Google also aimed at raising awareness for violence.

Read More…

Betrokkenheid: Bij het Groene Hart

Je hebt een ‘likeable’ merk, maar hoe maak je dat zichtbaar? Sociale media kunnen dit goed weergeven. Waar traditionele media gillen dat ze ‘likeable’ zijn, laten merken via sociale media zien dat ze ‘likeable’ zijn door de fans van het merk zichtbaar te maken. Ze hoeven niet te roepen dat ze het zijn, want hun zichtbare interactieve fans zijn het bewijs. En hoe meer fans en interactiviteit hoe meer nieuwe potentiële nieuwe fans worden bereikt. Zo is ook het Groene Hart een ‘likeable’ merk en daarom laat ik je in deze case-study zien hoe deze onzichtbare al bestaande fans zichtbaar zijn gemaakt met behulp van Facebook. Lees gerust even verder.

Read More…