De Geest van de Webrichtlijnen

Vorige week dinsdag gaf ik een presentatie op de Barcamp Webrichtlijnen over waar wat mij betreft de prioriteit moet liggen in het ontwikkelen met het oog op de webrichtlijnen.

Ik kwam er terecht via Ferry en het widgetproject wat ik voor Tam Tam heb gedaan en het evenement werd georganiseerd door de vriendelijke mensen van Cinnamon. Een grote vraag is of veel Web 2.0 technieken zoals AJAX en crowdsourcing etc. wel compatibel zijn met de webrichtlijnen, zoals ook beschreven in Ferry’s verslag.

Group

Zoals ik al zei, ging ik in tegen de heersende orthodoxie dat de huidige praktijk dat alleen maar XHTML opleveren goed is.

Mijn argumentatie betreft twee stellingen en ik hoop niet dat die zo vaag was als Don schrijft:

  1. De webrichtlijnen die het beste (automatisch) te meten zijn, zijn niet de belangrijkste. Mensen zijn geneigd om zich blind te staren op wat makkelijk meetbaar is en verliezen uit het oog waar het echt om gaat.
  2. We hebben meer dan genoeg te doen om de user experience op het internet te verbeteren zonder ons per se te conformeren aan elke webrichtlijn. Het maken van een standaarden-gebaseerde website is niet het moeilijkste. Moeilijker is het om een site te maken met mooi design, heldere tekst en goed interactieontwerp waar mensen op zitten te wachten.

Die twee punten zijn terug te vinden in mijn presentatie (op Slideshare kun je de notities uit de Keynote teruglezen):

De webrichtlijnen zijn wat mij betreft een goed middel voor zover ze je helpen om betere user experiences te creëren, maar ze zijn bij lange na niet het enige waar je naar moet kijken.

Binnen de kleine organisaties waarin ik gewend ben te werken is al veel kennis aanwezig zowel bij opdrachtgevers als uitvoerders over wat goede webervaringen zijn. Het maken van standaarden-gebaseerde website is daar verondersteld en ik denk niet dat de webrichtlijnen daar veel toegevoegde waarde bieden.

Bij grotere organisaties met minder kennis over de techniek van de materie, kunnen webrichtlijnen een goed (of het enige) middel zijn om te af te lezen wat wel en wat niet goed is, wie een goede uitvoerder is en wie niet. Maar dan nog is het een illusie om te denken dat als je organisatie-kennis niet op niveau is, je met de webrichtlijnen alleen een goede website kunt neerzetten.

Borreltje

De Heilige Graal

Bij Tam Tam is later die week ook Michèlle Thonen afgestudeerd op hetzelfde onderwerp en ik kan haar aanbevelingen alleen maar van harte ondersteunen:

  • Focus op de doelen
  • Stichting Webrichtlijnen: niet alleen de overheid, maar iedereen
  • Andere indeling Webrichtlijnen
  • Andere toetsingsregeling
  • Campagne (voeren)
  • Community (of practice opbouwen)

Met daarbij de opmerking dat ik niet denk dat kleine snel bewegende bedrijven zich kunnen conformeren aan de webrichtlijnen of dat ook maar willen doen. Het lijkt me beter als de webrichtlijnen zich langzamerhand conformeren aan hen. De webrichtlijnen zijn een serie bests practices voor het internet in het algemeen, dat internet wordt uitgevonden door de kleine innovatieve bedrijven. Daarna kan dat vastgelegd worden en kan de rest navolgen.

XHTML is dood — lang leve (X)HTML5!

Op de barcamp had ik nog een discussie over de toekomst van HTML en het gebrek daaraan bij XHTML. Het is wat mij betreft al enkele jaren apert duidelijk dat XHTML een doodlopend spoor is en dat de HTML5 werkgroep de ontwikkeling van het internet vooruit drijft.

Het toeval wil dat twee dagen later de W3 aankondigde de ontwikkeling van XHTML2 af te bouwen en zich te richten op HTML5. Dit nieuws was de bron van nogal wat discussie hier en daar over wat de gevolgen zullen zijn, of we dit hadden kunnen zien aankomen en wat we met al die oude troep moeten doen.

Mark Pilgrim heeft een goed overzicht van de issues en legt weer uit waarom validerende XHTML niet het belangrijkste is, zoek maar op ‘snake oil’ in de tekst voor de misverstanden. Een kort stukje vraag en antwoord over XHTML vs. HTML en wat discussie bij Simon Willison over het onderwerp.

Webpagina’s zullen nog steeds blijven werken, maar het is zonde dat we op dit moment een industrienorm hebben waar XHTML standaard maar achterhaald is. Standaard is goed, nu nog even zien hoe we dat achterhaalde op kunnen lossen.

Friendlier and more open government data

This is an English rewording of a post in Dutch earlier this week just in time for this Reboot session.

I’ve recently been involved with several government initiatives to make government data more accessible and to show what’s possible if that data is publicly available. The premise is that if government data is open, developers and other third parties kan reuse that data and make useful stuff with it. Stuff that can for instance serve as inspiration for our Dutch show us a better way contest: Dat Zou Handig Zijn.

Most recently we had a Hack the Government devcamp/unconference where people interested in this stuff could exchange ideas and build stuff.

Hack de Overheid
photograph by Anne Helmond

A while back I did a project on widgets which was mostly a supply side initiative triggered by a listing of readily available data.

