The future and the tightrope: Fronteers 2015


The last two days i’ve been attending the Fronteers 2015 conference in the Tuschinski theatre in Amsterdam. This was my fifth Fronteers conference, i was there in 2014, 2012, 2011 and 2010 as well.

The mix of talks was ideal: from the extremely technical (MPEG decoders in Javascript and WebAudio) to more higher-level presentations on team management and digital governance.  The team of volunteers making it all happen got a well-deserved standing ovation at the end of the conference.

Not just boys anymore

Of the 16 presentations, 6 were given by female speakers. That’s over a third. In 2010, five years ago, there were just 2 female speakers. Because we don’t want to have a web that’s primarily target towards white guys living in the Bay Area, it’s extremely important to have speakers that are as diverse as the world itself. If we want to have more woman in tech, we need role models to show that girls can code just as well as boys. So i loved the fact that one of the most in-depth technical talks, about the WebAudio API, was given by Soledad Penadés, who didn’t stop coding because she was a girl.

We need CMS as a service

For me, the most interesting talk that directly related to my work was the one by Phil Hawksworth on static sites. Because building static sites is basically all i do nowadays at de Volkskrant this talk was especially useful to me. Phil briefly mentioned ‘content as a service’ as one of the key pieces in a static site infrastructure. Unfortunately it also seems to be the thing that’s not widely available right now.

I’ve written before on how the perfect CMS should just be a CMS for an API instead of a site, this is basically the same line of thought.

Contentful is a CMS-as-a-service that is mostly following this route, but for now i don’t really like to bet on a proprietary solution. I would love to see some (open source) development in this area.

The future and the tightrope

You can’t have a frontend conference without talks about browser features that aren’t (yet) widely implemented and tips and tricks to improve performance. It was fascinating to hear about the new possibilities with service workers and ‘above-the-fold’ CSS rendering. And i think Chris Heilmann is right in ranting about how webpages still take up too much space, use too many requests, and don’t work without Javascript.

On the other hand, there is a reason why so many webpages are like that and i think it was best explained by the highlight of this conference: Primate’s talk about “the tightrope between mediocracy and bankruptcy”. In an entertaining and, at times, hilarious presentation, Espen, Bart and Gordon brilliantly explained the difficulties every small and medium-sized web agency faces. From the balance between using mediocre templates (that are cheap) or custom designing every piece of content (which is expensive) to the choices of having no clients or bad clients, they were spot-on.

Simply put: you just can’t put every single ‘best practice’ in practice because, well, you’ll go broke.

It’s fine to put every cutting-edge technology in your app if you’re Google or Facebook (because you have a virtually endless supply of money), but if you’re a regular company, you need some very good reasons to introduce such technology, because those developers don’t come cheap, and they’re not doing something your client will happily pay for.

That doesn’t mean you should never use anything cutting-edge in your sites, it just means that you need to consider the advantages and disadvantages, the exact thing your client is asking, and how much time and money you can spent.

To sum it up in that two-word developer cliché: it depends.

See you next year in April!

Tackling video and audio on the mobile web

Imagine that you’ve got this cool project where you’re building a multimedia scrollstory for the web. There’s some great video and audio content, the designer has made some really nice looking visuals, all you’ve got to do now is to bring it all together in a fantastic interactive extravaganza.

And then suddenly there’s a voice somewhere in the back of your head: wasn’t there something with audio and video on mobile webbrowsers?

The touch revolution has given us wonderful new possibilities, but also a lot of headaches on how to translate the desktop web experience to mobile and tablet. Audio and video might be one of the biggest hurdles.

So, what are those problems? And more importantly: how can we fix them?


Let’s start with the problems. Basically, there are three major problems with media on mobile.

  1. The biggie: on both iOS and Android (this includes both mobile and tablet devices) it is not possible to ‘autoplay’ a media file. What this means, in practice, is that you always need a user action to initiate an audio or video play, such as a button click. For ‘narrative video’, such as a YouTube embed, this is usually not a big problem, but it can be very frustrating when you’re trying to use video as a background layer (example).
  2. Only on iOS mobile (hence: iPhone and iPod touch) video will always start in a separate player, outside of the browser. This means that you can’t layer text or images over the video. It also means that the user gets taken out of the experience in the browser. Like the autoplay problem, this is mostly acceptable for ‘narrative video’, but awful for background video. Note that this problem does not apply to audio.
  3. On iOS (both tablet and mobile) you can only play one media file at the same time. When you have two videos on a page, you have one of them playing and you hit ‘play’ on the other, the first one will pause.

