api

You are currently browsing articles tagged api.

Jag har tjatat om Guardian och deras Open Platform, men jag tänker tjata lite till. Inte nog med att jag fick avnjuta Chris Thorpe, en av smartskallarna som jobbar tillsammans med Simon Willison och Matt McAlister på att förändra hela tidningsvärlden. Jag fick dessutom höra honom berätta om den brittiska offentlighetens nya projekt.

1000 datakällor släpps fria och man säger: ”Get excited and do things”. För egen del blir jag så uppskuttad att jag knappt kan sitta stilla. Tänk om Makten och öppenheten fick se ett sådant här genombrott. Tänk om vi fick se det redan till Fokus heldag, ”När tekniken förändrar politiken”,  den 15/10. Tänk om Mats Sjöstrand, ordförande i e-delegationen, säger att 1000 öppna datakällor innan september 2010 är hans plan också.

Open everything är en härlig våg, med många beståndsdelar (här är några), som sveper fram över världen nu. Läs vad brittiska kabinettet säger:

From today we are inviting developers to show government how to get the future public data site right – how to find and use public sector information.
The developer community through initiatives such as Show Us a Better Way, the Power of Information TaskforceMySociety and Rewired State have consistently demonstrated their eagerness and abilities to “Code a Better Country“.  You have given us evidence and examples to help drive this forward within government.

Så vad har detta med Guardian att göra egentligen? Jo, jag ser det så här. Guardian har inte bara skapat ett api, så där lite lagom lättvindigt. Man har på ett medvetet sätt arbetat genom hela sin strategi. Oavsett om man väljer den ekonomiska eller biologiska betydelsen så är ”mutualism” ett ord som genomsyrar strategin. Och enkelt kan man säga att det handlar om att ta en jämlik plats i det nya ekosystem som man menar att internet representerar. ”Weaving the Guardian into the fabric of the Internet

Givetvis har man räknat fram en massa konkreta, snabba, nyttor med Content API, Data Store, Apps Gallery och alla timmar man lägger ner på sitt utåtriktade arbete. Det räcker att snabbt titta in i Apps Gallery för att inse att det där hade man aldrig kunnat hinna bygga själv. Men det finns också ett annat element som handlar om att dela med sig och att få tillbaka. Och i den processen ingår också att du lär dig hur du kan använda andra så som de använder dig.

Guardian har helt enkelt skaffat sig ett försprång, ett övertag mot konkurenterna. Så när det nu plötsligt finns 1000 ytterligare datakällor att gräva ur, så är Guardian väl rustade på alla sätt:

  • Eftersom de själv utvecklat egna api:er så har de djup förståelse för hur de ska använda andras.
  • Eftersom de redan har släppt ut massor av sin egen data är det snabbt gjort att jacka ihop det man har med det som man nu får tillgång till.
  • Eftersom man har en upparbetad relation med hundratals frivilliga nördar så har man ett stort försprång när det gäller tillgången till grey matter (om ni minns – all that matters).

Behöver jag säga att de, dessutom, verkar ha förbannat roligt på jobbet?

Några sköna bilder från Chris lugna och coola presentation. Jag tyckte han var så behaglig att jag överväger att försöka flyga in honom istället för Simon till ”Från tryckeri till api” på Internetdagarna i november.

Chris Thorpe, Guardian. Intro. Building the stacks for a mutualised newspaper

Chris Thorpe, Guardian. Intro. Building the stacks for a mutualised newspaper.

Chris Thorpe, Guardian. On building the solution for user controlled expenses

Chris Thorpe, Guardian. On building the solution for MPs expenses. Kolla kalendertid, lansering en vecka efter beslut. En och en halv veckas mantid. Total kostnad för driften hittills är 50 pund. Utvecklingsmiljön är så klart open source och gratis.

Chris Thorpe, Guardian. On building the solution for #edfest

Chris Thorpe, Guardian. On building the solution for #edfest. Under en manveckas utvecklingstid. Byggt och hostat på Google App Engine – alltså helt gratis. Erkänner att det är lite fulhack, kräver en del handpåläggning/administration. Men ändå…

Chris Thorpe, Guardian. Final takeaway

Chris Thorpe, Guardian. Final takeaway!

BTW, rubriken är lånad av Mats Ronander. Den kändes passande.

Känner du något efter det här inlägget? Klicka på en plupp:

(0%) (0%) (40%) (0%) (60%)
10 röster