Simultaneously Ton and James did a project on process recommendations for the public sector when it comes to releasing their data. As a part of that project I helped them sift through the currently available data sources from a technical point of view and to see which of those sources could be repackaged in an interesting and more user and developer friendly way.

That wasn’t very easy. Dutch government does publish a ton of data online but usually in rather unaccessible formats and interfaces and without clear descriptions on what it is. We picked two data sources and we managed to realize two new websites based on that data: Schoolvinder (‘School finder’) and Vervuilingsalarm (‘Pollution alert’).

School finder

A Dutch institution called the CFI already has a store with a lot of data on schools. We used their search interface and output (which though ugly and slow was remarkably reusable) and rebranded that into a simplest possible school search engine which is easily understood by parents looking for schools in their area.

Besides that we also create a canonical URL for every school in the Netherlands so other parties can refer to that and we can build stuff on top of those school pages.

The first problem this fixes is that the website is poorly usable and worded almost exclusively in jargon. Employees from the ministry of education told us later that the CFI data is not meant to be used by the public but we think this is still a fix.

Secondly it fixes the fact that this information is quite hard to find and to refer to. Our search engine is easy and open and school data is republished at unique URLs using microformats.

We would have liked to link our school pages to some numerical data from another database of the CFI but that was too hard to realize within the alotted time. Even linking to that other site proved to be too hard because those webpages were shielded in a needlessly complex ASP.NET environment.

Pollution alert

Pollution alert takes the predicted particulate values for a number of sensor stations and makes those accessible. I made a scraper to take the predicted data from the RIVM site and store it in Google App Engine. From our own store in Google App Engine, we show the geocoded stations, we push alerts out to Pachube and Twitter, graph the data and provide an API. We believe there is a lot of latent interest in the general public for this kind of data but that usable presentation forms have not been forthcoming.

RIVM to their credit does publish most of their data online, but definitely not in the most accessible formats nor in ways that enable normal people to audit their living environment.

Principles

The sites we built are very advanced prototypes which are completely functional and even highly scalable. During building we followed some principles which may be interesting to touch upon here.

Friendly design

Both sites have a pleasant and friendly design created by Buro Pony. This is important because people are more inclined to use sites that look nice and experience those sites as being more user friendly.

A nice design needs to be accompanied by clear and simple writing without jargon that connects with the way people think about the stuff you’re describing.

Most websites can be improved massively by just implementing these two points.

Playing well with others

Both websites also connect with a bunch of other sites that improve upon the concept. They’ve been built on Google App Engine a system which is easy to develop for and which is readily scalable. Maps are retrieved from Google Maps, graphs are provided by Google Charts and sensor data is pushed to Pachube and Twitter.

The experience on the main site is just a part of the whole. The data needs to be accessible from and easily pushable to where it’s needed most.

On the Hack the Government event somebody said something along these lines: ‘systems integration is difficult and complicated and if you’re good at it, you can make a lot of money with it’. This is a well known Enterprise IT mantra but if there’s one thing that the abundances of mashups proves, it’s that integrating systems on the open web is everything but complex.

On the open web we have usable and developer friendly API standards with tooling, besides that we have proper standards for identity and authentication.

If you don’t dig yourself into a hole, it really doesn’t have to be that difficult. And none of this is exactly new, this technology has been around for ages and it just builds on the strengths of the internet.

Standards based

Both sites are completely standards based. As an experiment I wrote both in a conservative form of HTML5 (and validated that) partly out of curiosity to see how it would turn out and partly because I think that our current Dutch industry standard XHTML is a dead end.

Added to that I have sprinkled in some microformats in places where it was obvious to do so (e.g. school addresses). The notion that it takes significant extra time to add microformats to a project is absurd and these days the advantages of adding them keep piling up.

Yes, it takes some effort to learn to use standards and microformats properly, but once learned I think it actually takes more effort not to use them.

Quickly

Finally, both sites have been built in a couple of days over the course of about a week and a half. We wanted to show that when we’re talking about a quick project, it really can be quick and that building a non-trivial usable beautiful website does not need to cost a lot of time or money.

All of this can be improved. Let’s get at it.

Overheidsgegevens opener en vriendelijker

Ik ben pas bezig geweest met verschillende overheidsinitiatieven om overheidsgegevens makkelijker toegankelijk te maken en te laten zien wat er mogelijk is als die gegevens toegankelijk zijn. Het idee is dat als de gegevens van de overheid open zijn, ontwikkelaars en andere partijen die kunnen hergebruiken en dingen kunnen maken waar andere mensen behoefte aan hebben. En dat zou weleens handig kunnen zijn.

Hack de Overheid
foto door Anne Helmond

Pas was er al het widget-project wat een initiatief was gedacht vanuit het aanbod: ‘Wat hebben we waar we iets van kunnen maken?’

Parallel daaraan liep Ton en James hun project over aanbevelingen voor de publieke sector wat betreft het vrijgeven van data. Als onderdeel van dat project heb ik meegeholpen met een inventarisatie van de al online beschikbare gegevensbronnen in Nederland en kijken welke gegevens we op een interessante manier zouden kunnen heraanbieden.

Dat viel nog redelijk tegen. Er zijn online wel veel gegevens beschikbaar maar meestal zitten ze in relatief ontoegankelijke formaten en zonder veel uitleg erbij wat het is en wat je ermee kunt. Uiteindelijk hebben we twee diensten gerealiseerd Schoolvinder en Vervuilingsalarm.

Schoolvinder

