Mike Brittan berättar om hur Etsy tvingades att arbetar med flera olika verktyg och förbättrade processer i utvecklingsarbetet när teamet växte med 500% över 18 månader.

E-handlelssajten krävde enormt mycket snabbare och kvalitativ produktutveckling och Etsy hade behovet av att hantera snabbare deployer och minska riskerna.

Idag sker deploy till produktion (inkl. build to stage) via en enkel knapptryckning. Det krävdes för att man ska kunna göra ca 40 deployer /dagen som idag är snittet samt att alla på avdelningen (designer, backend och frontendutvecklare) kan utföra en deploy.

Less talk, more do
För att komma fram till den nya processen så pratade man i tydligare termer om att arbetet skulle fokuseras mer på att bygga mer kod och utvärdera arbetet i efterhand och faktiskt göra deployen. ”Always be shipping code” (även om det är din första dag), refakturera något releasebart varje vecka.

Förutsägbarhet
Problem uppstår alltid, det gäller bara att hantera riskerna. Då kan man vända risken till förutsägbarhet och tillit i systemen och applikationen ex. med monitorering på flera nivåer.
Om man uppmärksamma problem snabbt så att man kan agera direkt. Trygghet ger självförtroende.

Monitorera mera
Samla data för att visualisera och analysera arbetet i processen. Vad gör vi bra och vad gör vi mindre bra? Varje dag förändras allt i systemen, därför behövs en detaljerad monitorering och trendanalysvid dagliga deploys.

– Application metics: Hur mår applikationen, bildladdning etc.
– Business metrics: Hur ser trafiken ut, unika besökare, laddningstider, betalsystem, login etc
– System metrics: hur mår servrarna, databaserna, connections etc

Hantera risker
– Metrics (nyckeltal)
– Code reviews, storlek på ändring innan deploy
– Automatiserade tester, classer, unittests, selenium, funktionstester och integrationstester.
– Config Flags (enable and disable feautures quickly) sätt på/stäng av utan driftsättning på vilktiga core-funktioner
– Plus ”admin -Only”, procent ramp-up, A/B tesing, whitelist, blacklist etc.

Failure is inevitable – Visualisera
Bättre med flera små iterationer. Bryt ner alla problem och hantera dessa. Bättre med många små risker ofta än en stor. Operations och utvecklarna arbetar nära med produktutveckling, nya funktioner för att få förutsägbarhet i metrics.
Se det som en lärande process i misslyckande. Varför gick sajten ner, problem med databasen? Vad lärde vi oss av det och hur hanterar vi det i framtiden
Access, vad händer och hur ser det ut – visa med grafer på skärmar.

Övervakningsverktyg
Bygg upp monitoriering tillsammans med utvecklingsteam och operations.
Det är ett krav i Etsys team att metrics är en del av varje feautre samt configflags i alla releaser. Alla ska ha access till loggarna.

Verktyg som Etsy använder för monitorering:
Cacti (Nätverk)
Ganglia(Maskiner)
Graphite(Applikationer)
Splunk(Loganalys, Nightly report)
Nagios(Alerting)

Mer info
github.com/etsy
codeascraft.etsy.com

Visuell monitorering är alltid positivt och 40 deployer om dagen låter spontant mycket men med mer automatisering och förbättring av testprocesser med ex. selenium och verktyg för kodanalys så är vi en god bit på väg.

Talare: Avi Muchnick (Aviary, inc)

Communication is key
Prata med produktägare om förändring och kravställning. Ta reaktioner vidare för ändring och skapa tidslinjer. Informera alla i företaget om att arbetet pågår

Vad vill användaren ha? Fråga!
Användaren som stannar på nya sajten kommer att anpassa sig. Men det är viktigt att man får tid att experimentera med nya designen. Användaren behöver också full åtkomst till den gamla saiten utan restriktioner.

Checklista inför redesign

• 60-dagars transtionspersiod
• Side-by-side reviews
• Non-committal try before bying
• Social pressure – missar jag något?
• Incitament: badges
• Rollbackplan and capabilities

En smidig övergång är viktigare än en deadline! Lyssna på feedback från användaren
”Deadline can be deadly” – Håll tidsplaner flexibla för justeringar från användare.

Redesign i verklighenten
Avi visade några exempel på redesign av stora sajter och reflekterade över varför vissa lyckades bättre än andra.

Digg.com, Myspace.com, Worth 1000 är exempel på sajter som förlorade många besökare trots ganska små förändringar vid sitt senaste redesignarbete. Gemensamma faktorer som ex. begränsad feedback loop, borttagning av populära features och avsaknad rollbackplan gjorde att man tappade användarna under redesignarbetet.

Drudgereport.com är ett exempel där man tvärtom ökar trafiken utan att ändra designen på flera år.

