Apple’s Safari on iOS is pretty cool. It has pretty good support for HTML5 audio and video. Unfortunately there’s one big quirk that makes it almost impossible to do anything useful with it. Why? They disabled autoplay. According to the docs this is because:
(…) the user may be on a cellular network and be charged per data unit, preload and autoplay are disabled. No data is loaded until the user initiates it.
In theory, this sounds great. Who doesn’t detest autoplaying advertisements on sites? Unfortunately this ‘feature’ has a few side-effects that cripple the general use of HTML5 audio/video. The autoplay property isn’t the only thing that’s disabled. Playing a HTML5 media element is not possible at all without an user action.
What does this mean in practice? Consider a piece of HTML like this:
<script>
function play() {
var a = new Audio();
a.src = 'http://example.com/audio.mp3';
a.play();
}
</script>
<button onclick="play()">play</button>
This works on iOS because the play() function is initiated from a user action (the click on the button). Now, consider something like this:
<script>
function play() {
var a = new Audio();
a.src = 'http://example.com/audio.mp3';
a.play();
}
setTimeout(play, 3000);
</script>
This doesn’t work on iOS. The play() method is called, but nothing happens because the function is not called from an user action.
Now, you might say, why would you ever want to play a video from a timeout? This example is very simplistic, but consider you’re writing a cross-browser media player that falls back on Flash on Internet Explorer, automatically plays the next track in a playlist, etcetera. You want to write clean code, so everything is modulairized, maybe using a tool like RequireJS and a MVC framework.
This means you’re getting lots of asynchronous callbacks, events, AJAX calls and dozens of functions you’re working with. Your original ‘click’ is lost and your cross-browser player doesn’t work on iOS. Bummer.
Or consider a game with sound effects. Every time you hit an enemy you want to play a sound. I suppose you don’t want to let your user click a button when she wants to hear a sound effect.
Of course, if you just want a simple video player for a blogpost you don’t run into this problem. But for virtually all advanced applications you’re going to run into the autoplay bug sooner or later.
Native iOS apps don’t have this problem, and you can actually disable the autoplay ‘feature’ by putting your web app in a native app (using UIWebView) and disabling the UIWebView.mediaPlaybackRequiresUserAction flag.
On Android this isn’t a problem at all. The code above works fine (tested on 2.3.3).
I think Apple has three possible solutions to ‘fix’ this problem:
Prompt the user to enable autoplay, just like with geolocation
Disable the ‘mediaPlaybackRequiresUserAction’ flag when the device is on WIFI
iOS has some pretty decent support for HTML5 audio and video in the Safari browser. For the new 3voor12 site we’re currently investigating how can we use HTML5 video/audio to support the new site on touch devices, such as iOS. Apple’s development site has a nice section on preparing your media content for iOS. However, some of the sections are pretty terse, while they might have big implications on your site.
So, we did some research ourselves, and we like to share it with you here. Note that we tested on both iOS 3, 4 and 5. Any differences are marked in the text.
Autoplay problems
The autoplay property is disabled on iOS, as is the preload property. The reasoning behind this is that users might have a prepaid plan, and pay a large sum for their data transfer on media items. This sounds a bit weird, because no such restriction exists on large images, and AFAIK native apps don’t have this restriction.
A problem with this restriction is that the Javascript play() and load() methods only work on user events, such as a click. Normally this isn’t a problem, but it can be quite tricky when you want to do other things before playing the video. Imagine doing a call to some kind of web service using Ajax and on the callback play the media file. This doesn’t work because the ‘play’ didn’t originate from an user action.
However there’s a hack: when you do a synchronous Ajax call instead of asynchronous (which is the default when using a library such as jQuery) iOS does play the video after the callback. There are two drawbacks to this hack: sync calls don’t work cross-domain (for example using JSONP or CORS) and the browser is ‘frozen’ when the call is active. If your call doesn’t return your webapp is broken, Safari freezes and the user can only exit to home (closing the tab doesn’t work because the browser thread is locked).
The video element on iPhone and iPod Touch
There’s a distinction between using the <video> element on the iPad and the iPhone/iPod. On the iPhone a video always plays full-screen, while on the iPad it’s an element on the page and you can use it on your site like any other HTML element.
Audio in the background
Audio played in an <audio> element keeps on playing, even if the user goes to another app using the home button (provided the app doesn’t play audio itself). Video always stops whenever the user exits Safari. When the user returns to Safari different things happen on iOS 4 and iOS5: on iOS4 the audio keeps on playing, on iOS5 the audio fades out and the user has to press the play button in the web app again.
Playlists
For the new site we want to create auto-playing ‘playlists’ consisting of multiple files. Video and audio can be on one playlist, so for example after a video ends an audio file can start.
The restrictions mentioned above make this tricky on iOS Safari. Automatically playing the ‘next’ video after a media item ended (using the ended event listener on the element) works, apart from iOS 3 where apparently the ‘ended’ event doesn’t trigger.
However, if you’re switching from an audio to a video element the original ‘click’ doesn’t come from the original element and the next item doesn’t start.
There’s a hack: it’s actually possible to put an audio file in a <video> element and vice versa. This provides one hack to counter the autoplay problem on playlists (by playing all audio in a video element). However, it doesn’t allow you to play ‘video’ in the background, which means that on the iPhone the video element always takes over Safari and you can’t play audio and read the website at the same time.
More references
Miller Medeiros has written two in-depth articles pointing out more quirks on HTML5 video/audio on iOS:
Veel websites bevatten een easter egg, die kan worden opgeroepen door de zogenaamde Konami-code. Door een reeks van toetsen in te drukken kan de bezoeker een grapje van de programmeurs ontdekken. Dat kan bijvoorbeeld een filmpje zijn, of een spelletje, of iets heel anders.
Bij VPRO Digitaal zijn we fan van easter eggs en Konami-codes en daarom willen we voor de nieuwe 3voor12 site (die we gaan lanceren op Noorderslag 2012) de hulp inroepen van alle Konami-kunstenaars van de lage landen. Denk jij dat je iets kan met HTML, CSS en Javascript wat anderen niet kunnen? En zou je het gaaf vinden als jouw Konami-code te zien zal zijn op de grootste alternatieve muziekwebsite van Nederland? Doe dan mee met onze Konami-competitie!
Je kunt meedoen tot dinsdag 1 november 2011. Daarna zal een deskundige jury de beste Konami-code selecteren.
Regels:
De inzending
Je dient je code aan te leveren als een zip met minimaal twee bestanden: een index.html en een readme.txt waarin je kort je inzending beschrijft. Zet hier ook je mailadres en evt. Twitternaam en website in. Ascii-art wordt tevens op prijs gesteld.
De ZIP mag maximaal 64 kilobyte groot zijn.
Houd je code leesbaar: gebruik geen tools als UglifyJS. 64 kilobyte gezipt is ruim voldoende voor iedereen
Je code moet geschreven zijn in HTML(5) / CSS(3) en Javascript. Je mag geen gebruik maken van plugins als Flash en Silverlight. HTML5-specifieke technieken als SVG en Canvas zijn uiteraard wél toegestaan.
Je code moet werken op de nieuwste versies van minstens twee van de volgende browsers: Firefox, Safari, Chrome en Internet Explorer.
Je code moet geheel zelfstandig werken zonder libraries als jQuery of Prototype.
De code om de easter egg op te roepen hoeft zelf niet in je code te zitten (daar zorgen wij wel voor
Je mag data gebruiken van andere sites (b.v. de YouTube of Flickr API). Data die je op die manier laadt telt niet mee voor de 64 kb.
Je mag bovenstaande regel niet misbruiken om onder de 64kb grens uit te komen (b.v. door plaatjes op je eigen server te zetten en in te laden)
Jury & selectie
De jury bestaat uit een selectie medewerkers van VPRO Digitaal. Met de jury kan niet worden gecorrespondeerd.
Alle inzendingen worden in principe online gezet op het VPRO Digitaal weblog. De jury kan besluiten een inzending niet online te zetten zonder daarvoor uitleg te hoeven geven.
De jury selecteert uit de inzendingen een top vijf met de beste codes.
Inzendingen die gebruik maken van ‘Comic Sans MS‘ als lettertype zijn bij voorbaat gediskwalificeerd.
De winnende code zal te zien op de nieuwe 3voor12 site.
Mail je code in vóór 1 november (als 1 ZIP bestand) naar:
Op 19 september bezocht ik Kings of Code, de conferentie voor web developers. Het aardige aan Kings of Code is dat het complete spectrum aan web development aan bod komt en dus niet alleen een bepaalde programmeertaal of een bepaald framework. Hieronder een kort overzicht van wat ik op deze dag gezien en gehoord heb.
Understanding, Choosing & Instrumenting NoSQL
Tim Anglade werkt voor Cloudant en is de maker van NoSQL Tapes, een project met interviews en case studies over NoSQL-projecten. Hij gaf een uitgebreid overzicht van verschillende (open source) NoSQL-producten: CouchDB, Couchbase, BigCouch, Cassandra, Riak, MongoDB, Redis, Neo4j; besprak ze aan de hand van de volgende eigenschappen: distribution (Dynamo-style, master-slave, master-master), data/query model en disk structure; en gaf voor elke database een ideaal scenario. Zie de slides voor het overzicht:
Ik vond het opvallend dat hij NoSQL-oplossingen ziet als technologie waar je pas naar zou moeten gaan kijken als relationele databases je in de steek laten en je echt niet meer met een RDBMS toe kan. Onze ervaring met CouchDB is dat een NoSQL-oplossing ook gewoon allerlei wenselijke features kan hebben die je bij relationele databases niet vindt, zoals bijvoorbeeld de REST API van CouchDB. Aan de andere kant was het ook goed om een verhaal te horen dat niet uitsluitend de positieve kanten van NoSQL behandelde.
Declarative Applications
Steven Pemberton (CWI, W3C) is een oude rot op het web. Hij stond aan de wieg van de programmeertaal ABC (een voorloper van Python) en is tegenwoordig o.a. voorzitter van de XHTML2 en XForms Working Groups van W3C.
Na een interessante geschiedenisles over de kosten van computers en programmeurs door de jaren heen trekt Steven de conclusie dat programmeertalen traditioneel ontwikkeld zijn om zo efficiënt mogelijk door computers verwerkt te kunnen worden, omdat computertijd vroeger enorm duur was in vergelijking met het loon van een programmeur. Tegenwoordig is dat precies andersom: goede programmeurs zijn niet goedkoop, maar computers wel. Maar zijn programmeertalen daar op aangepast? Volgens Steven niet, of in ieder geval veel te weinig.
Het gros van het programmeerwerk wordt nog altijd in procedurele programmeertalen gedaan: de programmeur vertelt de computer stap voor stap wat er moet gebeuren. Volgens Steven is dé manier om programmeurs efficiënter te laten werken om ze gebruik te laten maken van declaratieve programmeertalen: specificeer wat je wil dat er gedaan wordt, niet hoe.
In beginsel ben ik het helemaal met Steven eens: het is prachtig als je declaratief kunt specificeren wat er moet gebeuren en de computer laat uitdokteren hoe dat precies moet gebeuren. Helaas illustreert Steven zijn punt met voorbeelden in XForms. De user interfaces van de voorbeelden zijn wat Spartaans (duidelijk een academicus, die Steven) en XML is naar mijn idee ook niet de meest leesbare vorm voor code, dus de wow-factor was wat laag. Daarnaast waren zijn voorbeelden dusdanig compact dat waarschijnlijk niemand in de zaal dacht: “Goh, dat levert een hoop winst op! Ik ga nooit meer iets met JavaScript doen!”
Het concept is prachtig, maar het is nog even wachten op degene die declarative programming naar de massa gaat brengen.
Jeroen van Dijk (CTO Enrise) gaf een mooi overzicht van hoe je ‘application accelerator’ Varnish Cache kunt gebruiken om de performance van je website te verbeteren. Hij liet onder andere zien hoe je performance kan verbeteren door cookies te laten negeren door de cache en hoe de website van AutoTrack.nl gebruik maakt van Edge Side Includes om verschillende onderdelen van de pagina voor verschillende periodes te cachen. Hierbij wordt de pagina dus eigenlijk samengesteld door Varnish (who needs a CMS?) en dat gaat toch wel wat verder dan een simpele reverse proxy (waar je Varnish overigens ook prima voor kan gebruiken).
Stephen Nelson-Smith (Atalanta Systems, Opscode) kwam ons vertellen waarom je je infrastructuur eigenlijk net zoals je software wil behandelen. Is een extra server toevoegen aan je setup een hoop werk? Is het lastig om een testserver te vervangen? Niet als je het installeren en configureren van een server en z’n applicaties automatiseert in code. Die code kun je testen, je kunt er versiebeheer op toepassen en je setup wordt makkelijk ‘repeatable’. Een server toevoegen aan een cluster wordt dan ineens een eitje.
En dat doe je dan uiteraard met Chef als het aan Stephen ligt. Chef voed je met ‘recipes’, wat feitelijk gewoon stukken Ruby-code zijn die gebruik maken van de Chef API. (De Chef Server gebruikt trouwens CouchDB als backend.) De vraag waarom je Chef zou moeten gebruiken in plaats een concurrerend product als Puppet (of CFEngine?) werd helaas ontweken.
Het zou naar mijn idee in beginsel best een goed idee zijn om de setup van een aantal applicaties bij de VPRO in een dergelijk systeem te vangen, maar het nadeel is dat onze infrastructuur niet erg homogeen is. Als al je machines (test, acceptatie en productie) bij Amazon in de cloud staan is dit waarschijnlijk goed werkbaar, maar als je lokale testserver een VMware image is en je acceptatieserver in een omgeving met NFS-shares staat, dan wordt het al snel een stuk lastiger.
Het zou interessant kunnen zijn om hier eens verder over na te denken en het zou misschien zelfs een argument kunnen zijn om een OTAP-straat te homogeniseren: het wiel niet opnieuw hoeven uitvinden voor elke stap in het proces kan een hoop tijd schelen en je documenteert ook indirect je infrastructuur.
Stephen Nelson-Smith gelooft niet in het publiceren van slides:
Web API’s World
Michele Zonca (Mashape) geeft een vliegensvlug overzicht van de staat van web API’s. SOAP was te complex, hoe REST opkwam, dat dat geen standaard maar een stijl is, dat een hoop mensen het verkeerd doen, het gedoe rond verschillende authenticatie-mechanismen en hoe je er geld mee zou kunnen verdienen. Dankzij zijn Italiaanse accent was het even lastig om erbij te blijven, maar het was een lekker compleet overzicht!
Chris Heilmann (Principal Evangelist Mozilla) presenteerde een tsunami aan technieken die HTML5 programmeurs in staat stelt om een lekker gelikte webapplicatie te maken. HTML5 is een misnomer, want de standaard omvat meer dan alleen markup: CSS3 (animatie, calculatie, hardware acceleratie), HTML5 forms (validatie (hoewel je daar voor beveiliging niet op kan vertrouwen, lijkt me, je zal toch server-side moeten valideren om te voorkomen dat iemand met de validatie heeft gerommeld), nieuwe elementen), File API, HTML5 video, Popcorn.js, Canvas, WebGL, local storage, offline mode, History API en SVG met D3.js en Raphaël.
Bert Belder is één van de core developers van Node.js, het event-driven I/O framework voor server-side JavaScript-applicaties op basis van Google’s V8 JavaScript-engine. Na een korte introductie over wat Node precies is begin hij aan een live demo. Hij begon met de mededeling dat live demo’s altijd een slecht idee zijn, omdat er altijd wat mis gaat. Waarom hij alsnog een live demo gaf is dan ook een raadsel, want het ging inderdaad mis. Een erg eenvoudige Node-applicatie startte zonder foutmeldingen, maar werkte niet. En Bert kon ook niet ontdekken wat er mis was. Niet al te beste reclame voor een systeem dat conceptueel wel erg interessant is.
Een tweede demo verliep iets beter en hierbij viel op dat Bert letterlijk JavaScript-code van de client naar de server kon verplaatsen, om deze door de server af te laten handelen. Het begin van de demo was een JavaScript-implementatie van Gorilla die in de browser draaide. Even later had hij een multiplayer-versie met een Node.js backend waar iedereen in de zaal met z’n laptop of telefoon op kon inloggen om ook met bananen te gooien. Node.js is duidelijk nog een jong project, maar heeft zeker potentie, zeker voor mensen die graag één programmeertaal gebruiken voor zowel frontend als backend.
Big Data
De dag werd afgesloten door Werner Vogels (CTO Amazon). Hij gaf geen presentatie, maar werd op het podium geïnterviewd door Robert Gaal, de host van Kings of Code, waarna er ook nog tijd was voor vragen van het publiek. De video van dit gesprek is nog niet beschikbaar, maar toevallig was hij enkele dagen later ook op bezoek bij Fast Moving Targets van o.a. oud-Digibaas Erwin Blom:
De MediaService is een systeem om de gegevens over onze audio en video bestanden in op te slaan. Audio en video die vervolgens uitgespeeld kunnen worden op websites of andere afzetkanalen (mobiel, digitale televisie).
Het is daarmee, simpel gesteld, een plek waarin niet de eigenlijke files, streams of downloads staan, maar wel de meta-data die nodig is om dergelijke files in een site of speler aan te bieden. Op afstand is de MediaService enigszins vergelijkbaar met Nebo, de dienst van de Publieke Omroep. Belangrijk verschil is dat een redacteur in de MediaService veel meer soorten media kan aanmaken: clips, trailers, programma’s, afleveringen, seizoenen, series, albums, speellijsten en zelfs volledige archieven van een omroep of portal. Eigenlijk alle soorten inhoud die zich binnen ons domein voordoen.
Aanleiding tot de bouw van de service was onvrede over de wijze waarop tot voor kort op afdelingen en redacties in verschillende systemen programmagegevens werden ingevoerd zonder dat deze informatie gedeeld kon worden tussen de verschillende systemen. Ieder CMS en menige site had zijn eigen “gidsdata importer” met bijbehorende redactie omgeving- en beheertools. Als gidsdata onverhoeds wijzigde dan moest deze wijziging in alle systemen los verwerkt worden. Om deze situatie te doorbreken vormt de MediaService de centrale plek voor alle onderhoud van online programma- en uitzendgegevens.
Flexibel, open en dynamisch
Belangrijk uitgangspunt bij de bouw van de MediaService was dat het een flexibele, open en dynamische oplossing zou bieden. Flexibel zodat het systeem snel en goedkoop geintegreerd kan worden met meerdere systemen binnen het VPRO gebouw en in het omroep domein. Een open karakter zorgt ervoor dat de meta-data vrij toegankelijk is voor alle afnemers. En dynamisch houdt in dat aanpassingen aan de meta-data near real-time gedistribueerd kunnen worden naar alle afnemers. Deze gewenste dynamiek stond in schril contrast met de logge batch georiënteerde im-/export processen die op dat moment gangbaar waren.
Dit levert, technisch schematisch, het volgende globale proces op van de aanmaak van programmagegevens (spoorboekje) naar publikatie van verrijkte gegevens op verschillende media of platforms (de niet-techneuten kunnen in gezelschap goede sier maken door achteloos iets te melden over gebruik van XML, CouchDB of metadata-opslag…):
Inmiddels is de service anderhalf jaar operationeel en bevat hij circa 100.000 mediafragmenten. Het overgrote deel daarvan is afkomstig van radio of tv uitzendingen van de Publieke Omroep over deze periode. Een klein deel is afkomstig uit archieven van de VPRO en Uitzending Gemist. In deze archieven zit nog een veelvoud aan informatie die nog aan de service toegevoegd kan worden. Ter vergelijking: het archief van Uitzending Gemist gaat terug tot 2004 en het online archief van de VPRO gaat zelfs terug tot 1997. We hebben ervoor gekozen deze archieven niet in één keer over te zetten. In plaats daarvan worden binnen lopende projecten kleine stukjes uit de bestaande archieven naar behoefte gemigreerd. Deze strategie heeft ervoor gezorgd dat inmiddels de belangrijkste sites van de VPRO en een aantal themaportals van de Publieke Omroep (Geschiedenis24 en HollandDoc) hun media op basis van de meta-data uit de MediaService uitserveren.
In de praktijk betekent dat voor de redactie dat de informatie over de audio en video, met de inhoudelijke beschrijvingen daarvan in de MediaService worden gedaan, en dat in een apart CMS (in dit geval Magnolia) de website zelf wordt gevuld en onderhouden.
In 2011 is de VPRO in overleg met de NPO bezig de service in te richten voor themaportals waarbij de VPRO niet direct betrokken is. Aanvankelijk zou hiervoor een losse omgeving ingericht worden, maar omdat dit een situatie zou creëren die lijkt op de oorspronkelijke situatie die de MediaService juist beoogde op te lossen, is ervoor gekozen om de externe themaportals op te nemen in de huidige versie MediaService. Het beheer van de huidige omgeving zal wel geleidelijk overgedragen worden aan de NPO. Er loopt nu (medio 2011) een pilot met Spirit24 waarbij de mogelijkheden van deze oplossing verkend worden.
Meta data
Een belangrijk issue dat binnen deze pilot speelt is de externe locatie van de media meta-data. Binnen de eerste VPRO projecten was de strikte scheiding tussen CMS en MediaService vaak de belangrijkste bron van langdurige discussie. Zowel redacties als site bouwers waren gewend om binnen hun eigen omgeving rechtstreeks toegang te hebben tot de meta-data van de media. Dit gaf ze volledige vrijheid om de data helemaal naar hun hand te zetten en gebruiken. In de nieuwe situatie zit de meta-data niet meer in het CMS. In plaats daarvan moeten site bouwers een aantal services en schermen gebruiken om een koppeling te maken tussen pagina’s van de site en de media die daarop getoond wordt. Aanvankelijk lijkt dit beperkend, maar in de praktijk biedt dit vaak dezelfde mogelijkheden als de oude oplossing. Belangrijk voordeel van de nieuwe situatie is dat de site bouwers zich niet meer hoeven te bekommeren om de updates van programma gegevens, aanlevering van streaming info, koppelingen met encodeer infrastructuur en alle ander zaken die al onzichtbaar geregeld zijn.
Een mogelijk knelpunt van de nieuwe situatie is dat redacteuren en bouwers niet meer de volledige vrijheid hebben om het datamodel van de service naar hun hand te zetten. Voor een deel is deze vrijheid schijn, omdat ze al gelimiteerd wordt door de externe partijen die de data aanleveren. Maar er zijn ook scenario’s denkbaar waar dit zeker een beperking is. Zeker bij omroepbrede inzet is dit iets dat gaat spelen. Als een service voor veel verschillende gebruikers wordt ingezet, komt er een moment waarop een gebruiker dusdanig specifieke wensen heeft dat deze niet meer binnen de globale opzet van de service passen.
Op de huidige VPRO sites is de scheiding tussen media meta-data en CMS (Magnolia) langzaam een vanzelfsprekendheid geworden en het afgelopen anderhalf jaar is er eigenlijk geen aanleiding geweest om deze scheiding opnieuw ter discussie te stellen. Redacteuren brengen naar schatting ongeveer evenveel tijd door in hun CMS als in de MediaService. Hoe deze verdeling precies uitvalt is sterk afhankelijk is van het soort site. Op sites als Geschiedenis24 of Wetenschap24, waar veel tijd wordt gestoken in het inrichten en zorgvuldig aankleden van webpagina’s, is de afspeelbare media inhoud slechts één van de onderdelen op een pagina. Aan het andere uiterste van het spectrum staan de sites waar voornamelijk energie wordt gestoken in het aanvullen van de media meta-data model. Webpagina’s van deze sites (zoals Holland Doc) zijn in wezen containers waarin media clips, playlists of hele series kunnen afspelen.
Een voorbeeld van een Holland Doc pagina die gevoed wordt vanuit de MediaService
Na anderhalf jaar hebben de beoogde voordelen van de MediaService zich bewezen:
De bezoeker kan zoeken of browsen door alle programma’s van de VPRO en zelfs de hele Publieke Omroep.
Updates en wijzigingen bij programma’s zijn onmiddellijk overal beschikbaar.
Alle redacties maken gebruik van dezelfde omgeving.
Verbeteringen aan het onderliggende systeem zijn direct voor iedereen beschikbaar.
Uniform gebruik van alle meta-data.
Hergebruik en doorverwijzing is nu veel eenvoudiger.
Met de vergroting van het aantal redacteuren, redacties en omroepen dat gebruik maakt van de Mediaservice vormt betrouwbaarheid en gebruiksvriendelijkheid van het systeem een steeds belangrijkere rol in. Zo kan de doorzoekbaarheid van de gegevens verbeterd worden en is het gebruik van de verschillende soorten meta-data een belangrijk punt van aandacht. Aan de verbetering van de Mediaservice zal zo, met de input van de groeiende gebruikersgroep, stap voor stap doorontwikkeld worden.
Weer zo’n handig online tooltje: cssprism.com Scant een CSS bestand op aanwezige kleuren en biedt je meteen een editor om ze aan te passen en het resultaat op te slaan. (Visual) search & replace was nog nooit zo makkelijk.
Project waarin het mogelijk is om door alle programma’s van de BBC heen te zoeken op basis van ondertitels. Verder koppelen ze de termen aan Wikipedia via Muddy waardoor ze ook b.v. weten dat Schotland vaker wordt genoemd dan Engeland op het nieuws en dat slechts 25% van alle personen op BBC 1 vrouw is. En ook dat Mark Rutte het afgelopen jaar slechts twee keer is genoemd op de BBC en Geert Wilders 18 keer.
Veel websites die we bij VPRO Digitaal maken hebben audio en video als belangrijkste onderdeel. Essentieel voor deze sites is dus dat de media goed te bekijken en te beluisteren valt. We bieden daarom graag onze bezoekers een consistente en prettig bruikbare mediaspeler.
In de praktijk blijkt het echter behoorlijk moeilijk te zijn om één speler aan te bieden. Er is natuurlijk de speler van Uitzending Gemist, maar die is alleen bruikbaar voor media die ook daar te zien is, en dat is lang niet alles wat we aan media hebben. Veel sites hebben een mix van media die wel en niet op Uitzending Gemist staat, dus dan zijn twee spelers al noodzakelijk. Verder past de Uitzending Gemist speler niet altijd in de vormgeving van de sites. Twee spelers betekent twee verschillende vormgevingen, en onduidelijkheid voor de bezoeker. Iets wat we niet willen.
Het afgelopen jaar hebben we daarom gewerkt aan een oplossing die én een consistente vormgeving heeft én alle benodigde formaten kan afspelen. Deze speler, die we de VPROHTML Player hebben genoemd wordt inmiddels gebruikt op onder andere de sites van Tegenlicht, Holland Doc en Geschiedenis24. Het streven is om de speler op alle VPRO-sites te gebruiken, waaronder de vernieuwde website van 3voor12, die later dit jaar online zal gaan.
Wat maakt deze speler anders dan de bestaande spelers? Daarvoor moeten we eerst even terug naar de basis van wat we willen met een speler: het afspelen van video en audio op het web. Er is op dat gebied technisch de laatste tijd veel veranderd: een paar jaar geleden was het alleen mogelijk om met behulp van plugins als Flash en Silverlight video af te spelen. Sinds de introductie van HTML5 kan het ook ‘native’ in de webbrowsers, met de <video> en <audio> tags. Dat is uiteindelijk beter dan plugins, omdat de ondersteuning al in de browser zit ingebakken. Het voorkomt problemen tussen de plugins en de browser (plugins zijn vaak een belangrijke oorzaak van crashes in de browser), en het maakt het makkelijker voor de ontwikkelaar en dus uiteindelijk ook voor de bezoeker.
Helaas is de ondersteuning van HTML5 nog niet op een niveau dat we het cross-browser kunnen gebruiken om media af te spelen. Ook is een groot deel van ons media-archief van de publieke omroep in het Windows Media-formaat, wat alleen af te spelen valt met de Silverlight plugin. Nieuwere video is wel beschikbaar in andere formaten als H264. Op termijn zal dat wel convergeren naar andere formaten, maar we zullen zeker nog een lange tijd meerdere combinaties van formaten, plugins en browsers moeten ondersteunen.
Dat betekent echter niet dat we geen gebruik kunnen maken van delen van HTML5 om wél die consistente speler aan te bieden aan onze bezoekers.
Het principe van onze speler is in feite heel simpel: alle controls van de speler (zoals de play en volumeknoppen) zijn gemaakt in HTML en worden bovenop de eigenlijke speler gelegd. De look and feel kan gewoon worden gestyled met CSS, net zoals de rest van de website.
De control-loze speler (die we het canvas noemen) wordt aangestuurd met Javascript. Dat gebeurt via een generieke interface, die is gebaseerd op de HTML5 specificatie voor het <video> en <audio> element.
Niet alle spelers implementeren de HTML5 <video> en <audio> API spec, maar dat maakt niet uit. Voor die spelers schrijven we een jQuery plugin die commando’s vertaalt naar de HTML5 commando’s. Als een speler bijvoorbeeld de totale tijd van een mediafragment ‘endTime’ noemt (zoals in de Uitzending Gemist-speler) in plaats van ‘duration’ (wat HTML5 gebruikt) dan vertalen we dat. Op die manier hoef je niet voor alle canvassen de controls overnieuw te schrijven. Je laat het aan de onderliggende jQuery plugin over om het te vertalen. De bovenste ‘control’ laag kan daarom helemaal toegesneden zijn op het goed verwerken van de aansturing van de gebruiker.
Op dit moment hebben we twee ‘canvassen’ gemaakt voor onze speler: de Uitzending Gemist-speler en een generieke Silverlight-speler voor alle andere media die niet in Uitzending Gemist zit. Die speler kan bijvoorbeeld ook MP3 of H264 afspelen. In de toekomst hopen we dat uit te breiden met de Flash-variant van de Uitzending Gemist speler, een generieke Flash speler en natuurlijk de HTML5 <video> en <audio> elementen.
Met de CSS3 Generator kun je snel CSS3 te generen met een eenvoudige interface. Er is ook ‘minimale ondersteuning’ voor Internet Explorer 7 en 8.
jQuery Waypoints maakt het makkelijk om events te koppelen aan scrollacties op een webpagina. Je kan op die manier bijvoorbeeld tracken wanneer je bezoekers een bepaald element op een pagina (bijvoorbeeld een advertentie) hebben gezien. Het wordt hiermee ook makkelijk om bijvoorbeeld ‘infinite scrolling’ of een ’sticky element’ op je pagina te bouwen.
Dale Harvey, verantwoordelijk voor webontwikkeling bij CouchOne, heeft een stuk geschreven over het schrijven van web apps voor mobiel. Veel goede tips, ook voor het debuggen. De thread op Hacker news is ook interessant, met wat opmerkingen over waarom je wel/niet jQuery mobile moet gebruiken.
+f(png)/image.png)