Zoals op de over-pagina van Schoolvinder al staat hebben we de gegevens die bij het CFI al geregistreerd staan over scholen versimpeld aangeboden met een simpel zoekscherm wat aan zal sluiten bij de ideeën van de gemiddelde ouder.

Daarnaast doen we een poging om voor elke school in Nederland een canonieke URL —een basisbehoefte op het internet— te definieren waar je naar kunt refereren en waar je dingen bovenop kunt bouwen.

Dit is een probleem wat we bij de overheid vaker tegenkomen, dat webpagina’s slecht samenwerken maar ook dat ze niet mooi zijn en vaak omkomen in jargon. Later hebben we van mensen van MinOCW begrepen dat de CFI gegevens niet voor het bredere publiek bedoeld zijn en dat schoolgegevens ook op andere plaatsen (en dan vaak ook op andere aggregatieniveau’s) bijgehouden worden.

Dat is misschien onhandig maar waarschijnlijk verklaarbaar waarom de gegevens dubbel bijgehouden worden maar dat de site voor werknemers bedoeld is doet er niks aan af dat hij moeilijk bruikbaar is. De herbruikbaarheid is redelijk ok —we hebben immers onze dienst er bovenop kunnen bouwen— maar het kan zeker veel beter.

En we hadden graag ook elke school gekoppeld met de database Onderwijs in Cijfers maar dat viel niet te realiseren omdat die webpagina’s (onnodig) ver weg zijn weggestopt in een complexe ASP.NET omgeving.

Vervuilingsalarm

Bij Vervuilingsalarm hebben we de gegevens uit een webpagina van het RIVM geplukt. We denken dat de interesse voor dit soort gegevens uit de omgeving bij het publiek potentieel groot is maar dat het tot nu toe te weinig op een gebruiksvriendelijke manier wordt weergegeven.

Bij het RIVM staan wel veel bestanden online maar ik kan niet zeggen dat ze in de meest toegankelijke formaten beschikbaar zijn of dat ze gewone mensen in staat stellen hun leefomgeving door te lichten.

Principes

De sites die we gemaakt hebben zijn vergevorderde prototypes die compleet bruikbaar en schaalbaar zijn. Bij het bouwen hebben we een paar principes gehanteerd die misschien interessant zijn om aan te stippen.

Vriendelijk ontwerp

De sites hebben een mooi en vriendelijk ontwerp gemaakt door Buro Pony. Dit is belangrijk omdat mensen een site die er mooi uitziet liever gebruiken en ervaren als gebruiksvriendelijker.

Bij dat mooi ontwerp hoort ook kopij met simpel en helder taalgebruik zonder jargon, die aansluit bij de belevingswereld van mensen.

De meeste websites kun je met deze twee verbeteringen al gigantisch vooruit helpen.

Integratie met anderen

Beide websites integreren zonder al teveel problemen met een serie andere sites die het concept versterken. Het is gebouwd op Google App Engine een systeem wat bijzonder schaalbaar en betrouwbaar is en zonder veel problemen worden kaarten opgehaald van Google Maps, grafieken van Google Charts en sensorgegevens worden doorgestuurd naar Pachube

Op het Hack de Overheid event zei iemand dat ‘het integreren van systemen moeilijk en complex is en dat als je dat goed kunt je er veel geld mee kunt verdienen’. Dit is een bekende algemene wijsheid in de enterprise IT maar als er één ding is wat de mashups die online normaal zijn bewijzen, is het dat integratie op het open web alles behalve moeilijk is.

Er zijn bruikbare API-standaarden met tooling, daarnaast zijn er goede standaarden voor identiteit en authenticatie en als je het jezelf niet te ingewikkeld maakt hoeft het echt niet moeilijk te zijn. En dit is niet nieuw ofzo, deze technologie bestaat al lang en bouwt gewoon door op wat het internet al goed doet.

Standaarden gebaseerd

De sites die we gebouwd zijn zijn compleet op standaarden gebaseerd. Ik heb de pagina’s als experiment geschreven in HTML5 (en gevalideerd) deels uit interesse en deels omdat ik van mening ben dat het nu gangbare XHTML een dood spoor is.

Verder heb ik waar ik het gepast vond ook gegevens (bijvoorbeeld de contactgegevens van de scholen) met microformats geannoteerd. Het idee dat microformats toevoegen aan een project significante extra tijd kost is wat mij betreft achterhaald en tegenwoordig is er een hard reëel voordeel aan te voeren.

Het kost even moeite om jezelf aan te leren om standaarden en microformats te gebruiken, maar als je het kunt is het bijna meer moeite om het niet te doen.

Snel

Verder heb ik beide sites gebouwd in een tijdspanne van een paar dagen. Waarmee we wilden aangeven dat een snel project ook echt snel kan en dat het maken van een gebruiksvriendelijke niet-triviale site niet veel tijd en geld hoeft te kosten.

Het kan allemaal wél beter. Laten we het dus gaan doen.

I come not to save Flash

Adobe’s CEO said that Flash is safe from HTLM5. Just the fact that Adobe made a board level comment on this is telling enough, the answer itself is somewhat lacking.

It’s nice that they’re optimistic for improvements in HTML. Seeing what disasters both the XHTML and in a somewhat lesser extent SVG tracks of the W3C standardization process have been, we could definitely use them. They should admit though, that a full fledged HTML5 with rich CSS3+ is the death knell for Flash.

