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 github1.

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 ondersteunt2 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 platformen3 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 uitvoer4, 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 doen5. 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 komen6.

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 ontwerpers7 worden ingezet en zoals ik al zei is dat ook een essentieel onderdeel (maar slecht ontworpen is nog steeds beter dan niks).

  1. We hebben geen licentie afgesproken, maar ik weet vrij zeker dat je niet gesued zult worden. []
  2. Netvibes ondersteunt OpenSocial widgets al een tijdje in hun ontwikkelversie, maar ze hebben het nog niet op de site aan gezet, misschien omdat dit de doodsteek zou betekenen voor hun UWA. []
  3. En dan hebben we het nog niet eens over de verschillende browsers als platform. IE6 is een beperkende factor en het zou misschien het meest twee-punt-nulle zijn wat de overheid kan doen om overheidswijd IE eruit te flikkeren (Chrome schijnt goed te zijn…). []
  4. Als we data dan herbruikbaar maken, laten we het dan in één keer goed doen. []
  5. Jammer, want Ning is een redelijk belangrijk doelplatform. []
  6. Al aangemeld, laten we hopen dat het probleem zichzelf opklaart. Google is niet heel responsief. []
  7. Gek genoeg zijn ontwikkelaars best bereid om bij te dragen aan open source projecten maar zijn de meeste ontwerpers er niet voor te porren. Nu kun je ook vraagtekens zetten bij de kwaliteit van de code die daar geproduceerd wordt, maar dat is een ander verhaal. []

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 buiten1. 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 vergunningen2. 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 voor3.

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.

  1. Er is misschien sprak dat er op de middellange termijn een publieke webservice komt, maar dat is nu nog niet duidelijk. Het is dan ook nog de vraag of die webservice SOAP of REST zal zijn. Voor ons op het open web is het een gelopen race maar grote bedrijven en overheidsorganisaties komen nu net kijken en aan hen wordt nog steeds SOAP verkocht als dé standaard. Waarschijnlijk blijven we op deze manier altijd achterlopen, maar SOAP is beter dan niks moeten je maar denken. []
  2. Dat is op Vergunningenkaart ook niet zichtbaar en daardoor is het nut van die site wat ons betreft redelijk beperkt. []
  3. Als iemand me de zin van xCal uit kan leggen, hoor ik het graag en ik had liever ook een hCalendar opgemaakte pagina gehad die met X2V over te zetten is. []

ThingsCon Amsterdam 2016 Talk

Tweet coverage of the 2016 Bot Summit at the V&A in London

I was at the 2016 Bot Summit in London a couple of weeks ago. I did my best to capture salient points from every talk in a tweet. Here are all of them in order.

Talk at Interaction16

I just got back from Interaction in Helsinki having given my talk about how Conversations are the New Interfaces.

I have been blown away by the response to and kind words about my talk. I think this is a conversation (!) worth continuing. Stay tuned for details on that.

Here now is a collection of photos I found of my talk (for my personal archive):

OSM Live Edit Screensaver

I’ve been running a live open streetmap edits view as a screen saver for a couple of years now and it never fails to draw the attention from people in the room (whether they know what OSM is or not). The OSM visualization is pretty cool and really comes to life when it is displayed full screen. It is also a great way to see a part of the world you might not have known existed. I used to browse atlases when I was a kid, so this is me indulging in virtual travel again.

Will attended me to the fact that I shot a video of it but I never wrote up the super basic process behind it, so here goes.

What it looks like:

This must have been the tweet by Thomas that started it all in early 2013.

After I read that I fiddled around a bit with making my own screensaver in XCode. That seems simple enough but building stuff on OS X is a bit of a pain if you’re used to iOS and definitely not something you’ll be able to finish in an hour or so. It turns out that there is a far far easier way.

  1. Install the webviewscreensaver. Thanks to Alastair Tse.
  2. Plugin the URL to the live OSM view into the screensaver. This one: http://osmlab.github.io/show-me-the-way/
  3. Enjoy.

Actually it’s about ethics in software engineering

This is an expanded transcription of a tweetstorm (based partially on conversations with Peter) that starts at this Tweet about the Volkswagen emissions scandal but actually as we go along it will be clear that it is about ethics in software engineering. First the news that started it all.

Volkswagen’s US head Michael Horn blamed his engineers during a testimony about the emissions scandal.

Does anybody believe a German multinational is agile enough for a couple of engineers to be able to ship a feature without oversight? Because on the one side as people have commented if this were true that would leave huge questions open when it comes to their quality control and delivery process. On the other side if true it would be a refreshing level of agility in a German corporation. A car maker that uses the tagline ‘move fast and break things’ would certainly be a novelty.

I would be curious to see what the codebase of a modern car looks like but thanks to the DMCA that will probably never happen. Unless maybe if somebody dumps the VW code during the CCC this year?

This isn’t about car manufacturing or recruiting engineers, this is actually about ethics in software engineering. How this will affect VW’s chances of hiring the best engineers (“Volkswagen, and how not to describe your employees”) is one issue. They couldn’t hire the best anyway but they will likely always be able to hire a fair level of talent. To write good code, having a clear vision and a stable process are more important than having a mythical 10x engineer on your team. The questions now are why this took so long to be discovered and what the consequences are for the various parties involved.

I will focus on the software engineers because I am one and because I think they will be underrepresented.

Programmers could get away not caring about ethics when it involved being callous with user data or new ways to serve banner ads. The proliferation of really weird privacy-invading ad tech used to be considered a perfectly acceptable way for engineers to spend their time. Even the leak of sensitive user data like in the Ashley Madison hack was more or less business as usual among digital companies. Software companies being liable for their errors and engineers engaging in ethical behaviour were considered optional.

Not anymore. You probably wish you hadn’t snoozed through that ethics class in university. Not that that would have helped that much. Unlike many others, in university we got courses in both ethics and in the history of science and technology. Courses which at the time were much maligned by my fellow students for their lack of practical application. They were right that that course wouldn’t have helped you much by itself, but some basic level of understanding on this subject is nice to have.

Besides continuing to teach ethics, schools should teach engineers about rights and liability. Those courses in ethics could be supplemented by a practical course about your rights and liabilities when you are working at somebody else’s company or at your own. It used to be that either nobody cared about this stuff or that the company would bear the consequences. Both of those notions seem fairly shaky right now.

What do you do when your boss tells you to implement a feature, or very very strongly encourages you to reach a certain outcome? What VW seems to be arguing is that nobody gave the order to build this specific feature but it arose from a rogue group of people. That seems just as unlikely as the case where this was mandated but VW management maintained the operational security required to keep it a secret. The investigation almost certainly will reveal that an order was given and who gave it.