Information som samlats ihop med hjälp av skattemedel skall vara fri — det hör man allt oftare. Inte bara i Sverige utan också utomlands. I många andra länder är diskussionen ofta dessutom om huruvida informationen i sig ska vara tillgänglig, medan vi i Sverige (Skandinavien) sedan länge haft offentlighetsprincipen. Att information ska vara åtkomlig, att man som medborgare. Och undantag ska vara att den inte ska vara det.

I USA är en av de som kämpar Carl Malamud som i flera år kämpat för att göra information fri. Där ser vi också kämpar för Creative Commons (med medkämpar även i Sverige), som önskar att mer information skall vara tillgänglig.

Varför är detta så viktigt? Jo, med hjälp av information kan (nya, flera) tjänster byggas. Det är det som för mig är Web2.0. För det är inte alltid de som har informationen som är världens bästa byggare av tjänster som använder den? Och i den marknadsekonomi som vi lever i, varför inte se till att det finns konkurrens? Må den bäste tjänsteleverantören vinna!

SL (Storstockholms Lokaltrafik) meddelande härom sistens att de kommer göra trafikinformation tillgänglig över ett standardiserat protokoll. Riktigt riktigt bra. Norska vädertjänsten gör samma sak, och är idag en extremt populär tjänst. Konkurrerar ut SMHI. Hur rätt och fel är det inte om tjänster i Sverige hämtar sin väderinformation (om Sverige) från Norge? Visar inte det att i detta fallet SMHI inte tillhandahåller de tjänster som marknaden efterfrågar?

Jag arbetade själv med att i slutet av förra milleniumet bygga Everyday.Com, och där skulle vi bl.a. ha nyheter, horoskop, väder etc. Naturligtvis producerade inte vi informationen, utan den fick vi från underleverantörer. Utom från SMHI. De ville att vi skulle inkludera information från deras website på vår website. Vilket naturligtvis skulle göra att vår website var helt beroende av att deras servrar var nåbar för att våra kunder skulle få en bra upplevelse. Hmmm… Nu kan man tycka att med “Web2.0″ så är det precis sådana beroenden man får hela tiden, och ska acceptera, så vad är jag orolig för egentligen? Kom nu igåg att detta var 1998 eller så, och det var helt enkelt som så att jag ville själv ha kontroll över de parametrar som kunde göra att vår site var nere. Man kanske kunde tagit ett annat beslut också, men så var det i varje fall på den tiden.

Så, rådata ska finnas tillgänglig. För att skapa innovation. För att få fram bättre tjänster. Klagar folk på att informationen “på webben” inte är tillräckligt bra — hänvisa till specifikation över hur data kan hämtas och säg åt folk att bygga en egen tjänst. Fortsätt spendera kraft och pengar på kärnverksamheten, som att SL ska driva kollektivtrafik, inte webbsiter.

Dock kommer detta naturligtvis innebära att finansieringsmodellen måste ändras för vissa myndigheter och organisationer. Vissa är finansierade, eller i varje fall delfinansierade, genom försäljning av förädlad information. Det är ju fint det, och ibland är den förädlade produkten riktigt bra. Men, nja, det är inte värt det. Fortsätt förädla information, och bekosta förädlingen genom försäljning, men annars? Låt den förädlade produkten som de producerar konkurrera på marknaden med förädlade produkter som andra producerar. Släpp informationen och bekosta arbetet från gemensamma medel.

Men detta utgår från att all information ska vara tillgänglig, och frågan är om den är det? Det finns den som inte är det och det är lite trist. Eller rättare sagt, den är tillgänglig, men bara på papper. Eller kanske som fax efter det att ett papper scannats in. Det är naturligtvis inte tillräckligt bra, för information måste vara tillgänglig på ett sätt att den kan behandlas maskinellt. Annars blir det fortfarande bara Web0.9 och inte Web2.0.

Ted Walentin är en person som arbetat hårt att bygga just tjänster med hjälp av information som andra tillhandahåller. Och det finns många fler som gör alldeles utmärkta sådana. Som jobbkartan.se som talar om vilka arbeten som finns att söka i närheten av där du bor. Eller flygkartan.se där man kan se vilka flygplansrörelser som finns. Varför har inte Arbetsförmedleingen byggt en sådan, eller Luftfartsverket? Informationen kommer ändå därifrån.