The more sites we see like the Holland Festival one the more it means that clients are choosing for an open and more semantic website with gradual improvements in JavaScript and CSS. It may take ten years, but we may see the first signs of a shift in this industry.

No mobile?

He’s right to say that it’s difficult to deliver a consistent HTML5 experience across browsers on the desktop. The fact that he conveniently ignores mobile browsers is more than a bit misleading.

Mobile internet usage is exploding and most of that usage is centered around Webkit based browsers. Mobile webkit is also pretty rapidly incorporating HTML5 features and things like CSS transitions. This gives developers who want to make a great mobile site for a big and important part of their audience a single very compelling target to develop for.

Like Gruber said, one of the most noteworthy non-announcements for iPhone 3.0 was no Flash. Who really needs it anyway on the iPhone? And why would Apple let somebody else in on their platform?

Is Flash dead? No. Is there for the first time a clear path forward to a world without Flash? Yes, finally!

The City Is Here For You To Get Fined By

For any international readers, as the Dutch are probably already very much aware of our totalitarian parking policies.

The headline for the piece accompanying this video reads: “Odds of getting fined doubled” in Dutch.

The video is in Dutch but you should still be able to make out a very interesting and frankly somewhat scary urban systems play.

There is a Google Streetview like car which drives through Amsterdam. It has 3 cameras on either side to be able to scan the three predominant parking patterns (queue, fish and orthogonal). The cameras OCR the license plates of all parked cars and check them with a database.

Another necessary ingredient is a new class of parking ticket machines where you need to punch in your license plate before you get your ticket. The machines are pretty poorly designed, causing a lot of user frustration but they are an essential part of the system. These ticket machines are connected and they push your license plate and the time you have bought to a central server.

So if the scanning car finds a license plate which a ticket machine has not designated as having bought a ticket, a third party is dispatched on scooter to check if there is in fact no valid parking ticket lying under the windshield. If there isn’t, he writes a fine.

Changes

The system dramatically increases the odds of you getting fined compared to the previous system where parking inspectors would walk the street samplewise. This approaches a total and real time assessment and billing of urban space.

The fact that the scanner does not need to get out of the car is interesting from a division of labor point of view. The person actually fining the car gets an SMS and then does a tactical strike with the urban rapid entry vehicle of choice. This minimizes the contact surface with the parking inspectors reducing both potential aggression and being able to see parking inspectors coming (and making a mad dash to the ticket machine).

When Google’s car scans the street all kind of privacy concerns are paraded even though the end result benefits and harms the entire public equally. Nobody even realizes yet what the consequences of this approach will be until we get to feel and see it more directly. It is difficult to ‘feel’ a higher accuracy of parking inspection except that people who normally would hardly ever get a fine, will get them now.

I’m also interested in people’s reaction to changing a leaky implementation of a system of regulations with its faults and errors but a human scale to a totalitarian implementation such as this one which covers enough as to be nearly foolproof. Protest? Quiet resignation? We will see.

And for all you militant free parking advocates out there, put this on your reading list: The High Cost of Free Parking

NDOV uitkomst programmeerwedstrijd

Recent was de prijsuitreiking van de 9292 programmeerwedstrijd voor een applicatie op hun databron gemaakt door studenten. Ik heb daar hier al genoeg woorden aan vuil gemaakt en de uitkomst is leuk maar niet zo opzienbarend als men deed voorkomen.

Wat wel interessant is, zijn de interviews met de verschillende spelers in de openbaar vervoersector en de uitspraken die ze dan doen.

Vincent deed al een oproep tot ‘Ramen open!’, eens kijken of en wanneer dat dan gaat gebeuren.

Eerst maar eens staatssecretaris Tineke Huizinga:

Huizinga kondigt de Nationaal Datawarehouse Openbaar Vervoer (NDOV) aan die in 2015 klaar moet zijn. Ze zegt dat marktpartijen dan planners moeten maken, en er moeten dan initiatieven uit de ‘markt’ komen. Vincente stelt terecht de vraag wie er dan gecertificeerd wordt om daarmee aan de slag te gaan.

Het is een wat raar verhaal waarom alle lokale overheden de vervoersinformatie eerst hebben ondergebracht bij 9292 die zo’n database heeft met alle vervoersinformatie en ze nu opnieuw zo’n database gaan aanleggen met dezelfde gegevens erin. Dubbel werk lijkt me. En wie zijn dan die ‘marktpartijen’ die planners ‘moeten’ maken?

Het gaat sowieso lang duren voor die NDOV er is en ik ben bang dat het proces van certificering te ingewikkeld in te kostbaar zal zijn waardoor de definitie van marktpartijen verengt tot ‘grote bedrijven die al werkzaam zijn in de sector’ en de innovatie een wisse dood sterft.

Maar het kan ook goed aflopen. Zie het verhaal van Gert Staal directeur 9292ov:

Staal meldt dat ze ‘openstaan voor vernieuwingen ook van buitenaf’. Vincent vraagt of derde partijen met een API kunnen integreren met 9292 waarop Staal bevestigt dat er meer zeker meer openheid komt maar:

  1. Dit kan niet 100% omdat lokale vervoerders in de weg zitten.
  2. Dit gaat gebeuren in samenwerking met het NDOV wat een initiatief is van Verkeer en Waterstaat samen met 9292 en waar alle actuele en statische informatie in het openbaar vervoer in opvraagbaar moet zijn. Staal: “Onder bepaalde voorwaarden kan iedereen daarbij. Die voorwaarden zullen voor iedereen gelijk zijn.”

