Categorie: analyse

Onbeperkt gratis gebruik Google Maps API is voorbij

In april waarschuwde Google al dat het er aan zat te komen, limieten op het gebruik van de Google Maps API. En nu zijn de details bekend gemaakt.

De introductie van de Google Maps API in 2005 wordt gezien als het begin van het Mashup en API tijdperk. Nu 6 jaar later, zijn APIs ‘serious business’ geworden en zijn ze niet meer weg te denken. Maar APIs kunnen voor een bedrijf ook erg kostbaar zijn. Anderen profiteren van de diensten die een bedrijf aanbiedt, in veel gevallen zonder daar iets voor te hoeven betalen. Langzamerhand worden er steeds meer betaalde APIs aangeboden, vaak met een beperkte, gratis variant (gelimiteerd of met reclame).

Eerder dit jaar schrapte Google al een hele serie APIs en maakte van de gratis Translate API een volledig betaalde variant. En nu is het dus de beurt aan de Google Maps API.

Er was overigens altijd al een betaalde variant van de Google Maps API, de Google Maps API Premier. Deze is bedoeld voor bedrijven die support willen, geen advertenties, meer geocoding of de kaarten intern willen gebruiken.

Google legt in de FAQ uit, welke limieten er geïntroduceerd worden. De API blijft gratis tot 25.000 ‘Map loads’ per dag voor de normale kaarten en tot 2.500 ‘Map loads’ per dag voor aangepaste kaarten. Daarboven moet er vanaf begin 2012 betaald worden. Voor de normale kaarten zal dit $4 per 1000 ‘Map loads’ worden en voor de aangepaste kaarten $4 of $8 per 1000 ‘Map loads’. Dit geldt zowel voor de JavaScript APIs als voor de Static Maps API. Opvallend is dat de oude JavaScript API (V2) ook nog ondersteund wordt, maar dat hiervoor $10 per 1000 ‘Map loads’ betaald moet worden.

Er wordt in de FAQ ook precies uitgelegd wat een ‘Map load‘ inhoudt. Het gaat hierom het laden van de Maps JavaScript door een website of applicatie of het genereren van een kaart afbeelding m.b.v. de Static API.

De limieten zijn overigens niet hard. Als een website over de limiet heen gaat, wordt niet direct de de kaart uitgeschakeld, maar bij herhaaldelijk overschrijden van de limiet, kan er een waarschuwing worden getoond op de kaart en zal iemand van Google contact opnemen.

Is het nu erg dat er voor de Maps API betaald moet gaan worden? De eerste reacties zijn overwegend positief. Natuurlijk is het jammer als je als ontwikkelaar moet gaan betalen voor iets dat voorheen gratis was, maar beter een betaalde versie dan helemaal geen Maps API meer.

Of dit nu zal betekent dat veel ontwikkelaars overgaan stappen op alternatieven, zoals bijv OpenStreetMap, zal de tijd moeten leren.

Overigens gelden de bovenstaande beperkingen alleen voor commerciële websites. Nonprofit websites kunnen zelfs nog in aanmerking komen voor opheffing van bepaalde limieten (bijv het uitschakelen van advertenties). Informatie hierover is te vinden op de Google Earth Outreach website.

Trends in API’s

Bij het ontwikkelen van internet toepassingen zijn API’s niet meer weg te denken, beter gezegd, ze zijn onmisbaar geworden. Zonder API was twitter niet zo succesvol geworden, zonder API was het een stuk lastiger om goede campagnes op Hyves of Facebook te voeren.

Het aantal organisaties dat een API aanbiedt is de afgelopen jaren enorm toegenomen. Op de website Programmableweb.com staan op dit moment 3891 API’s geregistreerd. In dit overzicht overzicht staan een kleine 40 Nederlandse API’s (overzicht is niet volledig, aanvullingen zijn welkom!).

Wat zijn op dit moment de trends in de (wondere) wereld van de API’s? Hieronder een overzicht:

json-only