There are some minor problems too. I won’t delve too deep into these points, it’s just so that you know it when you encounter them:

  • On both iOS and Android video files play in another process than the browser. This means that there might be some quirky edge-cases, such as having a different user agent when playing a media file (something like ‘Quicktime’ instead of ‘Safari’) and files that won’t work if they’re located in a folder that is behind basic authentication.
  • Support for subtitles (using the WebVTT standard) can be buggy. For example, styling the titles is limited on iOS and might lead to some weird bugs as well, such as videos not playing, even if their paused property says true. Also: the ‘subtitles’ button in the video interface sometimes randomly decides to turn off.


I could spend this whole article about why these restrictions exist on mobile, and whether they should be there or not.

I won’t. Let’s just say that there are some good reasons why you don’t want to have autoplay video on mobile (think sleazy advertisements) and some good reasons why you do (that wonderful multimedia project that you want to build). Instead of pointing fingers, let’s look at possible solutions.

First of all: there doesn’t exist one simple and easy solution that will fix all of these problems. There are some stable workarounds and others that are more experimental.

  • One solution to the autoplay problem is to only use one single video element and change the source instead of creating a new element. Then, you can ‘save the first click’ and use the event handler to switch between sources. You could even fade the video out, then change the source, then fade in again to have a slightly less clunky transition between two videos. I’ve created an example here (try it on your iPad!). This is a decent solution, but there are a few disadvantages. One of them is that switching still takes quite some time, i’ve timed it to around five seconds or so. Especially if you want to have smooth transitions (such as in a scroll story), this might be unacceptable. Also, this method doesn’t fade audio in and out. Remember that this solution won’t fix problem #2 and #3.
  • Another autoplay solution, especially applicable to audio, is using audio sprites. Instead of having different audio files you stitch them all together in one big file and move the current time. Another decent solution, but this takes a lot more work and overhead, and is probably unusable for video because of the file size. Also, you can still only play one sound at the same time.
  • Yet another autoplay solution, only applicable for audio, is to use the Web Audio API. Here’s an article about how to use it on iOS. Unfortunately the Web Audio API is not supported on any version of Internet Explorer and the stock Android Browser (Chrome for Android does support it), so you need to use other solutions for those browsers. You could try using something like Howler.js to make it work on all platforms.
  • A more experimental approach is to use a Javascript video decoder and play the video in a <canvas> tag. This actually works and, in theory, solves all three problems. There are a few big drawbacks though. The audio track doesn’t play at all, the browser needs to download the complete file first and, because it’s such an experimental technology, you might run into problems that are difficult to debug. Also, because the decoding is not hardware accelerated (native video is) this can be too demanding on older devices and result in choppy playback. There’s a decoder for MPEG1 (larger files, but better performance), and one for MPEG4 (smaller files, but buggier with slower performance).
  • One method pointed out to me by Daan Louter from the Guardian is crossfading a couple of JPEG files in and out. This works especially well if you don’t have a lot of movement in your ‘video’.
  • Don’t rule out the honourable Animated GIF. It tackles all three problems, but there are some obvious downsides. No audio again, and GIF is a very limited format. You can’t have more than 256 colours, and longer files of higher resolution tend to get really huge (think dozens of megabytes) pretty quickly. But for some usecases, that might not be a problem.

Rethinking the problem

Another solution is to completely rethink the app. Video and audio might be problematic, but why use them at all? Instead of using video to give the user a nice experience, maybe you can get the same thing while using CSS animations or the <canvas> tag.

The elephant in the room is of course going native. All of these problems don’t exist when you’re building an Objective-C / Swift (iOS) or Java (Android) app. But going native brings it own problems, including the need to develop three times if you want to reach the widest audience (iOS, Android and web for desktop), the loss of easy sharing using URLs, the hassle of going through the App / Play store and the fact that mobile developers don’t come cheap.

When all else fails, there’s always the obvious and easiest solution: use click-to-play video when possible, and still images when there’s no other option. But it’s a bit sad that mobile users will get a watered-down version of the desktop experience.

In the end it all comes down to what you really think is important and which tradeoffs you’re willing to take.

Do you have any other solutions or workarounds? Add them in the comments.

A proposal for a perfect CMS

Leonardo’s Vitruvian Man, showing the ideal proportions for an adult male.

Every web developer, and this includes yours truly, has at some point in their career either deployed, customised or written a CMS.

And again, and again. And then probably a few times more.

Wikipedia lists over 230 CMSs. There are many, many more. It’s not just the general-purpose ones like WordPress or Drupal: there are also countless CMSs written for specific sites, some based on ‘rapid prototyping frameworks’ like Laravel, Django or Ruby on Rails.

And yesterday i was finding myself building a new CMS yet again. I’m rebuilding my projects page, and i needed some kind of data entry system. Obviously i could try to fiddle with custom fields in WordPress (the CMS the rest of the site uses), or i could simply use something like CSV as a ‘database’, but those solutions seemed to be either inadequate or clunky.

