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.

Inspiratie voor mobiele diensten

Ik schreef een paar dagen geleden in een roundup over de wedstrijd van 9292 voor een nieuwe reisplanner. Marie-José Klaver heeft er ook een stukje over waarin ze nog wat minder mals is dan ik.

Mark de Bruin, marketingmanager bij 9292, heeft een twitter account en is bereid om tekst en uitleg te geven. Dat is tof en ik denk een essentiele eerste stap om verder te komen in de verstarde eenrichtingsverkeerkanalen waar deze hele sector zich in bevindt.

De uitleg rammelt hier en daar nogal en de noodzaak voor open vervoersdata blijft bestaan, dus laten we eens kijken wat hoe ver we komen. Mark nodigde uit om de discussie over e-mail voort te zetten. E-mail is niet schaalbaar en twitter is te kort, vandaar deze blog.

Zoals ik schreef zijn de voorwaarden van de wedstrijd nogal in het voordeel van 9292 maar heeft dat 22 teams toch voldoende gemotiveerd om mee te doen. Ik ben meer dan een beetje benieuwd waar zij mee komen.

Rechten

Alle deelnemers moeten op dit moment de rechten op hun applicaties afstaan aan 9292. 9292 zegt de applicaties niet te zullen overnemen maar te zullen gebruiken als inspiratie. Waarom kunnen deelnemers dan niet gewoon een verklaring tekenen dat ze 9292 toestaan om ideeën uit hun applicatie te gebruiken en gewoon hun rechten zelf behouden (tweet)?

Wat Mark en 9292 verstaan onder delen is dat de applicaties ergens intern verdwijnen en ideeën en onderdelen eruit verwerkt zullen worden in hun gratis applicaties. Dat is geen delen maar gewoon het uitoefenen van de taak waar ze al mee bezig waren.

De teams doen willens en wetens mee. Het is ook de vraag wat een team zou kunnen doen met hun eigen applicatie en wat voor nadelen dat voor 9292 zou kunnen hebben. De API tot de vervoersgegevens wordt (nog) beperkt vrijgegeven en zonder die gegevens zijn ontwikkelde applicaties weinig waard. Het lijkt dus niet veel uit te maken, dus waarom dan niet het goede doen?

Inspiratie

Mijn andere vraag was waarom dit soort conceptueel gebruikersonderzoek eigenlijk nodig is. De noodzaak en de behoefte lijken me apert.

We kunnen wel de wildste dingen verzinnen, maar op dit moment hebben we nog niet eens een fatsoenlijke app die de basics goed afhandelt. En dat is nog niet eens zo makkelijk, een applicatie als Trein.app ziet er heel simpel uit en is niet veel meer dan een dunne laag over mobiel.ns.nl, maar ik denk dat er veel tijd in zit om dat goed te laten werken.

GPS Primed Mobile Site

Er is op dit moment een 9292 applicatie voor de iPhone die op basis van je locatie de site opent. Dit is best een aardig idee en zou goed kunnen werken, maar ik heb hem pas getest.
Een paar weken geleden zaten we met vrienden op de verkeerde plek in Utrecht Terwijde en moest ik onder tijdsdruk snel een nieuwe route vinden naar een plek ergens anders in Utrecht, en de eerstvolgende bus, en de bushalte etc.
Dit was redelijk lastig voor elkaar te krijgen in de applicatie. Het was ontzettend moeilijk om een adres gevonden te krijgen, de kaarten die bij een advies komen zijn compleet onbruikbaar, en het is lastig om adviezen op te slaan en alternatieven te vergelijken. Met wat heen en weer schakelen naar Google Maps op mijn iPhone is het me uiteindelijk gelukt, maar makkelijk was het niet.
Bedenk dan dat Google aanbiedt om gratis en voor niets onze vervoersgegevens online beschikbaar te maken met de Google Transit website die op zich al bijzonder vooruitstrevend is maar die ook geïntegreerd is met de Google Maps applicatie op de iPhone. Waarom hebben we dat niet in Nederland?

Mijn vraag is dus niet direct waarom we de vervoersgegevens niet mogen hebben en aan Google mogen voeren. Ook al zou dat een hele goede vraag zijn, maar we hebben al gezien dat vervoerders daar nogal uptight over zijn.
Mijn vraag is meer of gebruikersonderzoek en testen niet belangrijker zijn om goede vervoersapplicaties te maken dan dit soort vrije conceptuele input.

Ik zie graag de antwoorden tegemoet.

Nimble hulks collaborate

It’s good to see not all newspapers are caught in a stupor the Japanese ones seem to actually be seeing their common interest and making something sort of useful to their readers.

First, it’s nice to see newspapers do stuff which is innovative instead of being stuck in the headlights and waiting to die.

