Presentationen börjar med en intressant bild över State of (mobile) web development 2011.

Javascript –  det är där det händer. Påminner om att vi måste satsa ännu mer på det området. Återigen hamras det in att mobilen kommer att gå om desktop inom några år. En annan trend är att HTML5 ökar i popularitet i förhållande till Objective-C.

Exempel på appar byggda i HTML5: Facebook, Netflix, Zynga, Sports Illustrated.

Några ord om Open Source: embrace (dont replace), contribute (dont fork) & promote (inga hemligheter).

Använd ramverk och bygg inte allt från början (JQuery, Dojo etc).

Apps vs Mobile webb?
Vi behöver både närvaro i appstore och ha en mobilsajt. Använd samma kodbas.

Sammanfattning i korthet: bygg app:ar i HTML5 och inte Native Apps.

Mer info
html5rocks.com
diveintohtml5.org 

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

Dag 2 börjar med en presentation från Yahoo om hur annonser påverkar laddningstid och upplevelse. Aftonbladets lead developer Tobias Järlund har hållit flera uppskattade presentationer och skrivit blogginlägg kring ämnet.

Att annonser påverkar prestanda är negativt både för sajtägare och annonsörer. Det är ett gemensamt problem. Ett grundläggande problem är annonsnätverken och att dessa ligger utanför sajternas kontroll.

Det gamla sättet: ladda innehåll och annonser samtidigt (annonser har åtkomst till DOM och kakor, ingen skillnad på innehåll och annonser, synkron blockerande laddning).

Nytt sätt: ladda sidan först, fyll sedan på med annonser (prioriterar användarens upplevelse).

Yahoos strategi är att precis som Aftonbladet ladda annonser i iFrame och att först läsa in själva sidan och sedan fylla på med annonser.

Några tips
– Sandboxa annonser i en iFrame (Aftonbladet använder Friendly IFrames, se Tobias presentation)
– Leverera iFrame från en annan domän (säkrare, stabilare, bättre prestanda)
– Implementera ett API för richer functionality (rollovers, expanding)
– Använd ajax för att ladda annonsinnehållet

Yahoo använder också Double Buffering för att byta annons i en annonsposition utan att ladda om sidan:
– ladda första annonsen i iframe
– ladda andra annonsen i en iframe under den första iframe
– när den andra annonsen laddas ta bort den första iFramen

TO DO: Ta reda på vad som är segt (decisioning, serving, network).
Hur? Hitta sätt att mäta varje annons och varje position. Sätt thresholds och larm. Följ upp.

En väldigt välbesökt session där det inte fanns sittplatser åt alla. Det känns i rummet att HTML5 är hett.

Det har hänt mycket senaste året och nu är stödet för html5 utbrett. IE9 och Firefox 4 med bättre stöd har lanserats. Ett stort steg är IE10 preview 3 som fortfarande ligger efter övriga men den versionen lovar gott.

Vad i HTML5 kan användas idag?
– se presentation för vilka taggar som är lämpliga (kommer snart)
– Geolocation API (fungerar på alla browsers och från IE9). Använd för Mobila webbapp:ar.

Vad är ’roughly usable’ (alla browsers förutom IE..)?
– history.pushState – update durrent URL (används av Facebook och Flickr). Stöds av alla utom IE – kommer i IE10 nästa år. Fallback: om det inte finns stöd ladda om hela sidan.

Vad går att experimentera med? (Minimal eller experimentell support)
– File API
– Web Sockets API
– Indexed Database
– Web Storage (typ stora kakor)
– Web Workers
– Web Messaging

Tips:
– Använd Progressive Enhancement istället för Graceful  Degradation
– Unobtrusive Javascript/AJAX
– Offline Web Applications (hur? Spara innehållet lokalt: Web Storage, Indexed Database, används t ex av Gmail)
– Använd Modernizr to detect and use offline/APIs

Största skillnaden mellan native och webapp:ar är att webbapp:ar når fler typer av enheter och är mer framtidssäkrat. Därför är det bättre än native apps i de flesta fall.

Tips på hur du håller dig uppdaterad om HTML5:
– Läs ’Latest Editors Drafts’ på W3C.
– Läs (bidra) WHATWG wiki
– Join #html5 IRC

Slutsats: HTML5. Nu är det dags. Men vi måste ha koll på vad som fungerar och vad som inte gör det.

Ett genomgående tema på konferensen är mobilen och hur viktigt det är att förstå och följa utvecklingen. Det här var den hittills bästa sessionen.

Den här sessionens tes är: Web products should be designed for mobile first.

1. Growth = Opportunity
Alla har mobiler och försäljningen ökar enormt. 40% av alla tweets är via mobil. 16% av nya användare på Twitter börjar nu i mobilen. Om drygt 2 år passerar antalet Smartphones antalet PC:s. Hemmaanvändandet av PC har minskat med 20% i USA sedan 2008. Varför? Smartphone och Tablets ersätter. Mobila FB-användare använder FB dubbelt så mycket som datoranvändare. 33% av inläggen sker via mobilen.

Analys: Mobila enheter blir vanligare än datorer för att nå webben under 2013.

2. Constraints = Focus
Skärmstorlek: 1024×768 blir 320×480. 80% måste bort. Begränsningarna tvingar fram prioritering av vad som är viktigt. Hur? Ta reda på vad användarna verkligen vill ha.

Nätverkshastighet: uppkopplingen går upp och ner. Lösning: skicka mindre data, komprimera och optimera för mobila enheter så blir webben automatiskt bättre