So here i was, building yet another CMS.

This doesn’t sound like fun. So that’s why i’ve been thinking about how it would be if we just had one CMS which would, obviously, be perfect. The perfect CMS, or PCMS, for short.

This is how it would work.

Separation of concerns

First of all: complete separation of concerns for data entry (the ‘admin’ part) and data output (the ‘site’ part).  Both entry and output should be in a structured format, so reuse is easy.


Data entry should consist of two parts: schema definitions for ‘content types’, and the entry process of the actual content.

Imagine a blog post or a news article: it has a few properties that are common everywhere (title, date, author) and properties that are really specific for a certain site (rating for a movie review site, list of ingredients for a recipe site, etcetera).

In PCMS the first step, before actually entering any content, would be to define these schemas. Most of the systems that i know choose one of two approaches. Either the schema is tied to the system, like in WordPress where the only option for non-standard data is to use ‘custom fields‘. The other option is defining it in application-specific code or a data model, like in Django or Ruby on Rails.

In PCMS, you would use something like JSON Schema on steroids. Instead of just defining basic types (integer, string, etc), you could also define more specific content types like ‘video’, ‘markdown text‘ or ‘image gallery’.

Aside from the content type, you could also define constraints: simple ones like a maximum length for a title, but also ones that are more advanced. Imagine an ingredient type that can be linked to a list of ingredients, maybe pulled from a source like Wikidata, so you can automatically calculate total calories and know if the recipe is gluten-free.

The PCMS schema definition is equivalent to how ‘document-orientated schemaless NoSQL‘ databases like CouchDB or MongoDB operate. It’s not like those databases are completely void of structure, it’s just that it’s very easy to change structure without having to rethink your whole database.

Another difference would be that the creation of schemas happens in the CMS. PCMS could use a simple JSON text editor, but given that this is a perfect system it should be easy for non-technical editors as well.

After defining schemas entering content will be significantly easier. PCMS knows what kind of data you want to enter, so the editor can be completely tailored for its purpose. No fields that you don’t need: if you’re editing a recipe the editor knows that an ingredient list is something different than a simple bullet list. The editor part might be close to how Sir Trevor JS works.

Because everything is JSON, queries would be easy. Imagine being able to run complex MongoDB or ElasticSearch-like queries on all content in your website. ‘Give me all recipes that have chocolate as an ingredient, contain a video, and are written by my favourite chef’ would be a piece of cake.


To show the content in a browser you wouldn’t need to learn a new template language with all its weird commands and quirks. Instead, PCMS would offer you a read-only JSON REST API that just returns the content. It would be up to you to choose the technology stack for developing the actual site/app/whatever.

Imagine that you can simply curl and get a JSON response back that shows you the content.

The advantages of such a system are obvious: if you’re building a native app, you would probably want to use the OS native controls for performance reasons. If you’re building a web site, you can just use any HTTP library and template system you like. Client-side only? Use React or Angular. Server-side? Use PHP with Twig templates.


Obviously PCMS also has all the basics you expect from a CMS: user logins with a role system (so your intern can’t delete all posts by accident), caching (so it’s speedy) and proper security (so your site can’t be hacked).

It would be tempting to provide PCMS with a default templating / theming system, but this might give people the false impression that it is the only system they can use. Instead of that, PCMS should just provide a JSON API, nothing more.

To make sure PCMS gets as widely used as possible it should be open sourced under a license like the GPL or MIT. I guess there would be enough interested companies to fund development and support.

Considering technology: PHP / MySQL would probably be a good choice because it’s so widely deployed and even people with basic server knowledge know how to deploy CMSs like WordPress. But i guess you can’t have everything, and maybe something like Node.js or Python would be more apt for this system.

Making it real

PCMS doesn’t exist, but many of the concepts mentioned in this article do. Drupal has something called the Content Construction Kit which brings ‘custom fields’ to a new level. The semantic web and linked open data would provide the linking between ‘ingredient’ and the list of ingredients. The separation of concerns backend/frontend with a JSON API is implemented in countless purpose-built applications. Google Spreadsheets combined with Tabletop.js is surprisingly adequate for implementing custom content types with a custom frontend.

But as far as i know, the combination of all those elements in a single, user-friendly system doesn’t exist. Drupal, even with the CCK, is still primarily used for old-fashioned websites. Semantic web and linked open data are fascinating concepts, but they don’t work in the real world. Purpose-built applications are, well, for a very specific purpose.

And i guess you can imagine the disadvantages of using Google Spreadsheets as a CMS.