Nej, vi måste hantera information på ett sätt att vi uppfyller kravet på möjlighet till innovation. För den fastlåsning som idag sker av information i de föråldrade förädlingsprocesser som många offentliga organisationer använder (dock inte alla, det finns undantag) hämmar innovation, och jag hoppas inte det är vad Regeringen önskar.

Känner du något efter det här inlägget? Klicka på en plupp:

(11%) (0%) (11%) (33%) (44%)
9 röster

I höstas skrev jag en post omFem saker alla mediehus bör göra nu”. Den handlade bland annat om att utnyttja nätets giganter för att publicera sitt material. Det slumpade sig så att bara några dagar efteråt öppnade flera tidningar kanaler på Youtube, i samband med lanseringen av den svenska versionen. Sedan har det rullat på, och tex har Expressen börjat med publicering på Flickr. Men jag har hittat få som gjort det fullt ut, och därför blev jag extremt glad när jag läste Sören Karlsson på HD berätta om ”Klickfest på hd.se när studentbalerna bevakas”. Det visar sig att det är Flickr som används för bilderna. På helt rätt sätt. Sören skriver:

För den tekniskt intresserade kan det kanske vara intressant att notera att vi experimenterar lite genom att använda bilddelningssajten Flickr som plattform för studentbilderna. Från Flickr bäddar vi sedan in bilderna på hd.se. Vinsterna med det här sättet att jobba är enkel uppladdning ute från fältet, att det genereras s.k. tumnaglar automatiskt och att våra bilder finns tillgängliga på ett ställe till på nätet (här är hd.se:s Flickr-sida).

Jag tycker det är intressant även för den som kanske inte är så tekniskt intresserad, så jag ställde lite frågor till gänget bakom. Nyttig läsning för den som publicerar mycket bilder. Och missa inte att HD har lagt sin lösning som Open Source på GitHub. Bara att ta hem och göra en egen implementering.

Mikael Rosenlöf, redaktionschef på hd.se berättar:

Anledningen till att det vi körde flickr var mest att det verkade vara ett snabbt sätt att återuppliva det gamla TNG-bildgalleriet utan att behöva bygga ngt i Escenic, vilket iofs förmodligen hade gått, men hade tagit längre tid pga att vi måste lämna kod til IT som sedan ska testas före deploy. Och det skulle tagit mer tid än från måndag när vi bestämde oss till onsdag bär vi körde lösningen för första gången.
En annan faktor som avgjorde var att folket på fältet inte behövdes köra Escenic via 3G-puck, vilket är lite meckligt och att det är relativt smidigt att ladda upp stora mängder bilder med hjälp av iphoto och flickr.

Både Mikael och Sören berättar också att de till nästa gång kan tänkas försöka få till en Creative Commons-licens på materialet. I det här fallet hade det varit extremt välkommet, balbilderna hade garanterat vidarepublicerats av en masse och gett HD mängder med goodwill (och inlänkar…)

Noah Williamsson är kodguru på HD, och en av de smartaste och snabbaste utvecklare jag haft förmånen att jobba med. Han får berätta lite mer om den tekniska lösningen och arbetsflödet:

Lite drygt två dagar tog det, från att ha varit fullkomligt inkompetent på Flickr till att ha ett basic galleri (albumlista, visa album, visa enskild bild med föregående/nästa-länkar).

Vi började på tisdag eftermiddag förra veckan, efter att ha pratat bildvisare, med att konstatera att Flickr tydligen skulle ha ett API. Resten av den dagen gick åt till att läsa på om Flickr och experimentera med deras API med olika existerande lösningar.
Onsdagen gick åt till att knacka ihop den koden som checkades in på GitHub tidigare i veckan.
Micke fixade ihop kopplingen till Escenic, introducerade berörda webbredaktörer och satte ihop dokumentation för arbetssätt etc.

Torsdagen var det bal, lite filande och buggrättningar samt en webbredaktör som på eget initiativ hittat fler sätt att använda Flickr på.

Och tidigare i veckan ville Sören ha något smidigt sätt att få in läsarbilder på sajten.
Micke hade en ide om upptaggning på Flickr och i samband med det så hittade jag det Flickr kallar “machine tags” (formatet är ungefär namespace:subject=arbitraryvalue). Så då byggde jag in stöd för det i koden också, nu kan man göra t.ex. http://hd.se/bildgalleri/?set=sneakrz-shoe-50 (hittar bilder taggade med sneakrz:shoe=50)