In an ideal company a manager of course will not tell their people how to do their work. Your boss should give you an ‘Auftrag’ (assignment) to reach certain strategic goals and leave it to you to determine the best way of getting there. They will trust that you will operate to the best of your ‘Fingerspitzengefühl’ (working knowledge) within the framework that is the norm in the ‘Einheit’ (unity) that is the company. This all borrowed liberally from Chet Richards’s excellent Certain to Win.

Even if an order was not given this points to an atmosphere in which exerting huge pressure is normal and where people consider it standard operating practice to cut corners maybe even without informing their superiors.

What recourse does a software engineer have in that situation? The current policy situation and broader environment suggest they have almost none.

Who’s responsible when that feature threatens the planet, evaporates shareholder value and leads to criminal investigations? Now that software is a determinant in one of the biggest industries in the world, bad actions have large consequences. Selling millions of faulty cars and exposing many millions more to pollution finally gives us a software malfunction that everybody can relate to.

This isn’t just the case for VW since other car companies are also implicated in fraud during emissions testing. It isn’t even exclusive for car makers since the sequence of events leading up to the financial crash were nothing but a large number of model/software malfunctions.

In the case of the financial crash nobody got punished. The American enthusiasm to extract punitive damages from VW may be attributed to the fact that the U.S.A. finally is a relevant player in (clean) car technology again.

Because these are the biggest industries in the world with immense resources and influence, normal or just rules of responsibility don’t really apply.

We need to answer these questions ourselves because if you ask the higher-ups it is clear who’ll get thrown under the VW bus. Software engineers can refuse to do work that they find ethically objectionable and find another job easily (the Snowden option). That is a luxurious position but it still remains to be seen how many actually do this.

What will likely happen is that the legal investigation will take forever and in the end some convenient people will take the fall. I think it’s unlikely that that will create a just outcome or improve the overall situation.

The criteria to which these emissions tests were held were already watered down thanks to the lobbyists of various car companies who also set the tests so that it would be easy to cheat on them. The tests may be fixed a little bit ostentatiously because they are the most visible point of failure.

The actual problem will go unfixed. We can’t independently verify the code that runs in cars now thanks to our broken copyright legislation. When cars become self-driving and dependent on remote services this will become infinitely harder. We are not be able to check software running in our devices to see whether it does what it promises to. That is the real problem and one I don’t think that is going to be fixed anytime soon.

Update: So today the word got out that some 30 managers at VW were involved in this. It looks like Michael Horn’s statement about the rogue engineers was not true.

Insurance in the age of big data and personalized tracking

Last week there was some debate spurred by some of the larger insurers of the Netherlands who want to use tracking data to personalize insurance coverage. A piece in the Reformatorisch Dagblad of all places and Rob Wijnberg talking about it at DWDD.

The problem is that insurance by definition is not personalized and we should be protected from each other’s best interests. I tweetstormed about it and have recorded it below.

This is particularly salient from a design perspective if you see the tweets below. What this comes down to is a policy design problem of a vast scale, a level of abstraction up again from service design. People aren’t well equipped to make these decisions for themselves and they probably shouldn’t have to be. They should be aware of which expertise they are lacking and they should know who they can trust. Creating those two competencies are the two hardest problems of our time.

Breaking into the English speaking world

Last week we finally got featured with Bycatch on Boingboing and Fast Company thanks to our invitation to the XOXO festival. It is amazing to see what that attention does and what kind of effect that has on sales.

Now that we have finally arrived in the English speaking world we can relax a bit and keep pushing out the marketing we had planned all along. I would be curious to see whether something similar happens at some point for Japanese and Chinese speaking online communities.

The redesign of Moritzplatz roundabout

This is turning into a traffic blog more than anything else. After taking stock of the plans for the new Maaßenstraße which is very slowly nearing completion, now let’s take a look at another place close to my heart: Moritzplatz. The square is right underneath my office and as such I cross it several times daily both on foot and by bike.

Cyclist get hits on MoritzplatzA couple of weeks ago week an accident took place there where a cyclist was touched by a car. No big deal in his case, but it could have been worse considering the way motorists behave here. I have to pay close attention every time I cross this roundabout otherwise this could happen to me as well.

Redesign

Two weeks ago they started marking what is to be the revamped Moritzplatz. I had my hopes up that it would be a serious improvement but judging from the plans it is mostly going to be a new paint job.

New lines on MoritzplatzThe paint job will separate the bicycle lane with stripes from the car lane narrowing the space the cars get and widening the space the bicycles get. The cycle lane itself will be painted bright red. New lines on Moritzplatz

Cycling on the new markings and adhering to the new situation is a bit weird but it does feel like it’s going to be an improvement. It is however not going to fix the most important problem with the square1.

Redesign Moritzplatz

The new situation for cyclists

Cyclists get their lane doubled in width and protected by markings. Whether that protection will mean anything in reality remains to be seen. Cars in Berlin will drive anywhere they please. What is a bigger problem on this roundabout and what will remain so in the new situation is that it is unclear who has precedence on the points where cyclists and cars have to cross each other. The angle with which the two cross has also remained the same so you really have to pay attention not to hit a cyclist and not to get hit by a car. A real solution would have been to mark the roundabout with Sharks’ teeth and maybe even to elevate the cycle path. That way cars entering and leaving the roundabout notice that they do so physically. Physical separations on the road make the power dynamic a little less unbalanced like you can see in this example from California. They are of course also expensive. There are roundabouts in the Netherlands that are laid out this defensively even though that usually is not necessary. Schermafbeelding-2012-07-03-om-13.52.56-480x309

The new situation for pedestrians

Pedestrians around Moritzplatz have really been shafted and they are getting a tiny improvement in the new situation. For a pedestrian there is no safe way to cross the square. The underground crossing through the U-Bahn station does not count. Going down and up stairs2 isn’t an option for disabled people and it’s too much effort for most people in general. Traffic should be safe for its weakest participants so that it benefits everybody. Let’s take a look at the various options to cross Moritzplatz. Keep in mind that you will often have to cross at least one arm of the roundabout to get anywhere. West – There is no way to cross the road here except for the traffic light at Stallschreiberstraße. This traffic light feels broken for pedestrians because during rush hour it gives you about 12 seconds to make the crossing. Almost nobody makes it across during the green phase and everybody knows that the red phase takes forever so people also cross when it’s already red3. The traffic light is not an option for crossing Moritzplatz since it is 50m away. That is too far. North – On this side there is an island in the road where pedestrians are relatively safe so at least they don’t have to make the entire crossing in one go. It is still unsafe because there isn’t a zebra crossing but it’s better than nothing. East – There is no way to cross here except for the pedestrian crossing 50m down Oranienstraße. South – A new pedestrian island is planned here. Unfortunately it is 15m off the main arm but that is better than 50m. Just like at the other islands, there won’t be a zebra crossing there which makes any pedestrian trying to cross still a potential victim. Redesign Moritzplatz

