Talare: Chad Dickerson

”A strong culture can overcome almost any bad decision in technology”
http://www.web2expo.com/webexny2011/public/schedule/detail/21279

En inspirerande session där Chad Dickerson berättar om hur de arbetar på Etsy med att odla en stark kultur bland utvecklarna och att man behöver en tydlig vision om vilken kultur man vill ha.  Definiera visionen och gör den till en synlig prioritet. Se det som en pågående organisk aktivitet.

Etsy’s kultur
– Be Nice or leave (visa respekt mot varandra)
– Få saker gjorda – principer för progress, skapa en bra miljö   (vad motiverar våra medarbetare) Verktyget ”Deployinate” – Deploy to QA en plats för att bidra till förslag för progress arbete.
– Skylta med ditt budskap – ”Just ship” trycktes upp på T-shirts
– Make a statement – engineers are creative people – Vi skapar konst ”We think of our code as craft” skapade en utvecklarblog codeascraft.etsy.com där skriver vi om saker som gör oss obekväma och tycker är jobbiga.
– Skapa en miniconference och prata om kulturen för andra och hur man vill jobba.
– Visa upp företaget och kulturen vid rekrytering på events
– Viktigt med beröm, vi är generösa och uppmärksammar vårt arbete på avdelningen
– Var lite tokig, vi har roligt!
– ”A strong culture is  a fun culture”

Blir nyfiken på hur vår vision kan definieras på Aftonbladet IT. Hur ser vi på vår kultur och hur vill vi att den ska vara när den är som bäst?

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.

Talare: Luke Wroblewski

”Luke is currently Chief Product Officer and co-founder of Bagcheck Inc. Prior to this, he was an Entrepreneur in Residence (EIR) at Benchmark Capital and the Chief Design Architect (VP) at Yahoo! ”
http://www.web2expo.com/webexny2011/public/schedule/detail/21259

Tänk på upplevelsen utifrån mobilen först, inte webben
”Mobile first and desktop second”
”Mobile applications first because there are better apps”

Trender 

1. Bättre prestanda
2. Bättre nät/uppkopplingar/anslutningar
3. Molntjänster

Vad innebär det då rent praktiskt?

Talare: Nick Disabato – Interaktionsdesigner från Chicago.

Nick berättar om ”Poor expectation management ” och olika negativa mönster som visar tydliga briser i design av webbapplikationer. Dessa mönster återfinns i allt från betaltjänster och annonser där tjänsten förmedlar fel information till besökaren.
Som användare är det ofta otydligt vad som händer med ex. min information i sociala medier och e-handelstjänster vid registrering och annonser som man klickar på.

Applikationer inger ofta falska intentioner och man får ofta något annat än vad man tror i ex. en kampanj som kan vara en inbjudningar till pyramidspel eller svårigheter att avregistrera sig från en webbtjänst. Tilliten för varumärket, produkten eller tjänsten påverkas mycket negativt vid dessa tillfällen.

Hur skulle vi då kunna undvika och förbättra för användaren och hur skulle då ett businesscase se ut? Vad kan vi mäta och hur kan vi skapa värde genom att börja använda bra design och UX?

Några användbara nyckeltal

• Besökarfrekvens
• Antal samtal från besökare
• Antal nya registreringar
• Antal problem på sociala medier

Hur kan vi bygga bättre design för att förhindra ”Poor expectation management”

• Hirarki – Vad vill vi att användaren ska göra på sidan ex. logga in, posta information, interagera etc.tydliggör förväntningar och intentionerna för besökaren.
• Timing – Presentera information i rätt sammanhang.
  Ex. i ett köpflöde kan man presentera flera produkter efter färdig betalning.
• Defaults – Var tydlig i vad man kan ändra på som användare
  Ex. i ett formulär eller editering av information.
• Simplicity – vs Complexity
  Ofta vanligt i sociala medier och här kan man jämför rättighetsinställningar för ex. Twitter och Facebook.
• Copy & Tone – Hur kommunicerar vi med våra användare, vilken ton använder vi?

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

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 

Första sessionen lyssnade jag på Scott Smith som berättade om applikationsutveckling för tablets ”Rules of the road”. Scott berättade om hur han själv upplevt vikten av att ha tydliga regler utifrån ett beställarperspektiv och att det finns några stora avgörande faktorer om man ska lyckas med utvecklingen av Tablet apps.

 (Scott Smith is the Senior Director of IT Publishing Solutions at Time Inc., where he leads (and takes most of the credit for) a twenty-person team that helps develop and integrate software across the enterprise.)
http://www.web2expo.com/webexny2011/public/schedule/detail/21834

#1 Choose the right partner
Lite marknadsföring för Woodwing men syftet var att tydliggöra att ett nära samarbete med en bra partner är avgörande.

#2 Know the territory
Vilken tablet är rätt för dig och din produkt? Fundera igenom vilket operativ som är bäst för dina behov och checka av samt jämför key features som du behöver.

#3 Get business ”by-in” on your ”rules of the road”.
Tiden är ofta det viktigaste, man vill vara först ut med en produkt i ex. ipad men det finns tid att spara om man tänker och planerar på rätt sätt innan man sätter igång utvecklingen.

– Vem är sponsor för affären?
– Vem äger produkten
– Är det en strategisk investering, finns en specifik ROI?
– Hur ska produkten marknadsföras och till vem?
– Vilka konsekvenser får vi om vi inte lyckas?
– Sätt ett lanseringsdatum som inte får flyttas.

#4 Document your vision – med fördel med bilder
Sätt en limit på feautres för att förhindra att scoopet växer, minska förvirring och minska time to market. Det går alltid att tillföra funktioner efter lansering, börja i liten skala för att nå i mål. Ofta vet vi inte hur användaren vill att applikationen ska fungera. Underlätta arbetet för utvecklarna med att sätta vad vi ska ha och vad vi inte behöver.

 #5 Creation is a messy business
Prioritera funktionerna som förmodligen inte kommer med, det kommer förhandlingar och då behöver det finnas en tydlig prioritering.  Undvik otydliga signaler och håll dig till en backlog.  Tänk dig för, det går inte att öka farten enkelt med fler utvecklare eller mer pengar, prioritera!

 #6 Fight off everyone else – ”Rambo” 
Du har en stor uppgift, skydda teamet och utvecklarna till varje pris för att de ska lyckas med lanseringen.

#7 When you first see the app… dont’t panic
Är det den här appen du bad dem bygga eller har utvecklarna valt ett fel spår som gör att ett nytt affärsbeslut behövs? Om inte, vilka konsekvenser ser vi, kan vi fortsätta?

 #8 Keep it short – Håll utvecklingsiterationerna så korta som möjligt
Minimera antal personer som pratar med utvecklarna, du är antagligen ingen av dem. Fokusera istället på att buggtesta appen, du kanske hittar något som utvecklarna missade, är dessa showstoppers? Gör en lista av alla bugger, vilka är showstoppers och vad är ”övrigt”.

 #9 Early or late? Om du inte är generad vid lanseringen av första lanseringen ”då har du lanserat för sent”.
Generad vid lansering? Det är något bra, appen ska inte vara färdigutvecklad och det kommer finnas fel men det drabbar inte time to market.

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?