Veel API’s bieden meerdere output formaten aan, meestal XML en JSON. Ontwikkelaars zijn gek op JSON. JSON is lekker simpel, niet te veel overhead, etc. Dit is de reden waarom veel API’s tegenwoordig JSON-only zijn. Vooral veel nieuwe API’s bieden alleen nog JSON aan als output formaat. Op Programmable Web is 20% van de nieuwe API’s (in 2011) al JSON-only. Maar ook steeds meer bestaande API’s stappen over op JSON-only.

Meta API’s

Als je een applicatie of mashup ontwikkelt, waarbij je alle informatie wilt gebruiken die over een bepaalde (geografische) locatie te vinden is, moet je meerdere API’s raadplegen, bijvoorbeeld Wikipedia voor de algemene informatie, Foursquare voor de checkins en tips, Twitter voor de tweets over de locatie, etc.

Het koppelen van de verschillende informatie bronnen kan soms complex zijn. De naam van de locatie is misschien net iets anders in Wikipedia dan in Foursquare en er bestaat al helemaal geen unieke id.

Meta API’s proberen een einde te maken aan dit probleem, door een overkoepelende API aan te bieden, of door een vertaalslag aan te bieden voor de id’s van de verschillende API’s. Een goed voorbeeld hiervan is de Uberblic Doppleganger API.

Realtime/Push API’s

Om een API te raadplegen moet meestal een verzoek naar een server gestuurd worden, waarna de resultaten binnengehaald kunnen worden. In deze tijd van realtime updates is dat vaak niet meer genoeg. Daarom worden er steeds meer push of ook wel realtime API’s aangeboden. Bij een push API worden nieuwe resultaten automatisch naar een applicatie gestuurd.

Bekend voorbeeld van deze push API is de streaming API van Twitter. Hierbij kan je als ontwikkelaar aangeven welke woorden of gebruikers je wilt volgen en komen de nieuwe tweets als een continue stroom van informatie naar je toe.

Ander recent voorbeeld: gisteren lanceerde Foursquare twee realtime API’s als beta. Een ontwikkelaar kan hier notificaties ontvangen als een gebruiker ergens incheckt of als er iemand op een bepaalde locatie incheckt.

Dit zijn drie trends die, volgens mij, op dit moment belangrijk zijn, heb ik nog iets gemist?

iPad

Het kan niemand ontgaan zijn, Apple heeft vorige week eindelijk de langverwachte Apple tablet aangekondigd: de iPad.

Er is in een week tijd al erg veel over dit apparaat gezegd en geschreven, de iPhoneclub heeft een mooi overzicht.

Flash

Er is veel kritiek, met name op het ontbreken van de camera (of zit deze er toch in?) en het ontbreken van Flash support. Zelfs de CTO van Adobe bemoeit zich met deze discussie.

Ik denk zelf dat ’t ontbreken van Flash geen groot probleem is. Flash wordt over het algemeen gebruikt voor video en interactieve, ‘multimediale’ toepassingen. Steeds meer videosites zijn aan het experimenten met HTML5 video. Dit is nog niet ideaal en er is nog een lange weg te gaan voordat HTML5 video Flash helemaal kan vervangen, maar op de iPhone werkt dit tot nu toe prima, dus waarom op de iPad niet?

Daarnaast zijn er volgens mij weinig interactieve toepassingen die echt Flash nodig hebben, de meeste kunnen m.b.v. HTML5, JavaScript en CSS3 prima ontwikkeld worden.

HTML5, JavaScript en CSS3

Natuurlijk zitten er nog wel nadelen aan het gebruik van deze drie technieken. HTML5 en CSS3 zijn nog niet ‘af’. De specificaties hiervan zijn nog volop in ontwikkeling en er kunnen dus nog wijzigingen plaats vinden.

Een ander nadeel is dat nog niet alle browers deze technieken volledig ondersteunen, met name Internet Explorer loopt op dit gebied achter op de andere moderne browsers. Maar ook Microsoft is sinds enige tijd betrokken bij de ontwikkeling van HTML5, dus er is hoop.