Facebook har lyckats med kontinuerlig redesign när det gäller tänket ”Side by-side”. Som användare behöver man inte kommita sig direkt och anamma den nya desingen. Dessutom är det Avi kallar ”social pressure” och ”no choise in the matter” hög.

När är en redesign lämlig?
När det är designen som är trasig. Om den är trasig, se till att fixa den!

Talare: Phin Barnes (First Round Capital)
http://www.web2expo.com/webexny2011/public/schedule/detail/20778

”The question entrepreneurs and investors have to answer is no longer “can this be built and by who?” but, “should this be built and for who?”

”Problem solving is driven by insights and understanding, product testing through rapid prototyping and iteration, iteration, iteration.”

The web is waking up to design
Design driver finansiellla resultat. Förstå din användare och prioritera det i arbetet. Ändra mindset ”Customer first”.  Förut tävlade vi olika tekniker men nu är designprocessen eller så kallad Lean startup i agile utveckling den avgörande faktorn för att behålla användarna och klara konkurrensen i framtiden.

När building blocks och verktyg finns tillgängligt för alla så är det  designen som gör skillnaden. Quick builds! Vi använder fler färdiga tjänster (Saas, Paas, Iaas etc) vilket gör att vi behöver skilja ut oss i designen och inte enbart i tekniken.

Sätt användaren i fokus
Den som lyckas erbjuda den bästa lösningen och designen till kunden blir en vinnare.
Se till att vara nära dina användare och förstå behovet. Tillåt alla i organisationen att kunna förverkliga och genomföra ideer, de förstår sina användare. Bygg en kreativ och förlåtande kultur för att alla ska kunna genomföra sina idéer. Hylla hantverket som på ex. Etsy!

Collaboration: samarbeta kring ex. en träningsvideotjänst. Personlig tränare sitter tillsammans med utvecklarna och bygger den bästa upplevelsen.

 ”Design is the competivtive advantage”

Det förutsätter förstås att tekniken och tjänsterna( applikationen) fungerar i övrigt och här är det också den totala lösningen och upplevelsen som gör skillnad, inte enbart designen.

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 

Talare: Nate Bolt (Bolt|Peters)
http://www.web2expo.com/webexny2011/public/schedule/detail/21258

Hur bygger vi bra saker för våra användare? Nate pratar om enkelheten i att använda olika verktyg i researcharbetet för att få feedback och kommunicera med testgrupper och besökare i utvecklingsprocessen.

Research and Creativity
Det pratas ofta om research inom marknad men vi bör fokusera ännu mer på research inom User Experience. Det finn flera olika verktyg som hjälper oss i analysarbetet och dessa ger oss bättre beslutsunderlag i utvecklingsprocessen. Arbeta med prototyper, Wireframes & Sketches.

2 principer
#1 Kombinera online metoder – det finns många bra
#2 Tid är allt

Man kan skapa och mäta upplevelsen på olika sätt och med olika verktyg.
Insikt, statistik, betraktelse. Olika verktyg för olika syften. Definiera ditt behov! Heatmaps för att fånga beteenden kopplat till frågeformulär.

Vem testar vi på?
Hur hittar vi en grupp med personer som vi kan testa på i reseaarchsyfte?
– Någon utanför, vänner, riktiga kunder, panelundersökningar, gruppmaillistor
usertesting.com tillhandahåller testpersoner. Det finns många bra alternativ.

Hur kan vi använda det här?
Hitta ett verktyg som passar för behovet och börja testa det tidigt i planerings- och designfasen. Det kommer förhoppningsvis ge oss bättre beslutsunderlag och trygghet i att vi utvecklar applikationer som våra användare vill ha, förstår och kan använda.

Det här låter som ett intressant verktyg http://www.dscout.com/
Anpasssat för App driven research
”capture user experiences in context and in the moment, describe, design, invite”

Tips på fler verktyg: http://remoteresearch.ch/tools
Automatiserade remote research tools (Usabilla, Loop11, Plainframe)
Usability tests: Låt användaren klicka runt, mät, följ upp med heatmap. Verktygen tillåter feedback kopplat till händelser.

Kompenserade gårdagens kalla macka med en kvalitetslunch

Wikipedia om ”Sashimi” i Scrum (små bitar av komplett funktionalitet)
”Sashimi is a report that something is ”done”. The definition of ”done” may vary from one Scrum Team to another, but must be consistent within one team. ”
http://en.wikipedia.org/wiki/Scrum_(development)

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: Johnny Lee (Google)
http://www.web2expo.com/webexny2011/public/schedule/detail/21299

Time…
Johnny inleder med att tala om tiden. Tiden det tar från research fram till kommersiell produkt. Koncepten är ofta gamla men urvalet och utförandet är baserat på dagens teknologierna för gränssnitt och interaktionsdesing. Vi har idag större möjligheter att utnyttja tekniker ex. ansiktsigenkänning, patterns och sensorer.