Maybe the combination of a CMS that is both general enough for most content-centric sites, but also flexible enough for very specific use cases is impossible and automatically leads to scope creep and overengineering.

But maybe, just maybe, shouldn’t we give it a try?

Comments on this article were also posted on Hacker News.

The Nonsensical Shirt Generator


You’ve seen them. Those shirts with nonsensical texts like “Oil Service / US 1975 / Beach Club no. 42901”. Maybe your mother used to buy them for you. Or even worse: you were the one handing over the cash.

Sorry, but this needs to stop. Those shirts are uninspired, bland and extremely boring. Read this comic and admit that they’re right.

To say goodbye to these shirts you may now create these shirts yourselves. In infinity, on the internet. Yes, i’ve built another generator.

De quantified self van de zware cameratas

iPhone 5s, gefotografeerd met mijn Canon 500D SLR (134g)

Canon 500D SLR in cameratas, gefotografeerd met mijn iPhone 5s (1736g)

Ik was een maand in Japan met mijn vriendin. Heel tof, vooral omdat mijn naam ‘ja’ betekent in het Japans. Anyway, als je in Japan bent maak je natuurlijk van alles foto’s. Vroeger had je dan zo’n grote spiegelreflexcamera. En die heb ik nog steeds. Maar zowel mijn vriendin als ik hebben een iPhone waar we ook foto’s mee maken. Drie camera’s dus.

Het combineren van de foto’s van de drie bronnen leverde 3.033 foto’s op. Een beetje veel om allemaal aan de buren te laten zien, dus we hebben een selectie gemaakt van 203 foto’s. Wat ik dan interessant vind: welk apparaat maakt de meeste selectie-foto’s?

Ik schreef een scriptje en ik denk nu dat ik echt nooit meer die loeizware en onhandige SLR ga meenemen. Aantal foto’s die ik ermee heb gemaakt: 1.634. Mijn vriendin maakte 913 foto’s met haar iPhone 6.

En dan de selectie: slechts 57 SLR foto’s zitten in de selectie (28%), bijna evenveel als de foto’s die ik met mijn eigen iPhone nam: 42 (21%).

Van de iPhone foto’s van mijn vriendin kwamen er 104 in de selectie. Meer dan de helft! Een iPhone 6 weegt 129 gram. Mijn cameratas met inhoud bijna 2 kilo.

Voor de (semi)-professional maakt een SLR nog steeds betere foto’s, maar hoe lang nog? Die vakantiekiekjes kan ik ook wel maken met mijn telefoon. Die loeizware camertas (15 keer zo zwaar als de iPhone) blijft voortaan thuis.

Recept: Iers sodabrood


Zo bak je een brood: kneden, laten rijzen, nog een keer kneden op een met bloem bestoven aanrecht. Wat een werk!

Wat lang niet iedereen weet is dat je ook brood kan bakken zonder al dat gekneed en gerijs. Het brood wat we in Nederland eten is vaak gistbrood, maar gist is niet het enige wat je kan gebruiken om brood te laten rijzen. In Ierland gebruiken ze baking soda (zuiveringszout) om het traditionele soda bread te maken. Supereenvoudig: dit brood kun je (met baktijd!) in 45 minuten maken, en dan heb je fantastisch knapperig geurig vers brood.


  • 250 gram bloem
  • 250 gram volkorenmeel
  • 100 gram havermoutvlokken
  • 1 theelepel zuiveringszout (baking soda, koop je bij de Turk voor weinig of bij de apotheek voor veel)
  • 1 theelepel zout
  • 25 gram roomboter in kleine stukjes
  • 0,5 liter karnemelk


  1. Verwarm de oven voor op 190 graden. Spreid bakpapier uit over een bakplaat.
  2. Meng de bloem, het meel, de havermout, het zout en het zuiveringszout in een grote beslagkom.
  3. Wrijf de kleine stukjes boter door het mengsel. Dit is het meeste werk: zorg ervoor dat je geen klontjes krijgt.
  4. Voeg de karnemelk toe en meng voorzichtig met een mes. Meng het mengsel verder voorzichtig in de kom. Absoluut niet kneden!
  5. Stort het brood op de bakplaat en maak er een ronde vorm van.
  6. Snij een ondiep kruis in het brood. Traditioneel zorgt dit ervoor dat de elfjes uit het brood komen, maar het is ook goed voor het doorbakken van het brood :)
  7. Bak het voor 30-35 minuten in de oven.
  8. Check of het brood hol klinkt als je er op klopt. Als dat niet het geval is: draai het om en bak het nog voor een paar minuten.

Dat was het! Zorg ervoor dat je een schone droge theedoek over het brood legt, zo blijf het lekker vers voor ongeveer drie dagen.

