Smashing Conference (#smashingconf ) – russinen ur kakan – dag 1

Simon Dahla

Conversionsita! at Smashing Conference Oxford 2014

Här följer anteckningar, tankar och reflektioner från de bästa talarna på Smashing Confernece – Oxford 2014 – dag 1

Joe Leech (@mrjoe) – Psychology and The Perfect Design

Joe satte förväntningarna högt när han tog sig an uppdraget att hitta den heliga graalen: den ”perfekta” desigen.

Joe menar att vi bygger mentala modeller från tidigare erfarenheter som vi applicerar på nya situationer och om dessa modeller inte passar på nya situationer gör användaren fel och det vill man ju inte. Detta gäller främst informationsarkitekturen på en sajt.

People don’t like to think. If people don’t have to think then the process is easier. Match the mental model (get inside people’s heads) and give them the information they want.

Joe pekade på att vi måste göra två saker för att lyckas med vår design:

  1. Matcha den mentala modellen. Finns det ingen sådan så måste vi skapa den, då gärna med användarstudier, intervjuer med kundtjänst och andra kvalitativa datakällor.
  2. Framkalla känslor. Vackra användargränssnitt är lättare att använda än fula. Samt tala till undermedvetna instinktiva känslor så som, rädsla, sex, hunger etc.

Joe tipsade även om att läsa dessa två vetenskapliga publikationer kring design:

Att lyckas handlar mycket om att minska den kognitiva belastningen för användaren. Han har även skrivit en tunn (och billig) bok som berör ämnet.

Dave Rupert (@davatron5000) – Real-Life Responsive Web Design: Lessons Learned

Dave delar med sig av sina erfarenheter och sina utmaningar med RWD (Responsive Web Design). Pre-RWD-eran så gjordes nästan all webbdesign utifrån en Photoshopfil. Det skulle vara ”Pixel Perfect”.

Sen…
Kom smarttelefonerna och hemsidorna såg dumma ut. Reaktionen på det var att vi skapade separata mobilsidor (m-dot-sites). Sen kom surfplattorna, ett nytt problem uppstod och det introducerades ännu fler enheter. Dave berättar att hans kylskåp till och med kan visa Netflix.

Allt börjar i ”A Dao of Web Design” en artikel som publicerades på A List Apart redan 2000. Dave påpekar att om vi hade struntat i att göra pixelperfekta hemsidor från början hade vi sluppit det här problemet – för det är egentligen inget nytt fenomen.

Daves utgångspunkt för att klara utmaningarna kring RWD är något han kallar ”device agnostic”.

Med den utgångspunkten tar han höjd för:

  • Små skärmar
  • Långsamma uppkopplingar
  • Touchenhter
  • Fientliga webbläsare (typ IE8)

Små skärmar

”Mobile first” är den nya standarden, han ger färsk statistik som visar att det sker en minskning på ca 10% per år i användandet av desktopenheter. Han visar också siffror från en undersökning som hävdar att 90% av webbanvändarna använder flera skärmar sekventiellt för att genomföra en uppgift.

Detta menar han är det starkaste argumentet för att börja bygga för mobilt och skala upp istället för att bygga en desktopsajt som beter sig som en ”lögn” i mobilen (i förhållande till desktopversionen).

Långsamma uppkopplingar

Laws of Simplicity: No one likes to suffer the frustration of waiting. – John Maeda

Slow = unhappy

Även om det inte är hemsidans (eller utvecklarna som byggt sidans) fel så behöver man alltjämt ta höjd för det. Han listar ett par orsaker som kan göra att en sida laddar långsamt:

  • WIFI på flygplan/flyplats/tåg
  • Tåg i en tunnel
  • Wifi på en konferens (Wifi:et på #smashingconf har inte fungerat alls 🙁 )
  • Ett avlägset hörn i ditt hem
  • Att du råkar stå bredvid en stor metallbit (?!)

Saker som är hemsidans fel:

  • För många bilder
  • För många olika fonder
  • För många och förstora Javascript
  • Ominifierade CSS/JS-filer
  • Suboptimerat antal anrop till servern

För att komma till rätta med detta vill han att man sätter en ”performance budget”. Optimera sajten utifrån ovanstående lista och allt eftersom man gör justeringar på sajten ser man till att hålla sig inom ramen för den budgeten. Detta kan vara relativa värden, som antal anrop, antal kB skickade från servern, antal bilder etc.

Touchenheter

Nu mera har även desktopenheter stöd för touch, som bekant är Windows 8 ”touch first”. När man bygger en sajt så kan man inte anta att bara för att besökaren kommer från en enhet med en liten skärm så är det en touchenhet. För tillfället är det bara Apple som inte stödjer touch i sitt OS.

Och de som försöker att spåra touch kommer snart märka att det är en omöjlig uppgift. Det bästa man kan göra är att från början designa för touch och testa på riktiga enheter.

Fientliga webbläsare

Det vore lätt att bara räkna bort gamla och utdaterade webbläsare. Dave menar dock att man måste ta hänsyn till användare som inte har ett val. Det handlar inte endast om IE8 och Opera Mini – utan även som den inbäddade webbläsaren i Twitter-appen på iOS som saknar stöd för modern webbstandard.

If you use mobile enough you start to realise how important supporting hostile browsers like the iOS UIWebView is. Not everyone has the choice of which browser to use.

For example IE8. What a curse! People often asks me ”what if the boss” uses IE8? I tend to answer ”I’ll buy him a new computer”.

Den responsive processen

”If you see the Buddha on the street, kill him.”

Om du ser eller träffar någon som säger att dom har listat ut RWD-processen, så har dom det INTE. Den finns inte, inte än och varje nytt projekt är unikt.

De flesta organisationer använder vattenfallsmetoden där man har olika teams för de olika stegen i processen.

Planera –> Designa –> Koda

Detta, hävdar Dave, är dåligt, fientligt och bäddar för konflikter, de olika teamen pratar inte med varandra och den enda kommunikationen sker med korta emails.

En bättre lösning är att bryta upp teamen och skapa hybridteam, med alla representerade i varje del i processen fast med en majoritet av den grupp som är berörd för tillfället. Dave säger att man kan få samma vattenfallsflöde inom teamet istället för mellan teamen.

Designer/Utvecklare-relationer

Designers:

– Lär hur ”web inspector” fungerar för att kunna ge mer värdefull feedback
– Håll barriären låg för hotfixes och tillhandahåll kod som är hyfsat nära det man vill åtgärda
– Lär vokabulären kring hur webben är uppbyggd

Utvecklare:

– Ge designers tillgång till lokala- och stagingmiljöer. Det tar bort mycket av mystiken kring vad som egentligen pågår och ”vad dom kommer få”. Om dom freakar ur, så kommer dom göra det mycket tidigare och då är det lättare att hantera.

Det bästa man kan göra är att sitta bredvid varandra och jobba, och jobba tillsammans.

Leverabler

Daves team leverar alltid små komponenter (tiny bootstraps). Han påpekar vikten av att leverera ett system, ett ramverk, moduler för att bygga en sajt och inte en färdigbyggd sajt. Detta stärker kunden i att kunna ta konceptet vidare och kunna vidareutveckla sajten.

Let the Wookie win!

Många gånger hamnar man i konflikt och i diskussioner med sina kunder. Han menar att alla fighter inte är värda att ta (även om man vet att man har rätt), att man ska välja sina strider (och låta Wookien vinna). Att man kan använda data som ett redskap i diskussioner och använda A/B-tester för att validera ett tillvägagångssätt.

Fabio Carneiro (@flcarneiro) – Hard-Won Lessons in Responsive Email Design

Fabio, som har jobbat på MailChimp sen ett par år tillbaka, hävdar att email är ett av de mest viktiga verktygen när det gäller att kommunicera med sin publik. På MailChimp ser de en stor ökning av människor som läser mail i sina mobiltelefoner. Det är numera ett måste att bygga responsiva epostmallar.

Olyckligtvis är epostdesign betraktat som en ”dark art”, det är en brant lärokurva med många fallgropar då det inte finns några egentliga standarder att följa. Ger två regler när det kommer till att designa epostmallar:

  1. Design like it’s 1996.
  2. There’s no rule 2.

Email är fruktansvärt att ha att göra med. Det är svart magi jämfört med traditionell webbdesign.

Så vad är grejen med att få email responsiva?

Det finns ett dussin olika epostklienter, vissa av dem stödjer inte marginaler (margin:), vissa av dem renderar <p>-taggar på ett märkligt sätt. Så vad ska man göra istället?

Designa inom givna ramar

CSS-stödet i epostklienterna är CSS2 knappt CSS3. Konstigt nog är det först nu som W3C fått upp ögonen för att sätta en standard för epost. Gör vad som helst för att få det att fungera, det finns ingen prestige i att det ska vara ”snygg kod” för epost.

Gmail is one of the worst mail clients available – forces styles to be inline. Outlook uses Word for its HTML rendering engine, it’s worse than IE6!

Designa för människor

Ett mejl måste vara läsbart med ett öga, med en tumme på en armlängds avstånd. Du ska alltså omedelbart kunna se vad det handlar om utan att behöva stanna upp. Du ska kunna använda en hand för att göra det du uppmanas att göra. Du bör kunna läsa texten utan att sätta näsan i skärmen.

Designa med ett syfte

With websites people come to you, with email you come to people.

Ett mejl måste var koncist och ha en eller flera starka CTA:er. Folk är trötta på att få onödigt skräp i sin inkorg. Det vanligaste misstaget är att marknadsförare betraktar epost som en hemsida – vilket det inte är. Man behöver inte navigation eller andra typer av statiska element – distrahera inte dem från innehållet. Ta tillvara på den kunskap du har om de som är mottagare – använd namn.

(utskick från steam)

Så hur gör man?

Epost är korkat komplicerat. MailChimp har en sajt med referenser kring allt man behöver veta för att göra responsiva email. Fabio tipsar också om Zurb:s responsiva epostramverk Ink.

Sen handlar det om att testa, testa, testa! Testa på riktiga enheter, i olika epostklienter. Vill man inte göra detta själv finns det tjänster på nätet som gör detta automatiskt.

Om du inte tror att det här är viktigt så presnterar Fabio på siffror från Litmus Community som visar på att epost i mobil har ökat med ~140% de sensate 12 månaderna.

Sammanfattning

Genomgående bra talare och vilken konferens vill man inte tala gott om när de öppnar den med en lasershow. Läs även nästa blogpost från Smashing Conference.

Läs även