It doesn’t matter if there is no way to cross the road, people still do of course. Even if you pay attention and cross the road when there is no traffic, incoming cars expect to be able to push you off the road4. At which point you are forced to run across or be killed.

The main flaw here is that people shouldn’t be forced to walk ten or fifty meters more to make things more convenient for motorized traffic. People are more important than cars.

Update: The work is nearing completion and actually the new markings do not seem to make that much of a difference except to cause everybody on the square to be fairly stressed out.

I guess this adequately describes all of us.

  1. Thankfully it’s not going to be botched as badly as the redesigned Kottbusser Tor roundabout. []
  2. Moritzplatz does not have an elevator for some strange reason. []
  3. German pedestrian lights don’t have a blinking green phase in between green and red. []
  4. I actually cannot comprehend how this is acceptable behaviour and why these people are allowed on the road at all. []

Terry Pratchett

Though I didn’t read him for very long, Terry Pratchett’s books in the local library translated to Dutch were my introduction to both fantasy and a certain kind of critical way of looking at the world. Only now I’m finding out how many other people were deeply influenced by Pratchett. I’m also glad to see how a literary establishment that had studiously ignored him and all genre fiction for all that time now has no other choice but to admit that they were wrong.

Turkey’s stolen elections

I have followed the Turkish elections on the night from Sunday to Monday which turned into a gripping account of prime minister Erdogan trying to steal the elections while most of the people were sleeping. Orchestrated blackouts had drawn out the count. The twitter block didn’t prevent activism from spreading but did reduce the reach of its effects. Those that knew and cared about it were at the counting locations trying to safeguard the ballots and the tallies.

The tally notes were shared to be able to corroborate them with entries into the online result system. Most of those results have been off, some by a small amount, some by a larger amount.

Altogether it was a mess and from the cross section of tallies I’ve seen it’s hard to believe that the AKP would have fully swept Istanbul and Ankara. What follows now is a long process of chasing the issue into Turkey’s notoriously horrible judicial system. It is unclear whether that will have an effect other than reducing the trust people in Turkey have in institutions even further.

What that night did teach me after the lukewarm Dutch municipal elections is that democracy is an institution worth defending both when things are calm but especially when times are tough. I am finally allowed to participate in a vote in Berlin. The European Parliament elections may be lackluster but I’ll take whatever little democracy I’m given.

I’ll post back here about how that vote and its count goes.

Something else that is noteworthy is the dismal coverage the elections got in the Dutch mainstream media. For any kind of news event that you are interested in, following tweets either in the local language or by English speaking commentators on the ground provides a far better experience. What I saw on Dutch television and in Dutch newspapers was predictable, shallow, disconnected and actively shameful.

We don’t need saddles nor do we need faster horses

We just switched over to Slack and we are quite happy with the tool as a replacement for our previous Hipchat setup. It all feels a bit fresher, it’s easier to integrate with the rest of the web and has more functionality and niceties built in.

I did have this frustrating twitter conversation with them about what I think is an important topic:

The problem is that it is difficult to use these tools if you are part of several organizations. The way people work these days I could be part of a dozen or more companies and non-profits. Slack is a bit more flexible and it allows quick switching between logged in organizations. What it doesn’t give you is an integrated view of your channels across organizations.

The way we use Slack may be different from most others people. We use it both to coordinate intensively around projects in private rooms, but besides that we have a couple dozen friends from all over the world in a couple of open channels1 who help us create and maintain our company culture. None of these people are ‘part of our organization’ per se but they all belong in our organization.

The hermetically sealed company wall is the anomaly. There are more free agents than ever who work in flexible configurations. This is a trend that does not show any sign of abating. What the twitter exchange above shows is that Slack either does not understand this or they don’t want to understand this. This is fine but also a bit disappointing for a company that wants to be visionary when it comes to new ways of working together.

I criticize because I love Slack. If there is any company that can help us work together in this new world, it is probably them. But for that to happen we need to start having these conversations.

  1. Which is also why we may be stuck on the Lite Plan indefinitely. []

Cuntstar né Congstar

I’m currently at a German MVNO called Congstar. Partially because somebody told me that they have LTE (which is not true) and partially because I had gotten rather fed up with my Vodafone prepaid plan (branded CallYa). Like any service in Germany this one too is terrible and since then I have come to call them Cunststar.

The website is an utter pain to navigate and essential information is spread out across major sections. Other essential information that you would like to have such as how much money there actually still is on your card is not available at all. Added to that there is no actual customer support but instead you are allowed to navigate through a maze of fora, bots and other things not at all relevant.

Still it gives you a data plan and such things are rare in Germany. There are also some switching costs to trying out all of the other MVNOs as well which are probably just as bad. So I stuck with it.

My latest ordeal came when I tried to upgrade my 1GB plan to a 3GB plan. Trying to give these people more money turned out to be quite difficult. It wasn’t very clear but I had to wait for the 1GB option to run out. Then out of the blue I got an SMS yesterday night that it was gone.

I then tried to activate the 3GB option. At that moment I had enough money in my account to be able to buy that option:

IMG_8440

Still Congstar wouldn’t activate it and as if by magic the next morning some money has disappeared to make it just out of reach. I have no idea where the money went and Congstar won’t tell me:

What is to say that these operators don’t shave off money from customers’ accounts when it suits them? Due to the lack of information from them it is impossible for a customer to verify where the money goes to1.

The major advantage of this plan over my previous prepaid is that I don’t get SMS spam all the time. Small blessings like that are all we can hope for in the land of telcos.

So why don’t I get a non prepaid plan? Because in Germany those are insanely expensive, all run for 24 months and LTE is but a faint glimmer on the horizon.

Update:

There is indeed a usage view but it shows that some time after I tried upgrading my plan (which failed) my phone tried to use the internet and incurred some charges.

Obviously if you don’t allow people to add a data plan if you wait long enough their phones will use data at some point when they can’t get a WiFi connection and you have a good excuse to let them pay more. Telcos are a bottomless pit into which we can throw money for all our lives.

  1. Well we know it went in some douchebags pockets. []