Om te variereren kun je de karnemelk vervangen met 500g (volle) yoghurt. Het brood krijgt dan een cake-achtige structuur, maar is net zo lekker!

Dit artikel is gebaseerd op dit recept van BBC Good Food.

Help a coder, even if you can’t code

Photo by Sebastiaan ter Burg  / CC-BY
Photo by Sebastiaan ter Burg / CC-BY

“I love to help with your project, but i can’t code.”
“This hackathon sure sounds cool, but i can’t program.”
“That competition sounds awesome, but i ‘m not a coder.”

Sounds familiar? I’ve heard this question dozens of times the last couple of years: non-coders who want to help with a technical project, but are afraid to do so, because they can’t code.

That’s a pity, because i feel there are many ways non-coders can help coders and work to create awesome things together.

So, how can you, as a non-programmer help a coder?

Here’s a dirty little secret that many people don’t know: coders actually don’t code that much. I’ve seen various numbers, but in my own experience ‘real’ coding, like typing code on a keyboard in a text editor, takes only between 2 to 3 hours during an average 8-hour workday.

So what does a coder do in those other 5 to 6 hours? Here are some things a typical web developer might do:

  • Discuss the interface design with the designer.
  • Test the site on a variety of browsers and devices (tablet, phones, desktops, etc.)
  • Tweak the design where it doesn’t really work in the browser.
  • Write bug reports.
  • Reproduce bugs and confirm with the bug reporter that’s the problem.
  • Communicate about feature requests and bugs.
  • Google for error messages and how to fix specific bugs.
  • Add test data to a CMS to check if it works.
  • Clean up an Excel or CSV dump with data, or import it in a database.
  • Sketch out possible solutions for a user story.
  • Decide which task is most important.
  • Write blog posts, send out tweets, make screenshots of the product.

See a pattern here? Indeed, all of these activities don’t require writing a single line of code. Of course, not all of these tasks might easily be done by somebody else, but i bet there are a few of these you can help out with.

Here are some examples:

  • Flesh out user stories that exhaustively detail a specific function or workflow of the product.
  • If you know how to use Photoshop / Illustrator: create and/or tweak the design.
  • If you don’t: do same paper prototyping to help with the interface design.
  • Test the product in all possible browser/OS combinations and write bug reports.
  • If you’re handy with Excel: clean up the data and export it to a exchangeable format (e.g. CSV).
  • Write / blog / tweet about the product.
  • Create a video / graphic / powerpoint about the product.
  • Setup a blog / site / Facebook page showcasing the product.
  • Do the paperwork for the competition / hackathon / startup.
  • Do some fast and simple user testing.
  • Track usage of the product using an analytics package.
  • Communicate with the client / user / designer.
  • Fill the database / CMS with ‘real’ content.
  • If you can’t program but do know how to use the command line: setup servers, hosting and deployment procedures.
  • Find the best and/or cheapest hosting / catering / workspace.
  • Prioritise and assign tasks.

Easy, right? Hopefully, the next time you’re asked to participate in a technical project, you’re not afraid to decline because you can’t code. And, after reading this article, you still don’t know what to do: coders love free coffee and a massage at times as well ;)

If you have more suggestions on what you can do as a non-coder: post a comment or send me a tweet.

NPO moet open kaart spelen

Het is vervelend om gelijk te krijgen. Twee jaar geleden ging ik weg bij de VPRO: een omroep waar ik vier jaar lang als ontwikkelaar had gewerkt aan websites als HollandDoc, Geschiedenis24, en 3voor12. Ik had toen namelijk al het idee dat het een beetje een aflopende zaak was, die omroepen.

Hoe dat komt? Drie letters: NPO.

NPO en het internet

Henk Hagoort werd in 2008 bestuursvoorzitter van de Stichting Nederlandse Publieke Omroep. Sindsdien is er een hoop gebeurd. Er werd €100.000 euro betaald aan de Nederlandse Postduiven Organisatie voor de domeinnaam, Nederland 1,2,3 werden NPO 1,2 en 3 en langzaamaan werd duidelijk dat de NPO meer was dan alleen maar een organisatie voor ‘het bevorderen van de samenwerking en cohesie tussen de landelijke omroepen‘.

Ooit was de NPO er alleen als koepelorganisatie voor de omroepen. De ambities van Hagoort en mede-bestuurslid Shula Rijxman liggen een stuk hoger: de omroepen opdoeken en NPO de baas maken.

Nergens zijn die ambities zo duidelijk als bij het NPO-internetbeleid. Het internet, dat nogal oncontroleerbare medium wat eindeloze mogelijkheden biedt voor het verspreiden van audiovisuele producties. Dat blijkt een probleem te zijn voor NPO, aangezien het internet niet te controleren is. Op het internet kun je moeilijk een netmanager neerzetten, zoals bij de radio en televisiekanalen.