Commercial success
Varför ser vi då inte fler produkter som bygger på den senaste tekniken? Väldigt få produkter blir lönsamma och kommer från en ursprungligt bra idè.

Det finns många anledningar till att ”Great Interface technology ideas” kanske inte lyckas
1 Fungerar den så bra som du drömde om?
2 Fungerar den robust nog for tillräckligt många naive användare?
3. Går den att tillverka till en lag kostnad?
4. Tyvärr, de flesta människor nöjer sig med att surra på ebben.
5. Ingen tredjepartsutvecklare kommer att utveckla för din plattform.
6. Ser styrelsen nya intäktsmöjligheter?
7. Är den före sin tid?

Efter den här inledningen övergår Johnny till en mycket underhållande och visuell presentation om hur vetenskapen drivit tekniken framåt sedan tidigt 80-tal fram till idag.
Vi får se inspelningar från olika labs och reflektioner av hur teknologin har skapats ur innovation med en vision om att knäcka koden om hur man skapar ”Human as a sensor”.
Vetenskapen och research inom senorteknologin gör att vi kan utnyttja allt från tankemönster(elektroniska signaler) och rörelser tillsammans med senaste tekniken för att skapa nya upplevelser. Ex. Elektroniska kontaktlinser, igenkänning via patterns.

Tekniken finns där men vi behöver bli bättre på att skapa behovet.

Talare: Louis Rosenfeld (Rosenfeld Media, LLC)
http://www.web2expo.com/webexny2011/public/schedule/detail/21140

Site search analytics (SSA) – Förvandla dina sökord till guld!
En fartfylld session där Louis förtydligade vikten av att analysera vad användaren gör på din sajt och hur vi kan använda sökorden och datainsamling till att ta fram underlag för att underlätta och skapa värde för affärsbeslut.

1. Make it harder to get lost
   Användare tappar bort sig på sajten. Man kommer direkt in på undersidor, djuplänkar via ex. Goole och sällan direkt på startsidan. Användaren förstår inte strukturen och därför behöver huvudnavigationen vara tydlig.
2. Reduce jargong
   Ta fram statistik på vanliiga sökord och frekvesen på sökta ord på din sajt som underlag för att skapa en bra struktur på sajten. Filtrera ut de mest förekommande innehållstyper som efterfrågas.
3. Priority by value
   Vad ska vi ha för typ av beslutunderlag? Relevansen på navigationen och sajtens struktur ska vara datadrivet utifrån prioritet av avändaren.
   Content types: Ex. inför en migrering av innehåll i CMS, vad ska vi flytta först?
   #1 application
   #2 reference
   #3 Instructions

   Underlaget för analysen gör att du kan skapa en kontextuell. navigering – en karta över dina building blocks.

4. Tune and adapt for presentation
   Fånga upp olika tecken som besökaren använder ex. # & ID, vad vill vi att besökaren ska få för typ av resultat? Bygg ditt varumärke genom att skapa riktade kampanjer baserat på SSA.

   ask.com förfinar informationen med olika presentationslager för besökaren.
   – Förfinat sök
   – Utöka söket
   – Bildsök
   – Wiki – extra information
   – Nyheter

5. Learn how your audiences differ
   Personas – Vem bryr sig om vilket innehåll? Försök att analysera vilken persontyp som söker på olika typer av information. Ex. studenter, Anställda etc. Hitta mönster för vad alla personas som har gemensamma intressen.
6. Know when to publish what
   Analysera sökorden utifrån tider och datum. ”skolor”, ”fotboll”, ”julmat” är säsongbaserat och återkommande och där med förutsägbart för att kunna presentera rätt information i rätt tid till användaren.
7. Own and enjoy your failures
   Problem med navigationen? Analysera oväntade sökningar och se till att besökaren hittar informationen genom att tagga upp eller skapa länkar av vanligt förekommande ord. Jämför vad användaren hittar i jämförelse med vad de vill ha. Ur affärssynpunkt så går det att öka ren konvertering på ex. betaltjänster där vanliga sökord ger ”0” resultat eller klicktrough rate idag.
8. Avoid disasters
   Vid byte av sökmotor, jämför resultatet utifrån relevans och precision för att se om förändringen bibehåller och ökar affärsvärdet. Håll koll på lanseringen av en ny sökmotor med hjälp av tuning och analys (SSA)
9. Predict the future
   Håll koll på dina peakar! Financial Times skapar sin ”editorial agenda” utifrån trendiga och högt rankadesökord som toppar

   Jag tänker på redesignprojektet där vi skulle kunna ta fram bättre beslutsunderlag på vad användarna söker på och efterfrågar för typ av information.

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.