Week 323

This week started with Pentecost. Trying to get stuff done in Germany during the bank holiday flurry that is May is always a challenge. I spent more time working on Cuppings. In all likelihood this app will never make any serious money, but there are other advantages to building apps which may become apparent in the future.

This week I gave an interview to Süddeutsche Zeitung about our project Politwoops which turned out pretty well:

Politwoops in SZ

Just before German class I was interviewed in German about altogether different matters:

KANT is slowly shaping up:

KANT in action

I received this device to be able to live digitally in the outdoors:

A cloudy start for my Wakawaka Power

And end of that week I spent some time writing and especially my piece on data was picked up nicely and got a record amount of views:

And the next day Peter and Michelle got married which was a tremendous amount of fun:

Vorstellungsronde

Week 322

So it turns out I’ve fallen immensely behind with the weeknotes over here, but we did start writing them at the new office now, which should make up for something. Those live at http://kantberlin.tumblr.com/ currently.

What happened that week was a bunch of work and getting a desk from IKEA to work on at the new place:
Upgraded to a small-ish roller desk

The Möbeltaxi driver took us on an interesting shortcut through the old service tunnels of Tempelhof —I am amazed that Moves tracked it as well as it did— which might be fun to do some urban exploring in at some point:
Secret route through the service tunnels of the old airport. Useful when there is traffic which is more or less always.

Back then we were still drinking some horrible leftover coffee brewed in a two step process:
The morning press and filter

And I had a talk for at Bits of Freedom that I sketched out on our brilliant new whiteboard:
I gave the new whiteboard a proper exercising for an upcoming talk

I promised the people future shock and I think I delivered that to some extent.

Week 269: Talks given and posted

The Hybrid Talk I gave the week before is up on Soundcloud. You can listen to it here and see if you agree with our ideas about how a client driven organization can operate without being rubbish.

The rest of the week was spent preparing the presentation for NEXT Berlin about Love in Times of Gamification. It went well (1, 2, 3, 4) and should be online shortly. It was an honour to be invited and to share the stage with James Bridle, David Bausola and the many others present at the event.

After that it was time to unwind and meet a lot of nice people and go for a nice dinner.

Even moahr meat!?!?

Next came the recovery part of the week. Also Iskander Smit wrote a nice recap of NEXT.

The fuck is this…

Week 268: presenting on transit and work, talking with Neelie Kroes

This week was marked by a massive sprint on saba which made me miss this year’s Myfest in Kreuzberg, which is annoying but survivable. I did manage to see Ryoji Ikeda’s Data Anatomy on its last day in Tresor. A visually spectacular but thematically flat affair.

Data Anatomy by Ryoji Ikeda - uploaded the last build and finally managed to make it out here on the last day

The next day Stefan Wehrmeyer and I went to the Abgeordnetenhaus Berlin to present on the subject of open transit data.

Stefan killing it (open transit data)

The situation here when it comes to opening up data is rather shameful. It seems hard for transit operators to realize that information about their services is an intrinsic part of their services. People who don’t know how to get somewhere, will also not buy any tickets.

This seems counter productive if you assume that transit operators actually want to transport people which it seems they do not. They want to serve the terms of their contract as cheaply as possible and as long as open transit information is not stipulated within that contract they will not do it. Thankfully Berlin politics is moving on the subjects (because the next tender is not due for many years).

Today's office

On Thursday I prepared and gave my talk for Hybrid Talks at the Berlin University of the Arts on the Heist Model which went quite well. I am going to write that particular presentation up on the Hubbub blog soon because I think it has a lot of mileage still. Most of the ways of organizing work that are doing the rounds assume you are a company selling a product, not a company doing work for clients.

On Friday I went to re:publica with a familiar theme. In any case it was a good opportunity to meet some people I hadn’t talked to in a while and to see the narratives being told in German about the internet.

Neelie Kroes

After the keynote by the Vice President of the European Commission Neelie Kroes, I got the opportunity to meet with her and discuss pressing issues when it comes to the digital agenda. I decided to step out of my immediate day to day worries and speak out for programming education for all school children (more on this soon, I hope). This struck a cord with her, but somewhat confused many of the other attendants who were more keen to push their pet agendas.

Hanging out with EC Neelie Kroes

Book presentation A Smart Guide to Utopia cc @tobybarnes @benhammersley @agpublic

After that I rushed over to Markthalle IX for the book launch of A Smart Guide to Utopia.

Most of the weekend after that was spent preparing my presentation for NEXT this week.

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 tooling1, besides that we have proper standards for identity and authentication2.

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 absurd3 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 it4.

  1. cURL as the simplest example []
  2. And it’s all open which means it can’t be hijacked by one party and controlled or made needlessly complex. []
  3. Client: “Yeah, you can do that when you have time to spare.” []
  4. Or like Chris says it: “This can all be made better. Ready? Begin.” []

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 tooling1, daarnaast zijn er goede standaarden voor identiteit en authenticatie2 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 gevalideerd3) 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 kost4 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.

  1. cURL bijvoorbeeld []
  2. En het is allemaal open waardoor één partij er niet een onevenredig belang bij heeft om het te controleren en complex te maken. []
  3. Validatie zegt niet zoveel trouwens. Ik krijg vaak genoeg valide XHTML-code die compleet onsemantisch is. []
  4. Opdrachtgever: “Ja, doe dat maar als je tijd over hebt.” []

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 foundation1.

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.

  1. Just look at Twitter which had its problems but also is breaking new ground in this field. []

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 September1— 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%2. 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 one3?

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 how4 we will get there.

  1. Though it will be interesting to see how far Apple will have advanced the signposts by then. []
  2. In many cases it’s not even possible to do that. []
  3. You may notice that Netvibes offers the option to intall widgets to Desktop widget runtimes and Google does not. []
  4. And how will Nokia’s interests in widgets, lightweight applications, device APIs and their own webkit browser relate to these developments? []

Widget distribution and other considerations

I am currently busy doing a project together with Tam Tam where we are tasked with developing a set of five widgets for Dutch government (assigned by the Dutch Ministry of Home Affairs and Kingdom Relations) as a proof of concept of how government data can be used. We’re developing widgets mostly because they are seen as modern, easy to develop and they can be deployed very near to users.

As a prerequisite for building these widgets, we need to work on the data sources to make them easier to use and better fitting to the available data and potential uses. Getting these data sources sorted out also provides a longer term benefit for any other party who would be interested in using this data. Our widgets are but one potential implementation in a realm of possibilities. Anybody can take the data source the widgets use and make something different and/or better. That vision is beyond the scope of this current project but it is also being worked on.