Dat klinkt dus goed zolang die voorwaarden enigzins open zijn. Nu nog een roadmap en het lijkt erop alsof we aan de slag kunnen.

A couple more widget notes

Some remaindered notes:

Trivial mashups

I recently did a survey to see what relevant mashups I could find as examples and I was surprised to find that there are not that many serious ones. Especially if you want to go beyond the chewn out examples of Flickr, last.fm and Google Maps, there simply is not that much there.

This is indicative of how much work remains to be done in creating data sources and adding semantics to the web. All the things we have made thusfar are mere proofs of concept compared to the potential that is still there.

One of the reasons why this may be the case is that it is hard to build a decent business on top of a mashups either because the license of the source is not permissive enough or because building on top of somebody else’s web app is a shaky foundation.

Channels

In the widget project we did, the channel was set namely: widgets. This both makes sense and doesn’t. Widgets are a general enough target for displaced information but for some types of information they are not the ideal channel.

Calendar information should be in your calendar whether that be Outlook, iCal or Google Calendar. It’s nice to have it in a widget but that’s not the most relevant place. Similarly for videos you should have a podcast link with all the video formats embedded as enclosures. The video widget we developed is finally live (embedded underneath) and displays the latest videos quite nicely, but it would be nicer still to integrate this with iTunes and Boxee and be able to watch it on your television.

So a more wholistic approach is necessary that recognizes the values and affordances of various forms of data and provides a consistent brand across channels. Widgets already say that your website is irrelevant, now take it one step further.

Also a small test of the open syndication facility of iGoogle. A bit hidden away but works nicely.

Widgets algemene afwegingen

Het is nu een paar weken geleden dat ik de eerste release versie van een serie widgets die ik samen met Tam Tam in opdracht van het Ministerie van Binnenlandse Zaken en Koninkrijksrelaties (BZK) heb ontwikkeld (een overzichtsartikel).

Doel van het project was om in een breder initiatief aangaande overheid en open data te kijken of met widgets huidige overheidsdata dichter en aantrekkelijker bij de belevingswereld van gebruikers gebracht zou kunnen worden. Er lopen op dit vlak nog meer initiatieven en de grootste uitdaging is de beperktheid van middelen en kennis om de informatie op een goede manier te ontsluiten.

Widgets zijn een nogal onduidelijke term voor kleine specifieke stukjes internet-functionaliteit. Om hier wat duidelijkheid in te verschaffen heb ik een onderzoek gedaan naar de verschillende platformen. De widgetruimte en spraakverwarring blijft groot en gefragmenteerd en recentelijk zijn er weer enkele initiatieven op het gebied van mobiele widgets bij gekomen die nog meer mogelijkheden (en incompatibiliteit bieden).

De widgets staan nu met beschrijving en uitnodiging om samen te werken in de werkruimte van Overheid2.0 en de code van de widgets is beschikbaar op github.

Genericiteit

Uit het onderzoek kwam naar voren dat de verschillende technische widget-platformen veel gelijkenis vertonen en dat er een beweging is naar consolidatie. Een platform als Netvibes gebruikt de overeenkomsten om met hun UWA te proberen één widgetdefinitie te laten draaien op verschillende platformen. In de praktijk valt dit tegen. Het hergebruiken van stukken website is ook een belangrijk onderdeel van iGoogle/OpenSocial en gezien het grote aantal (sociale netwerk-)sites dat dit ondersteunt en de aanwezigheid van een open runtime lijkt dit het platform met de grootste impuls.

Het hebben van een generiek platform is belangrijk omdat de problemen vaak hetzelfde zijn en de verschillen klein. Daarom ook is het apart dat er niet meer plaatsen zijn waar OpenSocial widgets te draaien zijn en het is teleurstellend dat het mobiele widgetplatform van Opera niet hiermee samenwerkt.

Op zijn simpelst gezegd is een widget een vakje om HTML in te tekenen met specifieke Javascript APIs voor bepaalde functionaliteit. In OpenSocial betreft dit toegang tot de functionaliteit van het omliggende sociale netwerk en op het mobiele platform gaat het om functionaliteit van de mobiele telefoon.

Wij gebruiken dus de OpenSocial gadgets.* API van Google zonder de sociale extensies. Deze sociale extensies kunnen in de toekomst altijd nog gebruikt worden, maar dit voegde nogal wat nodeloze complexiteit toe omdat de primaire runtime niet een sociale omgeving is maar een persoonlijk dashboard. De complexiteit zit hem er dan ook niet zo bijzonder in de conditionele javascript maar in de conditionele presentatie waar dan ook meer grafisch/interactie-ontwerp voor nodig is.

De motivatie om tot één generieke widget te komen bleek gerechtvaardigd. Ik heb de widgets gebouwd in de laatste gadgets API versie van Google die ook gebruikt wordt in OpenSocial maar het iGoogle dashboard werkt zelf nog steeds op de oude versie van de specificatie. Het omschrijven van elke widget naar zijn -legacy.xml versie is redelijk triviaal maar het zorgt ervoor dat je dubbel werk doet niet alleen in implementatie maar in het bijzonder ook in het testen (je kunt geen wijzigingen uitrollen zonder een goede test). Dit is al tijdrovend bij 2 soorten widgets; ik denk dat je ervan uit kunt gaan dat de bestede tijd om de verschillende platformen te ondersteunen vrij snel je complete budget op zal slokken.