Omgivningen – mode of use: Mobilen används ofta i en rörig miljö i farten. Designa för ett öga och en tumme. Bra och enkel design i mobilen blir bra och enkel design på webben. Gör det som är viktigt för användarna.

3. Capabilities = Innovation
Tilt-scrollning. Tilta framåt och bakåt för automatisk scrollning. Går att göra för våra artiklar.

Touch-baserade skärmar. Hur använder användarna touch? Innehållet är interfacet. Jfr med hur barn interagerar med en iPad. Naturligt och enkelt. Vilka olika typer finns: tap, double tap, shake, rotate, drag etc. Läs mer här lukew.com/touch

Geolocation: var befinner sig användaren?

…och mer: NFC, två kameror, scanning, gyroscope, audio input, augmented reality…mm (se presentationen).

Slutsats #1: hur kan vi förbättra våra befintliga tjänster och utveckla nya med tanke på ovanstående punkter?

Slutsats #2: Utveckla för Mobilen först så blir även webben bättre. Enkelt att säga svårt att utföra. Webben sitter i väggarna. Vi har lite att göra när vi kommer hem.

Den andra sessionen hölls av NPR från vilka vi lånat COPE-tänket. En sammanfattning av förra årets NPR-session finns här.

Utmaning: få ut innehåll i olika kanaler.

Principer:
– Bygg inte ett stort system – koppla ihop många mindre komponenter
– COPE (se tidigare inlägg)
– CMS och presentationslagret är olika saker
– ATOM (Storyn är NPR:s atom, Storyn har Assets (text, bild, video etc) och tillhör listor)
– IT is better to be incomplete than inaccurate

Mål för NPR:s API:
1. Öka effektiviteten i utveckling
2. Distribuera till partners
3. Tillåt omvärlden at bygga tjänster
4. Öka flexibilitet i vad som kan göras med innehållet

Det spelar ingen roll vilket CMS som använts bara innehållet sparas på ett bra sätt. Abstrahera innehållet och spara inte som HTML är NPR:s tips. Här har vi en bra bit kvar…

(Infoga bild av NPR Architecture of COPE)

Hur har det gått senaste 3 åren? Resultat och lärdomar:
– Ökad effektivitet -> ja, endast utveckling i presentationslagret krävs i de flesta nya projekt
– När API:et är byggt måste det användas rätt (internt och externt)
– Skalbarhet är viktigt. Cacha, cacha, cacha.
– XML användes till en början hela vägen i API:et men det krävde mycket underhåll. NPR byggde om hela arkitekturen och byggde om till serialiserade PHP objekt. Enklare kod och mer rakt på. Resultat: bättre prestanda, snabbare utveckling, inga enorma DOM-träd.
– Bilder. NPR använder Imagemagic.

Vad händer om hela storyn bygger på Flash eller flera bilder för att fungera? Lösning: tagga upp det som är viktigt i storyn.

Viktigt att trycka ut uppdateringar och om artikeln blivit borttagen.

Har externa utvecklare byggt tjänster på API:et? Ja, t ex iPhone-app. En google-utvecklare byggde också en NPR-Android-app på sin 20% innovationstid.

Hur hantera t ex bokrecensioner i ett Storybaserat API? Det går men kräver mycket logik i presentationslagret. Det finns begränsningar och lösningen är att bygga ett recensions-API.

Tips: bygg inte själva utan använd Mashery eller liknande. Det fanns inte när NPR började bygga sitt API.

Frågor:
– Bygger alla tjänster på API:et? Ja, alla nya. Fortfarande finns legacy som inte gör det.
– Hur hanteras UX? Inom utvecklingsteamet i 2-veckorssprintar.
– Hur hanteras CSS för olika kanaler? Varje kanal hanteras separat. I det bästa av världar kan ett presentations-API fungera.
– Hur tar man sig ur ett CMS-beroende där innehåll och presentation sitter ihop? Lös det inkrementellt. Låt ingen lägga in html direkt. Parsa och städa upp lite i taget.

Mer info: npr.org/blogs/inside

Min första session handlade om framtiden för betalningar. Det var en sponsrad session av Visa vilket är lite av en chansning då säljbudskapet oftast tar över. Det började bra men gled sedan över till mer och mer sälj. Betyg: 2 av 5.

Den springande punkten var att mobila betalningar ökar enormt. Visa satsar hårt på en digital plånbok. Nyckeln är enkelhet och att det fungerar att betala med den överallt.

2015 finns det fler mobilanvändare än datoranvändare. Jag tror att det går fortare för oss. Sociala medier:  78% av handlarna har ett FB-konto. Ett ökande område är mobila spel. Här är det främst in-game betalningar som gäller. Prognos: Mobila betalningar är 35% av alla betalningar 2012.

Mobilen har några unika egenskaper t ex att den är personlig och lokaliserad vilket innebär möjlighet att styra och anpassa erbjudanden.

Nästa generations betalningslösning måste vara:
– enkel (one-click-payment)
– standardiserad
– säker
– globaliserad

Betallösningarna måste också vara enkla för utvecklade att integrera och innovera kring.

Visas digitala plånbok kommer att rulla ut under hösten med start i USA.

Lärdom: planera för mobila betalningar för alla våra tjänster. Hur kan vi använda digitala plånböcker kopplade till mobilen? Vilka nya erbjudande kan vi ta fram baserat på det?

För andra året har Schibsted och Aftonbladet skickat en delegation till Web 2.0 Expo i NY. Namnet i år är Unlock the Digital Economy. Förväntningarna är höga och programmet ser väldigt intressant ut. Vi kommer att rapportera löpande i bloggen. Det blir råa anteckningar blandat med tankar och idéer. Nu kör vi.