For this project we need to find a way to develop widgets which are deployable to a multitude of platforms with as much ease as possible. There are far too many widget platforms out there, as can be seen in this presentation by Niall Kennedy and because this is a Dutch project there is an elephant in the room we have to take into account.

Data sources

The data sources we got were already halfway there. Some were not machine readable, those that were, were either not very well formed or did not include as much data as one would like. We filed change requests for some modifications but these move slowly in some cases. The data sources we are going to use and republish would ultimately be:

  • RSS, preferrably well formed Atom and in some cases RSS 2.0 with media enclosures and/or geodata
  • iCalendar (or xCal1) probably wrapped in RSS
  • generic XML or simpler still (CSV, TXT)

Personal vs. Public Dashboard

For widgets there are two major contexts in which they are run, either on personal dashboards such as iGoogle or Netvibes (or on public versions of these but dashboards nevertheless), but much more interestingly on social networking profile pages as a display of identity.
Ideally the widgets would work on both, though the uses of some of the data sources do not lend themselves well to be displayed on public vanity pages. Nevertheless being able to deploy widgets to both would be very welcome.

Taking the greatest common divisor of platforms restricts our set of functionality. There may be specific API methods available on each platform —most notably the social APIs exposed in the social networking platforms2— which would enable us to make socially aware widgets. Incorporating sociality and the notion of a specific user is beyond the scope of this project. We most probably will rely on the cross platform nature of the client side and rely on the platform to supply us with a HTML rendering environment.

Important target platforms

Clearspring has a list of ‘drop targets’ which is pretty large. Because this is a project by the Dutch government and it is principally aimed at the Dutch public, we need to cover the online places that Dutch people use a lot first and foremost. This mostly means that we are not so interested in Orkut and Hi5 but more so in Hyves and MSN Live3.

Hyves has a coverage of about 5M people in the Netherlands, MSN messenger and by extension the entire MSN platform should be bigger than that. This alone makes them very important to support and test for.

Considerations

The government has some additional considerations which need to be taken into account when choosing a platform and or a technology.

  • Dutch government tries to adhere to open standards and open source software wherever possible. This is not a hard requirement but it does influence decisions as far it is practical do so.
  • Dutch government should strive to be independent of commercial partners and definitely should not mix commercial branding with governmental information.
  • We need to consider a wider growth path towards the future so sustainability and scalability of efforts and platforms are considerations.
  • In some cases exerting tight control over appearance and functionality of a widget may be desired.

Platforms

There are a number of technology platforms that can be used when developing a widget. Each of these has its own advantages and disadvantages and implications for eventual deployment.

Flash
Any platform that allows the use of embed codes in the HTML is a suitable host for Flash widgets. This type of widget is very popular mostly due to its ease of development and deployment, and full graphical control within the widget. Disadvantages are that ease of modification and reuse are severely limited because the platform is not very open and well known (at least not as well known as HTML), which will deter reuse and remix of widgets in the future.
After some deliberation we chose not to use Flash. Creating or reusing Flash widgets necessitates the use of an expensive authoring environment. This does not fit into the widest possible reuse, either within government or outside of it. Most of our data sources also mandate more text based and less graphical widgets, so Flash is not strictly necessary. And finally anybody who wants to make a Flash widget can embed it into any of the chosen technology platforms without any problems.
Straight HTML and JavaScript
A widget is a piece of a webpage and it happens to be that a (piece of) a webpage can also be used as a widget. Any webpage that displays a very specific piece of functionality on a limited amount of screen can function as widget.
Allowing the upload of a simple HTML page and wrapping that in an <iframe> or similar is the approach taken by some platforms and it works quite well. An advantage is that the widget may be rendered by a fragment of the same template that rendered the main webpage. Disadvantages are that the widget is not aware of its surroundings and does not have a way to set or retrieve settings.
iGoogle Gadget
An iGoogle Gadget is a web page as described above wrapped in an XML document with some metadata extensions and a wrapper around some javascript calls to provide settings functionality and proxied XMLHttpRequest4.
OpenSocial Gadget
An OpenSocial Gadget is an extension of the iGoogle gadget platform with some social extensions to the API which make a gadget aware of its social surroundings (logged in user, profile user, friend list) and allows gadgets to send messages to various activity streams. An iGoogle gadget will run in an OpenSocial container and essentially function as an OpenSocial gadget without social functionality.
Netvibes UWA
The Netvibes Universal Widget API is a way of creating a straight HTML page in such a way that it can be recompiled and served to a series of target platforms. There are some metadata extensions which have to be followed, the scripting environment is both extended to include settings and sizing, and the DOM is severely crippled5. The UWA relies on the fact that most widget runtimes are de facto HTML rendering environments with many similarities and bridges the differences.
Just this week Netvibes announced the release of an OpenSocial compliant UWA which should make UWA widgets run on any OpenSocial container and make Netvibes itself also an OpenSocial container. A release of this new version is still forthcoming.
Facebook
Facebook applications need to be written in the FBML which is specific to Facebook. There are some widget distribution options which wrap a widget and republish it as a Facebook application but currently Facebook is not a large priority for this project.
Sprout
Sprout is a very interesting platform which provides a web based Flash widget builder where anybody can very easily use drag an drop to build their own widget from standardized elements (no programming required) with both simple controls and complex ones backed by outside data sources. The provided set of elements should cater to most needs, but being able to modify and build additional controls would have been very nice.
For this project it may not be the best starting point but if we make our data sources clean and standard, anybody can plug them into the Sprout Builder and rapidly build their own versions of our widgets.

Widget Diagram I have made a diagram (PDF) summarizing the various options, platforms and eventual deployment targets in the widget landscape. This diagram is not complete but it gives a good impression of the complexities involved.

Test application

To define a simple test application to write and run on the various runtimes. The application should:

  • Display some HTML
  • Use custom CSS to style the elements
  • Be able to display images
  • Be able to retrieve RSS/XML data from the same server
  • Be configurable with user preferences

And some softer requirements:

  • Be able to embed Flash content
  • Be aware of its own dimensions
  • Respond to resize and refresh actions of the widget platform

Here is the test application as a plain HTML file, a version which should run on the iGoogle platform and a version for the Netvibes UWA. It looks quite horrible because it does not have proper styling, but it does most of the things listed above. Translating the base HTML version to the specific platforms was not too difficult, but somewhat idiosyncratic. There are some specific metadata elements which need to be accounted for, the DOM is altered in some cases and there are platform specific calls for XMLHttpRequests that use a local proxy to retrieve data. What is immediately apparent when working is that the documentation on the Google platform is far more comprehensive.