Laatste nadeel is dat HTML5, JavaScript en CSS een andere soort ontwikkelaar vereisen dan Flash. De meeste Flash ontwikkelaars zijn gewend om met de grafische Flashontwikkelomgeving te werken. Voor HTML5, JavaScript en CSS zijn deze er bij mijn weten nog niet. Tenminste niet met hetzelfde gemak als Flash. Maar ik heb zo’n gevoel dat deze tools niet lang op zich laten wachten en het zou best kunnen dat Adobe daar een belangrijke rol in gaat spelen.

Met name door de goede ondersteuning van HTML5, JavaScript en CSS3 in de mobile Safari (Webkit) lijkt de iPad me een interessant nieuw apparaat om voor te ontwikkelen.

ePub

Ik zit zelf alleen nog met een vraag. Hoe staat het met de ondersteuning van ebook standaard ePub? Apple heeft aangekondigd dat de iPad ePub ondersteund, maar er zijn nog geen details bekend.

Er is op dit moment nog geen audio of video mogelijkheid in de ePub standaard, maar er zijn wel manieren om toch audio en video op te nemen in een ePub document. Er zijn tot nu toe alleen weinig devices die dit ondersteunen.

Het zou toch mooi zijn als boeken, maar met name magazines en kranten gebruik zouden kunnen maken van audio en video zonder dat er voor iedere publicatie een aparte App ontwikkeld moet worden.

Proof of Concepts

Alhoewel deze Apps misschien in eerste instantie wel nodig zijn om te bepalen wat voor unieke mogelijkheden het apparaat biedt voor tijdschriften en kranten. Want als maar een klein stukje van deze twee ‘proof of concepts’ mogelijk worden gemaakt met de iPad, dan komen er mooie tijden aan voor tijdschriften en kranten die met hun tijd mee willen gaan.

Mag+ from Bonnier on Vimeo.

Google Chrome OS

Het grootste internet gerelateerde nieuws van de afgelopen week is toch wel de introductie van het Google Chrome OS. Niet alleen internet gerelateerde websites en blogs schreven erover, de aankondiging haalde ook reguliere kanalen zoals het NOS journaal.

De meeste berichten gaan met name in op de concurrentie die Google in de ogen van veel mensen nu aangaat met Windows van Microsoft. Dit zal ongetwijfeld zo zijn, alhoewel ik niet verwacht dat veel Windows gebruikers direct zullen overstappen op Chrome OS. En daar zijn velen ’t over eens.
Het schijnt trouwens dat CEO Eric Schmidt al 6 jaar bezig is om Sergey Brin en Larry Page ervan te weerhouden een OS te ontwikkelen. Schmidt vond dat Google nog niet klaar was voor de OS concurrentie strijd, nu dus blijkbaar wel 😉

Voor mij als techneut is het veel interessanter om te kijken hoe dit OS opgebouwd zal zijn en ik denk dat daar al meer over bekend is dan je in eerste instantie zou zeggen.

Google Chrome OS doet denken aan de Netwerk Computer of Thin Client, die verschillende partijen in het verleden al op de markt hebben proberen te brengen. Oa Oracle en Sun hebben in ’t verleden (rond 1996) systemen op de markt gebracht waarbij de computer beperkte capaciteiten heeft en de applicaties op de server draaien. Chrome OS is in eerste instantie bedoeld voor NetBooks waarbij de capaciteit ook minder is dan een volledige laptop/deskop computer.

Ook browser ontwikkelaar Netscape heeft in het verleden de browser al gepresenteerd als het nieuwe OS. Helaas is hiervan weinig meer terug te vinden. Ik kan me nog hele mooie whitepapers over dit onderwerp herinneren.

Negen maanden geleden heeft Google de Chrome browser geïntroduceerd. Sindsdien zijn er een aantal ontwikkelingen geweest die volgens mij allemaal een relatie met het Chrome OS (kunnen) hebben.

HTML5