Det gör att vi i princip skulle kunna be läsarna att tagga upp sina Flickr-bilder med hd:lasarbild=nyarssaluten eller hd:lasarbild=vårtecken, och sedan presentera ett bildgalleri på sajten som söker hos Flickr efter bilder med dessa taggar.

Vi kör f.n. busigt med en non-commercial API key på grund av de snabba puckarna.
Har skickat in begäran efter en kommersiell API nyckel häromdagen men det är handläggningstider på 2-4 veckor.
Ett nej på den requesten (och ev efterföljande, om man orkar) vore riktigt tråkigt och riskerar, om de är tjuriga, att vi blir av med kontot.

Jag funderade också lite på hur mycket bandbredd det här sparade, eftersom bilderna ju levereras från Flickr istället för via den egna linan. Noah hade svar på det också:

GA har räknat 49k unika sidvisningar för Helsingborgsbalen hittills, och 84k för Ängelholmsbalen.

Med reservation för att jag tänkt eller räknat fel;
Räknar man bort unika visningarna av Helsingborgsgalleriets startsida (den med tummnaglarna, 2300 unika visningar) hamnar vi på ca 47k sidvisningar. Den siffran innehåller x unika besökare, som tittat på i snitt y unika bilder. Man borde kunna utgå från att visad bild hamnar i browser cachen, varför det totalt antalet sidvisningar är irrelevant.

Med ett snitt på 60kb per bild som visar i galleriet gånger 47 unika sidvisningar så handlar det alltså hittils om ca 2800 megabyte data. Som också är 2.8 gigabyte, och som kan avrundas till ungefär 28GBit med om man räknar in overheaden vid överföringen. Slår man ut 28GBit över fem-sex timmar så hamnar man någonstans runt 1.5mbit/sekund. Och detta är alltså peak-siffror vid en relativt stor händelse.

Det kan jämföras med att bara HTML-koden (35kb komprimerad) som skickas ut vid varje sidvisning (500k/dag) äter 2mbit/sekund, varje dag. Och då är det inte inräknat bilder men framförallt webb-tv här heller.

I det långa loppet är nog den största vinsten med Flickr inte bandbredden utan snarare vad vi slipper underhålla och ta backup på. För att inte tala om räckvidden och de sociala bitarna som kommer automatiskt med Flickr.

Och därmed sätter jag punkt för dagens lilla lektion i ”hur man gör saker på rätt sätt”;)

Känner du något efter det här inlägget? Klicka på en plupp:

(0%) (0%) (0%) (0%) (100%)
3 röster

OK, alla mediechefer där ute. Fram med att-göra-listan och skriv in de här fem punkterna. Sätt sedan igång och implementera dem direkt. Det är ingen raketforskning. Det finns inget att förlora. Det finns kanske en och annan vägbula som ni måste över, men tro mig – det här måste göras. ”Resistance is futile” skulle man kunna säga, men faktum är det bara är halva sanningen. Det är inget vi behöver känna motstånd inför, utan det kommer att bygga vår affär. Här är punkterna i korthet:

  1. Placera allt egenproducerat material under en Creative Commons-licens. På mindpark.se har vi valt  licensen som tillåter oberänsat utnyttjande av allt vi gör, men för traditionella mediehus är nog ”Erkännade-ickekommersiell” den rätta nivån.
  2. Se till att allt material är åtkomligt via RSS, även sökningar och andra specialare. RSS:a upp hela sajten. (Är du osäker på RSS finns en bra intro ”in plain english” från Commoncraft). Och som Networkers.se skriver så bra: se till att det är fulla flöden, inte bara ingresser eller kapade texter.
  3. Lägg ut hela bildarkivet på Flickr. Det finns andra sajter men Flickr är min favorit. Deras teknik är industrial strength, de har ett bra api och de har en stor publik. Flera fotografer har upptäckt detsamma.
  4. Dubbelpublicera all video på Youtube, av samma skäl som jag väljer Flickr här ovan. Publiken finns där och tekniken funkar. Givetvis har de ett api och det är ingen konst att integrera det i dagens arbetsflöde. Inget extra arbete alltså.
  5. Och på tal om API, skaffa ett eget. Gör ditt innehåll ”programerbart”. Det är det stora steget av de här fem, så det behöver inte vara klart imorgon. Men börja läs på, och börja arbeta i den riktningen.