Secondly, this adresses a real problem. On any commute I make with my iPhone, I theoretically can read all the news from the world’s best newspapers instead of grabbing a free newspaper from the box on the station. I’ve done so for a while, but lately I don’t bother anymore.
The reason I don’t bother is that it is too much hassle to lead the newspaper’s awful bloated websites over what passes for 3G in this part of the world, then select what I want to read and then read that. There are too many actions involved and the cognitive load is too great.

A simple app which works like a specialized RSS reader where you can triage for a specified set of newspapers and categories the articles you want to read and then get those in rapid succession would be a godsend.

Halsoverkop project-des-ontwikkelen

Taplin schreef van de week al dat de economische crisis onrust en onveiligheid op lokaal niveau tot gevolg zou hebben. Blijkt dat Dubai al het ravijn in glijdt en niemand weet hoe erg het daadwerkelijk is.

Nu is het nogal onhandig om in tijden van crisis de boel nog verder aan te halen en geen informatie vrij te geven zodat de paniek alleen maar groter kan worden. Het gerucht gaat al dat de eilanden teruggeclaimed worden door de zee (waarschijnlijk omdat de baggeraars zonder werk in Nederland zitten).

Wie had gedacht dat dunebashen in SUVs en snowboarden in het midden van de woestijn niet houdbaar zouden zijn? Als het Dubai-Disney niet eens marginaal economisch duurzaam is, hoe ecologisch duurzaam had het dan kunnen zijn?

Megalomane projecten waarvan iedereen aan had kunnen zien komen dat ze de noodzakelijke onderbouwing misten. Ook al durfden weinigen dat te zeggen in het aanzicht van het ‘economische wonder’. Nu hebben we gezien waar economische wonderen van analysten, investeerders en bankiers toe leiden.
Blijkt dus dat je geen wereld kunt bouwen in 10 jaar, ook al heb je nog zoveel hijskranen.

Van de week ging ook al het TVCC gebouw in Beijing in vlammen op. Het heeft er niks mee te maken maar een zekere symboliek valt niet te ontkennen.

Guidelines for government data