This test application was then run on the various platforms and galleries where applicable to see if it would work and what the options for redistribution per platform were. The experiences of these tests have shaped our impressions of the various distribution options. Our findings are discussed in the next section.

Galleries

Galleries sometimes have widget building options but most of them are concerned with spreading a widget to as many platforms as possible and monitoring the reach of the widget. Important considerations when picking a gallery (if any) are:

  • the input options, what kind of widgets this gallery will accept
  • the output options, to what platforms can this gallery spread a widget
  • look and feel of the gallery and of the widget wrapper
Netvibes

The Netvibes ecosystem provides a way for people to browse widgets submitted to the ecosystem and install them to either Netvibes or to a number of other platforms. The gallery also shows an install count per widget.
The Netvibes ecosystem accepts: UWA widgets, iCal files, SWF files.
The Netvibes ecosystem publishes to: a blog, iGoogle (install and gallery submit), Vista, Live, Dashboard and seems to work all right.
Clearspring

Clearspring is a generic widget gallery service with methods to widgetize page content and completely manage a widget.
Clearspring accepts: SWF, HTML, Javascript (not very clear how this would work) and Image widgets.
Clearspring exports to too many platforms to mention, notably: Blogger, embed, iGoogle, Live, Dashboard, WordPress, delicious, e-mail, Facebook, Netvibes, Typepad. Clearspring can also publish directly to the Netvibes, Live and iGoogle galleries.
The options look fairly good but the inwidget functionality borders the widget with an ugly border through which the functionality to add the widget to other platforms is implemented.
Gigya
Can’t really get Gigya to work. It looks mostly focused on Flash widgets but the site is a mess and the documentation is very sparse.
Widgetbox

Widgetbox is a partner of Netvibes
Widgetbox accepts: Flash, HTML+Javascript pasted or remote, Atom/RSS, Google Gadget
Widgetbox exports and shares with some platforms such as Blogger, Netvibes, iGoogle and WordPress.
A Widgetbox wrapper also includes a very ugly border button that enables visitors to add the widget to their platform of choice.
Widgadget
Widgadget has severely limited creation and publication option, documentation is sparse.
Spring Widgets
Spring Widgets offers an SDK for Flash based widget development and seems to be exclusively focused on Flash widgets.

Various OpenSocial sites (Hyves, LinkedIn, Ning) have their own galleries for applications and their own policies on which to include. Most of these sites also have sandboxes where inputting the address to the gadget.xml file suffices to run an application. Hyves for instance has to give their approval of your gadget before it is included in the site.
On the subject of galleries our clients remarked that the appearance of control and non-commerciality needs to be maintained. Widget galleries which are all too present on the widget and exert a lot of control are not preferred. It is completely undesirable (and understandably so) to see the Clearspring logo mixed with government branding and data. So because galleries are not essential, they are mostly out of consideration for now.

Conclusion

During a final meeting based on this research, we presented our findings and got some more input as to in which direction we should focus and the consequences that would have on our final platform choice.

HTML vs. Flash

Using HTML in favor of Flash proved to be contentious but the compromise was chosen to have the basic functionality of widgets be done in HTML markup. Interested parties can always have a Flash widget developed and embed that in a chosen technology platform or use it standalone.

Platform choice

Based on the techology choices and the platforms that it definitely should run on: iGoogle, Hyves, LinkedIn, Ning our choice of platform is quickly reduced to either UWA or iGoogle. UWA widgets can already be compiled to iGoogle gadgets and with the upcoming release of the next version they should also more easily run as OpenSocial apps, but this version has not been released yet. The coyness of the Netvibes team6, together with the sparsity of their documentation makes you wonder if this latest release of OpenSocial support7 isn’t a last ditch attempt to regain relevancy. For all we know Netvibes may cease to exist tomorrow, so sustainability is certainly a question.

On the other side if we choose for iGoogle gadgets to be the widget platform of choice, it will run on most of our target platforms and with the new version of Netvibes it will also run in their OpenSocial container. The only thing that we will not be getting are Netvibes recompilation options for Dashboard and Vista8. iGoogle/OpenSocial looks like the platform with the most momentum and momentum is worth a lot.

Genericity

There is a strong desire to make the widgets in the project as generic as possible to enable reuse for other applications. At a certain point there was the idea that we could make one widget to do everything, this however is not really advisable.

We defined a set of widget archetypes (news, events, images, videos, geodata, calculation, infodisplay) where a widget may fall into and we think that for the future it would be useful to have reference implementations of each archetype on file so that a request for a new widget can quickly be fulfilled by taking an archetype widget and customizing that.

For this project though, we will be making specific widget implementations which can be easily generified to their archetype. So after we make a branded news widget, any interested party can swap in the RSS feed and their own logo to make it theirs. We thought it would fit better in the modest scope of this project to deliver conclusive results instead of half-finished products.

Gallery

Given this choice of base platform, if we were to use a gallery to ease distribution and monitor its reach, we would probably use Clearspring because it seems to be the most mature and functional of the lot (Clearspring is also used by the CBC (see their presentation at the Widget Summit)) with Widgetbox as a close contender. But because of the all too visible branding of Clearspring and other containers, we will not be using either9.

Call for comment

Fortunately we do not have to make a definitive choice right now. For our set of widgets we will first be designing the functionality and doing some reviews. After that the basic functionality of the widget will be prototyped in HTML and finally the HTML will be modified to run on the target platform(s) of our choosing.

We’re not committed yet, so some of our choices are still open and most of it is up for debate. If you have any questions, additions or things we have missed in our survey, we would love to hear from you in the comments.

Update: Though not visible on the site yet, Techcrunch reports that Spring Widgets will be shutdown by Fox Interactive.

Update: Sprout Builder recently announced a pricing model to their up until then free service.

Update: The overview overlooked the yourminis widget publishing platform. Yourminis takes SWF files and distributes these to a number of platforms.

  1. xCal seems to be mostly obsolete but it is still referenced and used in various places viz. translator, Upcoming feeds etc. []
  2. I’ll talk more about OpenSocial later on. []
  3. Or whatever its brandname du jour. []
  4. Being able to get data from arbitrary websites is normally restricted because of security considerations. []
  5. Not being able to use document.getElementById() is something of a pain. []
  6. They announced the new version of UWA at LeWeb ’08 but offer nothing but vague promises when asked for the actual code. []
  7. Which had already been promised a long time ago. []
  8. How hard would it be to build an OpenSocial container to run in Dashboard? []
  9. It’s not a bad question to ask how we then defend the choice of Google for instance, but OpenSocial is a relatively open platform. []