I korthet – det handlar om att göra allt vårt material tillgängligt för vidarepublicering. Allt som vi idag publicerar digitalt går tekniskt att använda av vem som helst redan idag, men vi säger att de bryter mot vår upphovsrätt då. Det finns mycket att vinna på att vända på den stenen. Några punkter:

  • Vi gör det lättare för den som är kommersiellt intresserad av vårt material att hitta det. Flera fotografer säger idag att deras bästa försäljningskanal är Flickr. Vi kommer att sälja mer.
  • Vi låter miljontals privatpersoner över hela världen dra nytta av vårt material. De länkar tillbaka till oss, vi vinner goodwill, vi blir kompisar med publiken istället för att stöta bort dem. De som redan hittar till våra sajter är inte målgruppen – det är den breda publiken på tex Youtube och Flickr som nu får en chans att bygga en relation med oss.
  • Vi får bättre möjlighet att hålla koll. Redan idag återvinns en hel del av vårt matrial. Men då utan länk till oss, utan möjlighet för oss att räkna hur det nyttjas, var det nyttjas. Vi tappar fullständigt greppet, till ingen som helst nytta alls.
  • Vi kliver ut och tar aktiv del av uppbyggnaden av det kollektiva medvetandet och jag lovar, JAG LOVAR, att vi kommer att få så mycket mer tillbaka. Give, and you shall recieve. Det funkar, det är inte bara flum och filosofi. Vi kommer säkert att få mycket cred också, tex från den allt mäktigare bloggosfären.
  • Rent tekniskt gör det ju inte ont att vi på köpet får offsite-backup på allt material också, helt utan kostnad.

Det finns egentligen bara ett enda problem och det kommer att handla om gränsdragningar. Det kommer inte alltid att vara enkelt att hävda skillnader mellan kommersiellt och icke-kommersiellt utnyttjande. Men där måste vi vara frikostiga, att en hobbyblogg kör lite adsense borde inte få oss att skramla med advokater. Grundprincipen är att de flesta aktörer som är kommersiella på riktigt ändå kommer att vilja göra rätt för sig.

Jag kan lista många fler fördelar och självklarheter som leder fram till slutsatsen att det här bara är att göra. Men jag är mer nyfiken på de som säger att det här är fel. Kom igen, upp till debatt. Ge mig fem lika starka skäl till varför det här INTE ska göras.

[uppdatering: jag har ett par sådana fempunkts-listor till som kommer efter hand; den här handlar om hur vi publicerar. Det kändes som det enklaste första steget för det är så otroligt konkret. Men jag återkommer till intag, medverkan, arbetsflöde och organisation, nya funktioner och tjänster etc... Dessutom: det finns masterplan för intäkterna. Den kommer snart den också. Debattera så länge...]

Andra som skriver på det här temat:

Känner du något efter det här inlägget? Klicka på en plupp:

(0%) (0%) (25%) (0%) (75%)
4 röster

Så inleds den gamla klassikern Epic 2014 (och även uppföljaren Epic 2015). Har du inte sett dem, så se dem. Eller se dem igen – de är underbara tidsdokument och fortfarande snyggt producerade. Deras tagline lyder så här:

In the year 2014 the New York times has gone offline. The Fourth Estate’s fortunes have waned. What happened to the news and what is EPIC?

Jag kommer självklart att tänka på det när jag läser den information som börjar sippra ut om New York Times API. Den konstiga förkortningen står för Application Programming Interface och betyder i detta fallet helt enkelt att man öppnar upp för maskinell bearbetning av sitt innehåll. I sin yttersta form kan det egentligen betyda att vem som helt kan programmera att skal, ett lager, ovanpå allt innehåll som finns hos NYT. Men hur långt man kommer att gå är inte klart än. Aron Pilhofer, chef för Interactive News, säger att man vill ”göra NYT programmeringsbar”. Men han säger också:

Once the API is complete, the Times‘ internal developers will use it to build platforms to organize all the structured data such as events listings, restaurants reviews, recipes, etc. They will offer a key to programmers, developers and others who are interested in mashing-up various data sets on the site. “The plan is definitely to open [the code] up,” Frons said. “How far we don’t know.

Även om de inte går hela vägen nu, så visar det tydligt på vilken riktning det bär iväg mot. Jag tror man har gjort samma analys som jag och många andra – ska man vara relevant i framtiden så gäller det att möta publiken där publiken finns. Den som gör det enklast för publiken att bryta loss sina ”conversation pieces” är den som vinner. Den vinner i alla fall publikens hjärta. Men affären då?