This weekend I visited the Barcamp UK Govweb (#ukgc09, barcamp) in London to talk with people about government websites, data and see what the state of the art is in the UK on this topic. It was a very interesting meeting and I learned a lot from people who’ve been doing this for far longer than I have been.

Stand around

Government Data

Open Government Data Session Tack-on Free For All

One of the most interesting was the session on government data and the various initiatives and other activities that are being advocated to give us better and easier access to government data to make cooler stuff.

A lot of issues about current initiatives were discussed, about various Click-Use Licenses and about how open data should be financed.

Guidelines

One of the things that I found surprising is that most people present were firmly against a set of guidelines about how to open up your data.

I agree that a set of guidelines like these if done improperly can cause more pain than they solve and maybe they are not necessary in the UK with the OPSI in place. In the Netherlands we would like an open data process where everybody who has data and would like to open it up could go to and get advice what the best strategy is.

I want to prevent situations where when faced with the problem how to open up data, a government body contracts it out and we get a site with a bunch of PDFs in return. Guidelines can’t catch all cases, but we should be able to create something which prevents the worst from happening while simultaneously not tying us down when we try to make usable systems.

Everybody present in the government data session implicitly knows what should be done when opening up data but the problem is that this knowledge is tacit and in that form is useless to any government official interested in opening up their data. If you’re in that position and you’re willing to consider opening up your data in a ‘developer friendly’ format, it would be nice if we had more to offer to you than some vague ideas.

None of the rules in the guidelines should be definitive, they probably should be in the form of a series of questions with explanations so people are forced to consider stuff and by answering those questions come to a better end result.

As far as I am concerned the main rule should be to avoid unnecessary complexity when publishing data and consider stuff such as potential users and their needs, licensing, description, URL/availability and data format. I agree you cannot draft guidelines which guarantee a good outcome but I do know that change is necessary.

Initiatives

During the session a number of initiatives were named, maybe somebody else has a more definitive list:

I think the Hack The Government Day that Rewired State are planning is a very good idea. It’s been something of a year since we had our last govcamp in the Netherlands but I also see the need to combine the currently running initiatives into a more developer related event.

Corporate obstacles in the Netherlands

I talked with Max Whitney at 25C3 for a bit to learn about how NYC Resistor came to be. The story seems to go something like this:

They find a loft in New York.
They find 9 people willing to plunk down some cash ($1000 each).
They setup a Limited Liability Company.
The LLC subleases the loft from the current leaser on a year contract.
Membership dues and workshop money (and the occasional party) pays the rent on the space.

This story is a stark contrast with what you would need to do in the Netherlands to setup something similar. I know because I’m in the market to expand our current coworking space both because we will be kicked out in April and because we could use some more space for stuff and projects.

So how is this different and much more difficult to setup in the Netherlands? There are a number of factors which contribute to this difficulty.

Zoning

Zoning laws prohibit using something like a loft for commercial/office-like purposes. If you’re doing a startup, the boundary of what is your house and what is your place of work may blur, but in the Netherlands an office is an office and a home is not an office.

Municipalities especially will not want livable houses to be extracted from the housing market and occupied by businesses because a lot of them already face a housing shortage.

Personal investment

People just dropping in some cash to get a space started is probably easier in New York too. One factor Max mentioned was that leases are ridiculously expensive anyway so people are used to paying a lot of money.

But a more important factor probably is that there is a bigger culture in the US of personal investment. What is annoying to startups here is that there are so few European angels. There has hardly ever been a significant internet cashout in the Netherlands and neither do we see a lot of reinvestment happening. On both coasts of the US there seem to be more people with money who are willing to invest it into cool stuff. The vast majority of people with money in the Netherlands are more boring than anything.

Liability

Limited liability companies in the Netherlands are called a B.V. and they require a seed capital of €18’000 to start. This money does not have to remain there but it is still a sizable hurdle. In comparison a British Ltd. costs €100 to setup.

Setting up a Ltd and using that to enter into a lease agreement in the Netherlands would be frowned upon because Ltds have a historically bad reputation.

Another way around this may be to setup a voluntary association or a foundation but to be able to shoulder liability, these would need statutes which need to be acquired from a notary and require a significant fee.

Subleasing

Subleasing spaces in the Netherlands is usually frowned upon especially when the sublessor makes a profit. This is because a lot of houses in the Netherlands are rent controlled and are rented out at half or less of their market value.

This means that a lot of houses are not being utilized to their full market value and that the supply in houses is far too small (and the supply of officeplexes too big). Rather than having the market clear this mess up, we are stuck with this heavily entrenched real estate system.

Lease agreements

Office leases are usually agreed upon for a period of 5+5 years, which mean you get a five year contract with the option to extend it for another five years. This five year contract is in fact meant to protect the lessee from fickleness on the part of the lessor but it does not take into account the fact that businesses may not want to be tied down.

This would not be so much of a problem if limited liability companies were easier to setup (the company would then take on the lease) but I treated that above.

Critical market

To be able to partially fund a space on workshop and party revenues, it helps if there is a large pool of potentially interested people. With the scale of something such as New York that may be possible, it’s a bit harder for us in Delft. We are at the moment somewhat pressed to find a fourth coworker let alone people who’d be willing to pay money to support us.

Concluding

None of the things I mention above are insurmountabel but I think they do in large part explain why Dutch business and venture culture is not as dynamic and booming as that in the US.

Our digital senses

In some of Adam Greenfield’s backpages “Whatever happened to serendipity?” he recounts how he used to scrounge for punk rock records and how the difficulty and uncertainty of the experience was part of what made it worthwhile:

But at the risk of sounding like an old man, this ritual – make no mistake, that’s what it was – invested the purchase with meaning and value for me, and I despair at a world that doesn’t at least offer the possibility of similar adventures to its inhabitants.

This resounds simply with the fact that things that are worth doing are oftentimes difficult to do or to learn and things that are worth having are the ones you invested effort in getting.

Just to narrow this down to music, 99% of the music I listen to has no meaning whatsoever to me. This has no bearing on the quality of contemporary music, which I think is actually quite high. Only a couple of albums and artists have managed to strike a chord with me that makes their music merit a repeat listen.

This may be different for others but the real investment of Fl. 45,– or so back then was quite significant, distribution channels were few and the diversity they offered near zero, you got your recommendations either from mass media or from word of mouth. The experience was radically different.

Yes, something has been lost in the transition but the abundance we have gained in return makes it more than worthwhile for me.

But the piece is about the loss of serendipity and shortly after he writes:

Yes, I suppose you could always switch the thing off, leave it behind, deliberately “forget” it. But when you’ve lived your entire life through the intercession of a mobile and benevolent Delphi, is that realistically an option? I suppose we’ll find out.

Having spent two and a half weeks in the United States most of which in and around San Francisco. I can testify that it is indeed not an option.

San Francisco is so well mapped within most online services that the experience you have there using the internet is unparalleled. Most services originate there which results in San Francisco being completely mapped in Google Maps, well covered in Yelp and there are ample Twinkling Twitter users in the proximity.

Unfortunately for a visiting European like myself it is prohibitively expensive to use roaming data, meaning that most of the time my iPhone was a multimedia brick. Being disconnected like this, made me acutely aware of how reliant I have become on the real and virtual compass my iPhone provides. Walking around without a continuous stream of data coming in on the iPhone felt as if a sense was missing.

What is a sense other than a mapping of external information to a part of your brain? The services on my iPhone provide me with a sense of presence and sense of direction within my spheres of contacts. My brain is conditioned to receive regular updates to this sense and withholding those updates used to be called something like “withdrawal from information addiction” but since this is a sense we’re talking about, I think “sensory deprivation” may be better suited. Without this sixth sense so much of your peripheral ‘vision’ is cut off that you feel like you are wandering around half blind.