Google zet zwaar in op HTML5. Deze nieuwe HTML specificatie is nog niet afgerond, maar wordt nu al ondersteund door verschillende browser fabrikanten waaronder dus door Google met Chrome. Google heeft ook al verschillende applicaties ontwikkeld die gebruik maken van HTML5 features, zoals de mobiele versies van Gmail en Calendar.

Tijdens Google I/O, de developers conferentie van Google bleek dat Google aan nog veel meer HTML5 projecten werkt, zoals bijv een Flash vrije Youtube.

Voordelen van HTML5 zijn oa offline mogelijkheden, lokale opslag, video en audio zonder plugin afspelen, etc. Deze mogelijkheden zijn goed te gebruiken in een Operating System.

JavaScript

De Chrome browser maakt gebruikt van de opensource Webkit Browser Engine, behalve voor de JavaScript parsing. Daarvoor heeft Google de V8 JavaScript Engine ontwikkeld. Deze JavaScript Engine is erg snel en dat is natuurlijk onmisbaar als je volledige applicaties ontwikkeld die gebruik maken van deze programmeertaal.

Native Client SDK

Een van de belangrijkste vragen die gesteld zijn na de bekendmaking van Google Chrome OS is of het OS ook native applicaties gaat ondersteunen. De kans is natuurlijk klein dat er bijvoorbeeld Windows programma’s op gedraaid kunnen worden. Maar afgelopen december heeft Google de Native Client gelanceerd. Dit is een research project waarbij onderzocht wordt hoe native x86 code binnen webapps gebruikt kan worden, met behoud van browser neutraliteit.

Deze technologie kan bijvoorbeeld gebruikt worden om vanuit de browser de hardware direct aan te spreken. Voordeel hiervan is dat er snelheidswinst in allerlei berekeningen behaald kan worden. Ook voor de ontwikkeling van games kan het belangrijk zijn om de hardware direct aan te spreken.

O3D

Een andere vraag is hoe zit het met graphics? Natuurlijk heeft HTML5 canvas en SVG ondersteuning, maar dat maakt geen gebruik van specifieke grafische kaarten. Ook hier heeft Google al ‘iets op de plank’ liggen, nl O3D. Dit is een API om interactieve 3D applicaties in de browser te ontwikkelen.

Wave

Google Wave is een nieuwe manier van communiceren en samenwerken op het internet. Hoe dit precies in het Chrome OS verhaal past, weet ik niet, maar ik denk wel dat we dit terug gaan zien in het OS. Google Wave is ook nog niet officieel gereleased, maar er is al wel een uitgebreide API.

Ik ben zelf erg benieuwd hoe applicaties voor het OS ontwikkeld gaan worden. Maakt Google alleen gebruik van de bovenstaande technieken, waardoor de applicaties inderdaad ook op andere browser gebruikt kunnen worden, zoals ze zelf zeggen. Of komt er toch ook een soort native SDK waarmee op een soort Palm WebOS achtige manier applicaties ontwikkeld zullen worden?
De tijd zal het leren, want Google gaat het OS later dit jaar beschikbaar maken als opensource en dan in de 2e helft van 2010 zal het beschikbaar komen voor consumenten.

Maar een ding is duidelijk, voor webdevelopers zoals ik, zijn het interessante tijden 🙂

Update: Ik ben benieuwd naar jullie reactie en ideeën hierover. Wat denken jullie? Kunnen jullie je een beetje vinden in m’n gedachtengang? Of sla ik de plank volledig mis?

Kamer van Koophandel, ZZP’ers en Google Maps

Begin april was er ophef over het feit dat adresgegevens van bekende Nederlanders op Google Maps te vinden is. Het gaat om bekende Nederlanders die ingeschreven staan in het Handelsregister van de Kamer van Koophandel. Veel mensen weten niet dat deze informatie door de KvK doorverkocht wordt en dus ook aan Google.