Så sent som idag, i samband med en presentation i Oslo fick jag den frågan. Och tror mig, jag förstår frågan. Den är helt logisk, det är klart att vi – som haft en stabil affärsmodell i 180 år – undrar hur vi ska tjäna pengar när vi inte ens har besökarna på vår sajt. Men det är inte det vi ska oroa oss för, inte nu.

Självklart har jag en plan på hur vi ska tjäna pengar. Men det måste koka lite till. Än så länge kan vi nöja oss med att konstatera att om vi inte är snabba och om vi inte krokar på i den här utvecklingen så kommer vi att förlora vår relevans och vår roll helt och hållet. Och då kan vi garanterat inte dra in några pengar. Det finns bara ett motsatt alternativ: att köra på som man gör nu, tjäna så mycket pengar man kan så länge man kan, och under tiden planera för sin nedläggning. Jag återkommer till hur det kan undvikas, för jag ser verkligen att det är ”the best of times”

Förresten, en annan spännande sak. Jag har propagerat hårt i diskussioner om olika sajter att man oftast bör välja ben. Antingen är man en ”original content provider” och då gäller det att öppna sig så mycket som möjligt och få ut sitt innehåll på så många täter som möjligt. Eller så är man en ”aggregator” och arbetar med att bygga skal. Då är det spännande att dagen efter att NYT tar ett steg närmare mot content, så tar TV4 här hemma ett steg närmare aggregator. Spana in den samlingstjänst som fotbollskanalen.se under namnet ”Min arena” bygger tillsammans med netvibes. Bra tänkt.

Känner du något efter det här inlägget? Klicka på en plupp:

(0%) (0%) (0%) (0%) (0%)
Inga röster

Idag lanserades Google App Engine, och bloggosfären gick totalt bananas. Men jag tycker det är dåligt fokus på det som är det verkligt briljanta. Den här sortens tjänster har i någon mån funnits tidigare. Men Google gör det så klart med en twist. En baktanke. Mer smartness än andra. Via val av lösning och prissättning (gratis insteg) har man har hittat ett mekaniskt sätt att fånga upp smartskallarna. Låt mig förklara.

I korthet handlar Google App Engine om en gratis driftsmiljö för dina applikationer. Du hackar ihop en pythonapp på din lokala maskin och sedan laddar du upp den till googles massiva miljö. Förutom servrar som är tajt integrerade och tål all trafik du kan kasta på dem så får du tillgång till en massa godis. Tex kopplingar till deras api för users, mail och url-fetch, Django mm – och allt är snyggt (vad jag kan bedöma) samlat i ett gemensamt ramverk som kallas webapp.

För allt detta betalar du ingenting. Så länge du håller dig under deras relativt frikostiga begränsningar (ca 5 miljoner sidvisningar, tex) är det helt gratis. Än så länge är det sluten beta, och avtalet kan ändras, men inget tyder på att det kommer att förändras till det sämre iaf. Man flaggar för att det kommer att bli en kostnad för utnyttjande över de gränser man sätter. Men jag tror inte det är där affärsmodellen ligger.

Istället tror jag det handlar om att attrahera smartskallarna. Det här tillåter ju en extrem form av bootstrapping. Du kan testa din idé utan att det kostar ett öre. Om den visar sig flyga så kan du ju alltid betala för fortsatt drift. Men långt innan du får en faktura tror jag det blinkar stora röda lampor hos Google, som talar om för dem att här händer det saker. Och då kommer de och knackar på din dörr med ett bra erbjudande.

Det finns mer att säga, om hur det här står sig mot amazons alternativ (och varför google är smartare), om eventuella risker med ännu fler ägg i Googles korg, om vår egen modell för att attrahera smartskallar och om den ständiga jakten på ”the next big thing”. Men det få bli senare. Jag vill avvakta och se hur Google App Engine tas emot över tiden. Och jag vill hinna testa mitt eget konto…

Tills dess, läs mer hos till exempel:

Känner du något efter det här inlägget? Klicka på en plupp:

(0%) (0%) (0%) (0%) (0%)
Inga röster

Lifestream är ett begrepp som handlar om att på ett samlat sätt kunna presentera sina digitala fotspår. I takt med att vi blivit mycket mer aktiva, både i fler tjänster, men också totalt på nätet har det här kommit att bli något som väldigt många pratar om.

