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. []

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. []

Ramen open in het openbaar vervoer

Dennis tipte me net deze video:

Het is een beetje warrig maar wat Vincent Everts zegt is:

Ik denk dat als eerste stap om de ramen open te doen en te zeggen laten we samenwerken aan producten, hier heb je mijn basis-API maak er iets moois van. Ik denk dat dat veel verder doorgegaan moet worden en dat die API die jullie nu hebben waarmee iedereen dus een basisvervoersadvies kan krijgen en dat kun je dan zelf verrijken, dat dat een hele goede weg is en ik denk dat 9292 ook verder moet doorzetten.

Ruwweg hetzelfde wat ik ook zeg, met dien verstande dat die API waar Vincent het over heeft niet publiek of onder andere voorwaarden beschikbaar is. 9292 moet in ieder geval verder doorzetten, laat dít dan een mooie eerste stap zijn.

Verder ben ik erg benieuwd naar de inzendingen en de winnaars van de wedstrijd. Die worden op 2 juni bekend gemaakt.

Update: Even later een interview van Vincent met Gert Staal, de directeur van 9292 waarin hij vraagt of er een API komt voor vervoersinformatie. Staal verwijst naar de NDOV (waar Mark de Bruin het hier al over had) die ergens in 2011 operationeel moet zijn. Iedereen zou daar toegang toe moeten krijgen.
Ik heb meer vragen:
Onder welke voorwaarden en op welke manier krijgen we dan toegang tot het NDOV?
Wie bepaalt hoe het geïmplementeerd gaat worden en krijgen we daar inspraak op?
En 2011 is nogal ver weg; wat kunnen we doen als we vandaag aan de slag willen?

Cycling Zuid

Erasmus

And to finish off the week, yesterday evening we had a nice ride through Rotterdam during the alleycat. I’d never done the Maastunnel before, nor seen most of Zuid, the Cuyp and the Brienenoord on bike before, so it was a great day of discovering Rotterdam.

Unfortunately no pictures of glorious Rotterdam during the golden hour as I crossed the Erasmus bridge for the last leg of the race. Too busy biking.

The week in pictures

Richard Avedon - FOAM

Tuesday morning I went to foam to see the last couple of days of the Avedon exhibit and I’m glad I did. Spectacular work! The exhibit is done in Amsterdam, but maybe you can catch it somewhere else (tweet)1? It is very much worth it.

OpenID in de praktijk

Then I went to report on an event about practical applications of OpenID. The event was heavily suit oriented which struck me as interesting. My report in Dutch is posted on Frankwatching (tweet).

Co-creation

Wednesday morning was filled with a symposium on Context Mapping at the local faculty of Industrial Design (tweet). Interesting collection of people and great content on the topic (tweet, tweet). I picked up the thesis “Brining the every day life of people into design” by Froukje Sleeswijk Visser (tweet).

Rijksmuseum

Friday morning had a ridiculously early start (tweet) at the Rijksmuseum for a ‘hard hat tour’. It is interesting enough to see the construction and reconstruction from the inside. The reconstructed artwork is quite beautiful and I’m anxious to see the end result. For some of my friends this was the first time they had ever set foot in the building at all (which is a shame), and this will stay the only opportunity for the following year or five.

RFIDuino workshop

After more coffee (like I said, it was an early start), it was off to the soldering irons at Mediamatic for the RFIDuino workshop given by Marc Boon. After a lot of fidgeting and my first real soldering experience in I think 15 years, some of us managed to build a working RFID shield for their Arduinos. Lots of unpredictable behaviour (tweet) though2. Where is that post-mortem debugger with hot code replace for your hardware setup?

  1. At the SF MOMA from July 11th until November 29th. []
  2. Mine still doesn’t work reliably which we attribute to the weak USB power supply coming from my Macbook (tweet). []

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. []

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? []