Overigens is dit niet nieuw, in 2007 schreef ik al een artikel over de bronnen waar Google haar informatie voor Google Maps vandaan haalt. Dat er nu ophef over ontstaan is, wordt veroorzaakt doordat er ‘privé-informatie’ van BN’ers naar buiten is gekomen. Steeds meer zzp’ers zijn verplicht om zich in te schrijven in het Handelsregister, dus ook bekende zzp’ers.

De ophef heeft geleid tot kamervragen. Vorige week werd bekend dat de ondernemer/zzp’er meer zeggenschap krijgt over de gegevens die opgenomen zijn in het Handelsregister.

Meer zeggenschap is natuurlijk altijd goed, maar voor veel ondernemers is het gevonden worden op Google Maps erg belangrijk. Google gebruikt de informatie van Google Maps tegenwoordig ook in de ‘normale’ zoekopdrachten. Zodra er een plaatsnaam in de zoekopdracht voorkomt, wordt ook de lokale informatie uit Google Maps gebruikt.

Een onbekende mogelijkheid van Google Maps is het Lokale Bedrijvencentrum. Met dit bedrijvencentrum kan je de informatie, zoals deze op Google Maps verschijnt, wijzigen en zelfs uitbreiden (extra omschrijving, werkterrein, url, etc). Ook hier schreef ik al eerder over, maar deze informatie is verouderd. Ik zal binnenkort een vernieuwde versie van dit artikel publiceren.

Mocht je in de tussentijd geïnteresseerd zijn om de informatie zoals deze in Google Maps over je bedrijf vermeld staat, aan te passen, dan biedt Google uitgebreide help informatie.

Kom je er niet uit of wil je je er niet in verdiepen, neem dan contact met mij op (of via @gvenk).

Vrije overheids data

Ik had al een tijdje een artikel klaar staan met als title “Open publieke data”. Het stuk was nog niet af, maar hierin beschreef ik een belangrijk missend onderdeel van de discussie rond het gebruik van Open Source Software en Open Standaarden door de overheid. Eerst even wat achtergrondinformatie.

Staatssecretaris Frank Heemskerk heeft de dag voor Prinsjesdag 2007 een actieplan naar de Tweede Kamer gestuurd. Dit actieplan, “Nederland open in verbinding”, bevat een groot aantal actiepunten voor het gebruik van Open Source Software en Open Standaarden binnen de (semi-) publieke sector.
De nadruk van de actiepunten ligt op het gebruik van Open Standaarden, deze worden verplicht gesteld, mits niet een van de uitzonderingscriteria geldt (zie de pdf blz 10 voor deze criteria).
Over Open Source Software wordt er in het document gezegd dat er een implementatie strategie ontwikkeld moet zijn voor de aanbesteding en inkoop en het gebruik, het moet een ‘eerlijke’ kans krijgen.
Het document gaat uit van het zogenaamde ‘pas toe of leg uit strategie’. Als er afgeweken wordt van het gebruik van Open Source Software en Open Standaarden moet dat uitgelegd worden.

Ik ben een groot voorstander van het gebruik van Open Standaarden en Open Source door overheden en andere organisaties in de publieke sector, dus ik juich zo’n actieplan van harte toe. Maar wat mij tegenvalt in het actieplan is dat er met geen woord gerept wordt over het beschikbaar stellen van publieke data op een open manier.

Publieke data

De (semi-)overheid produceert en verzamelt veel data. Een (groot) deel van deze data is interessant voor het publiek. Denk hier bij bijvoorbeeld aan geografische data (straten, publieke gebouwen, etc), maar ook informatie van de onderwijs inspectie over scholen, politie statistieken, vul zelf maar aan.

Op dit moment wordt er verschillend met deze data omgegaan. Sommige data wordt verkocht aan commerciële partijen (dit geldt bijvoorbeeld voor de geogratische data). Andere data is doorzoekbaar via een website, maar de informatie kan niet zo maar verder gebruikt worden (bijvoorbeeld de rapporten van de onderwijs inspectie). En zo langzamerhand verschijnt er ook data die ontsloten wordt via een webservice, zodat je daarmee nieuwe Mashups kunt ontwikkelen (bijvoorbeeld de Nieuwe Kaart van Nederland).