Helaas voor NPO zijn er op het internet niet een beperkt aantal zenders. Daarom bedachten ze zelf maar iets: het zogenaamde ‘aanbodkanaal‘: een kunstmatige schaarste van het aantal websites voor de omroepen. Elke nerd kan u vertellen dat zoiets flauwekul is: op het internet is er onbeperkt ruimte, en je hoeft niet te bedelen voor zendtijd.


Afgelopen woensdag kondigde NPO aan dat ze hadden ontdekt dat het internet nog veel minder ‘aanbodkanalen’ had dan ze dachten: slechts 50.

Wat dat betekent? Heel simpel: honderden sites moeten verdwijnen. Projecten als NPO Doc (voorheen HollandDoc) en NPO Geschiedenis (voorheen Geschiedenis 24) die al bijna twintig jaar goed draaien worden rücksichtlos de nek omgedraaid. Oh, en wil je graag video op je website? Dat mag niet, want daar hebben we één site voor: De sites van de omroepen mogen wel online blijven (want van eigen ledengeld), maar dat is vooral ‘voor de ledenbinding’.

De grap is natuurlijk dat die hele ledenbinding ontstaat door de producties die er gemaakt worden en vertoond worden op de sites. Mensen kennen de VPRO van Rembo en Rembo, de KRO van Boer Zoekt Vrouw en de VARA van De Wereld Draait Door. Die producties mogen niet meer worden aangeboden op de eigen websites want ‘het terugkijkaanbod van het archief moet centraal’ (Shula Rijxman in de Volkskrant).

Waarom dat centraal moet? In het eerder gelinkt Volkskrant-stuk wordt genoemd dat NPO “niet kan excelleren, omdat het aanbod zo versnipperd is”. Dat versnipperde aanbod is een feit op het internet: niet iedereen zit op dezelfde platforms. Dan kun je hopen dat iedereen naar jou toekomt, maar je kunt het beter omdraaien: wees daar waar de mensen zijn.

Daarnaast eist de NPO van de omroepen dat ze “meer waarde toe moeten voegen aan de bestaande sites en apps”. Beetje lastig om ‘waarde’ toe te voegen aan een website als je er niet je eigen video’s op mag zetten.

En waarom mogen omroepen dan “niet zomaar sites in het leven roepen”? Volgens de NPO is dat omdat er een grote bedreiging is: “het internet is oneindig.” Ik zou zeggen: juist dát is de kracht van het internet.

De NPO spreekt zichzelf tegen: al het videoaanbod moet centraal, maar Rembo en Rembo van de VPRO wilden ze helemaal niet hebben. Als de VPRO het dan maar op de eigen site zet mag dat ook niet. Wat wil de NPO nou eigenlijk?


Dat al die sites moeten verdwijnen is doodzonde, maar wat mij misschien nog wel meer steekt is dat er vanuit NPO op geen enkele manier een visie is hoe dit beleid bijdraagt aan de missie van de publieke omroep. Wij, de mensen die de publieke omroep betalen, moeten het bij elkaar puzzelen uit oneliners van Shula Rijxman en Henk Hagoort in de krant. Op de site van NPO zelf staat vooral newspeak en bobotaal. Waarom NPO Doc weg moet, waarom programma’s van de omroepen niet op Netflix of YouTube mogen, echt heel duidelijk is het allemaal niet.

Het verhaal is anders dan wat de NPO probeert te vertellen in wollige oneliners: ze zijn doodsbang dat ze irrelevant gaan worden door de opkomst van Netflix en YouTube. ‘Internet-born’ mediabedrijven als Buzzfeed of Huffington Post weten heel goed hoe ze daar mee om moeten gaan: wees daar waar de mensen zijn. Zit je publiek op Facebook? Zet je video’s op Facebook. Zit de jeugd op Snapchat? Zet je nieuws op Snapchat.

Zo kijkt NPO er niet naar. Misschien heeft het er iets mee te maken dat de top slecht één lid heeft dat Abraham nog niet gezien heeft. Het bijna veertigjarige hoofd financiën werd bij haar aanstelling door Shula Rijxman “een jong talent” genoemd. Misschien dat het eens tijd wordt dat er bij NPO mensen aan de top komen die niet zijn geboren toen Swiebertje nog op televisie was.

Alle ballen op NPO

De strategie in Hilversum is, geheel tegen de tijdsgeest in, om alles naar zichzelf toe te trekken: op de eigen portal. NPO denkt te kunnen winnen van grote internetbedrijven als Google en Netflix met eigen platforms, of desnoods op een, met de commerciële omroepen opgezet, zieltogend platform als NLZiet.