Aanpasbaarheid

Een andere afweging wat betreft de genericiteit van de widgets betreft het maken van een widget of widgetplatform waarin een niet-programmeur door het opgeven van enkele plaatjes, kleuren en een databron automatisch een widget kan laten maken.

Dit is de heilige graal maar het was binnen dit project niet realistisch. Er zijn heel weinig projecten die dit goed doen (Sprout Builder is eigenlijk de enige die ik ken) omdat het bijzonder moeilijk en bijzonder veel werk. En dit slecht doen is geen optie (dan kun je het beter niet doen).

Bij een halve versie krijg je een rare tussenvorm die lastig werkbaar is en ofwel te weinig vrijheid toe laat of teveel en dan weer teveel voorafgesproken kennis veronderstelt. Dit terwijl het maken van een mooi en goed design juist één van de grootste toegevoegde waarden is die je kunt meegeven aan een widget (zie volgende punt).

We hebben er dus voor gekozen om concrete affe versies te maken maar wel met een redelijk simpele en heldere opmaak en presentatie waardoor ze eenvoudig door wie dan ook te herbranden zijn in een nieuwswidget voor een ander bestuursorgaan. Het deel van de widget dat praat met het platform en de data ophaalt blijft dan gelijk.

Presentatie

We hebben nogal wat tijd en aandacht besteed met de ontwerpers van Tam Tam samen aan een mooie presentatie van de widgets binnen de huisstijl van de originele site. Je ziet dat dit al snel veel toegevoegde waarde heeft niet alleen in ‘branding’ maar ook in (gebruiks)vriendelijkheid van de gegevens. Vergelijk onze rijkere RSS nieuws-widgets maar met de standaardmanier om RSS te presenteren in iGoogle (zie screenshot).

Presentation of Feeds

Bij de videowidget zie je dat er zonder al teveel moeite al makkelijk de perceptie van een ‘kanaal’ te creëren is, door de layout en de functionaliteit.

Widgets die nu beschikbaar zijn bieden vaak wel interessante functionaliteit en redelijke interactie maar vaak weinig tot geen grafisch ontwerp. Visuele presentatie heeft een sterk effect op de usability en wat dat betreft is er een wereld te winnen.

Waar je denkt aan presentatie denken veel mensen ook aan Flash. Onze keuze om geen Flash te gebruiken heeft zich denk ik ook bewezen. Veel interactieve widgets zijn gebouwd in Flash, maar die komen vaak niet veel verder dan een spel, video of ander grapje op iemands profiel. Het gebruik van Flash voor normale dingen als tekst en hyperlinks loopt vrijwel altijd uit op een ramp wat betreft gebruiksvriendelijkheid. Daarnaast is Flash slecht begrepen en slecht editbaar. Vergelijk dit met de publieke git repository waar het project nu staat en waar het voor iedereen te bekijken, becommentariëren en bewerken is.

Data

Het idee was om de widgets een uitingsvorm te laten zijn van al bestaande data omdat we dan sneller aan de slag zouden kunnen. We zagen toen al in dat wijzigingen aan de data-aanbiederskant veel tijd zouden kosten. Uiteindelijk zijn er wijzigingen nodig geweest voor alle databronnen behalve één (die van het VWA waar al een RSS-feed beschikbaar was), duurden die wijzigingen inderdaad heel lang als ze al kwamen want er zijn nog steeds twee databronnen niet af.

De beschikbaarheid van data is het belangrijkste punt en iets waar Ton en James mee bezig zijn in hun project. Er zijn een boel dingen nodig: bereidheid om data beschikbaar te maken, middelen om het te bewerkstelligen, richtlijnen voor de uitvoer, een geschikt uitvoerformaat en distributiestrategie.

Verder als je echt begint te werken met de standaarden die we nu voor handen hebben merk je dat er veel nog in de kinderschoenen staat. Er is weinig bewezen en getest en er is ook lang niet overal code voor. Dit is geen pleidooi om het dan maar niet te doen en overal Excel sheets en PDFs online te zetten, integendeel; we leren dit soort dingen alleen maar door het te doen.

Platformafhankelijkheid

De aanwezigheid van een open implementatie van Shindig beperkt je afhankelijkheid van derde partijen voor platformen in zeker mate, maar over het algemeen gesproken zullen mensen widgets toch graag willen plaatsen op hun vaste plekken.

De OpenSocial standaard wordt nog niet overal even goed toegepast en naast de technologische verschillen hebben de verschillende platformen ook verschillende ontikkelaarsrichtlijnen voor projecten. LinkedIn is bijvoorbeeld erg gesloten terwijl Hyves relatief weinig eisen stelt.

Bij het testen van onze OpenSocial gadgets kwam ik erachter dat ze het op Ning bijvoorbeeld helemaal niet doen. Op Hyves was er wat herschrijven nodig en zitten er nog wat kleine fouten in het platform waardoor de widgets niet perfect werken maar wel werkbaar zijn. En recentelijk liggen de widgets er af en toe compleet uit in iGoogle waarna ze na een paar dagen weer terug komen.

Dit is allemaal jammer, maar dat is één reden waarom kiezen voor het grootste en actiefste platform belangrijk is. Op die manier is er temminste een kans dat deze problemen in een toekomstige update opgelost worden.

Groeikansen