Waarom beschikbaar stellen?

Waarom zou de overheid deze data vrij beschikbaar moeten maken? Want doordat ze nu deze data soms verkopen aan commerciële partijen krijgen ze er geld voor en dat is weer voordelig voor ons als belasting betalers.

Maar toch denk ik (en gelukkig velen met mij) dat het goed is als deze data vrij beschikbaar komt. De burgers, consumenten organisaties en journalisten zouden op deze manier meer inzicht krijgen in het politieke proces. Waar gaat het geld naar toe, wat wordt er allemaal gedaan, maar ook waar kan je terecht met je vragen en opmerkingen over specifieke onderwerpen.

Verder zal de toegankelijkheid en doorzoekbaarheid van overheidsdata toenemen als de data beschikbaar komt. Zoekmachines zullen deze data (beter) kunnen indexeren, maar er kunnen ook specifieke zoekmachines of indexen ontwikkeld worden voor de publieke data.

En, wat ik zelf ook erg interessant vind, alle data kan gecombineerd worden in Mashups, zodat er weer nieuwe informatie bronnen ontstaan. Toepassingen waar de overheid zelf niets aan heeft en dus nu nooit zal ontwikkelen, kunnen door anderen ontwikkeld worden. Data kan worden verrijkt, gevisualiseerd, etc. Er zullen nieuwe startups ontstaan die hiermee aan de slag gaan en dat is weer goed voor de economie.

Voorop lopen door vrije data

Afgelopen woensdag was er een debat in de Tweede Kamer over het eerder genoemde actieplan. Voorafgaand aan dit debat heeft OpenStreetMap Nederland een rapport gepubliceerd Voorop lopen door vrije data. Het rapport stelt dat het vrijgeven van overheidsdata de doelstellingen van het actieplan ‘Nederland in open verbinding’ bevorderd:

  • Open standaarden bevorderen de interoperabiliteit. Vrije data kan dit een extra impuls geven. Vrije data is niet alleen in principe uitwisselbaar, vrije data kan samengevoegd worden tot een enkele dataset.
  • Open standaarden en open source verminderen van de afhankelijkheid van leveranciers. Vrije data kan hieraan een extra bijdrage leveren op het vlak van de inhoud. Tevens kan de beschikbaarheid van vrije data de hoeveelheid leveranciers van software vergroten, zoals hierboven aangetoond.
  • Open source bevordert een gelijk speelveld op de software­markt en bevordert voorts de innovatie en de economie. Waar de beschikbaarheid van data een voorwaarde is voor de ontwikkeling van software, bevordert vrije data een gelijk speelveld, de innovatie en de economie.

Debat

Het was de bedoeling dat dit artikel voor het debat van woensdag online zou komen, maar doordat mijn internetverbinding het niet deed is dat niet gelukt. Ik zou nog schrijven dat ik me afvroeg of het rapport van OpenStreetMap wel veel aandacht zou krijgen, aangezien er vooraf voornamelijk aandacht was voor de discussie over ODF en OOXML en de rol van Microsoft in het geheel..

De Tweede Kamer is akkoord gegaan met het plan, maar ik heb tot nu toe geen verslag kunnen vinden, dus ik weet niet of er ook gesproken is over vrije data. Van alles wat ik er tot nu toe over gelezen heb, krijg ik de indruk dat dit niet het geval is. Een gemiste kans dus, tijd voor een vervolg actieplan!

Google gaat ‘OpenSocial’

De geruchtenstroom was vorige maand al op gang gekomen, Google zou op 5 november met een alternatief voor het Facebook Platform komen. Dit alternatief zou 100% open zijn en bestaan uit een aantal APIs waarmee de sociale informatie binnen Google ontsloten zou kunnen worden. Ook zouden mogelijk andere sociale networken gebruik kunnen gaan maken van deze APIs om toegang te geven tot hun informatie.