Wat de NPO lijkt te vergeten is dat de producties van de publieke omroepen niet van hen zijn, maar van de Nederlandse belastingbetaler. Die heeft er geen enkel voordeel bij dat het aanbod maar op één platform aangeboden wordt. Als belastingbetaler wil ik gewoon de content zien waar het mij het beste uitkomt, dus op YouTube, of op de sites van de omroepen, of hier, op mijn eigen blog, als embed.

Het embedden van NPO-producties is, sinds de lancering van eind 2013, niet meer mogelijk. Wederom kan NPO niet uitleggen waarom dat beter is. NPO meldt dat het “uiteraard nog wel mogelijk om te verwijzen naar de locatie van de video’s van de NPO via bijvoorbeeld social media”. Natuurlijk! Want waarom zou ik een video willen bekijken op YouTube of een blog als het ook gewoon kan op de enige plek voor producties van de publieke omroep:


Kleur bekennen

Ik vind dat de NPO kleur moet bekennen. Zeg het gewoon: wij willen af van die suffe omroepen en de baas zijn op televisie. Dat internet is leuk voor als je de uitzending terug wilt kijken, en verder doen we er maar niks mee, zeker niet als je publiek van onze portal weglokt.

Laat ik daar dan iets tegenin brengen: misschien klinkt het achterhaald en archaïsch, maar ik vind de ouderwetse publieke omroep best een goed idee. Crowdsourcing avant la lettre. Iedereen betaalt een vast bedrag per jaar, daarvoor krijg je een supergevarieerd groot aanbod van televisie, radio en internet. Het is publieke financiering op z’n best. Als je maar genoeg mensen vindt kan iedereen een omroep beginnen. En ondanks dat ik moet kotsen als ik Pownews op televisie zie ben ik toch blij, want dat is precies waar de publieke omroep voor is: iedereen een stem geven.

Best een tof systeem, toch? Iedereen betaalt een beetje geld, en we maken fantastische radiodocumentaires, briljante televisieprogrammas, vernieuwende websites. Voor iedereen te bekijken. Gratis. Zonder dat je pornobanners hoeft te ontwijken van de Pirate Bay, of eeuwig moet zoeken op YouTube, of een tientje per maand moet betalen voor Netflix. Dat het daar toevallig ook op staat en geld oplevert voor nieuwe producties is dan mooi meegenomen.

Nee, als de publieke omroep verdwijnt vergaat de wereld niet, en mensen stoppen niet opeens met het maken van nieuwe producties. Maar het is wel jammer dat we plekken hadden waar jonge makers ideeën konden uitproberen. Organisaties waar mensen konden experimenteren. Je weet wel, omroepen, dat idiote idee uit het verzuilde Nederland van de jaren vijftig. En ook nog een van de goedkoopste van Europa.

Dat is nou precies het verhaal wat we niet horen van NPO. Het enige wat we horen is dat er een hoop weg moet, want dat is beter. Maar tot ze duidelijk kunnen maken waarom dat beter is ben ik voor de ouderwets goede Nederlandse publieke omroep.

Naschrift: ook Erwin Blom (ex-VPRO) en Roeland Stekelenburg (ex-NOS) schreven over dit onderwerp onder de titel Vier redenen waarom het online NPO-beleid kansloos is.

Het lijstje, editie 2014

Ja, daar zijn we weer. Weer een jaar voorbij, dus het kan niet anders dat ik hier (voor de 11de keer inmiddels) een lijstje met de beste muziek presenteer van het afgelopen jaar.


Maar eerst iets anders. Op 29 november overleed een van mijn grootste muzikale helden: Luc de Vos, de zanger van Gorki, from Belgium baby. Ik zeg niet snel dat ik fan ben van iemand, maar van de Vos en zijn band was ik dat zonder enige twijfel. Sinds Eindelijk Vakantie (2000) volg ik zijn werk, en eerlijk gezegd heb ik zelden een slecht Gorki-nummer gehoord. Sterker nog, ik durf wel te stellen dat er geen betere muzikant was binnen het Nederlands taalgebied. In maart 2014 zag ik hem nog fantastisch spelen in de Helling in Utrecht.

Het enige positieve is dat zijn muziek voor eeuwig zal blijven. En misschien dat er door zijn dood meer mensen zijn muziek ook zullen horen, en dan ontdekken dat hij zoveel meer heeft gemaakt dan alleen Mia.

Goed, genoeg nare zaken. Door naar het lijstje.

In tegenstelling tot 2013 vond ik 2014 een beetje tegenvallen. Weinig wow, veel ‘best aardig’. Alles na nummer vijf in dit lijstje valt in beetje in die laatste categorie.