Wat de widgets betreft nodigen we iedereen die wil uit voor participatie ofwel op conceptueel niveau in de werkruimte van overheid20 ofwel in de code op github. Op zijn lichtst gezegd kan de participatie daar wel iets hoger.

Verder staan er op ons verlanglijstje nog een serie generieke widgets die de basisfunctionaliteit bevatten en die door iemand met kennis van HTML/CSS snel te rebranden zijn voor een specifiek doel. Video-, Event- en RSS-widgets hebben we nu al, op het verlanglijstje staat nog een Image-widget (plaatje(s) van de dag) en een echte kaart-widget om maar iets te noemen. Deze widgets zouden niet alleen bruikbaar zijn binnen de overheid maar overal waar hier behoefte aan is.
Als er code op andere plaatsen beschikbaar is, die past bij deze doelstelling hou ik me aanbevolen. En patches kunnen mijn richting op, hoe meer hoe beter.

Uiteindelijk is de beschikbaarheid van data essentieel. Je ziet hoe lastig het is voor een project om met mandaat maar zonder paraat beschikbare data te opereren. Andersom denk ik dat als er maar data beschikbaar is dat mensen dan vanzelf uit interesse of al naar gelang behoefte wel iets zullen maken. Zonder data gaat dat in elk geval niet gebeuren.
Wat daar wel bij opgemerkt moet worden, is dat je goed grafisch design bijna alleen maar ziet bij dit soort betaalde projecten waar professionele grafische ontwerpers worden ingezet en zoals ik al zei is dat ook een essentieel onderdeel (maar slecht ontworpen is nog steeds beter dan niks).

Widgets overzicht

Pas dus het project van een stel widgets voor het Ministerie van Binnenlandse Zaken afgerond. Hier een beschrijving per widget met afwegingen over de functionaliteit en de data. In een vervolgbericht wat algemenere projectnotities.

De widgets zelf met installatiecodes staan op overheid20.nl, de teksten staan gewoon in de beschrijvingen van de widgets en de code staat vrij te gebruiken op github.

Zoekdienst Bekendmakingen

De overheid indexeert voor een hele reeks gemeenten en andere lokale instanties de bekendmakingen die ze publiceren op overheid.nl. Dit is een flinke klus omdat elke instantie dit op een andere manier publiceert, maar het is ontzettend handig om op een simpele manier door deze dingen heen te kunnen zoeken.

De website oogt een beetje onvriendelijk maar is wel goed bruikbaar en er is een zoekdienst waar je je kunt abonneren op bekendmakingen in jouw interesseprofiel bij jou in de buurt.

Deze zoekdienst en de bekendmakingen waar deze op gebouwd zijn bieden geen publieke herbruikbare data aan. Er wordt intern wel van enkele webservices gebruik gemaakt maar deze worden (nog) niet ontsloten naar buiten. Voor dit project konden we niet wachten tot er een API zou zijn omdat het bijzonder onvoorspelbaar is of en wanneer deze er dan is, dus hebben we maar iets gemaakt met wat er voorhanden was. Vergunningenkaart is een site van geostart die wel toegang heeft tot de gegevens en geocodeert ze zelf en maakt ze weer beschikbaar.

Ik heb voor de widget alle gemeenten van vergunningenkaart in één overzicht gestopt zodat je snel voor een bepaalde geeente kunt zien welke vergunningen er spelen. Dit is toegegeven een redelijk beperkt gebruiksdoel en in ons ontwerp hadden we ook voorzien dat het relevantste is om snel te kunnen zien wat er bij jou in de buurt nieuw is aan vergunningen. Zonder goede toegang tot de data is dit helaas niet realiseerbaar.

In Groot Britannië hebben ze de attenderingenservice van de zoekdienst bekendmakingen dus wel gerealiseerd met dat gebruiksdoel voor ogen maar dan niet in een widget maar via Twitter met Twitterplan.

Agenda van Werken bij de Overheid

Op Werken bij de Overheid is er ergens achteraf weggestopt een agenda met relevante evenementen voor mensen die een baan zoeken bij de overheid. De evenementen op die agenda hebben niet een eigen (landings)pagina, maar op ons verzoek is er door Rhinofly een RSS feed van alle evenementent gemaakt op basis waarvan wij dan de widget konden maken.

Een agenda widget is fijn om te hebben precies omdat dit soort dingen vaak weggestopt worden en vaak op meerdere plaatsen relevant kunnen zijn. De uitvoer naar ics maakt het nog boeiender want uiteindelijk hoort agenda data thuis op de plaats die voor mensen het relevantste is: in de agenda. Het maken van een iCalendar uitvoerformaat was niet de opdracht (wij maken widgets) en uit de metadata in de RSS feed (naar voorbeeld van de RSS van Upcoming gemaakt) zou het niet al te moeilijk moeten zijn om een iCalendar te genereren maar er zijn geen standaard tools voor.

Rijksoverheidsvideo’s

De Rijksoverheid produceert video’s van bijzonder hoge kwaliteit in een verscheidenheid aan formaten en met volledig transcript, ondertiteling en noem maar op. Deze video’s worden al verspreid naar de traditionele media maar gezien de hoeveelheid werk die erin gestopt wordt en de kwaliteit van het materiaal en metadata spreekt het voor zich om ze online ook verder te verspreiden.

Net zoals evenementengegevens thuishoren in de agenda, horen video’s thuis op televisie of een andere player door middel van een podcast. Een podcast RSS is een redelijk goed begrepen de facto standaard waarmee de gegevens handig af te spelen zijn en ook op andere manieren bruikbaar zijn.