Enkelt uttryckt, ett exempel: du lägger dina filmer på youtube, du direktsänder video från nallen via bambuser, du tankar upp bilder både på flickr och på picasa, du microbloggar på jaiku, du har såklart både en och två bloggar, och dessutom kommenterar du hej vilt både på de tjänsterna, men också på vanliga nyhetssajter – det även kan handla om tex en läsarbild du skickat in. En lång lista och det var ändå bara ett litet urval. (Jag räknar med att jag är mer eller mindre aktiv på minst ett 50-tal platser/tjänster på nätet.) Hur ska någon som som är intresserad av att hänga med i ditt liv ha en chans. Och hur ska du känna att du ”äger” dina egna fotspår. Någon form av lifestream är svaret.

Många tjänster har gjort en variant på det genom att göra det enkelt att prenumerera på ett rss-flöde. Tex är det kan man flöda in många kanaler i sin news feed i facebook eller i jaiku. Men det är ett för trubbigt vapen. Du kan inte samla in allt, och du kan inte få ut det i ett vettigt format om du vill publicera ditt flöde någon annanstans. Framför allt missas ofta kommentarerna. Det du säger i en kommentar ska ju inte försvinna i molnet. Din klokskap förtjänar ett bättre öde. Så det har utvecklats tjänster som specialicerat sig på att hantera ditt ständiga flöde av digitala fotspår, och den som skapat mest buzz på sista tiden är FriendFeed. Och i natt hände äntligen det som alla väntat på.

FriendFeed har släppt sitt api, och det ser vackert ut. Du blir kanske inte så upphetsad om du inte vet något om vad ett api kan göra, och i så fall blir du förmodligen inte mer upphetsad efter att ha läst wikipedias förklaring ;) Men helt kort betyder det här att FriendFeed kan komma att fungera som en stabil och vidöppen motor för att hantera ditt digitala flöde. Nu är det enkelt för alla som driver någon slags tjänst på nätet att se till att det du gör hos dem kommuniceras in till din lifestream, direkt. Och det är enkelt för dig att avgöra hur den informationen ska presenteras, var och för vem.

Förresten, Morris hörde precis av sig med ett koppel sköna idéer – som alltid. De tog avstamp i att ”FriendFeeds sajt är skitful och helt felbyggd”. Det har han helt rätt och och det är så det ska vara. Friendfeed är motorn, inte själva skyltfönstret. Så det är bara att sätta igång och bygga dina sajter ovanpå friendfeeds API, Morris. Do it!

Komplicerat? Kanske. Men tro mig, du kommer att stöta på det framöver, och du kommer att gilla det. Så, march iväg och sätt upp ditt eget flöde, och just nu rekommenderar jag alltså FriendFeed. Det finns många fler element i det här pusslet som håller på att byggas. OpenID har bra tryck när det gäller hantering av identitet och inloggningar, OpenSocial ser intressant ut för att ta ytterligare steg utanför specifika walled gardens när det gäller applikationer, ytterligare andra jobbar med öppna lösningar för vår profilinformation, våra kontaktlistor – snart sagt allting som idag ligger låst i olika applikationer på datorn eller på nätet. Läs tex om OAuth och OpenID här. Det är spännande tider av öppenhet och möjligheter, och alla verkar dras in i molnet.

Lifestream som begrepp förresten, är ju inte så lysade för oss. Välkommen att komma på ett bra svenskt namn. Digitala fotspår leder, än så länge.

Berätta gärna för mig om du hittar bra tillämpningar av det här, själv tänker jag sätta mig och börja klura på hur vi ska hantera det. Under tiden startar jag tidtagningsuret för att se när (om) någon av de kommersiella cms-leverantörerna i sverige tänker göra något av det här…

(Det är ännu tidigt over there men fler ser med väldigt nyfikna ögon fram emot det här. Tex RWW som skriver FriendFeed Launches API – This Should be Interesting)

Update: Mashable skriver intressant på temat, och pekar också till första utkastet på en WP-plugin som tänker helt rätt: ”FriendFeed API: The Conversation Re-Joins the Blogosphere

Update2: Det blev en intressant jaiku-diskussion på temat. Läs den här.

Känner du något efter det här inlägget? Klicka på en plupp:

(0%) (0%) (50%) (25%) (25%)
4 röster