Achter elk album staat een Spotify-icoontje wat naar (verrassing) het volledige album op Spotify verwijst.

  1. The War on Drugs – Lost in the Dream
  2. Cloud Nothings – Here and Nowhere Else
  3. Spoon – They Want My Soul
  4. Run the Jewels – Run the Jewels 2
  5. Future Islands – Singles
  6. Caribou – Our Love
  7. Aphex Twin – Syro
  8. Toumani Diabaté – Toumani & Sidiki
  9. Marissa Nadler – July
  10. How To Dress Well – “What is this heart?”
  11. St. Vincent – St. Vincent 
  12. Arca – Xen 
  13. Metronomy – Love Letters 
  14. Röyksopp & Robyn – Do It Again 
  15. D’Angelo – Black Messiah 
  16. Lykke Li – I Never Learn 
  17. Sharon Van Etten – Are We There 
  18. Grouper – Ruins 
  19. FKA twigs – LP1 
  20. Eno & Hyde – High Life 

Zoals elk jaar heb ik ook weer een YouTube mix gemaakt met de beste liedjes van bovenstaande albums, inclusief de liedjes waar de albums het niet van gehaald hebben:

Dan hebben we ook nog het beste optreden van het afgelopen jaar. Dat was uiteraard het briljante optreden van Future Islands in de Melkweg. De sublieme performance bij David Letterman (in de mix boven) was nog maar een voorproefje, het optreden was nog veel opzwepender. Bij het laatste nummer werd zelfs gestagedived en klom iedereen het podium op:

En last but not least: de heruitgaves. Als rereleases ook zouden meetellen voor het lijstje zou met stip bovenaan de Nigeriaanse disco-funk artiest William Onyeabor hebben gestaan met de heruitgaves van zijn  synthesizer muziek uit de jaren zeventig en tachtig zoals het briljante When the Going is Smooth & Good:

Naast Onyeabor was een andere noemenswaardige heruitgave uit de jaren tachtig die van de Canadese crooner Lewis:

Dat was het voor dit jaar. Mocht u nog steeds hongerig zijn: bekijk dan eens de lijstjes van The GuardianBest Ever Albums, Metacritic, Tiny Mix Tapes, Drowned in Sound, Pitchfork en Sander Spek. En voor hen die graag in het verleden duiken heb ik ook nog lijstjes van 20132012201120102009, 2008, 2007, 2006, 2005, 2004 en 2003.

Een spetterend 2015 en tot volgend jaar!

HOWTO backup your Telegram chats (if you don’t fear the terminal)


Considering that WhatsApp was sold in February 2014 to Facebook for a petty $19 billion dollars you might have looked around for alternatives. Currently the most promising messaging client is Telegram, an alternative mostly financed by Pavel Durov, who ironically founded Facebook’s biggest competitor in Russia: VK.

Now some people might suggest switching from WhatsApp to Telegram is simply trading one evil (Facebook) for another (VK). However, Durov has nothing to do with VK anymore and the people behind Telegram say they respect your privacy. Telegram is mostly open source as well. Time will tell if Telegram can stay true to their promises.

Anyway, one missing feature (the only one, in my opinion) is the ‘export chat’ option that is available on WhatsApp. I’m not that interested in transferring messages between devices, but i do think it’s important to have an export of your digital history, whether it’s e-mail, instant messaging or your tweets.

There are multiple feature requests for the various (semi) official apps, but currently there doesn’t seem to be a simple solution.

Anyway, i found a hack, but unfortunately it’s pretty technical and not for those afraid of the command line. But hey, it’s better than nothing.

We’re going to use a command line Telegram client called tg. Unfortunately it’s only for Linux and Mac systems.

Here are the steps to make an export of your chats:

  1. Open up a Terminal (iTerm didn’t work for the backup on my machine) and follow the instructions to install tg for your operating system. On my MacBook with Yosemite i needed this ugly hack to properly install the brew dependencies.
  2. Now run tg (bin/telegram-cli) and follow the steps to get an activation code.
  3. Run the command contact_list to get an overview of all your contacts.
  4. Use the command history to get the chat log. The first argument is the name of your friend (note that tg offers tab completion!), the second one is the number of messages. There doesn’t seem to be a setting for ‘all messages’ so simply pick a high number, e.g.:
    history My_Friends_Name 10000
  5. tg doesn’t offer a way to export the history to a text file, so you either need to copy-paste the stuff from the terminal or save the terminal output to a file (the last option works best for the OS X Terminal).
  6. Note that history also works for groups. There is no groups_list command, but using dialog_list will also show groups.
  7. Repeat for every user and/or group you want to export.

I know, this is all pretty clunky. Hopefully the people at Telegram and/or the coders who create the clients will create a better export option in the future.