In dit geval moest er een nieuwe RSS feed gespecificeerd worden waar daadwerkelijk verwijzingen naar de videobestanden in staan. Deze feed is nog niet af. De videowidget draait op een testfeed waar drie video’s in staan en die nog geen koppeling met de echte data heeft.

Waarschuwingen van de VWA

Een simpele nieuwswidget met daarin de meest recente waarschuwingen en terughaalacties van de Voedsel en Warenauthoriteit. Van deze nieuwsberichten is er al een RSS feed op de site van de VWA te vinden. We hebben die simpelweg ingepakt op een prettige manier.

Het is technisch niet een hele complexe widget, maar de layout, huisstijl en de iconen om te differentieren tussen terughaalacties en waarschuwingen geven hier de meerwaarde die dit de moeite waard maakt.

Vacatures van Werken bij de Overheid

De vacatures van Werken bij de Overheid (RSS) zijn dat waar de meeste bezoekers van die website naar op zoek zijn —denken we. Dus iemand gaat naar Werken bij de Overheid om te zoeken naar een baan, vult op de voorpagina zijn eisen in en zoekt op die manier.

De widget die we hebben gemaakt biedt precies dezelfde zoekcriteria als op die pagina en laat altijd de laatste vacatures zien. Op die manier bespaart de widget iemand die een baan zoekt herhaaldelijke bezoeken naar de site. Qua personaliseerbaarheid en relevantie (voor een baanzoeker) lijkt deze widget me het meest geslaagd.

Voor zover een beschrijving per widget met afwegingen over de functionaliteit en de data. In een vervolgbericht wat meer over de projectbrede afwegingen.

Mobile Widget Camp

In spite of the nice weather, I spent today at Mobile Widget Devcamp in Pakhuis de Zwijger. Having done some projects on widgets recently, I was curious to see what the state of mobile widgets was.

Vodafone presented their app manager which will be rolled out to Vodafone mobile users. The app manager makes it easier to find and install widgets/apps to the mobile phone. Widgets can be submitted to the app manager in an App Store like proces and in due time —I think the word was come September— you can even charge money for your widget in a 70/30 split.

The mobile widgets by Vodafone are a W3C standard and the app manager is an application which wraps the widget rendering components of the Opera browser into a user and developer friendly package. Opera has quite some experience in mobile rendering engines, widgets and web technology in general and it shows.

The afternoon was widget building workshops and a contest for which I built two widgets: a pollen prediction widget and a Dutch government job search widget (if you run Opera, clicking those links will actually do something).

The documentation is a bit sparse (as are the APIs) and the environment is mostly unfamiliar but that probably will be fixed over time. I built and tested these on my desktop Opera browser. I don’t have a mobile phone that runs these widgets, which is a problem.

Depending on your target audience you may or may not want to build for this platform. In any case if you have your data, APIs and design in order, it shouldn’t be too difficult to build a basic widget.

I think you can find more detailed coverage, slides and maybe even streams of the day if you look around a bit. Here are some observations.

Terminology

There is a lot of terminology confusion in this space: widsets, widgets, apps, gadgets and applications which can get pretty unclear here and there.

Simple is not important

All the talk focused on how simple it is to get a simple widget running. It hardly ever is about the simple stuff, we can believe that that works. It’s about the tools and documentation, the nooks and crannies and the 80% of effort necessary to nail that last 20%. Every new platform, however simple it may be, adds another of that 80% of extra overhead.

OpenSocial

There is a lot of overlap with OpenSocial and I find it hard to believe that it would not be possible (not to mention wise) to converge the two. Both specifications deal with rendering a bit of HTML in a tiny window with specific Javascript APIs, social APIs in the case of OpenSocial and device specific APIs in the case of mobile widgets. Added to that OpenSocial feels like it has more momentum, a solid implementation and better documentation.

One difference here is that the widgets we ran today must be rendered by the Opera browser whereas an OpenSocial widget is processed on the server and the resulting HTML can be rendered by any standards compliant browser.

In any case more consolidation and convergence can only be a good thing, especially when the essential differences are so minor. I found a brief reference to that possibility by a CETIS guy.

I also think it’s curious that OpenSocial/iGoogle gadgets don’t run in more places. Why isn’t there an OpenSocial container for Vista and OS X desktop gadgets just to name one?

Promises, promises

Many of the presentations were promising a lot of things and the current SDK and capabilities we have been presented are just a taste of what is to come.

There currently aren’t any APIs yet to access any mobile specific device features from your widget. These are ‘forthcoming’ somewhere but the process and timeframe in which these should be available were vague. Without these APIs the widgets you can make don’t go much further than a twitter search or your daily fortune, with those APIs really serious things become possible (as does really serious abuse).

Vodafone positions this app manager framework as a platform to reach the vast masses who do not yet use the mobile internet and do not yet run applications on their mobile phones. To reach them a lot of components must be in the right place and the experience to get and run applications needs to be smooth as silk and even then it remains to be seen if it will work. This is a big promise with a huge potential payoff.

In that future being able to install and share widgets/applications across platforms with minimal effort will have serious consequences for the very notion of what a mobile app is. Just a web service with a bit of logic and access (control) to device hardware using uniform APIs?

As Chipchase wrote: “[…] the interesting trend to watch will be the mainstreaming of just-in-time discovery and consumption of highly focused and contextually useful applications.”

I can’t wait to see if and how we will get there.