Vandaag licht Techcrunch een tipje van de sluier op, Google lanceert morgen OpenSocial.

OpenSocial (link werkt vanaf donderdag) is geen nieuw sociaal netwerk, maar het is een set van APIs waarmee applicaties ontwikkeld kunnen worden, die met alle sociale networken kunnen samen werken, zolang deze de OpenSocial APIs ondersteunen.
Lees verder “Google gaat ‘OpenSocial’”

APIs, Mashups en copyright

Gisteren las ik op Programmableweb.com een artikel met de titel “Can an API Steal Data”. Een Flickr gebruiker is erachter gekomen dat zijn foto’s in een Mashup (Adactio Elsewhere) verschenen, terwijl hij de rechten voor al z’n foto’s op ‘All Rights Reserved’ (ARR) heeft staan. De discussie die hierna onstaan is gaat vooral over wie nu verantwoordelijk voor het probleem is, Flickr of the Mashup ontwikkelaar. Maar wat is nu precies het probleem, wie is er verantwoordelijk en welke gevolgen heeft deze discussie?
Lees verder “APIs, Mashups en copyright”

Hergebruik van publieke omroep video

Uitzendinggemist is een populaire dienst van de Publieke Omroep. Eind vorig jaar zelfs zo populair dat de dienst dreigde te bezwijken. Waarom Uitzendinggemist zo populair is? Ik denk dat het voornamelijk te verklaren is door de beschikbare bandbreedte in Nederland, de opkomst van het uitgestelde kijken en het Long Tail effect.

Toch mis ik nog een aantal dingen. Je kan de video van Uitzendinggemist niet op je eigen site gebruiken, dus geen artikel schrijven over een bepaalde uitzending en deze direct bij het artikel plaatsen. Je kan niet eenvoudig linken naar een specifiek stukje in een uitzending. En als laatste, er is maar 1 RSS feed voor heel Uitzendinggemist. Het moet eenvoudig zijn om ook RSS feeds toe te voegen voor de verschillende onderdelen van de site (zender, genre, omroep of zelfs specifiek programma).

Ik kan wel een aantal redenen bedenken waarom je video van Uitzendinggemist niet mag ‘herbruiken’ (rechten, in eigen hand willen houden, hogere eisen aan de technische infrastructuur, etc), maar in het huidige Web-2.0 tijdperk kan dat eigenlijk niet meer. Inhoud moet herbruikt kunnen worden, zeker eigen materiaal van de Publieke Omroep. Een publieke organisatie wil met haar uitzendingen oa nieuws brengen, een bijdrage leveren aan politieke discussies, maar ook bijdragen aan de cultuur van Nederland. Hoe kan een organisatie dit nu beter doen, dan toe te staan dat deze uitzendingen ook op andere sites geplaatst mogen worden? Hierdoor wordt het bereik groter en worden er eventueel meer kanten belicht dan op de tv vaak mogelijk is.

Als de Publieke Omroep een mooie embedded player zou ontwikkelen, zouden de video’s herkenbaar blijven als materiaal van de Publieke Omroep.
Lees verder “Hergebruik van publieke omroep video”

Huizensites 2.0 (2): Mogelijkheden

In het vorige artikel heb de ik huidige stand van zaken van de huizensites in binnen- en buitenland beschreven. In deze post geef ik een overzicht van de mogelijkheden die huizensites volgens mij hebben en nog (bijna) niet gebruiken.

De kern (= de Social Objects) van een huizensite is duidelijk, dat zijn de huizen. Helaas zijn de huizensites een beetje vergeten voor wie en aan wie ze de huizen verkopen: mensen!

Dit artikel beschrijft een aantal mogelijkheden waardoor de huizensites de mensen (zowel kopers als verkopers) beter van dienst kunnen zijn. Daarnaast zullen ze door het ontwikkelen en inzetten van deze mogelijkheden het ‘2.0-tijdperk‘ betreden en beter voorbereid zijn op de toekomst.
Lees verder “Huizensites 2.0 (2): Mogelijkheden”