Det grymma med att vara på en bred utvecklarkonferens som Øredev är ju att det är lätt att gå lite utanför den vanliga fåran, där man brukar vara.

Jag har gått på några UX presentationer idag som varit rätt bra. Om man ska vara riktigt generös med tolkningen av användare så var jag på en igår också på temat ”API the hidden UI”. Tanken är att den som kommer använda ditt API också är någon form av användare, en stor skillnad är dock att ett GUI kan ändras efter att det börjat användas, ett API kan däremot inte ändras utan att saker verkligen går sönder för användare. I princip kan man säga (ok, lite hårddraget) att man bara har en chans att göra API:t rätt. När det publicerats är det användarna som äger det. Inte själva implementationen, men du kan inte ändra hur som helst längre.

Flera av lärdomarna där har jag hört upprepas idag på mer traditionella UX presentationer t ex:

• När man får förfrågningar om nya funktioner får man det oftast i form av ett halvfärdigt lösningsförslag. Försök att fokusera på det underliggande problemet istället. En princip som kan användas är att det inte ska bli bättre bara för en användare utan för många. Beställaren ska kunna motivera varför, för vilka den löser vilket problem.
• Använd konventioner som är utbredda. Analogt med att användare spenderar mest tid på andra webbplatser än din egen, så spenderar API-användare mest tid med andra API:er än ditt. Ett exempel är att en relation mellan brukar benämnas parent-child. Om man i sitt API kallar det för father kommer det bli förvirrande.

Jeff Patton presenterade två klassiska ”failure modes” när man utvecklar och jobbar (mindre bra) med UX:

1. Man antar att ”om jag gillar det så kommer användarna också göra det”
2. Man frågar användare direkt vad de vill ha och ger användare skulden om det inte blir bra.

Sam Ramji från Apigee höll en föreläsning om strategier för API:er. Många bra tankar.

RAMVERK FÖR API-STRATEGI (modifierad för att passa AB)
1. Vad vill vi uppnå? Motivera och förklara.
– effektiv utveckling av nya och befintliga tjänster
– leverera innehåll i fler kanaler
– publikt API (steg 2)

2. Target your Developers
Utvecklingsspråk: Facebook oväntat stora, PHP enormt stort, Javascript stort och ökande.

Publik eller privat – Öppet eller Stängt? Vi börjar privat och stängt.

3. Sätt mål, metrics och KPI:er
För internt API blir det en annan typ av mål än ett publikt. Exempel: antal app:ar, developer satisfaction, användning, antal anrop etc

4. Sätt en roadmap för utvecklingen
– vem gör vad?
– prioritering?
– tidsplan

5. Manage the API Program
– vem ansvarar för API:et?
– hur underhåller vi och utvecklar API:et?
– hur följer vi upp nyttjande?
– hur prioriterar vi utveckling av API:et?
– utbilda och motivera

Idé: API-team med övriga utvecklare som beställare.

Roller: Developer Envangelist (intern), Developer Advocate (hur ska vi bygga)

Men först: utred vilket eller vilka ramverk som passar oss bäst. Bygg inte saker som redan finns.

TO DO #1: Definiera hur vårt API ska se ut (behövs olika för artiklar och recensioner t ex)
TO DO #2: Inventera vilken information vi har
TO DO #3: Kolla upp Apigees tjänster och andra som t ex Mashery

Talare: Zach Brand, NPR Digital Media

Mycket intressant session där Zach berättar om NPR:s strategier för API och innehåll. Sessionen började med en kort inledning med en sammanfattning av vad API, COPE, Crossmedia och CMS innebär och vad man menar med dessa definitioner.

 Crossmedia strategier, varför ska man ha det?
Användarna finns på alla plattformar och vi har behov av att få ut innehåll i alla kanaler ex. mobila appar, tables etc.

• Bygg inte ”ett system” som gör allt. Bygg flera små. Det kommer innebära flera API:er för olika syften och innehåll utifrån behov.
• COPE ”Create one publish everywhere” – Storybaserat innehåll via API för flera kanaler
• CM verktyg och presentationslager
• Förstå din kärna (Stories ex. text, video, images)Skapar förståelse för vad API ska göra, hur ska API leverera en story
• Tänk på innehållet som lagras och publiceras, det blir tillgängligt för alla så tänk på vad och hur du skriver.
• Öka flexibiliteten för innehållet

Mål för API

• Distribuera content öppet, även för ex. partners och kunder
• Gör ditt innehåll tillgängligt för alla
• Snabbare app-utveckling och enklare underhåll

NPR:s arkitektur för COPE
Olika datalager för att distribuera ut storys tll olika kanaler

Har API:et förbättrat appliktionsutvecklingen för NPR?
Ja, snabbare och enklare att utveckla för mobilt och tablet. Med ett bra API går det enkelt att anpassa presentationslagret för olika kanaler.

+ Underhållet förenklas, separera innehåll, presentation, xml repository, CMS)
+ Inte bara en teknikfråga, förstå hur vi använder verktygen och presenterar och arbetar med innehållet ex. SEO

Fick vi en massa ”Free stuff”?
Ja, var beredd på att andra kommer utveckla produkter på ditt innehåll ex. en androidapp eller andra tjänster som du inte har kontroll över. Prioritera bra dokumentation för ditt API.

Har vi blivit mer flexibla?
Vissa begränsningar med storys när man ville lansera ett digitalt bibliotek om böcker där det fanns andra behov för attribut som inte passade in i storyn. Man behövde utveckla ett separat bok API och det finns behov för fler API när man gör vägvalet för att inte ha ”ett” system som gör allt.

Läs mer: API www.npr.org/api
Blog: http://www.npr.org/blogs/inside