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?

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.