Unsubscribe

Toeval na bericht van gisteren dat Spaink vandaag over de columns-mailinglijst met het bericht komt van de nieuwe Amnesty International-campagne “Unsubscribe.” Deze gaat over de War on Terror, die zogenaamde oorlog waardoor we onze privacy en burgervrijheden kwijt raken in Europa wat later dan in Amerika, maar zeker niet veel minder.

Het zijn drie filmpjes —vandaag de eerste— van ondervragingsmethoden die volgens de CIA geen marteling zijn. En als het geschreven staat is het natuurlijk waar. Kijk het filmpje en vraag je af of je hier part aan wil hebben of dat je wilt Unsubscriben.

Vroeger als ik in discussies over politiek de boel wilde polariseren, wilde ik nog weleens zeggen dat mensen die op de VVD stemmen fascisten zijn1. Het discussieren heb ik opgegeven2 maar eigenlijk vind ik nog steeds wel dat mensen die op de VVD stemmen fascisten zijn.

Het bovenstaande filmpje is alle onderbouwing die nodig is voor die stelling. De CIA vindt wat daar gebeurt geen marteling, en dus de Verenigde Staten ook niet. Door bepaalde kabinetten met de VVD die we hebben gehad omdat mensen in Nederland op de VVD hebben gestemd, vindt Nederland dat dus ook niet.

Ik schaam me en ik heb niet eens VVD gestemd.

(In hetzelfde straatje is dit gesprek tussen Errol Morris en Philip Gourevitch over Abu Ghraib ook wat lang3 maar de moeite waard om op de achtergrond aan te hebben staan.)

  1. Voor elke discussie heb ik wel een paar uitspraken die gegarandeerd polariseren. []
  2. Één-op-één is een discussie een zinloze masturbatieve bezigheid. []
  3. Als je Morris’s essays nog kunt herinneren over die twee foto’s. []

Microblogging als manier van communicatie

Vandaag op Frankwatching een artikel gepubliceerd waar ik al een tijdje aan aan het werk was: Microblogging als communicatiemedium

Hier nog even de tekst integraal voor mijn eigen archief. Maar lezen en reageren doe je bij Frank.

Bijna iedereen heeft ondertussen wel van Twitter gehoord. Onlangs is Jaiku, een tegenhanger van Twitter, overgenomen door Google. De manie, de verslaving en de behoefte van mensen om te uiten wat ze aan het doen zijn, zijn uitingen van het fenomeen microblogging waar mobiel en presence bij elkaar komen.

Robert Scoble en anderen noemen het een vervanger van e-mail maar dat lijkt me wat overgehyped. Ondertussen is wel duidelijk dat microblogging op verschillende plaatsen terugkomt en zijn invloed heeft in andere diensten. Het is een blijvertje, maar wat moeten we er dan mee?

Microbloggen is het overbrengen van een kleine boodschap via SMS, web, IM, mobiele clienten of desktop tools en widgets. Dit is redelijk divers, hieronder een blik op Twitter en Jaiku en hun invloed op het (mobiele) web.

Twitter

Twitter is een beetje de eerste echt grote microblogging site en op dit moment ook de dominante. Anderhalf jaar geleden in Amerika begonnen als spinoff van Odeo, leek het een leuk klein dienstje. Destijds had ik moeite om vrienden hier in Nederland eraan te krijgen. In de tussentijd is Twitter uitgegroeid tot een van de meestgenoemde sites op het internet.

Het concept is erg simpel: Je tikt een boodschap op de website of verstuurt het door middel van SMS of plaatst het via de API. Deze boodschap is een kleine status update oftewel een “microblog”en deze wordt geplaatst op het internet, doorgestuurd via SMS of IM aan mensen die je volgen en is opvraagbaar voor andere programma’s via een API.

Op een gegeven moment explodeerde in Amerika de populariteit van Twitter en de site lag er om de haverklap uit. Het feit dat Twitter plat lag, was een running gag, maar de problemen met Ruby en de schaalbaarheid ervan lijken opgelost te zijn.

Foto door Pieter Baert

Pas is Biz Stone op de eDay geweest om te spreken over Twitter en hun succes (zie verslag op Marketingfacts). Het is leuk om de dingen uit de mond van de maker te horen, maar veel nieuws wist hij niet te melden. De toepassingen en de creatieve uitingsvormen die bovenop Twitter gebouwd worden zijn uit zijn handen gegroeid. Twitter is de enabler voor ontzettend veel andere diensten.

Het is onduidelijk waar Twitter zijn geld aan verdient. De kosten van servers en (SMS) bandbreedte moeten ergens door betaald worden. Twitter heeft pas een financieringsronde van $5M gekregen.

Over Twitter is hier en op andere plaatsen al heel veel geschreven. Ik ben zelf nooit een actief gebruiker van Twitter geweest en vindt dat er interessantere trends zijn in dit domein. Hier ga ik het dan ook over hebben, beginnende met Jaiku.

Jaiku

Jaiku is ook een microblogging dienst, maar het is tegelijkertijd veel meer dan dat. Het lijkt er bijna op alsof microblogging een lokkertje is om te laten zien dat er nog veel meer mogelijk is.

Naast het instellen van berichtjes is het mogelijk om andere stukjes van je online leven bijeen te brengen op je Jaiku pagina. Dus invoer van Twitter, Last.FM, Plazes, Dopplr, Flickr, je weblogs en andere RSS feeds wordt door je normale berichten heen geweven om een completer beeld van jou te krijgen.
Verder is het mogelijk om op de berichten en alle andere stukken content commentaar toe te voegen, wat zorgt voor een veel rijkere interactie dan de losse berichten stroom met reacties van Twitter. Ook heeft Jaiku de mogelijkheid om kanalen te openen die vooralsnog niet veel gebruikt wordt maar het beste te vergelijken is met een soort mobiel online IRC.

Jaiku Mobile App

Verder is één van de bijzonderste features van Jaiku de mobiele client die draait op S60 GSM’s van Nokia. Deze client vervangt het normale adresboek en laat voor je vrienden die ook Jaiku gebruiken tegelijkertijd zien wat hun laatste update is, hun huidige status en locatie en hun volgende afspraak. De keuze voor het Nokia-platform beperkt de markt voor deze functionaliteit, maar dit soort geavanceerde toepassingen zijn een voorproefje van wat we kunnen verwachten zodra ontwikkelen op mobiel makkelijk on open wordt.

Deze week is Jaiku door Google gekocht voor een niet nader te noemen bedrag. Het team van Jaiku verhuist naar San Francisco om daar verder te werken aan Jaiku en de integratie met de diensten van Google. Of Jaiku nu een bijdrage gaat leveren aan de sociale netwerken explosie die Google heeft aangekondigd, of dat de Jaiku mobiele client een integraal onderdeel gaat vormen van de aangekondigde GPhone, het belooft veel voor de toekomst.

Mobiele presence is meer dan microblogging

Wat maakt microblogging sites nu zo boeiend? Jyri Engeström (Jaiku pagina) een van de oprichters van Jaiku heeft al vaak gesproken over de noodzaak van een dienst als Jaiku en van de daadwerkelijke voordelen die microblogging biedt boven andere vormen van communicatie. In zijn presentatie op Reboot8 vorig jaar getiteld “Blind Men’s Baseball” zette hij de problemen waar we allemaal mee te maken hebben uiteen. We bellen mensen meestal op met vragen als ‘Waar ben je?’, ‘Wat doe je?’ en ‘Waar ga je heen?’. Dit zijn precies de vragen waar de mobiele client van Jaiku in een oogopslag een antwoord op geeft. Jaiku biedt dus ‘social peripheral vision’ waarmee je beter op de hoogte blijft van wat je vrienden aan het doen zijn ongeacht waar ze zich bevinden.

Jyri EngeströmFoto door Alper Çuğun

Pas op Reboot9 en op verschillende andere plaatsen hield hij een presentatie over wat microbloggen nu echt voor voordelen biedt boven het oude bloggen. Dit zijn onder andere gemak, onmiddelijkheid en context. Het is gemakkelijker om een microblog te schrijven dan om een blog artikel (zoals dit). Het is een enkel tekstveld en er hoeft niet eens een ontvanger aangemerkt te worden, hierdoor zijn er minder bewuste handelingen nodig om te microbloggen.

Dat is microbloggen als uitingsvorm, maar Jaiku kan ook al een toegevoegde waarde bieden zonder dat de genoemde persoon ooit een bericht tikt. Doordat veel informatie automatisch door de client wordt doorgegeven, kun je zien dat iemand ‘er is’. Engeström gaf als voorbeeld zijn eigen vader bij wie hij de client had geïnstalleerd, die nooit een update plaatste maar door zijn mobiele presence toch wel in het oog en dus in het hart bleef.

De onmiddelijkheid en het gemak van microblogging met hun interruptieve aard dragen bij aan de snelheid van onze communicatie en interactie. Als je op een paar manier op de hoogte wordt gehouden van Tweets en Jaikus word je continu gestoord (letterlijk en figuurlijk). Deze storingen kunnen je concentratie compleet onderuit halen maar de informatie en verbindingen met anderen kunnen ook leiden tot waarde en kansen die je anders niet had gehad.
Stowe Boyd en James Governor zien het positieve ervan in: “If Markets are conversations, then Twitter is money” terwijl Kathy Sierra het standpunt van de cultuurpessimiste inneemt: “Is Twitter TOO good?”

Concurrentie?

Internationaal zijn er door het succes van Twitter een heleboel applicaties ontstaan die ofwel een directe kopie zijn ofwel microblogging integreren in het geheel (lijst). Pownce is een bestandendeel en berichtenapplicatie van Kevin “Digg!”Rose en Leah Culver. Plazes heeft een relaunch gedaan van de dienst waar ze aan hun ‘rich geo-presence’ functionaliteit, de mogelijkheid hebben toegevoegd om activiteiten te koppelen aan locaties: Ik ben ergens en ik doe iets. En Loic LeMeur heeft pas Seesmic gelanceerd, een video-microblogging site.

Al deze diensten maken het er niet gemakkelijker op voor gebruikers om berichten te plaatsen en bij te houden wie waar iets heeft geschreven. Microblogging zou het juist makkelijker moeten maken om op de hoogte blijven. De APIs die deze sites aanbieden maken het gelukkig mogelijk om verschillende sites weer uit te lezen en met een druk op de knop naar meerdere sites tegelijkertijd te posten. Twitku is een voorbeeld van de combinatie van Twitter en Jaiku en

In Nederland zijn er ook wat directe kopieën maar deze lijden een schrijnend bestaan. KWID, Numpa en Zezz (speelprojectje van mezelf) zijn een paar voorbeelden. Sommige sites zijn wel bereid om via een SMS-nummer microblogs te ontvangen en te plaatsen (evt. tegen betaling) maar het uitsturen van updates over SMS is niet betaalbaar aan te bieden in Nederland vanwege de redelijk gesloten telecommarkt.
Op eDay E Factor werd een whitelabel microblogging platform gepresenteerd onder de naam Brandlog maar de presentatie (slides, video) was niet overtuigend en de cijfers die genoemd werden lieten zien dat een dergelijk concept grote moeite zal hebben om winstgevend te worden.

Het is voor grote mediapartijen ook niet verstandig om alles per se zelf te willen doen. Twitter en Jaiku bieden met hun APIs en rijke ecosystemen genoeg ruimte voor andere toepassingen en weinig aanleiding om het buiten die dienst te zoeken. Het multi-channel reportage project van Ben Hammersley voor de BBC “Turkish Journey”, bewijst dat je door best breed oplossingen (Twitter, YouTube etc.) te combineren, tot mooie synergie kunt komen.

Toekomst

Het samenbrengen van je online aanwezigheid op één plek wordt een belangrijk thema in de sociale netwerken van de toekomst. Google en Yahoo! hebben dit al ingezien en zijn bezig met de eerste prototypen van de volgende generatie sociale netwerken. Yahoo! Mash is nu bijvoorbeeld in gesloten bèta en Google heeft aangekondigd om op 5 november een groot deel van hun diensten en sociale connecties vrij te geven.

Het internet blijft veranderen, en media zijn nu sneller dan ooit. Er ontstaan eigenlijk alleen maar meer vragen. Wat zal de toekomst brengen en zijn er harde grenzen aan hoe snel we kunnen communiceren, hoeveel informatie we tot ons kunnen nemen en met hoeveel mensen we in verbinding kunnen staan?

Alper Çugun —hoofdredacteur van Four Starters— denkt na over webapplicaties, maakt ze en waakt over hun relevantie en bruikbaarheid onder andere bij Tipit.to.