Kapitel 3: Webbdesign


Du läser nu boken Webb­strategi för alla.
Gå till bokens innehålls­förteckning ›

Sedan några år tillbaka har det blivit tydligt att vi inte har kontroll över hur våra besökare väljer att ansluta till vår webbplats. De kan komma in via allt från mobiltelefonen när de sitter på en skakig buss till att surfa på sin gigantiska tv tillbakalutad i vardagsrummet.

Det är inte bara storleken på skärmen som spelar roll, även hur din besökare styr sin enhet, vilken uppkopplingshastighet denne har och hur högupplöst media skärmen kan visa.

Förutom att göra besökaren nöjd i dennes situation behövs mogen design för verksamhetens mål för att inte alla designförslag ska jämföras enbart med subjektiva mått. Se inte din webb som en statisk trycksak, varken vad det gäller innehåll eller den teknik man använder. Teknik och innehåll behöver med allt kortare intervall hållas aktuellt för att din webbplats ska vara relevant.

Bild 36: Så här såg en dator ut när webben föddes. Skärmar stora som surfplattor men väldigt mycket sämre upplösning.

Bild 36: Så här såg en dator ut när webben föddes. Skärmar stora som surfplattor men väldigt mycket sämre upplösning.

Mellan 1991 och 1993 skapades det som vi idag kallar för webben. 1993 dök dessutom Mosaic upp – den första webbläsaren. Det var en väldigt basal upplevelse med text som kunde länka mellan olika sidor. Först 1996 kom en konkurrerande webbläsare i form av Microsofts Internet Explorer (IE), en webbläsare som hade stöd för den då obskyra tekniken CSS (Cascading Style Sheet, på svenska kallat stilmallar) för att skilja innehållet från dess utseende.

Mosaic blev strax omdöpt till Netscape och konkurrensen med IE kom igång på allvar om vem som hade den mest funktionsrika webbläsaren. Det där med att följa eller utveckla den initiala standarden för webben glömdes snabbt bort med tekniker som Javascript, dynamisk HTML, CSS och Adobe Flash. Detta gav utgivare av webbplatser enormt mycket extra arbete då de inte sällan byggde två separata webbplatser beroende på om besökaren använde Netscape eller IE. Ibland blev det tre då huvudsajten var i Flash och en vardera för Netscape och IE.

Idag är det däremot lite mer ordning på torpet kring standarder. Delvis för att branschen mognat men kanske mest för att det finns så otroligt många varianter av webbläsare, versioner av webbläsare som stödjer olika tekniker och dessa körs på olika typer av enheter. Många webbdesigners lösning på detta var att återgå till att använda det som är standardiserat vilket gjorde att det som byggdes fungerade i merparten av besökarnas datorer.
Att inte utveckla för webbstandard, eller inte kräva det vid beställning av en webbplats, är ett kardinalfel i dagsläget. Särskilt då det är det enda sättet att försöka få webbplats att fungera som det är tänkt i kommande teknisk utrustning.

Det finns mängder med designstrategier att anamma när man bygger webbplatser. Jag tänkte ta upp de mest fundamentala som är värda att inspireras av eller rent utav att följa fullt ut. Vissa är övergripande för hur man lyckas med ett projekt, andra går ner i detalj på hur formgivning av knappar bör se ut för att förstås av besökarna.

Gov.uk’s designprinciper

Världen över har offentlig sektor börjat standardisera hur man gör saker och ting för att inte slösa energi på metoder man redan prövat och misslyckats med. Brittiska staten är ganska framstående inom området kring öppna data och servicedesign.

Britterna har tagit fram något som kan liknas vid budord för design av webb och digitala tjänster. Även fast detta är ett förslag för offentlig sektor har de absolut bäring på vilket projekt som helst som ska resultera i en digital produkt. Principerna finns, och utvecklas, på nedan länk men jag tänkte återge dem med egen svensk översättning då de passar utmärkt in i denna del och som påminnelse om ting som ibland inte tycks vara så självklart (tba.nu/govuk).

1. Börja med behoven

Användarens behov och inte avsändarens ska vara i centrum. Vilka behov ska tjänsten i stort och i delar stödja? Man behöver ha djup insikt i behoven innan någon annan form av arbete kring design av en tjänst är meningsfull, samtidigt är det värt att komma ihåg att vad användarna frågar efter inte alltid är vad de behöver.

Använd de dokumenterade behoven som kategorier för att organisera vilka insatser som görs, besökarna kommer trots allt till tjänsten för att få något specifikt gjort. Det finns ingen anledning att gömma undan lösningen på ett behov i någon brödtext när det går att få denna information att sticka ut från mängden.

2. Gör mindre

Gör mindre, och ibland inget alls. Om någon annan redan skapat en tjänst är det bättre att länka dit än att lägga ansträngningar på att bli en senkommen konkurrent. Om man kan erbjuda API:er räcker det kanske för att någon annan ska designa en tjänst och då kan man själv fokusera på kärnverksamheten samtidigt som man sparar pengar.

Principen gäller även för hur mycket man ska presentera på en och samma gång. Ett uppslag på en webbplats blir bättre om det finns ett fåtal tydliga val för besökaren att ta ställning till, dessutom behöver det innehållet hänga ihop tematiskt.

3. Designa baserat på data

Oftast designas inte en tjänst helt utan tidigare erfarenhet, troligen finns redan en motsvarighet i den fysiska världen som man kan dra lärdom av och ha som inspiration för hur en första version av en digital tjänst kan se ut.

Det första postorderföretaget som byggde en webbtjänst tog säkerligen med sig en del kunskap om vad som funkat tidigare. Den kunskapen tillsammans med A/B-testning gör att man metodiskt kan lära sig av vad som fungerar. Man spelar ut alternativ A mot alternativ B och det alternativ som presterar bäst blir den som används fram till det tillfälle man vill testa ytterligare alternativ.

4. Ansträng dig för att förenkla

När man designar en tjänst är det en god idé att ta en titt på vad som ska göras med nya ögon och inte bara välja den mest uppenbara lösningen för att snabbt bli klar. Hur svårt måste det vara? Ett snabbjobb riskerar att orsaka komplexitet för användarna – om du inte orkar göra det så enkelt som möjligt kommer det gå ut över användarna som får betala med sin tid och energi?

Det finns mängder med exempel, inte bara inom statlig sektor, på när man behöver ha jobbat många år inom en organisation för att kunna hitta fram till information. Skulle du med pensionen i pant tvärsäkert uttala dig om huruvida din egen arbetsgivare har lagt blanketter för tjänstledighet under ämnet ekonomi eller personal på intranätet? Antagligen inte. Att man har ett omedvetet avsändarperspektiv är lätt hänt men lika lätt avhjälpt genom att ta hjälp av någon extern part som inte har lika lätt att falla in i invanda mönster.

5. Iterera, och iterera igen

Bästa sättet att bygga en tjänst är att starta smått och fortsätta med konstanta uppdateringar av tjänsten baserat på vad riktiga användare gett som respons.

En tjänst eller webbplats blir aldrig klar, har man den tankegången kan det behöva en hel del förklarande eller troligen förkastas som tanke. När tjänsten är sjösatt är det direkt efter lanseringsfirandet dags att inom kort släppa den första uppdateringen. Dessa uppdateringar bör även gälla webbdesign, grafisk formgivning, identiteten i stort och inte bara rättning av felaktigheter. Stora omdesign-projekt tenderar till att förvåna besökarna, byte av all identitet likaså och att göra ett omfattande projekt plötsligt efter något år borde man inte behöva då det kunde ha gjorts pö om pö sedan tidigare.

6. Bygg inkluderande

Alla ska med” kampanjade Socialdemokraterna med och förlorade valet 2006, men att inte exkludera någon från din tjänst är en god tanke. Det handlar om att låta läsbarheten gå före låg kontrast på text, se till att klickytor är stora nog, att besökarna ska kunna använda vanlig utrustning och att man följer designkonventioner. Rent tekniskt finns en del att göra men tack vare tillgänglighetsriktlinjerna WCAG (Web Content Accessibility Guidelines) är det lätt att förstå och välja en lämplig nivå att jobba efter.

Den som har funktionsnedsättningar, och den ofokuserade mobila bussresenärsbesökaren, ska kunna använda tjänsten som designats.

7. Förstå sammanhang

Det handlar inte om att designa för en skärm eller bygga en e-tjänst, man designar för människor som ska kunna använda tjänsten i deras normala sammanhang. Det sammanhanget kan vara mobilt utan muspekare, vid en informationskiosk på ett bibliotek och det kan vara så att de inte har ett Facebook-konto att använda för att komma åt tjänster man lagt där.

Tjänsten ska gå att använda i alla tänkbara och mindre tänkbara sammanhang.

8. Bygg digitala tjänster, inte webbplatser

Allt kretsar inte kring webbplatsen. Lösningen på ett behov kan mycket väl börja på webbplatsen men avslutas på postkontoret nära användaren – det behöver man ta höjd för i designen även fast vissa delar är utom ens kontroll.

Det kanske inte är en webbplats som är bästa tjänsten? Kanske finns annan digital möjlighet som skulle prestera bättre?

9. Var konsekvent men inte likformig

Så långt det är möjligt ska man använda samma språk och designmönster då det underlättar igenkänningen för en besökare. Ibland är det dock inte möjligt eller praktiskt genomförbart och då ska man se till att man är konsekvent i sin design.

Av naturlig anledning kan inte en tjänst för mobilen se identisk ut som för den med stor datorskärm, men man ska utan ansträngning kunna se att det är samma avsändare och det ska fungera på ett likartat sätt utan att man ska behöva lära nytt.

10. Verka öppet, det gör saker bättre

Man bör jobba inför öppen ridå om det går, och dela med sig av både erfarenheter och resultatet av arbetet. Dela med sig av kod, data, design, idéer, misslyckanden och ambitioner. På detta sätt kan man få fler att granska det som skapas och man kan få stöd från andra som även de är intresserade av att resultatet blir så bra som möjligt.

Även om man inte själv använder öppen källkod har vi nog alla lärt av andras erfarenheter och vi borde dela med oss. Webbens fundament är att dela med sig till andra och även om det inte är skattepengar som betalar projektet du jobbar med kan även du ha nytta av att dela med dig.

Ett i mitt tycke vanligt problem på webben är att man krånglar till det. Designar för mycket eller andra saker som inte sätter användarens behov i första rummet. Nästa designprincip, KISS, tar upp hur man förhåller sig till enkel design.

Keep it simple, stupid – KISS

Designprincip från amerikanska flottan som under 1960-talet krasst konstaterade att de flesta system fungerar bäst om de förblir enkla istället för att tillåtas bli komplexa. Därför borde enkelhet vara det primära designmålet och man ska undvika all onödig komplexitet till varje pris.

Enligt denna princip kan en användare knappt göra fel, om denna inte lyckas är det de som designat tjänsten som klantat till det. Ofta innebär KISS att man låter bli något och det går att applicera på allt möjligt. Vilken nytta gör utsmyckningsbilder? Den där häftiga effekten, behövs den verkligen? Varför ha egen design på knappar och formulär när användarna riskerar att inte förstå vad det är?

Om du krånglar till det för användarna rent tekniskt är chansen också stor att sökmotorer hindras från att indexera din webbplats. Blir det krångligt för sökmotorerna kommer man få färre besökare därifrån och då börjar det närma sig meningslöst att ens ha en webbplats – om man nu inte aktivt är ute efter att ens material ska hamna i det som kallas för djupwebben, alltså den delen man inte når via sökmotorer. Det hör nog inte till vanligheten i alla fall.

Don’t break the web

Sedan gäller det att inte förvåna användare eller bryta mot de konventioner de lärt sig. Ett vanligt exempel är huruvida man kan räkna med att det går att använda bakåt-knappen i webbläsaren när man är på internetbanken, eller om man är halvvägs in i processen att checka ut en kundvagn. Osäkerhet uppstår säkert om man är tvungen att använda eventuella tillbaka-knappar på webbsidan eller om de i webbläsaren går för sig.

Självklart ska webbläsarens bakåt- och framåt-knappar gå att använda i alla webbapplikationer. Tyvärr tycks det inte vara en hederssak bland utvecklare att fixa det och av någon anledning verkar det inte alltid vara ett specificerat krav från beställarnas sida.

Bild 37: I Outlook Web Access kan man med iPhone inte backa i webbläsaren, däremot fungerar knappen Microsoft lagt in (med blå bakgrund).

Bild 37: I Outlook Web Access kan man med iPhone inte backa i webbläsaren, däremot fungerar knappen Microsoft lagt in (med blå bakgrund).

Ta mjukvarujätten Microsofts produkt Outlook som används som e-postsystem av miljontals användare världen över – tror du att man kan backa tillbaka från ett mejl och hamna i inkorgen igen? Nepp, inte om man använder webbläsarens bakåt-knapp och råkar surfa med en iPhone. Knappen, utan förklarande text, med en vänsterpekande pil i det blå fältet fungerar dock utmärkt men använd för guds skull inte bakåt-knappen i webbläsaren bara för att det funkar på praktiskt taget alla andra webbplatser! 🙂

Det är minst sagt ynkligt att man istället för att hamna i inkorgen skickas ända tillbaka till inloggningsfönstret. Microsoft är dessvärre inte ensamma om detta loja beteende. Om du är beredd på att stå ut med mycket krångel så kan du från och med nu testa att konsekvent ladda om sidor efter att du skickat ett formulär eller är mitt i en process på en webbtjänst. Du ska se att banken klagar högljutt, du kommer få dubbla beställningar i kundvagnar och i vissa fall kommer du få frågor om du verkligen vill posta ett formulär, du aldrig sett, en gång till.

Allt väsentligt på en webbplats ska fungera i alla webbläsare och oavsett vad som används för att interagera med sidan. Det är många år sedan det var rimligt att förvänta sig att ens besökare har en muspekare att hovra över något, trots detta är många webbplatsmenyer optimerade för att man ska ha en muspekare och ibland går de inte alls att använda med pekgränssnitt.

Bild 38: Missöde i Sveriges krisinformation där man inte lyckades ge information till vissa vanliga webbläsare.

Bild 38: Missöde i Sveriges krisinformation där man inte lyckades ge information till vissa vanliga webbläsare.

Man bör inte heller kräva att besökaren har några särskilda tillägg i webbläsaren för att ta del av det mest primära. Java i webbläsaren (obs, jag skrev inte Javascript vilket är något helt annat) har under många år varit en enorm säkerhetsrisk, Adobes Flash-plugin har fått många datorer att gå på knäna för att visa komplicerade annonser. För att inte tala om Microsoft som många år för sent kom ut med sitt idiotiska Silverlight-plugin för att konkurrera med den dåliga idén Flash när webbproducenter sedan åratal varit överens om att Flash var dött.

Hur långt man drar att en webbsida ska fungera utan vad som kan ses som onödigheter beror lite på. För ett intranät kan man i större utsträckning ställa krav på vilka webbläsare de anställda använder och vilka tillägg som är obligatoriska. Men samma KISS-princip gäller på intranät så anställda som är blinda eller har andra funktionsnedsättningar inte diskrimineras på grund av någons inkompetens eller ointresse. Dock kan man inte slå sig till ro, behoven kommer att förändras över tid. De som jobbat någonstans där man ”standardiserade” sina webbsystem runt Internet Explorer 6 vet vad jag menar, det blev väldigt smärtsamt att modernisera alla system samtidigt.

Inte nog med att en webbplats behöver vara enkel att förstå, den ska också övertyga och bygga förtroende. Nästa designprincip handlar om hur man med design vägleder besökaren genom den interaktion som behövs för att uppfylla webbplatsens syfte och alla delmål.

Persuasive web design (PWD) – design som övertygar

Design för att övertyga besökaren att göra det utgivaren av webbplatsen önskar ska utföras. Det kan exempelvis vara att visa upp vilka varor som är på väg att ta slut på lagret – vilket psykologiskt får besökaren att tro att hen gör en bättre affär än i verkligheten – men också att ha en sida innan du kan checka ut din kundvagn där ytterligare erbjudanden visas.

Om man lämnar de ofta enkla e-handelsexemplen kan PWD användas till att visa en förenklad version av ett avtal och istället länka vidare till den fullständiga versionen. Just här dyker det etiska dilemmat upp då förenklingen, alltså röjandet av hindret framför användaren, måste ligga i användarens intresse och inte riskera att orsaka några obehagliga överraskningar. Det kan låta enkelt, men tro det eller ej alla resonerar inte på samma sätt som du. Det du tycker är ett fantastiskt erbjudande kan med för mycket övertygande design göra att mottagaren känner sig grundlurad.

Det handlar om att sänka tröskeln för beslut och vägleda till en serie av flera mikrobeslut mot det mål du har. Här kommer begreppet dark pattern in, att genom design styra vad som händer på ett sätt som inte ligger i användarens intresse eller avsikt. Det kan vara att flytta runt knappar så användaren råkar ge en app femstjärnigt betyg i en app-butik, utan förvarning lägger till varor i kundvagnen eller de tjänster som i ditt namn skickar epost till dina kontakter.

Bild 39: Samtycke till att donera sina organ. Det som skiljer ljusa och mörka staplar åt är hur frågan var ställd. I ena fallet var det ett aktivt val att avstå donation, i det andra ett aktivt val att donera.

Bild 39: Samtycke till att donera sina organ. Det som skiljer ljusa och mörka staplar åt är hur frågan var ställd. I ena fallet var det ett aktivt val att avstå donation, i det andra ett aktivt val att donera.

Ett något mildare exempel på dark pattern är att vad som är förvalt i ett formulär faktiskt påverkar utfallet. Exempelvis hur troligt det är att man donerar sina organ. Det har gjorts undersökningar på flera länders befolkningar och den gigantiska skillnaden av hur svaret blir styrs uppenbarligen av hur frågan ställs.

Det som skiljer danskarna från svenskarna är att frågan till danskarna ställdes i stil med ”Kryssa i denna ruta om du vill donera dina organ” medan svenskarna behövde kryssa i rutan om de inte önskade donera sina organ. Detta förklaras med att man inte lägger särskilt mycket tanke eller tid på att ändra det som är förvalt och i detta fall hände två diametralt olika saker om man lät bli att kryssa i rutan.

För att inte röra till det för besökarna, eller bli för ivrig att konvertera besökare till kunder, kan följande checklista vara värd att gå igenom vid varje designbeslut men också utformning av texter.

1. Var tydlig i allt

Tydlig om vem avsändaren är, syftet med tjänsten, vad man kan göra och så vidare. Lägg det som är viktigast först i text och rent grafiskt. Att skriva rubriker istället för överskrifter är viktigt så rubrikerna innehåller information om innehållet istället för att som en överskrift klassificera innehållet. Dina rubriker behöver vara sanna, aktiva och beskrivande i stil med ”Vi jobbar enligt metodiken Scrum” istället för ”Tillämpad metodik hos oss”. Vad i texten behöver lyftas upp till rubriken för att beskriva textens innehåll?

2. Var väldigt försiktig med vad som är förvalt

Genom vad som är förvalt styr du folks beteende och står inte besökarens intresse i första rummet kan det skapa onödig irritation som kanske inte ens lönar sig på kort sikt.

När du utformar en knapp kan man sänka tröskeln genom att med språkliga knep använda mindre avskräckande text som ”Lägg i kundvagn” istället för ”Köp”. Om du mäter på dessa två alternativ är det troligt att fler vågar lägga något i kundvagnen än om klicket direkt betyder ett köp. Om det leder till fler avslut? Sätt igång och mät så vet du.

3. Visuell hierarki är viktigt

Bild 40: Det är lättare att uppmärksamma bilduppladdning än länken för att hoppa över det steget hos Twitter.

Bild 40: Det är lättare att uppmärksamma bilduppladdning än länken för att hoppa över det steget hos Twitter.

Gör det som förväntas utföras lätt att hitta och utföra. Det kan vara att ett formulärs skicka-knapp sticker ut mer grafiskt än knappen för att rensa formuläret. Med färg, storlek och placering kan man minska friktionen att posta in formuläret.

Syns det användarens ska göra utan att man behöver skrolla först? Även på en mindre skärm? Om en besökare inte ser den så kallade call to action, exempelvis en knapp, minskar chansen att det man önskar ska hända faktiskt sker.

4. Fokusera på det gemensamma målet du och besökaren har

Bild 41: Att logga in på Dropbox är lägre prioriterat än att hjälpa nya kunder skaffa konto. Visserligen är befintliga kunder återkommande och är nog mer motiverade att hitta “sin” knapp.

Bild 41: Att logga in på Dropbox är lägre prioriterat än att hjälpa nya kunder skaffa konto. Visserligen är befintliga kunder återkommande och är nog mer motiverade att hitta “sin” knapp.

Du har säkert sett webbplatser där all navigation försvinner när du är mitt i processen att checka ut en kundvagn? Det är för att du inte ska bli distraherad och avbryta köpet. Syftet med utcheckningsdelen är ju att användaren med så lite ansträngning som möjligt ska klara av att göra ett köp, det är ett uppenbart verksamhetsmål för en e-handelsplats.

5. Försök hushålla med din besökares uppmärksamhet

Designa webbplatsen så den är så självinstruerande som möjligt. Ett exempel på något att undvika är att lägga nyttiga länkar efter en väldigt lång text, chansen att de länkarna används minskar ju längre texten är och länkarna kanske kan göra större nytta innan texten.

Du har garanterat sett de allt för vanligt förekommande genrebilderna från stockfoto-sajterna där människor från världens alla hörn ler mot besökaren. Är bilden inte meningsbärande ska den inte konkurrera om utrymmet med något som är viktigt!

Väl utförd PWD kommer upplevas av besökaren som en tydlig och intuitiv tjänst, vilket borde vara ett mål för varenda webbplats. Samtidigt ska det avsändaren vill ska utföras också bli gjort. Något annat som borde vara ett självklart mål för varje webbplats är att den presenterar sig så bra som möjligt på så många typer av enheter som möjligt, det är vad responsiv webbdesign siktar på.

Responsiv webbdesign

En webbplats ska klara av att visa sig, och vara användbar, på den utrustning som besökaren väljer och göra det bästa av situationen utan att komma med speciallösningar. Tanken är att man satsar sin energi på att göra en riktigt bra kompromiss för alla typer av enheter besökarna kan tänkas använda istället för att bygga en mobilsajt, en skrivbordsdatorsajt, en spelkonsolsajt, en för projektorvisning och vad mer som komma skall i form av utrustning med webbläsare.

Bild 42: Hur en icke-responsiv webbplats kan se ut på iPhone 5S.

Bild 42: Hur en icke-responsiv webbplats kan se ut på iPhone 5S.

Situationen med speciallösningar har vi redan haft på nätet på den tiden man hade separata webbplatser; en i HTML och en i Flash, och ibland fick man välja Netscape- eller Internet Explorer efter att man valt HTML-versionen på en startsida för att få rätt stilmall. Vissa skrev ut vilken typ av utrustning som rekommenderades som om en besökare skulle växla webbläsare eller ställa om upplösningen på skärmen för varje webbplats man besökte. Det där var inte direkt smidigt, och idag har vi fler varianter av webbläsare och typer av skärmar än någonsin. Dagens webb måste anpassa sig efter besökarna och responsiv webbdesign (hädanefter kallat RWD) är det första samlingsbegreppet där man med en enda webbplats ska kunna ta hand om alla varianter av besökare utan en massa speciallösningar.

Innan RWD slog igenom var det under många år vanligt att man utgick från att besökaren kunde se 960 pixlars bredd på sin dator. Dessa 960 pixlar delades sedan upp i det antal kolumner man behövde för sin design. När iPhone släpptes 2007 började dock gemene man surfa med en webbläsare som i porträttläge hade 320 pixlars bredd och 480 pixlars höjd på en 3,5-tumsskärm. Webbplatser förutsatte då att besökare hade åtminstone 13-tumsskärmar med minst 1024 pixlar i bredd och 768 pixlar i höjd. En stor skärm i landskapsläge till skillnad från en mindre skärm med lägre upplösning oftast använd i porträttläge. Webbplatser blev då i en smartphone betraktade i ett utzoomat läge utan skärpa nog att ens en person med extremt god syn kunde läsa annan text än i bästa fall större rubriker. Det var ingen vidare upplevelse att surfa via mobilen helt enkelt.

Precis som om webben vore en trycksak hade många av webbens formgivare anpassat sin design likt en konstnär väljer en duk av lämplig storlek för att måla på – webbens duk var 960 pixlar bred och med oändlig längd för skrollande. Att det inte går att välja en duk, ett kanvas, för att planera sin webbplats är egentligen den viktigaste insikten att ta med sig från idén med responsiv webbdesign.

Den mobila drivkraften

Responsiv webb är egentligen inte en teknik för att mobilanpassa sin webbplats men konkurrerar indirekt med tanken att ha en separat mobilsajt då man försöker behålla även de mobila besökarna på sin huvudsakliga webbplats. Bygger man ändå en mobilsajt behöver även den vara responsiv av den enkla anledningen att det finns en allt för stor variation bland mobila enheter för att man ska kunna göra antaganden om skärmstorlek bland annat. Samma sak gäller sedan länge även mer vanliga skrivbordsdatorer. Vissa av oss använder enbart en bärbar dator med en skärm vanligen på 13-15 tum, andra kopplar ibland in sig på en stationär datorskärm på upp till 30 tum, eller på Tv:n.

Anledningen till att responsiv webb slog igenom stort runt 2013 beror nog mer på att många såg i sin webbstatistik att andelen av mobila besökarna ökade stadigt och för vissa började närma sig hälften av besökarna. En responsiv webb är enhets-agnostisk vilket gör det till en lösning även för hur webbsidan presenteras och blir användbar i en mobil eller liten surfplatta. Samtidigt började tillräckligt många webbanvändare ha stöd för den moderna webbstandard som behövs för responsivitet.

Det webbgeniet Luke Wroblewski kallar ”The Mobile Moment”, alltså när andelen mobila besökare är större än de som använder icke-mobila datorer, inträffar olika fort, om ens någonsin för vissa webbplatser. Exempel i min närhet är att vårdsajten 1177.se hade sitt mobile moment i början av 2013, beroende på om man räknar med surfplattor som mobil enhet, medan sjukhuswebben sahlgrenska.se vid samma tidpunkt hade runt 90 procent på vanliga datorer.

Beståndsdelarna av responsiv webbdesign

Responsiv webb är egentligen tre olika tekniker i en kombination. Teknikerna i sig var inte nya men kombinationen av dem blev lite av en uppenbarelse när Ethan Marcotte skrev sin artikel 2010 på webbplatsen A List Apart (tba.nu/rwd).

1. Flytande rutsystem – låt designen fylla skärmen

Rutsystem för kolumner har använts länge, den största skillnaden är att med responsiv webbdesign anges bredden i relativa mått istället för med ett exakt pixelantal – relativt till det utrymme som finns på respektive skärm alltså. För mobila, och andra små, enheter är det oftast svårt att få plats med annat än en enda kolumn vilket gör att innehållet behöver staplas på vartannat i en lång kolumn. På en liten skärm är det därför extra viktigt att använda hela bredden så inte värdefullt utrymme slösas bort på onödiga marginaler man för samma design kan kosta på sig för den besökare som har en större skärm.

2. Mediefrågor – anpassa designen efter innehållets utrymmesbehov

Bild 43: Antalet kolumner i bredd minskar ju smalare webbläsaren är.

Bild 43: Antalet kolumner i bredd minskar ju smalare webbläsaren är.

Med hjälp av mediefrågor kan så kallade brytpunkter identifieras vilket gör att designen kan anpassas för olika skärmbredders behov. Vid dessa magiska punkter visas sidan på ett annat sätt. Exempelvis ändras antalet kolumner beroende på de brytpunkter där designen behöver det för att få innehållet att fungera. Det är vanligt att saker av lägre prioritet inte visas upp alls om utrymmet är alltför begränsat – utsmyckningsbilder till exempel.

Ofta är åtminstone startsidan en enda stor kompromiss där alla med inflytande sett till att få med något de bryr sig om. Via en mobil syns inte merparten av det man det man är van vid från en skrivbordsdator. Därför är rangordning av innehållet en av de svårare uppgifterna ett webbprojekt av idag står inför.

Mediefrågor är som att sätta storleksspann på skärmar och hur designen ska bete sig inom det spannet. Exempel på mediefrågor kan vara:

  1. @media(max-width:350px) För de små mobilskärmarna.
  2. @media(min-width:351px) and (max-width:767px) Större mobilskärmar och många små surfplattor.
  3. @media(min-width:768px) and (max-width:979px) Surfplattor och många datorer där webbläsaren inte är i fullskärm.
  4. @media(min-width:980px) Surfplattor och datorer där webbläsarens bredd är minst 980 pixlar.

I detta exempel är det fyra olika designvarianter av webbplatsen man kan hamna på, fyra olika möjligheter till att specialanpassa designen så den stöttar innehållets optimala presentation.

Bild 44: Layout för stor skärm.

Bild 44: Layout för stor skärm.

Bild 45: Layout för en mellanstor skärm.

Bild 45: Layout för en mellanstor skärm.

Bild 46 – Layout för liten skärm i porträttläge.

Bild 46: Layout för liten skärm i porträttläge.

Man bör inte välja 3 versioner som i skrivbordsdator, iPad och iPhone för att illustrera sina brytpunkter. Bland annat för att det inte nödvändigtvis är just de enheterna dina besökare använder men kanske främst för att det inte riktigt går att visa exakt hur en responsiv webbplats ser ut. Poängen med responsiv design är att ge upp inför faktumet att variationen av skärmar är för stor med tanke på alla typer av enheter och att innehållet säkert byts ut med jämna mellanrum. Istället ska man utgå från när exempelinnehåll behöver brytas upp för att fungera väl för att uppnå förväntad effekt hos besökaren och med detta välja sina brytpunkter.

3. Flexibla bilder

Även bilders bredd sätts i relativa mått så deras storlek skalas upp eller ner beroende på övrig design, detta istället för att ha exakta pixelmått. Ofta sätts bilders bredd till hundra procent av utrymmet och höjden automatisk för att få proportionerna i bilden att stämma. Detta på den egna webbplatsen, alltså ett sammanhang man själv kontrollerar, men precis som annat material används bilder i andras sammanhang. Bilder återanvänds ofta tillsammans med länkar till den sidan bilden visas på vilket du har lika lite kontroll över som hur stor skärm din egna besökare råkar ha.

Många har designat sina nybyggda responsiva sajter med fina dekorativa, inspirerande och enorma bilder. Att bilderna är enorma, både till utrymme men också filstorlek, beror på att en och samma bild ska kunna visas över större delen av skärmen för vissa besökare ner till att synas på en liten skärm. En stor bild blir väldigt tung om den ska ha någon nämnvärd bildkvalitet – särskilt svårt blir det om det är människor på bild då vi är känsliga för bildoptimeringens sidoeffekter på ytor med hud.

Bild 47 - Bilden dominerar på en stor skärm.

Bild 47: Bilden dominerar på en stor skärm.

Bild 48: Samma bild nedkrympt till en mobilskärm.

Bild 48: Samma bild nedkrympt till en mobilskärm.

Jag kan bara gissa varför många valt enorma bilder men lägger nog min röst på att det med responsiv teknik blev enkelt att få designen att fungera så bra med dominerande bilder och bildkaruseller att man helt glömde bort att inte alla har blixtsnabb uppkoppling. Till och med samhällsaktörer som kommuner, som förväntas bedriva service och informationsplikt via sina webbplatser, sveptes med och la ut så massiva bilder att startsidorna ibland kunde väga in på 5 Mb. Det är cirka en procent av mobilens månatliga surfpott för vissa av medborgarna som gick åt till oftast ganska meningslösa bildkaruseller.

Beroende på vem man pratar med kan man få höra om mängder med andra saker som ingår, eller inte ingår, i responsiv webbdesign. Punkterna ovan belyser ett antal utmaningar som man rimligen behöver ta hand om, bland annat att bilder inte går att skala upp utan att det ser dåligt ut. Sedan att pixeltätheten är olika på mobilskärmar och de flesta stationära skärmar, och att mobil uppkoppling inte går att jämföra med fast kontorsuppkoppling är egentligen något som mer ingår i begreppet adaptiv webbdesign (AWD). En välbyggd modern webbplats tar givetvis hand om även dessa utmaningar och många menar att begreppet AWD inte behövs (mer om AWD senare i boken).

Argument för responsiv webbdesign

Om du fortfarande behöver övertygande kring varför RWD är något att överväga att följa så kommer här några vanliga argument av varierande tyngd beroende på vilken typ av verksamhet du har på din webb.

Ordlista – User-agent:
Information webbläsaren lämnar ifrån sig till varje webbplats vid ett besök. Där framgår vilken webbläsaren är, vilken version, vilken typ av enhet det är, operativsystem och en del annat.
Detta använder man på webbplatser för att veta vad besökaren har för utrustning, exempelvis för att avgöra om besökaren har pekskärm etc.

1. Google anser att det är industristandard

”Responsive design: serves the same HTML for one URL and uses CSS media queries to determine how the content is rendered on the client side. This removes the possible glitches of user-agent detection and frees users from redirects. This is Google’s recommended configuration.
Googles utvecklarsidor, tba.nu/googlerwd

Förutom att rekommendera RWD tar Google upp två andra exempel; att servera olika sidor beroende på vilken user-agent webbläsaren har och varianten att skicka besökaren vidare till en separat mobilsajt. I sin motivering till att man ska välja RWD nämner man att det är den enklare lösningen bland alternativen. Då Google står för lejonparten av besökare man kan få via sökmotorer är deras ord nära på lag för hur man utformar sin webbplats (diskussionen om varför de har denna rekommendation kan vi ta över en öl när man är lagom konspiratoriskt lagd).

2. En enda webbplats att etablera (för flera sorters enheter)

Lägg all energi på att bygga en bra upplevelse för alla typer av enheter och storlekar av skärmar. Alternativet är inte längre att bygga en mobilwebb då mobiler har väldigt olika stora skärmar och du även där skulle mötas av samma typ av problem – förutom att du då har åtminstone två olika webbplatser att ta hand om.

Det är värt att tänka på att en och samma person kan använda flera olika sorters enheter för att besöka din webbplats under en och samma dag. Säg att personen börjar på jobbet vid en dator för att fortsätta med mobilen vid busshållplatsen. Är sajten inte responsiv kommer man antingen få börja om på ny kula på en mobilsajt och eventuellt hitta fram men det kan också vara så att den vanliga sajten visar sin fulaste sida först vilket får många att ge upp.

Publiceringssystemsleverantören EPiServer gjorde en undersökning under 2013 som fann att 70 % aldrig återvände till en mobilsajt som var svåranvänd, det lär vara minst detsamma för vanliga webbplatser på en mobil. Varannan tillfrågad irriterade sig på att många sajter inte är utformade för smartphones. (tba.nu/epimobil)

3. Logisk URL-strategi

En responsiv webbplats har bara en adress. En undersida har en adress oavsett vad och kan användas av en mobilanvändare eller någon som använder en annan typ av enhet. Du har säkert fått en mejlad länk från en vän, öppnat på en vanlig dator och kommit in på en mobilsajt – eller tvärt om fått upp en skrivbordswebbplats på din mobil. Det är förstås inte tanken och sällan optimalt för det utgivaren önskar ska hända dig under ditt besök.

Med en responsiv webbplats behöver inte besökare skyfflas fram och tillbaka mellan olika varianter av webbplatser beroende på vilken typ av enhet de ansluter med.

4. Enklare att förvalta och underhålla ju färre webbplatser man har

Innehållshanteringen är enklare och för att följa upp hur innehållet presterar behöver du inte hoppa mellan olika webbstatistik-konton då uppdelningen efter typ av enhet endast är en enkel segmentering i Google Analytics. Alla kampanjer blir enklare då du skyfflar besökare till samma adress, du får en bättre överblick över hur dina landningssidor presterar och kan enkelt se på vilken typ av enhet du kan göra ett bättre jobb.

5. Responsiv är mer framtidssäkrad

En väl utförd responsiv webbplats fungerar bättre på enheter som idag inte är vanliga, i värsta fall får man lägga till lite justering. Säg att dina besökare plötsligt börjar använda en webbläsare i en spelkonsol på en tv. Det är något som faller väl under responsiv webb men haltar illa som ytterligare en specialwebbplats om man återvinner argumenten att ha en mobilsajt.

Att tänka på vid responsiv byggnation

Innehållet blir inte per automatik bra på en liten skärm bara för att man gjort webbplatsens design mer användbar på fler sorters skärmar. Bland annat är en vanlig kommentar att huvudrubrikerna tar upp halva skärmens höjd eller att utsmyckningsbilder skymmer det faktiska innehållet. Med andra ord har man ett ypperligt tillfälle att se över sitt innehåll från en mobilanvändares synvinkel, vilket kan vara det dominerande sättet att surfa vilket år som helst även på din webbplats. Jag skulle rekommendera innehållsgeniet Karen McGranes bok ”Content Strategy for Mobile” (tba.nu/mcgrane) och googla gärna fram hennes föreläsningar på ämnet för en driva goda råd.

Vissa kan säkert fråga sig om man ska uppgradera sin befintliga webbplats rent designmässigt eller börja om från början? Det beror på om man tror att innehållets presentation och struktur kommer fungera i ett mobilt scenario, om inte är det lika bra att börja om helt förutsättningslöst.

En stor del i ett responsivt projekt är hur man gör med bilder i sin design och huruvida man har råd att visa upp bilder, som ofta tar procentuellt större plats, på en liten skärm när det konkurrerar med annat material. Så som jag gjorde i mitt senaste projekt var att titta igenom de mest besökta webbsidorna och se om man kunde klara sig utan bilden. Oftast tillförde inte bilden något avgörande vilket gjorde valet ganska enkelt att prioritera rubrik, ingress och brödtext istället.

Det finns massor med kreativa lösningar på hur man försöker lösa det här med att inte ladda onödigt tunga bilder eller utsmyckningsbilder på de små enheterna som inte riktigt har plats för det på sina skärmar. Den variant vi valde på Västra Götalandsregionen var att om webbredaktören inte uttryckligen valt att bilden även ska visas för mobila besökare så ersätts den med en genomskinlig pixelstor bild – vilket drar nästan ingen bandbredd alls.
Det knepiga med sådana beslut är att man inte nödvändigtvis kan ta för givet att en person med liten skärm sitter på en mobiluppkoppling, de kan likväl använda ett hypersnabbt wifi-nät. Samtidigt är jag en av de som kör med mobilt bredband hemma till min stationära dator. Skärmstorlek säger helt enkelt inte per automatik vilken sorts uppkoppling som används.

Det svåra med att välja bilder som fungerar i ett responsivt scenario är att få lagom detaljrikedom på bilder som föreställer något besökaren ska känna igen. En högupplöst skärm som är stor som en surfplatta eller större klarar i många fall att visa bilder med lite mer översikt på exempelvis 1024 pixlar. Samtidigt fixar inte alltid en liten lågupplöst skärm att få exakt samma bild nedskalad i upplösning, exempelvis i 320 pixlar, då viktiga detaljer försvinner.

Att tänka på är att bildupplösningen, alltså finkornigheten som ger skärpa och detaljrikedom i bilden, är på en mobiloptimerad bild endast en tredjedel jämfört med en större surfplatta. 320 pixlar jämfört med 1024 pixlar i standarddefinition (SD – ibland kallat native resolution).

Bild 49: Bild med 1024 pixlars bredd. 263 KB filstorlek.

Bild 49: Bild med 1024 pixlars bredd. 263 KB filstorlek.

Bild 50: Samma bild med 320 pixlars bredd. 33 KB filstorlek.

Bild 50: Samma bild med 320 pixlars bredd. 33 KB filstorlek.

Bild 51: Beskuren version av samma bild, i 320 pixlars bredd. 34 KB filstorlek.

Bild 51: Beskuren version av samma bild, i 320 pixlars bredd. 34 KB filstorlek.

Att visa en och samma bild på en liten och lågupplöst skärm som på en större skärm är svårt då det finns färre pixlar att ge skärpa i den lilla bilden, man behöver då beskära den lilla bilden och välja bort lite av översikten till förmån för att se vad bilden föreställer. Visar man originalbilden på en liten men högupplöst skärm kommer man skicka en precis lika tung bild som till stora skärmar med skillnaden att den visas litet och superskarpt – något som kan gå förbi besökaren men påverkar definitivt nedladdningen negativt.

Därför behöver man välja bilder med stor omsorg, eller byta ut dem, så de passar även de mindre stora eller mindre bra skärmarna. Åtminstone är det värt att kolla hur många som kommer drabbas av ett lite mer slapphänt bildredaktörsjobb, det kanske inte är någon fara på just din webbplats. Med andra ord är det avgörande för förståelsen, och meningsfullheten med bilder att man prioriterar tydlighet i vad de föreställer. Än värre är det förstås med informationsgrafik full av text, diagram och symboler. Dessa utmaningar bör du titta efter när du går igenom en webbplats för att se om den ska uppgraderas till RWD eller om det är bäst att börja om från början.

Som du märker är det här med responsiv bildhantering en balansgång på slak lina. Enda rådet att ge är att ha goda marginaler och prova hur ens bilder gör sig i de olika typerna av enheter.

En, i skrivande stund i alla fall, kommande standard är att kunna specificera ett flertal bilder i olika storlekar där bara den som matchar rätt brytpunkt i stilmallen visas för besökaren. Säg att du har en mediefråga för en brytpunkt där alla skärmar under 512 pixlars bredd får en beskuren och tydlig bild medan alla skärmar på 512 pixlar eller mer får den större, mer skarpa, bilden. Då kommer de med små skärmar med låg upplösning få bilder som går nästan tio gånger så fort att ladda ner förutom att du kan skräddarsy vilken version av en bild respektive skärmstorlek får, vilket underlättar för besökaren för att förstå innehållet. Då kan du ge särskilda beskärningar till de skärmstorlekar som särskilt behöver det.

”We’re not designing pages, we’re designing systems of components.”
Stephen Hay, @stephenhay på Twitter

Webbdesignern Brad Frost har beskrivit ett system för att tänka på webbplatser som en kollektion av mindre beståndsdelar – Atomic Design (tba.nu/atomic) – vilket är en av många rörelser bort från klassiska publiceringssystem och deras rätt statiska sidmallar. Detta tillsammans med övningar som att klippa isär utskrifter av befintlig webbplats för pusslande i en enda lång kolumn kan jag personligen rekommendera för att få icke-designers att tänka mer responsivt med innehåll de redan är bekanta med.

En webbplats minsta beståndsdel är enligt Frost atomen, som kan kombineras till molekyler, som kan bli en organism för visning i en sidmall vilket med navigering och andra standardkomponenter utgör en webbsida. I detta sätt kan sökfältet vara en atom, sökknappen en annan och tillsammans utgör de en molekyl för snabbsökets gränssnitt. Tillsammans med sidhuvudets andra molekyler bildar snabbsökfunktionen en organism. Likadant med sidans innehåll (sidmallen), och sidfot där alla delar utgör webbsidan. Genom att dela upp varje webbsida i beståndsdelar ner till atomer och pussla ihop dem på nytt får man en metod som gör att man inte fastnar i vad som ska plockas bort för att fungera på en mobil.

Bild 52: I Android kan man begära att få skrivbordsversionen av en webbplats. Användbart om man inte gillar webbplatsen i den utgåva man fått den.

Bild 52: I Android kan man begära att få skrivbordsversionen av en webbplats. Användbart om man inte gillar webbplatsen i den utgåva man fått den.

Apropå mobiler. Det vanligaste argumentet jag hört mot RWD är att det inte behövs. Det som förenat dessa personer är att de haft Android-mobiler av dyrare variant och lite större skärm än genomsnittet. Dessa telefoner lider inte fullt lika mycket av gammaldags design och då blir det önskvärt att själv kunna hoppa mellan de olika brytpunkterna om man vill hitta något man vet exakt var det låg på skrivbordsdatorversionen av webbplatsen. Googles webbläsare på Android har en funktion för detta i form av att man kan välja att hämta skrivbordsversionen av en webbplats. Ett annat alternativ som möjligen kommer att växa fram är att man blandar in valet av webbplatsversion bland andra tillgänglighetsinställningar som textstorlek, kontrast med mera. Har du en avancerad eller medveten användare förväntar de sig säkert att få välja detta.

Responsiv typografi

Då spaltbredden på små skärmar är ganska smala riskerar långa sammansatta ord att stå ensamma på en rad, eller i värsta fall ge horisontell skrollning i onödan. Redaktionellt och i statisk text kan man förebygga detta med hjälp av det som heter mjukt bindestreck. Det är ett bindestreck som avstavar ett ord med bindestreck om det behövs.

Bild 53: Rubriken i högerkolumnen avstavas automatiskt om utrymmet blir för smalt. Bakgrunden är iPad i landskapsläge, förgrunden iPad i porträttläge.

Bild 53: Rubriken i högerkolumnen avstavas automatiskt om utrymmet blir för smalt. Bakgrunden är iPad i landskapsläge, förgrunden iPad i porträttläge.

Dessa mjuka bindestreck görs med hjälp av en liten kod som ser ut som följer:

<h2>Optimerings&shy;tester</h2>

Det är &shy; som spelar huvudrollen för att vid behov avstava ordet inom rubriken av andra storleken. Det är värt att tänka på att denna kodsnutt behöver tas emot av besökarens webbläsare som HTML-kod vilket gör att du i din WYSIWYG-editor får växla över till kodläge, det kanske inte fungerar i alla textfält att ange denna kod, men det är inte farligare än att du testar vad som händer.

Något du kan behöva göra tillsammans med en utvecklare är att lösa eventuella problem med längd på namn i menyer genom att med Javascript använda kortversioner av namn. Om sidans bredd är under ett visst mått byter man ut tecken som att ”och” blir ”&” eller hela ord mot något kortare så texten inte bryter designen.

Det är inte bara tycke och smak som avgör design som exempelvis kolumners bredd. Är innehållet text finns typografiska regler som styr. Idealfallet är att ha någonstans mellan 45-75 tecken per rad för god läsbarhet, det påverkar hur bred en kolumn kan vara om texten ska linjera med kolumnens högra kant. Innehållet ställer krav på en brytpunkt om raderna blir för långa, alternativt om man sätter en maximal bredd enbart på text för läsbarheten skull men tillåter andra element på sidan att flyta ut ytterligare.

Webbredaktören får lov att hjälpa till med &shy; för att avstava ord så smala kolumner inte får ett eller få ord per rad då läsbarheten blir lidande. Om du inte är ensam om att fylla på med information är det säkert en god idé att ha med mjuka bindestreck på fusklappen för redaktionella knep alla webbredaktörer bör ha tillgång till.

RESS – Responsive Server Side

En logisk uppföljare till responsiv webbdesign är det som kallas för RESS (Responsive Server Side). Det skiljer sig mot en ortodox RWD genom att webbservern tar reda på vilken utrustning besökaren använder och skickar en anpassad version av webbplatsen. Det är lite som förr i tiden när man skickade olika stilmallar beroende på om besökaren använde Internet Explorer eller Netscape som webbläsare, men med skillnaden att idag är det massvis med fler faktorer än två olika webbläsare man har att ta ställning till.

Ett simpelt exempel på där RESS kan skilja sig från en vanlig responsiv webbplats är att om webbservern i RESS-varianten märker att det är en mobil besökare skickas inte flera megabyte med utsmyckningsbilder. Verkar det vara en desktop-version av någon webbläsare kanske man väljer att skicka tyngre material och kan med att prioritera en mer visuell upplevelse. Att responsiva webbplatser skickar på tok för mycket data till mobila enheter är ett av de vanligaste invändningarna mot att följa den designprincipen. I stora drag är det samma innehåll som skickas till alla besökare, man gör dock avkall på vissa delar av ortodox RWD där det är motiverat.

Nu kanske du undrar hur webbservern vet vad besökaren har för utrustning? Det finns flera knep för att ta reda på detta men mest grundläggande är att kolla på det som kallas för user-agent, alltså information om den programvara du använder för att ansluta till webben. Så här ser min user-agent ut:
Mozilla/5.0 (Macintosh; Intel Mac OS X 10_9_1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/32.0.1700.107 Safari/537.36

Av min user-agent kan varje webbserver jag ansluter till läsa ut att jag använder en Macintosh, med operativsystem OS X 10.9.1, webbläsaren Chrome och att utseendet på webbsidor ritas upp med hjälp av renderingsmotorn WebKit. (Kolla din egen user-agent här tba.nu/ua)

På en iPhone kan en user agent se ut så här:
Mozilla/5.0 (iPhone; CPU iPhone OS 7_0_5 like Mac OS X) AppleWebKit/537.51.1 (KHTML, like Gecko) Version/7.0 Mobile/11B601 Safari/9537.53

För en Google Nexus 5-telefon kan det se ut som följer:
Mozilla/5.0 (Linux; Android 4.4.2; Nexus 5 Build/KOT49H) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/32.0.1700.99 Mobile Safari/537.36

Som du säkert märkt på de föregående exemplen har man störst användning av att titta på user-agent för att avgöra vilken typ av enhet som används av besökaren. Som i dator eller pekbaserad enhet, om det är Windows, Linux eller Mac. Android, Windows Phone eller iOS. Det finns en hel del slutsatser man kan dra enbart på denna information för att skicka HTML-kod och innehåll som är optimerad för respektive plattform, eller om man kan skicka optimerat innehåll som det än så länge udda bildformatet WebP som är 39 % mindre än vanliga JPG-filer för fotografier.

Förutom att titta på user-agent kan webbservern försöka sig på att kontrollera andra faktorer som påverkar hur man vill presentera sin webbplats, exempelvis hur snabb uppkoppling besökaren har. Vad besökarnas webbläsare berättar om sig själva för webbservern förändras konstant, så kolla vad som kan upptäckas av en webbserver när du har anledning till att bygga nytt nästa gång.

Sorry, detta avsnitt blev lite långt men det finns så mycket att säga om responsiv webbdesign då det är lite av en referenspunkt för alla webbprojekt för ett tag framöver. Nu ska vi kolla vidare på en, enligt vissa, uppföljare till responsiv webbdesign.

Adaptiv webbdesign

Iden bakom adaptiv webbdesign (AWD) är att skräddarsy varje besökares upplevelse av en webbplats i detalj. Det är att använda de möjligheter som finns, så kallad progressive enhancement, vilket ger en god grundfunktion till alla besökare och beroende på vad mer som stöds hos besökaren aktiveras även det. En av de första adaptiva designmöjligheterna många använde var att låta moderna webbläsare dra nytta av CSS3 tidigt, som runda hörn på boxar etc, medan de med en gammal version av Internet Explorer fick en fulversion. Kan lika gärna nämna direkt att vid diskussion om denna terms nödvändighet ger många av mina vänner på webbyråer något trött uttryck i blicken och menar att vi inte behöver det här begreppet då ”allt det där ingår ju i en bra responsiv webbplats”. Jag är beredd att hålla med i mångt och mycket, men anledningen till att jag ändå tar upp AWD är mer för att belysa den mångfald med saker som beroende på vem man pratar med riskerar att missa som en del av vad nu ”bra responsiv webb” ändå innebär.

För enkelhetens skull kan du tänka på AWD som en responsiv webbplats med skillnaden att för AWD är det mer ok att ge helt unika upplevelser beroende på vilka förutsättningar besökaren har, och vilken designkonvention som gäller för respektive enhet. Dessutom kan en AWD-webb skicka olika kod till olika sorters enheter vilket är den största skillnaden mot RWD. I den mån besökarens förutsättningar är kända, och värda att anpassa sig efter, gör man en optimerad version. Många gånger använder man Javascript-ramverk, som exempelvis Modernizr, för att enkelt få svart på vitt vad respektive användares enhet klarar av. Modernizr kollar exempelvis efter hur mycket stöd besökarens webbläsare har för CSS3 och HTML5:s funktioner.

Bild 54: Webbplats frågar om lov att använda mobilens geoposition.

Bild 54: Webbplats frågar om lov att använda mobilens geoposition.

Exempel på förutsättningar som kan variera och vara användbara i designen av en webbplats som följer AWD:

  • Har enheten en kamera? Kan vara användbart ifall användaren ska kunna ta en profilbild, eller kanske fotografera prylen hen vill sälja på den annonswebbplats denne är inne på.
  • Hur styrs enheten? Det kan vara rätt avgörande för vissa designelement om besökaren har en mus att styra med, om det är någon pek-liknande svepning eller annat. Annars blir det svårt att kontrollera bildkaruseller exempelvis, säg att det varken är en mus eller pekskärm när det istället kanske är hela kroppen som är någon sorts fjärrkontroll.
  • Kan man avgöra en geografisk plats? Är väldigt avgörande för geopositioneringstjänster men självklart bra som indata i sökfunktioner så geografisk närhet till användaren kan tas med i relevansmodellen när denne letar efter något.
  • Vilka möjligheter finns för ljud, film och vektoriserad bild? Bland annat är det bra att veta vilka format enheten kan ta emot så man kan skicka det bästa man har i ett format som går fort att överföra.
  • Databasstöd i webbläsaren? I vissa webbapplikationer utförs mycket arbete lokalt i webbläsaren, främst då det som ger trög känsla på webben är att skicka material fram och tillbaka till servern. En förutsättning för att använda webbläsaren som klient är i många fall att den kan hantera en lokal databas.
  • WebSockets för realtidsuppdatering i webbläsaren? Detta används för att kommunicera mellan olika användare, och mellan användaren och webbservern exempelvis vid realtidsspel. Meddelanden där man ser att den andra skriver eller innehållet tenderar till att uppdatera sig självt, bland annat.
  • Web Workers för applikationer? Web Workers är en lösning som får Javascript att bli programmeringsspråket i webbläsaren för att bygga större applikationer, något som används i många Single Page Applications redan idag (SPA, mer om detta senare i boken).
  • Finns telefoni i enheten? Att göra om telefonnummer till klickbara länkar för uppringning är en trevlig funktion om det nu går att ringa med den enhet besökaren har – annars kanske man struntar i att länka, eller länkar till en ring-upp-funktion istället.
  • Hur högupplöst är skärmen? Om det är en så kallad hög-DPI-skärm (ibland kallad retina av Apple-användare) kan normalupplösta bilder upplevas som suddiga. Gäller särskilt text i bilder och även logotyper.
  • Vilken hastighet har internetuppkopplingen? Ska exempelvis video strömmas är det bäst att lagom bandbredd väljs automatiskt så det inte laggar i uppspelningen.

AWD innebär inte nödvändigtvis att innehållet, som texter, förändras beroende på besökarens förutsättningar, som geografiska plats exempelvis. Det är mer på en övergripande webbdesign-nivå. Att i detalj styra vilket innehåll som dyker upp tillhör mer begreppet personalisering, dock med undantag för att en AWD-webb behöver prioritera innehåll att visa på små skärmar eller vad som ens går att använda på besökarens enhet.

Däremot kan man och kanske bör, åtminstone som samhällsaktör, se till att en otroligt nedbantad version erbjuds de med klart undermålig internetuppkoppling. Om överföringen är tillräckligt långsam får besökaren en slimmad sajt med bara det allra nödvändigaste. Där kan besökaren själv, likt på en mobilsajt, välja att gå över till den fullständiga webbplatsen om denne har tålamod eller växlat till en bättre uppkoppling. Man skickar inte några som helst bilder eller material tyngre än text och grundläggande design för att få fram det mest väsentliga innehållet. Denna lösning kanske kan fungera som någon form av katastrofversion om servern eller nätet blir överbelastat.

Bild 55: En snabb 3G-uppkoppling på nästan 16 Mbit/sekund nedströms och 0,048 sekunder svarstid.

Bild 55: En snabb 3G-uppkoppling på nästan 16 Mbit/sekund nedströms och 0,048 sekunder svarstid.

Bild 56: Sämre 3G-uppkoppling på 0,035Mbit/sekund och 1,2 sekunder i svarstid.

Bild 56: Sämre 3G-uppkoppling på 0,035Mbit/sekund och 1,2 sekunder i svarstid.

Du kanske tänker att det inte är så illa egentligen, men då har du nog aldrig stått på utkanten av 3G-nätet och råkat surfa in på en responsiv webbplats. För vissa som befinner sig på landsbygden är detta normalsituationen. För att exemplifiera med två tillfällen jag själv mätte min uppkopplingshastighet under 2013 så hade jag i Göteborg 16 Mbit/sekund nerströms och 3 Mbit/sekund uppströms med en fördröjning på 0,048 sekunder. I Fengersfors, i Dalsland, blev det däremot lite mer blygsamma 0,035 Mbit/sekund nerströms och 0,4 Mbit/sekund uppströms med fördröjning på hela 1,2 sekunder!

Om jag försöker sätta dessa siffror i perspektiv så är det i Fengersfors långsammare surf än med 90-talets 56 Kbit/s-modem, med en dryg sekund i lagg för varje fil innan den börjar skickas. Som lök på laxen är dagens webbplatser ofantligt mycket mer nedtyngda av stora bilder, fler filer för Javascript och stilmallar, var och en av dessa filer lägger till en sekund på laddningstiden i ren fördröjning.

Låt oss räkna lite på hur det här kan se ut hos en besökare på en lite väl tung responsiv webbplats på 5MB fördelat på 30 olika filer – en storlek till och med ett antal kommuner tyckte sig komma undan med för sina fina responsiva startsidor. Med det snabba exemplet tar en sådan webbplats cirka 1,4 sekunder i fördröjning plus 3,2 sekunder i nedladdning. För att vara en onormalt tung sida är det ju ändå helt ok att den laddas in på under 5 sekunder. Samma material som ska skickas via det långsamma exemplet på uppkoppling blir istället 35,8 sekunder i fördröjning och 143 sekunder i nedladdning. Det är praktiskt taget tre minuter.

Där AWD briljerar är att det är mer självklart att man inte ska skicka filer till besökaren denne inte har någon nytta av. Responsiva webbplatser har i många fall skickat bilder i större version än vad besökarens skärm klarar av att visa, för att inte tala om att bilder skickas som inte ens presenteras för besökaren. Det finns förstås ingen poäng i att vara så renlärig till responsiv webbdesign att man inte gör denna optimering, och personligen tror jag att det är här diskussionen om AWD kontra RWD uppkommit. AWD-anhängare menar att deras variant är bättre optimerad och laddar mycket snabbare, medan RWD-folket menar att AWD-folket bygger flera sajter i en.

Bild 57: Mobila besökare på 1177. se, 53 % kör iPhone, 18 % iPad, resten Android, Blackberry, Windows Phone m.fl.

Bild 57: Mobila besökare på 1177. se, 53 % kör iPhone, 18 % iPad, resten Android, Blackberry, Windows Phone m.fl.

Frågan är hur många enheter man ska optimera extra mycket för? De 5 mest populära? Vilka som är populära kan faktiskt förändras ganska snabbt. Bara antalet unika enheter dina besökare kan tänkas använda är häpnadsväckande. Under 2013 var det 355 stycken olika sorters mobila enheter som identifierades på den relativt välbesökta webbplatsen 1177.se vilket pekar på behovet av att tänka responsivt även när man bygger AWD då skärmstorlekarna varierar mycket och man inte kan ge unika lösningar till alla. Utgå från din webbstatistik, och bedriver du försäljning på webbplatsen kan du ta en titt på vilka enheter de har som är mindre lönsamma än genomsnittet – om de är många nog kan det finnas anledning att hitta en lösning.

Utseendemässigt ser de flesta AWD-webbplatser ut som vilken modern webbplats som helst som följer RWD, men till skillnad från RWD kan upplevelsen skilja sig ordentligt om man går in med en annan typ av enhet.

Själv tycker jag att AWD är mest intressant som motkraft till att så många vill bygga enkla informations-appar till mobiltelefoner istället för att ta hand om sin befintliga webbplats. Med en god dos Javascript och lite omdesign kan vilken webbplats som helst se ut och bete sig som en mobilapp bara man fäster en genväg på hemskärmen på mobilen. Det är också i mobilen de intressanta delarna av AWD dyker upp då man har andra designkonventioner för något som upplevs mer ”appigt” i navigation och hantering av designelement.

HTML5 har ett API för batteriets status på mobila enheter, AWD-webbplatser bör givetvis använda detta när det går för att bland annat minska mängden nätverksanrop för att spara på batteriets kvarvarande kapacitet.
Någonsin känt dig bländad av din mobil? Antagligen!

Webbstandardorganisationen W3C har tagit fram en rekommendation kallad Ambient Light Events som gör att man kan dra nytta av ljusmätaren som finns i vissa datorer och praktiskt taget alla mobiler. Vad man gör av den informationen när man ska designa sin webbplats är upp till var och en, men personligen skulle jag nog göra en design för dagtid och en för nattetid – många applikationer av idag har denna funktion men man måste byta manuellt.

Bild 58: Ljus botten och mörk text fungerar bäst under ljusa förhållanden.

Bild 58: Ljus botten och mörk text fungerar bäst under ljusa förhållanden.

Bild 59: Mörk botten och ljus text är behagligt när man är i mörk omgivning.

Bild 59: Mörk botten och ljus text är behagligt när man är i mörk omgivning.

Hur vet man att ens webbplats gör så bra ifrån sig som möjligt? Genom att kontinuerligt utvärdera data på hur användarna beter sig förstås. Det kommer härnäst.

Datadriven design

När man väljer att låta data styra designen av en tjänst är det ett sätt att försöka jobba med aktiv bevisföring över vad som faktiskt fungerar, eller inte fungerar, och vad som kan bli bättre. Det är ett sätt att få erfarenhet av användningen av en tjänst för att nästa uppdatering ska bli ännu mer i linje med vad användarna förväntar sig. Ett ganska prestigelöst sätt att se på sin design.

Om du ska låta data styra designen behöver du först veta vad webbplatsen ska kunna hjälpa till med. Vilken roll den ska spela i helheten. I vissa fall kanske man inte har en aning om varför man har en webbplats och då kan en titt i organisationens affärsplan/verksamhetsplan vara en god idé – där bör övergripande tankar finnas som går att bryta ner i mätbara mål för hur webbplatsen kan tillföra nytta. Är det mer av en informationswebb bör stöd för hur man definierar en väl presterande webbplats finnas i en kommunikationsplan eller projektdirektiv. De mål webbplatsen ska jobba mot bör dokumenteras och stämmas av med alla berörda.

Att kunna bryta ner en hel webbplats till mängder med delar som graderas efter huruvida de är nyttiga är nog inte ett arbetssätt alla är vana vid. Om man inte riktigt känner att man kan se eller förklara vad webbplatsen tillför för nytta är detta arbetssätt utmärkt för att ta reda på det och upptäcka vad som kan göras bättre.

Det är en hel vetenskap att ta fram mätvärden, ofta kallade KPI:er (Key Performance Indicators), och något utanför ämnet på denna bok men det som är värt att nämna är att man ska jobba både med kvantitativa och kvalitativa mätvärden. Skillnaden dem emellan är att:

  • Kvantitativa mätvärden utgår från mer automatiskt insamlad data, exempelvis signaler som indikerar ett beteende vid faktiskt användning av en webbplats. Detta är siffror som svarar på frågor som vem, vad, när och var kring användningen. Denna information kan du bland annat få från din webbstatistik.
  • Kvalitativa mätvärden är data baserat på intervjuer, enkäter och annat som baseras på människors egna subjektiva uppfattningar eller handlingar. Med data menas här människors svar på frågor som varför eller hur kring deras intryck eller beteende – lite mer av anekdoter med andra ord – men kan också vara att man observerar personen när denne fått en uppgift att lösa.

Ett exempel på kvantitativt mätvärde är en siffra för antalet besökare från Europa under januari. Ett kvalitativt mätvärde kan vara att majoriteten av besökarna, inom det mobila segmentet, i en webbenkät angett att tjänsten fungerar mycket bättre på en mobil sedan en omdesign. Kvantitativa värden anger omfattning och kvalitativa värden ger perspektiv.

Att komma igång med datadriven design

Om man börjar helt från scratch med en tjänst har man kanske inga egna data att utgå ifrån. Men om det ska skapas en digital motsvarighet till en offline-verksamhet finns säkerligen en del slutsatser att dra från offline till ett kvalificerat startpaket online. Oavsett om man har en befintlig verksamhet eller inte, digital eller offline, är det en bra idé att göra lite efterforskningar. Kolla gärna på digitala motsvarigheter om det finns, och särskilt på eventuella konkurrenter.

Att vägledas av data innebär att man är beredd på kontinuerlig förändring vilket gör att man behöver vara noggrann med vad ens data innebär. Kvantitativa data är ofta värdelösa om man sammanställer dem till en för hög nivå, men i en allt för snäv segmentering blir det statistiska underlaget så litet att det är lurigt att dra några lärorika slutsatser.

Här har du en svår balansgång att välja ut vilka frågor du tycker dig kunna få svar på genom dina data. Se kritiskt på dina data så slipper du förhoppningsvis obehagliga överraskningar.

Dina mätvärden ska vara specifika och isolerade nog att kunna besvara en fråga om användningen. Antalet unika besökare på en webbplats är för all del intressant men för att göra en webbplats bättre är det exempelvis viktigare att veta hur många som överger sin kundvagn innan betalning. Istället för att sitta nöjd med att man har 10 % fler besökare än föregående månad kommer den som jobbar baserat på data att se på kvantitativa data (När överges kundvagnen? Vid utcheckningen kanske?) och kvalitativa data (fråga besökare om deras upplevelse av köpprocessen) för att optimera ytterligare.

Som du säkert listat ut vid det här laget behöver man förutom de webbplatsövergripande målen ha tydliga, och helst dokumenterade, mål för många av de enskilda undersidorna på webbplatsen – inte sällan finns flera mål per undersida. Dessa mål är den långa listan nästan varje förändring av webbplatsen ska linjera med och sträva efter en förbättring.

Vissa sidor kommer ha mål som inte stämmer överens med andra sidors mål, eller vad många anser är kriterier på bra mottagande hos besökaren. Exempelvis är det vanligast att man vill ha en låg avvisningsfrekvens, alltså att en undersida inte får besökarna att lämna webbplatsen, men det finns sidor vars innehåll hänvisar till andra webbplatser. I ett sådant exempel är en hög avvisning ett mått på att besökarna förstår syftet med undersidan, accepterar det och hittar länken till den andra webbplatsen. Detta är ett exempel där det övergripande målet om att behålla besökarna på webbplatsen motarbetas av vissa undersidor. Rapporter över hur webbplatsen presterar måste anpassas efter det så inte en ökad andel besökare på vissa undersidor får webbplatsen att se ut som om den underpresterar.

Vad du vet om dina besökare

För att veta vad som är värt att justera på en webbplats krävs en viss kännedom om vilka besökarna är. De olika typerna av besökare är dina segment inom denna typ av design. Ett segment är återkommande besökare, ett annat är inloggade kunder som lagt en viss sorts vara i kundvagnen. Det du behöver fundera på, och samla data kring, är vad som behövs för att få respektive segment att konvertera – alltså göra det du önskar på webbplatsen. En konvertering kan vara att rekrytera en helt ny kund som lägger en beställning, men det kan också vara ett mindre storslaget mål som att besökaren följer en länk till organisationens profil på Instagram. Vilka konverterande aktiviteter besökaren utför beror på vilken del av webbplatsen besökaren varit på. Att varje undersida ska vara en del av att konvertera besökare kommer säkerligen som en chock för många webbredaktörer inom offentlig sektor, men där en webbshop försöker tjäna pengar verkar offentligheten mer på få sina besökare att känna till sina rättigheter, använda e-tjänster eller klicka sig vidare till andra relevanta webbplatser.

Det viktiga är att veta varför en undersida finns till, vad den ska tillföra helheten och på vilket sätt den uppfyller de övergripande målen som finns för webbplatsen. Kan man inte svara på det ska sidan troligen tas bort.

Optimering behöver ske inom ett litet segment av användare och störst nytta är det om man kan få reda på vilka som har störst problem med att konvertera – alltså vilken typ av besökare man inte lyckas övertyga att utföra en önskvärd aktivitet på webbplatsen. Det kan vara segment som ”de som har störst problem med att ta sig igenom köpprocessen med sin kundvagn” men också kan det handla om att konvertera ”folk som kommer in på landningssida för resa till Kreta”. Att hitta dessa segment är något som kräver verksamhetskunskap och är svårt att anlita konsulter för att avhjälpa. Svaret på dessa utmaningar är inte alltid att designa om webbplatsen utan kan mycket väl vara att försöka nå ut med en nyskapad landningssida för resmål på Kreta, eller att göra det lättare att se vad man förväntas göra på en viss typ av undersida.

I vissa fall vet man lite om sin besökare på grund av att de är inloggade och har lämnat avslöjande uppgifter om sig själva – som om i vilken sektor de jobbar inom. Ibland vet man inte mycket mer än att man bör klumpa ihop dem efter hur de hamnade på webbplatsen. Kom besökaren via en kampanjlänk, ett nyhetsbrev eller spontant via en googling? Ja, det kan göra hela skillnaden i huruvida din webbplats klarar av att konvertera besökaren till en kund, ett fan eller vad du nu är ute efter med webbplatsen. Det är i dessa detaljer du letar segmentering för att förbättra hur din webbplats levererar baserat på kvantitativa data för hur användarna beter sig. Hittar du ett större segment av besökare som inte gör vad du vill på webbplatsen har du en stor outnyttjad potential att jobba med. Har du uppgifter om inloggade personers tillhörighet till offentlig eller privat sektor, eller annan gruppering som underpresterar är det bara att sätta igång med att fundera på vad som kan göras bättre. All data om dina besökare är bra data då du likt en detektiv söker efter vilken underpresterande grupp du ska sätta tänderna i först.

Något du säkert redan sett, men möjligen inte reflekterat över, är de kassaerbjudanden som finns på många webbshoppar innan man är klar med sin beställning. Det är en digital motsvarighet till att du i en fysisk affär hittar godis, batterier, tidningar och andra väl valda varor närmast kassan där du köar för att få betala. Självklart ska inte dessa kassaerbjudanden vara statiska och desamma för samtliga kunder på en webbshop. Det som erbjuds ska givetvis först och främst vara något som kompletterar köpet men också ha en god vinstmarginal. Risken är ju att man tappar sin kund genom att införa detta mellansteg i kundvagnen.

Hur vet man att det mellansteget i utcheckningen är värd risken att din kund överger sin kundvagn? Eller vilka extra-produkter man ska erbjuda innan köpet är fullbordat? Genom testa olika alternativa designer kan du med hjälp av data se om det är värt att ha ett extra steg innan kassan för dina kunder.

Bild 60: Webhallen försöker få kund att plocka med några kassaerbjudanden som kompletterar kundvagnens kategori. I kundvagnen ligger ett brädspel.

Bild 60: Webhallen försöker få kund att plocka med några kassaerbjudanden som kompletterar kundvagnens kategori. I kundvagnen ligger ett brädspel.

Bild 61: Komplett. se tipsar om kompletterande sladd till datorskärm. Det är inte en vild gissning att de har en stor vinstmarginal på den sladden.

Bild 61: Komplett. se tipsar om kompletterande sladd till datorskärm. Det är inte en vild gissning att de har en stor vinstmarginal på den sladden.

Kontinuerlig A/B-testning

Genom att kontinuerligt jobba med så kallade A/B-tester kan du testa dina hypoteser för vad som är mest framgångsrikt för att konvertera en besökare till att utföra en önskvärd aktivitet. Ett A/B-test är en tävling där man på förhand förberett två olika alternativ av något man vill mäta vilken variant som ger bäst effekt bland riktiga användare. Det kan vara små detaljer som vilken text som fungerar bäst på knappen för att lägga en vara i kundvagnen, hur besökare agerar på en landningssida till att mäta hur besökarna reagerar på större designbeslut – som antalet kolumner med innehåll. Eller varför inte ta reda på vilka extra tillbehör kunderna väljer till respektive produkt.

Bild 62: Alternativ A. Sidmall med två kolumner för sidans unika innehåll.

Bild 62: Alternativ A. Sidmall med två kolumner för sidans unika innehåll.

Bild 63: Alternativ B. Alternativ sidmall med en kolumn som ger större yta till kartfunktionen.

Bild 63: Alternativ B. Alternativ sidmall med en kolumn som ger större yta till kartfunktionen.

Dessa alternativ slumpas ut till besökarna under en testperiod och det är viktigt att man splittar upp besökarna istället för att man byter alternativ varannan dag. Hälften får alternativ A och andra hälften får alternativ B. Det kan vara så att testet designas för att bara köras på ett visst segment, delmängd av besökare alltså, för att man ska kunna isolera sin hypotes. Exempelvis kan man vilja testa olika designidéer enbart på nya besökare och se om man kan få dem att i större utsträckning utföra en konverterande aktivitet. Det är inte en bra idé att testa större designförändringar på återkommande besökare då de redan har en uppfattning om hur webbplatsen borde fungera, om du gör detta så försök mildra besökarens förvåning.

Alternativ för att utvärdera designfrågeställningar kan vara att testa hur dominerande designelement kan vara, eller hur många kolumner med information som funkar för de med små skärmar, eller vad du nu vill.
När testperioden är över utses en vinnare, oftast automatiskt baserat på framgångskriterier man satt upp, och blir den variant som fortsätter att användas framöver tills dess den får en ny utmanare.

Bild 64: Påminnelse per epost om övergiven kundvagn.

Bild 64: Påminnelse per epost om övergiven kundvagn.

Ibland kommer testen inte att komma fram till att det är någon väsentlig skillnad mellan alternativen, men det är även det en värdefull lärdom.

Var uppmärksam på att undvika fallgropar som att designa målen på ett sätt som är i konflikt med din besökares intressen. Exempelvis är det rätt dumt att minska tonvikten av länkar till partnerwebbplatser för att följa ett webbplatsövergripande önskemål om att behålla besökare inom sin egen webbplats. Statistiken är inte ett mål i sig.

Bild 65: InternetWorld tipsar tidigt i sin brödtext om relaterade nyheter. Deras mätvärde på ett lyckat besök är troligen mer åt antal sidvisningar än genomsnittlig tid per sida.

Bild 65: InternetWorld tipsar tidigt i sin brödtext om relaterade nyheter. Deras mätvärde på ett lyckat besök är troligen mer åt antal sidvisningar än genomsnittlig tid per sida.

Exempel på A/B-tester för uppföljning inom och utom webbplatsen

Hur dina A/B-tester ska utformas vet du bäst själv, men jag tänkte ta upp några exempel på tester som kan vara värt att inspireras av.

  • Utformning av knappars och länkars text, färg, storlek och placering. Förutom uppenbara användbarhetsproblem med att något inte är lätt nog att upptäcka kan nyanser, avstånd till andra grafiska element med mera spela stor roll. Hur du utformar text kan göra all skillnad i världen, exempelvis beror det på dina besökares teknikintresse om det ska stå ”Prenumerera” eller ”RSS-flöde” som länktext – detta behöver testas och mätas.
  • Ta fram två alternativ till registreringsformulär till webbplatsen. En person som ryggar tillbaka eller har användbarhetsproblem med ett registreringsformulär är en förlorad kund.
  • Bildval på landningssidor. Vilka bilder fungerar för att inspirera besökaren till att lägga en vara i kundvagnen?
  • Längd på, och formulering av, texter. Produkttexter och hur huvudrubriker komponeras är värt att testa. Behöver texter förkortas för de mobila besökarna? Testa.
  • Se hur kunder reagerar på att bli påminda per e-post om varor i övergivna kundvagnar. Kan bli en serie av tester för att lista ut vilka kunder som reagerar positivt på en påminnelse men det kan behöva testas ut om det fungerar olika bra beroende på typ av produkt.
  • Skicka två olika nyhetsbrev och mät vilket som har minst andel som avregistrerar sig. Precis som webbstatistik om vilka delar av webbplatsen som är populära finns anledning att försöka få koll på vad som uppskattas när informationen uppsöker mottagaren, Det är något helt annat att personen ifråga besöker en webbplats för att denne är medveten om sitt behov.
  • Testa olika erbjudanden vid utskick. Att skicka erbjudanden några få är intresserade av är slöseri av samtligas värdefulla uppmärksamhet. Om man ännu inte testat tillräckligt för att nå erfarenhet kring vad som funkar bör två olika varianter skickas ut och sedan jämföras efter deras respektive effekt mot verksamhetens mål.
  • Placering av sekundärt mål. Då många viktiga sidor kan ha flera mål är det en god idé att testa den optimala placeringen av andra mål än det primära. Det är troligtvis inte en slump att många av de etablerade tidningswebbplatserna har tips om relaterade nyheter inbakad i sin nyhetstext. Antagligen är inte heller positionen inom texten en slump utan lär ha utvärderats för att se hur långt in i en text en sådan länk har mest verkan att hålla kvar besökaren. Det gäller att generera de där sidvisningar man kan sälja till annonsörerna.

Några som testat det mesta inom optimering av försäljning på nätet är internetjätten Amazon.com. De fick på julafton 2013 ett patent beviljat på att skicka varorna innan kunden ens beställt något. Så här sammanfattar Amazon lösningen i patentets abstrakt:

”A method and system for anticipatory shipping are disclosed. According to one embodiment, a method may include packaging one or more items as a package for eventual shipment to a deliviery address, selection a destination geographical area to which to ship the package, shipping the package to the destination geographical area without completely specifying the delivery address at time of shipment, and while the package is in transit, completely specifying the delivery address for the package.”
tba.nu/ampatent

Hur skulle Amazon kunna göra detta? Genom att ha stenkoll på besökarnas beteenden och relatera det till försäljning. De får koll på ditt beteende genom massiv datainsamling, exempelvis ökar sannolikheten att just du beställer granola-musli om folk i din geografiska omgivning plötsligen börjar köpa den varan eller de du följer på Twitter skriver mycket om det. Men trenden behöver förstås inte vara lokal, det kan hänga ihop med andra faktorer. Ett ganska utflippat exempel är att affären Target genom en tonårings köpmönster insåg att hon troligen var gravid och erbjöd varor baserat på det. Tonåringens pappa vädrade sitt missnöje med att butiken propagerade för att dottern skulle skaffa barn i så unga år, detta samtidigt som hans dotter faktiskt var gravid. (tba.nu/gravid)

Mobile first

Att bygga en webbplats för användning i en mobiltelefon handlar inte bara om att få till en fungerande design även för de med små touchskärmar. Mobile first utgår från mobilens perspektiv först, dess begränsningar och möjligheter. ”Mobile first” är titeln på skrivelsen på detta ämne av Luke Wroblewski.

Utgår man från mobile first förväntar man sig inte att besökaren har en stabil internetuppkoppling med hög hastighet. Inte heller att miljön runt omkring besökaren är ergonomiskt utformad. Snarare har man tagit höjd för att besökaren är på en skakig buss i ödemarken samtidigt som solen bländar, för att strax därefter komma in i radioskugga i en tunnel.

Bild 66: Adlibris.se är bland de första mobile first- webbplatser jag stött på.

Bild 66: Adlibris.se är bland de första mobile first- webbplatser jag stött på.

Studier visar att de som surfar med mobil är otåligare än andra, troligen för att de lärt sig att det inte är lönt att vänta. Detta gör att snabbhet och enkelhet behöver prioriteras extra mycket. Mobila besökare har också en vana av annan designkonvention och hur interaktion görs, exempelvis är det närmre till att skrolla bilder sidledes om man primärt är mobilanvändare och många tjänster man är van vid i appar anpassar innehåll efter personens geografiska position. Det finns helt enkelt en annan förväntan från besökarens sida man behöver försöka leva upp till.

Bild 67: Som skrivbordsdator- besökare kan mobile first kännas lite simpelt. Här Adlibris på 24-tumsskärm.

Bild 67: Som skrivbordsdatorbesökare kan mobile first kännas lite simpelt. Här Adlibris på 24-tumsskärm.

En inte helt osannolik konsekvens av att man gör om sin webb till att följa mobile first är att återkommande besökare inte bara får den sedvanliga huvudbryn över vart material tagit vägen utan också att det på en vanlig dator är så till den milda grad förenklat att man kan tro att något gått fel. Samtidigt kan man inte vänta tills majoriteten av besökarna kommer via en mobil. Alltså behöver man designa något enkelt, som utan att kompromissa med mobiliteten kan skala upp till att möta förväntningarna från skrivbordsdator-besökare.

Mobile first kontra responsiv webbdesign

Skillnaden mellan en responsiv webbplats och en mobile first-webbplats är vad som anses vara normal utrustning man anpassat webben efter. De flesta responsiva projekt jag hört talas om utgår från att en och samma webb ska kunna anpassa sig efter olika stora skärmars förutsättningar att visa upp innehåll. Responsiva webbplatser tenderar att handla om två eller tre utgåvor; liten, mellan och större skärm. I och med att den stora skärmen finns där är det enkelt att landa i det vanliga tänket att den mobila skärmstorleken kommer lite på undantag till förmån för en stationär skärm som sedan skalas ner till en mobil kompromiss. I det klassiska tänket har man inte nödvändigtvis mobilens begränsningar och möjligheter som absoluta konstanter att förhålla sig till.

Bild 68: Adlibris.se på iPhone 5S.

Bild 68: Adlibris.se på iPhone 5S.

Bild 69: Adlibris.se på en skrivbordsdator. Fler kolumner för att fylla ut ledigt utrymme men i mångt och mycket samma design.

Bild 69: Adlibris.se på en skrivbordsdator. Fler kolumner för att fylla ut ledigt utrymme men i mångt och mycket samma design.

I många fall blir en webb enligt mobile first bättre även på skrivbordsdatorer jämfört med föregående webbplats då man tvingas prioritera vad man placerar på det begränsade utrymmet. Ofta är utseendet mer konsekvent mellan olika sorters enheter jämfört med responsiva webbplatser vilket kan underlätta för oss som använder flera olika sorters enheter varje dag för att surfa på webben.

Mobile first är att designen görs för den mobila skärmen, sedan om man har möjlighet och kan komma på vad man kan fylla på med på en större skärm så läggs det till. Lite som responsiv fast man börjar på den lilla skärmen och arbetar sig uppåt istället. Tittar man renlärigt på mobile first och responsiv webbdesign så är de egentligen inte konkurrenter, rent utav behöver en bra mobile first-webbplats vara responsiv för att fungera som tänkt på den uppsjö av mobila enheter webben besöks av.

Mobilens möjligheter

Det är många saker som talar till mobilens fördel för en användare av webben. Den viktigaste poängen är förstås att den går att ta med sig, att man kan fortsätta med något man höll på med när man väl stigit på bussen, betalat för sig och satt sig ner. Inte minst intressant är att alla mobiltelefoner har en massa sensorer och utrustning vi normalt sett inte har haft i datorer. En av de mest använda funktionerna är att geografiskt positionera mobilen vilket är fantastiskt användbart för karttjänster man kan bädda in i sin webbplats.

Praktiskt taget alla mobiler har sensorer för enhetens orientering och en accelerometer vilket gör mobilen medveten om sin omgivning. Det återstår att upptäcka en webbplats som gör något meningsfullt av detta men på rak arm kan jag tänka mig att om accelerometer anger mycket rörelse förenklas formulär, textstorlek ökar och andra användbarhetsjusteringar.

Vid det här laget är det lätt att glömma att en av de stora innovationerna med mobiler är att de har pekskärmar. Det medger en mycket mer intuitiv interaktion direkt med fingrarna istället för att man ska vänja in sig med diverse styrdon. Vad pekskärmarna kan användas till i förlängningen återstår att se men så här långt har det mest handlat om att göra interaktionen mellan användare och tjänst mer naturlig, bland annat genom att man i karttjänster enkelt kan rita ut ett område att söka efter lunchställen.

Det är mest fantasin som sätter gränserna för vad man använder kamerorna, gyroskopet, mikrofoner, ljussensorer, närhetssensorer och alla andra möjligheter till.

Mobilens begränsningar

Fakta:
Det mobila 4G-nätet täckte under 2014 cirka hälften av Sveriges yta, den snabbare versionen på 30 Mbit/sekund täckte endast 2 %.
Källa: PTS.

De begränsningar en mobil lider av kan sammanfattas till följande:

  • Skärmen är väldigt liten – jämfört med tidigare uppfattning om normal skärmstorlek visade de första mobilerna endast upp en femtedel så många pixlar. Nu finns större mobiler och högre upplösta skärmar men de är fortfarande mycket små jämfört med en skrivbordsdator.
  • Rörlig – rörlig som i att man har den i näven och fortsätter använda den även när man går in i ett skyddsrum under jord där man tappar kontakten med mobilnätet.
  • Sammanhang – tänk hur ergonomin är vid användning av en mobil, som ljusförhållandens påverkan på vilket kontrastförhållande som behövs för att läsa text och mycket mer. Man kan inte räkna med användarens odelade uppmärksamhet ens för en kort stund, inte ens hemma i tv-soffan då mobiler oftast används samtidigt som något annat pockar på uppmärksamhet.
  • Ofta på en sämre uppkoppling – om inte ett snabbt Wifi-nät eller 4G är anslutet så har en mobil ibland riktigt svårt att hantera många eller tunga filer för nedladdning.
  • Månatlig surfpott – en månatlig kvot för hur mycket trafik man får använda gör att användaren själv behöver hushålla med sin trafik och inte är särskilt villig att ta emot onödigt tungt material.

Begreppet offline first är något som man rimligen borde inbegripa i mobile first. Idén är att besökaren ska kunna tappa anslutningen till nätet och att det så långt det är möjligt ska gå att fortsätta använda webbplatsen. Mobilanvändare är vana att appar fungerar utan uppkoppling och det är säkert oftast baserat på att de data man använder finns som lokal kopia i mobilen. För dessa personer är det rätt ointressant huruvida de enligt en tekniker startade en ”native mobil app” eller klickade på ett bokmärke på mobilens hemskärm – det ska ju bara fungera. I ett mobile/offline first-scenario ska man inte betrakta en tappad anslutning som ett fel och meddela användaren att de är offline, istället ska man så långt det är ekonomiskt försvarbart se till att det fungerar att använda tjänsten även de stunder som uppkopplingen försvunnit.

Det finns massor med tillfällen man har svajig uppkoppling till nätet. Tänk åka tåg och tunnelbana, åka bil på kuperad landsbygd och alla andra situationer som inte kommer magiskt fungera över hela klotet inom den närmsta framtiden. När man har en uppkoppling är den ofta av en tveksam kvalitet vilket gör att det kan ta flera minuter att ladda hem en mindre genomtänkt webbplats, detta kommer vi gå igenom ordentligt i delen om webbprestanda.

The mobile moment – när mobilanvändarna är i majoritet

Fakta:
Under 2013 var det 25 % av de mobilsurfande amerikanerna som nästan enbart använde en mobil enhet. Endast i undantagsfall använde de något annat, exempelvis en skrivbordsdator.
Källa: Mobithinking

När det mobila ögonblicket, att majoriteten av ens besökare använder mobil, inträffar är olika beroende på vilka användare man har. I vissa fall har det redan skett och för några få kanske det aldrig kommer att inträffa.

I början av 2014 släppte Facebook statistik om att cirka tre fjärdedelar av deras användare besöker tjänsten via sin mobiltelefon. Mer häpnadsväckande är att nästan en fjärdedel enbart använder Facebook från en mobil. För oss som jobbar på kontor kan det vara lätt att tänka att folk fortfarande har en ”riktig” dator de använder flera timmar varje dag och bland annat surfar på nätet både för jobb och lite nöje. Även fast många är i den situationen är det värt att inte förutsätta att det gäller majoriteten av de man vänder sig till.

När är ditt mobile moment och är du redo? Om det tenderar att ta några år att bättra på din webbplats design så kanske det är dags att börja med mobile first redan nu.

SPA – Single Page Application

Med SPA är tanken att omedelbart få gensvar från en webbplats istället för det vanliga beteendet att en ny sida anropas för att sedan laddas in. Det sker löpande kommunikation, utom synhåll för besökaren, mellan webbläsaren och webbservern för att ladda in det material som utgör webbapplikationen. Används ofta på webbplatser med information som uppdateras löpande, exempelvis där det finns ett flöde av nya inlägg som ska laddas in utan att man ska behöva ladda om sidan för att se dem. Inte sällan designas dessa webbplatser lite så de påminner om installerade program på en skrivbordsdator snarare än en vanlig webbplats.

En annan vanlig SPA-funktion är att hela webbplatsen läggs ner som en lokal fil på enheten vilket ger rätt extrem prestanda samtidigt som man blir oberoende av uppkoppling till nätet. Utmaningen är att dessa applikationer ofta behöver kunna uppdateras, eller synkas mot, en central server emellanåt. Idag finns bra stöd för dessa tekniker tack vare HTML5 och specifikt Web Storage.

Begreppet SPA används nog mest i tekniska kretsar, men många av de senaste årens jättefunktionella mobilsajter, många med ett app-likt beteende, är egentligen vad som avses med detta begrepp.

Det SPA innehåller är en stor dos beroende till Javascript, ramverk med hjälpkod och tillägg i webbläsaren. Ett begrepp du säkert hört talas om är AJAX vilket är den kombination av möjligheter som sköter utbytet av data mellan servern och webbläsaren som klient. Detta baseras på att man använder API:er vilket gör det mer till en arkitekturell angelägenhet eftersom webbplatsen är att likställa med en app – ett fönster mot API:et. Det finns två varianter på hur information skickas till webbläsaren. Antingen skickas det som rådata, oftast i formatet JSON, från API:et eller så är det färdig HTML-kod som ska uppdatera innehållet på en viss del av webbplatsen. Exempelvis ett nytt mejl i inkorgen skulle antingen enbart innehålla strukturerad rådata som sedan med hjälp av Javascript-kod som körs i webbläsaren lägger till design som fetstil, radbyte etc. Annars kan ett nytt mejl skickas från servern till webbläsarna som HTML-kod vilket gör det färdigt att presenteras direkt i webbläsaren, det knuffas in överst i listan av mejl.

Utifall att man tänkt sig ha en mobil-app, eller externa användare av API:et, finns det anledning att välja att låta API:et lämna ut rådata då färdig HTML styr i detalj hur utseendet ska vara.

Många webbplatser har komponenter liknande det som utgör hela SPA-webbplatser. Vanligaste exemplet är nog de som erbjuder meddelandefunktion mellan besökare som befinner sig på samma webbplats likt det meddelandefönster man har på Facebook för att prata i realtid med andra användare. En annan vanlig SPA-liknande funktion är de listningar med innehåll där det fylls på automatiskt med innehåll likt en ström av information. För att erbjuda uppdatering av innehåll och direktkommunikation mellan användare på en webbplats används webbstandarder som WebRTC (Web-Realtime-Communication), WebSocket med flera för att tillföra funktioner som tidigare var omöjligt på webben – bland annat att upprätta en långlivad anslutning för realtidskommunikation direkt mellan klienter är lite av en nyhet på webben.

Trots att många tekniker runt omkring dig kommer fatta stort intresse om du nämner SPA finns det något väsentligt icke-tekniskt att ta med sig, nämligen att SPA är utmärkt för många mindre webbprojekt där man prioriterar snabbhet i användning och upplevd smidighet. SPA är också bra om man inte riktigt är säker på om det man gör ska kompletteras med en app vid ett senare tillfälle, då är en hel del av investeringen redan gjord i API:et som funkar oavsett vad det är för plattform som står för användningen.

Design för SPA-webbplatser

Bild 70: Webbtjänsten Netvibes var tidigt ute med SPA- funktionalitet som dashboards och sammanställning av datakällor.

Bild 70: Webbtjänsten Netvibes var tidigt ute med SPA- funktionalitet som dashboards och sammanställning av datakällor.

Även fast SPA till stor del handlar om vilken teknisk arkitektur man valt för att bygga upp en webbplats med har det funnits några gemensamma kännetecken när det kommer till ytan. De tidiga app-liknande webbplatserna byggde ofta en mobilplats samtidigt som webbkoden kunde paketeras till en riktig mobilapp. De såg därför ofta ut som första generationens iPhone-gränssnitt.

I takt med iPhones marknadsandel sjönk har designspråket blivit mer neutralt och gemensam nämnare för SPA-webbplatser är nu mer att de är väldigt lika appar i utseende och funktion. De ber ofta om att man ska lägga länk till webbsidan på hemskärmen på mobilen. Gör man det blir skillnaden mellan app och webb väldigt liten.

Bild 71: Många tidiga mobilanpassade webbplatser såg ut på detta vis. Designspråk som liknade iPhones gränssnitts- komponenter genom att använda ramverket jQuery Mobile.

Bild 71: Många tidiga mobilanpassade webbplatser såg ut på detta vis. Designspråk som liknade iPhones gränssnitts- komponenter genom att använda ramverket jQuery Mobile.

Förutom app-likheten har många SPA-webbplatserna också drag av att ge översikt över många olika saker, så kallade dashboards som hos tjänsten Netvibes. Detta applikationsbeteende gör att man som användare egentligen bara har en vy av webbplatsen snarare än den uppsjö av unika mallar för olika sorters innehåll man är van vid, något som kan vara både bra och dåligt.

Under senare tid har det vuxit fram många varianter på SPA-temat där man har en enda lång webbsida och länkar till olika sektioner med hjälp av sidintern länkning, inte sällan med evig skroll där nytt innehåll fylls på när man närmat sig botten på sidan. Det finns också gott om webbplatser som har en enskild sida som är SPA bland en massa informationssidor, själva applikationen är SPA resten är vanlig webb.

Bild 72: Hultafors webbplats beter sig som en mobilapp om man besöker webbplatsen via en mobil.

Bild 72: Hultafors webbplats beter sig som en mobilapp om man besöker webbplatsen via en mobil.

Utmaningar med SPA

I och med att det används så mycket Javascript och dynamik är inte en vettig sökmotoroptimering något man kan ta för givet. Ett vanligt beteende på en SPA-webb är att det bara finns en enda adress oavsett var man som användare befinner sig inom applikationen. Alltså finns det inte olika adresser att indexera till en sökmotor utan egentligen bara en startsida – detta gör webbplatsens innehåll i mångt och mycket osynlig för sökmotorerna och deras användare. Det finns sätt att lösa detta och vilket också ofta är nödvändigt för att få applikationen att fungera utan Javascript aktiverat i webbläsaren.

Samma problem med adressering drabbar också användare som tror att man kan kopiera allt i adressfältet och skicka till någon för att den personen ska se samma sak som man själv.

Något man bör ha i åtanke är att inte bryta de navigationskonventioner besökarna är vana vid. Exempelvis är det dessvärre vanligt att det inte blir som man tänkt sig när man backar i webbläsaren på SPA-webbplatser, ibland blir man utloggad men det kan lika gärna vara så att det inte händer någonting alls.

Om man strävar efter att göra sin SPA-webbplats funktionell offline behöver viss planering göras för att allt ska hinna laddas ner. Det finns troligtvis en prioritetsordning av vilket innehåll man helst vill ha offline om man inte kan välja allt. Risken är att det laddas ner väldigt mycket som aldrig kommer att användas, därför bör man överväga att ha text lokalt i enheten och senare ladda ner tyngre material om förutsättningarna är de rätta. Är det en långsam mobil uppkoppling är det läge att anpassa vad som laddas ner men på en publik webbplats bör man också tänka på att vissa besökare kan ha en månatlig trafikkvot att hushålla med.

SPA handlar mycket om att erbjuda den funktion som besökarens enhet klarar av, och har en del extra utmaningar inom feltolerans, vilket vi snart kommer gå in på.

Webbstandard och användbarhet

Ordlista – Användbarhet:
Ett mått på hur lätt det är att utföra specifika uppgifter med en produkt, på en webbplats eller annat ting. I webbsammanhang är det hur enkelt det är att förstå hur man interagerar med en webbplats – huruvida den är intuitiv eller inte.

Ordlista - Tillgänglighet:
Hur väl det fungerar för personer med någon form av funktionsnedsättning, exempelvis synnedsättning, motoriska problem, inlärningssvårigheter med flera.

Ordlista – Webbstandard:
Att följa öppna och inkluderande standarder och arbetssätt när man konstruerar en webbplats.

För att avrunda ämnet kring webbdesign tänkte jag gå igenom vad som är bra webb, att webbplatsen fungerar som det är tänkt. Det handlar om att det som publiceras ska vara användbart och följa etablerade standarder så långt som det är möjligt.

Webbstandard går ut på att det man bygger ska fungera för alla användare oavsett deras fysiska eller tekniska förutsättningar. Begreppet beskriver den ursprungliga filosofin om en öppen och inkluderande webb men också användandet av gemensamma standarder. Som motsatser till webbstandard kan nämnas kommersiella, eller proprietära, format som exempelvis Adobe Flash eller Microsoft Silverlight. Istället ska man använda sig av öppna format som exempelvis HTML5 med flera som arbetats fram som rekommendationer av W3C och andra trovärdiga arbetsgrupper. Man ska välja standarder som ställer så låga krav som möjligt.

Användbarhet handlar inte bara om användarvänlighet utan också om att tillföra något meningsfullt, ha ett syfte användaren förstår och accepterar. En första nivå för att sträva mot användbarhet är att se till att det man byggt fungerar på de enheter besökarna väljer att använda, att designa allt feltolerant då det finns stor variation bland besökarnas utrustning men fortfarande hålla sig efter webbstandard.

Progressive enhancement och graceful degradation

Ordlista – Progressive enhancement (PE):
Att utgå från att besökaren inte har den senaste tekniken, eller webbläsaren, alla tänkbara plugin utan istället erbjuda en grundversion som är bra nog även utan extra tillägg.

 

Ordlista – Graceful degradation (GD):
Design av system som när fel inträffar eller krav på användarens utrustning inte möts kommer inte allt att krascha. Snygg felhantering där man planerat för att fel kommer inträffa.

Progressive Enhancement (PE) är en designstrategi som framför allt annat prioriterar tillgänglighet, att koden följer en etablerad och väl utbredd standard snarare än att ge en häftig eller experimentell upplevelse. Det handlar om att erbjuda en stabil och förutsägbar webbplats utan extravaganser man lika gärna kunde varit utan.

Men i konceptet kring PE ryms även att när väl man fyllt grundbehovet är det helt i sin ordning att, under kontrollerade former, lägga till funktioner som enbart kommer gynna de besökare som har möjlighet att ta del av det. Med andra ord skapar man inte en undersida där de som inte har ett visst obskyrt plugin hänvisas till att ladda ner det, snarare ska det vara osynligt vad man går miste om. Ett typiskt exempel är den övergångstid när inte alla webbläsare hade fullt stöd för CSS version 3, då såg man till att designen fungerade utmärkt utan CSS3 men för de som hade stöd i sin webbläsare kunde de få se små förbättringar som runda hörn exempelvis. Det viktiga i sammanhanget är att inget designval får gå ut över den besökare som har en ”fattigare” upplevelse.

Om du läste delen om adaptiv webbdesign så såg du redan där tanken bakom PE, nämligen att krydda besökarens upplevelse med extra funktioner om dennes utrustning har stöd för det. PE brukar oftast handla om webbdesign med avseende på formgivning men det finns ingen anledning att strunta i att inkludera tankar som besökarens uppkopplingshastighet i PE – om riktigt snabb uppkoppling används kan man lika gärna strömma video i 4K Ultra HD för optimal kvalitet. Med andra ord kan man hävda att mobile first är PE då det utgår från en liten skärm och eventuellt lägger till material om det finns mer plats.

Bild 73: Javascript och CSS gör ett formulär mer hjälpsamt för de med moderna webbläsare.

Bild 73: Javascript och CSS gör ett formulär mer hjälpsamt för de med moderna webbläsare.

Graceful Degradation (GD) är på sätt och viss PE:s raka motsats då GD är att designa för den modernaste och mest optimala tekniska utrustningen besökaren kan ha i form av webbläsarens stöd för ny teknik. För att det ändå ska fungera i äldre utrustning bygger man in massor av feltolerans.

Ett sätt att tackla problemet med att vissa webbläsare (ja, Internet Explorer har historiskt sett varit den största syndabocken) inte har stöd för den senaste webbstandarden är att använda så kallad polyfill. Polyfills är lösningar för funktionalitet man har god anledning att tro att en viss webbläsare kommer att få stöd för i framtida versioner men för att det ska fungera i äldre versioner har man hjälpkod att falla tillbaka på. Exempel på detta är att stödet för SVG-bilder (Scalable Vector Graphics) är väldigt varierande och istället för att själv ta fram specialkod till varje webbläsares respektive version tar man hjälp av polyfills – i detta fall kanske Javascript-biblioteket Modernizr – för att få det att fungera. Säg att besökaren i fallet med en SVG-bild kör Internet Explorer 8 så kommer det polyfill man använder se om besökaren i alla fall har Adobe Flash, finns inte det ger man upp då IE8 inte klarar av SVG. Istället för att ge upp direkt när kraven inte möts försöker man på ett strukturerat sätt lösa bekymret med äldre utrustning.

Det är tydligt hur man ser på sin webbplats och vilka krav man ställer på sin besökare om man väljer GD eller PE. Behöver jag nämna att PE är en vidareutveckling av GD? Nej det och att jag föredrar PE lär du ha läst mellan raderna vid det här laget 🙂

Användbarhet kontra tillgänglighet

Två begrepp som på många sätt kan ses som samma sak, nämligen användbarhet och tillgänglighet är något som ofta tycks skapa huvudbry bland folk (jämför usability och accessibility på engelska).

Bild 74: Gissar att den som valde budskapet att man ska ta trapporna inte själv sitter i rullstol.

Bild 74: Gissar att den som valde budskapet att man ska ta trapporna inte själv sitter i rullstol.

Det mest populära sättet att skilja dem åt är nog att användbarhet handlar om webbplatsens ergonomi för en genomsnittlig användare inom din målgrupp. Ergonomi så de klarar av att exempelvis ta sig igenom en betalningsprocess i en webbshop. Tillgänglighet däremot drar mer åt att möjliggöra för så många som möjligt att använda en webbplats, även de med funktionsnedsättning. På tal om funktionsnedsättning så används ofta exemplet med blinda och deras nytta av tillgängliga webbplatser. Det är lite förrädiskt förenklande då tillgänglighet är något majoriteten av befolkningen har nytta av. Vi har alla nytta av en tillgänglig webbplats när vi är trötta, ute i starkt solsken med mobilen, hänvisad till något udda styrdon för muspekaren eller textversion av ljud när vi glömt hörlurarna hemma och befinner oss i en tyst miljö.

Det finns förstås hjälp att finna för hur man utvecklar en webbplats på ett tillgängligt sätt. Framförallt är det riktlinjerna från W3C:s WCAG (Web Content Accessibility Guidelines) man ska gå efter för att skapa tillgängligt webbinnehåll (se mer på www.w3.org/TR/WCAG/).

I all korthet kan nämnas att WCAG består av ett antal principer och riktlinjer för att göra webbinnehåll:

  • Möjligt att uppfatta.
  • Möjligt att interagera med.
  • Möjligt att begripa.
  • Robust, alltså möjligt att använda med olika webbläsare och hjälpmedel.

Att använda version 2.0 av WCAG är standard i skrivande stund. Det är till och med tal om att göra WGAC nivå AA, den näst högsta, obligatorisk för myndighetswebbplatser i Europa, åtminstone om man ska tro att förslaget på EU-direktiv på ämnet går igenom.

Under sommaren 2012 återlanserade E-delegationen ”Vägledning för webbutveckling”, på adressen www.webbriktlinjer.se, vilket ska vägleda offentliga sektorn att göra rätt men innehållet är väl värt en genomläsning för alla som håller på med webb. Läser du webbriktlinjerna i nummerordning kommer du se att den första talar om att webbplatsen ska klara av WCAG 2.0 nivå AA.

Oavsett om du är medveten om att din målgrupp består av folk med särskilda behov eller inte så är det viktigt att ha en god grundläggande nivå av tillgänglighet och användbarhet. Det uppmuntras av sökmotorerna, och jag antar att du vill ha trafik till din webbplats? Även om man inte prioriterar exempelvis blindas behov när man formger sin webbplats är det värt att tänka på att Google inte heller kan se, just för stunden kan Google inte heller höra. Om du inte bryr dig om att få besökare via sökmotorer eller inte har några anställda med särskilda behov som behöver nå intranätet är det väl bara att jobba på.

Tillgänglighet handlar om att ta hänsyn till människors varierande förutsättningar. En helt tillgänglig webbplats kan användas av personer med bredast tänkbara variation av egenskaper och förmågor, till exempel de med olika funktionsnedsättningar. Bland vanliga tillgänglighetsutmaningar finns exempelvis att text faktiskt är riktig text för en person med skärmläsare och inte en bild, att rubriker också i koden är rubriker istället för fet förstorad text, och att sidan har en sidtitel. Enkla grejer kan tyckas.

Användbarhet har mer med effektivitet och upplevelse att göra. En webbplats kan vara helt tillgänglig, men ändå inte särskilt användbar, om den till exempel är väldigt tidskrävande eller upplevs som irriterande. Din webbplats kan faktiskt vara användbar för person A men inte för person B samtidigt, om de har olika mål med sitt besök eller olika preferenser.

Ett sätt att få din besökare att hålla med om att webbplatsen är användbar är att designa den med spelmekanismer, så kallad spelifiering, då det ofta tillför en känsla av sammanhang till vad man försöker uppnå.

Spelifierad design

Spelifiering (gamification på engelska) är ett sätt att se på vad en användbar webb är, inte bara vad användaren ska klara av för att använda webbplatsen utan också förstå vad som behöver göras och varför. Spelifiering är en populär term som handlar just om detta – hur man använder spelmekanismer för att ge mening och struktur till en tjänst.

Det handlar inte bara om att jaga troféer, medaljer eller andra digitala utmärkelser utan är oftast ett sätt att vägleda en person genom en process eller motivera personen till att utföra vissa uppgifter. Det är utmärkt för att introducera nya och befintliga användare, men det behöver inte ha så mycket spelkänsla – kanske mer av naturlig tävlingsinstinkt och viljan att behaga.

Om du tänker dig att du utvecklat ett webbaserat system, var ska då introduktionen och hjälpen finnas till dina användare? I webbsystemet förstås! Det lärande som behöver göras är en digital guide som hjälper användaren att komma igång, ger tips, motiverar att fortsätta utforska och gör användaren trygg vid eventuella motgångar.

Spelifiering kan vara allt från ett fullständigt spel till att plocka några små delar där man uppger för sin användare vilka extra personuppgifter de behöver ange för att dra maximal nytta av en tjänst.

Saker som utmärker en tjänst som drar nytta av spelifiering är exempelvis:

  • Relationer – socialt sammanhang. Hur du förhåller sig till oss? Vilka andra är med?
  • Rörelsen – motivation till vad respektive aktivitet tillför individen utan att det varken känns som morot eller piska. Varför ska jag lämna ifrån mig min e-postadress och vad tjänar jag på det? Vad händer om jag låter bli?
  • Återkoppling – man behöver löpande få veta om man gör rätt sak och är på väg åt rätt håll. Uppgifter ska med andra ord brytas ner till så små aktiviteter att de är svåra att misslyckas med.
  • Lärande – hur gör man bättre ifrån sig nästa gång, finns något att förbättra?
  • Högre syfte – vad är det tjänsten går ut på och varför ska varje enskild användare engagera sig?
  • Belöning – lite lön för mödan kan komma i form av digitala varor som medaljer men lika gärna vara något som kan omsättas till den fysiska världen. Inte alltid ska resultatet belönas utan istället ansträngningen, här bör man lägga en del eftertanke så spelet inte automatiskt får haverister. En bra grej är att sätta ett uppnåeligt mål alla kan relatera till, när målet är nått är man klar. Ibland finns flera nivåer av belöning vilket ger extra spänning, likt lotterier, att se vad man får.
Bild 75: Linkedin listar tydligt i en anteckningslapp vad jag ska göra för att få mer nytta av tjänsten (2012).

Bild 75: Linkedin listar tydligt i en anteckningslapp vad jag ska göra för att få mer nytta av tjänsten (2012).

Bild 76: Linkedin med nytt försök att motivera användarna att lämna ifrån sig mycket persondata (2013).

Bild 76: Linkedin med nytt försök att motivera användarna att lämna ifrån sig mycket persondata (2013).

Bild 77: Cirkeln nere i högra hörnet bidrog till att 20 % fler uppgav fullständiga uppgifter jämfört med tidigare design (2014).

Bild 77: Cirkeln nere i högra hörnet bidrog till att 20 % fler uppgav fullständiga uppgifter jämfört med tidigare design (2014).

Några exempel på lyckade spelifiering-idéer:

  • Sociala jobbnätverket Linkedin.com fick 20 % fler av sina användare att fylla i alla viktiga uppgifter. Ändringen de gjorde var att med en cirkel ange hur komplett användarens profil var.
  • Mobiloperatören giffgaff låter kunderna stå för merparten av supporten till varandra. Kunderna får samtalsminuter som kompensation för sin insats. Bolaget har cirka 16 anställda för att ta de svårare problemen och annan administration. På detta sätt kan de hålla lägre priser till sina kunder som är mer aktiva än konkurrenternas kunder vilket säkert har fler fördelar.
  • Runkeeper, Nike, Jawbone, Fitbit och alla andra som gett vardagsmotion en social dimension där ens dagliga (in)aktivitet och delmål jämförs med vännernas. Social tävlan med målet att motionera mer, sova godare, äta nyttigare och peppa varandra.
  • EBay där man som säljare och köpare sätter betyg på varandra.
  • Slashdot som har ett karma-system för kommentarer på artiklar. Man måste göra sig förtjänt av karmapoäng. Först när man har poäng kan man rösta ned/upp på andras kommentarer. Många uppröstningar på ens kommentar gör att man förtjänar bättre karma. Endast de kommentarer som röstats upp visas som standard för besökare vilket ger ett självmodererande system.
Bild 78: Runkeeper uppmuntrar vid nästan varje aktivitet och har massor med delmål värda att fira.

Bild 78: Runkeeper uppmuntrar vid nästan varje aktivitet och har massor med delmål värda att fira.

Ett problem man kan ställas inför när man försöker dra nytta av spelifiering är att man fokuserar på vad man själv vill att användaren ska göra. Istället bör man fokusera på, och hjälpa till med, det användaren vill göra. Det du som spelsystemskapare gör är att skapa spelmekanismerna så de får spelaren att följa med, det går inte att plötsligt byta till en uppfordrande ton om vad spelaren måste göra. Vi är inte längre ett lydnadssamhälle, snarare har vi gått över till ett motivationssamhälle. Att bli skriven på näsan om vad man ska göra kan få motsatt effekt, bättre är förstås att fokusera på varför var och en vill göra något för sin egen skull.

Designa och planera för att fel kommer uppstå

Ordlista – 404-sida:
Den där sidan som visas upp för besökaren när den har gått till en adress där ingen sida finns. Det händer bland annat när en undersida tagits bort, besökaren stavat fel på en adress eller om ett fel i en adress smyger sig in vid trycksaker etc. 404 kommer sig av att det är statuskoden i protokollet för webben, HTTP, för att säga att sidan inte finns. Andra vanliga koder är 301 för att en sida flyttat till en annan adress och 200 för att allt gick enligt plan.
Mer på tba.nu/httpcodes

Nu ska man egentligen ytterst sällan hamna på en 404-sida, att man gör det så pass ofta beror delvis på avsaknad av respekt för besökarens bästa bland våra vänner som driver webbplatser. Om en sida på en webbplats inte längre är värdig att få vara publicerad, eller om en adress bryts, så skulle jag vilja påstå att det i nio fall av tio beror på något av följande:

  1. Sidan handlar om tidsbunden information, som en nyhet eller kalenderhändelse. Vanligt argument för att kasta dessa sidor är ”att ingen bör vara intresserad längre”, kanske ”men det hände ju förra veckan” eller att ”den tar upp onödig plats”.
  2. Man har bytt publiceringssystem och inte tagit med sig sina inarbetade adresser.Det tycks vara enkelt att glömma att de adresser man haft på sin webbplats har ett värde, inte minst:
    a) I besökarens bokmärken.
    b) Hos sökmotorer som inte kommer ge dig en guldstjärna för din nya fina sida då den är, just, ny.
    c) Via länkar till sidan från intranät, webbplatser eller i folks epostlådor som helt plötsligt kommer sluta fungera.
  3. Publiceringssystemet man valt hanterar inte adresser på ett bra sätt. Flertalet av de publiceringssystem jag sett har ett format på adresser att de återspeglar trädstrukturen webbredaktörerna har i själva publiceringssystemet. Den har sällan mycket med strukturen på webbplatsen att göra. Inte sällan ser man att en huvudsida får nytt namn på en mycket stor webbplats, då råkar alla undersidors adresser ha bytts ut.

Exempelvis:
www.exempelsida.se/kundtjanst/tjanster-till-dig-som-kund/lista-a-o/c/

Om man bestämmer sig för att det ska heta ”kundcenter” istället för ”kundtjänst” kommer alla dess undersidor att få nya adresser. En vettig URL-hantering är en av många saker att ha på kravlistan när man väljer publiceringssystem.

Helt klart finns det tillfällen då man inte kan ta hand om sin besökare och de måste hamna på en 404-sida. Då finns några enkla tips att tänka på vid sin utformning av 404-sidan, nämligen:

  1. Låt det inte undgå besökaren att sidan inte kan hittas, att ett icke-önskvärt fel inträffade.
  2. Se till att besökaren får ett utseende som liknar resten av webbplatsen, vilket ska inkludera logotyp, navigering, färg och formgivning.
  3. Ge förslag på sätt att gå vidare. Kan vara att lista de tio mest besökta sidorna eller om nu sajtens struktur framgår i adressen som gav 404-sidan kan man länka närmsta startpunkt. Ibland kan säkert en sökruta vara användbart.
  4. Skicka HTTP:s statuskod 404 till besökaren. Gör du inte det kan du räkna med att det straffar sig hos sökmotorer.

Gör man en bra, kanske till och med underhållande, 404-sida kan man förmildra den initiala besvikelsen som en besökare råkat ut för.

I de fall det går att peka ut en ny sida som ersätter den gamla ska så göras! Detta ska göras med en permanent hänvisning, en så kallad ”HTTP 301” på teknikspråk, eftersom alla alternativen är sämre.

Bild 79: En felkonfigurerad webbserver kan råka lämna så här oanvändbara 404-sidor.

Bild 79: En felkonfigurerad webbserver kan råka lämna så här oanvändbara 404-sidor.

Bild 80: Svensk mjölks 404-sida skiljer sig tydligt från webbplatsens övriga sidor och gör många rätt kring hur en sådan sida ska se ut.

Bild 80: Svensk mjölks 404-sida skiljer sig tydligt från webbplatsens övriga sidor och gör många rätt kring hur en sådan sida ska se ut.

Bild 81: Spotifys gulliga maskot hälsar att hen gärna sjunger för pengar. Sidan som sådan kan bli mer användbar.

Bild 81: Spotifys gulliga maskot hälsar att hen gärna sjunger för pengar. Sidan som sådan kan bli mer användbar.

Webb, mobilwebb, appar eller lite av varje?

Under överskådlig framtid kommer vi stå inför frågan om vilken paketering vår information eller tjänst ska ha. Idag är frågan oftast relaterad till huruvida det ska vara en app till mobiler eller om man ska ställa högre krav på sin befintliga webbplats.

Precis som många flyttat in sin information till sociala plattformar, för att det är där ens målgrupp redan befinner sig, kan lika gärna egna mobil-appar spela ut sin roll om mobilen blir plattformen för att starta ett fåtal tjänster. Jag skulle säga att det är däråt utvecklingen är på väg, det blir allt svårare och dyrare att få någon att ladda ner ens app även om den både är gratis och fantastisk. Däremot kanske det är en app inuti en större applikation man bör titta på – exempelvis erbjuder Spotify tredje part att lägga in ”appar” i deras app.

Användbarhetsgurun Jakob Nielsen menar i sin bok ”Mobile usability” att man bör ha en separat webbplats för mobiler, kanske rent utav en app för de mer frekventa användarna och den typ av användning de har. Det är den slutsats man drar om det endast är användbarheten som är viktig. Samtidigt dödförklarar han att bygga webbplatser som fungerar för de mer enkla mobiltelefonerna, så kallade feature phones, då användbarheten ändå är så fruktansvärt dålig.

Bild 82: Kul uppdatering för de som pratar italienska eller polska, men för majoriteten var det en rätt onödig information.

Bild 82: Kul uppdatering för de som pratar italienska eller polska, men för majoriteten var det en rätt onödig information.

Där appar däremot briljerar är där webben i många fall inte ens försöker konkurrera, spelprestanda på en mobil exempelvis. I viss mån har det historiskt sett varit lättare för de med funktionsnedsättningar att använda appar istället för att ge sig in på webben med mobil webbläsare. Fördelen appar hade tidigare med att redan vara nedladdade och klara sig utan kontakt med mobilnätet är något som även vanliga webbplatser blir allt bättre på.

Appar av idag har en del utmaningar jämfört med webben. En webbplats har man som utgivare full kontroll över och behöver inte oroa sig för att ens kunder använder olika versioner där vissa inte fungerar. Finns ett fel på webbplatsen fixar man det för alla och det är inte en obligatorisk notis till samtliga användare att man nu bättrat på stödet för det fåtal som har isländska som modersmål. Appar behöver dessvärre installeras innan man kan ta del av innehållet vilket är lite som att lägga hinder runt entrén till affären.

I mitt tycke är det väldigt svårt att argumentera för att sänka sina krav på sin webbplats, eller att låta bli att ha en, och istället fokusera på en app. Appar har så här långt haft väldigt dålig transparens via webbens sökmotorer vilket gör att man gömmer sitt innehåll i en behållare som är svår att finna jämfört med en vanlig publik webbplats. Appar är något som kan komplettera en webbplats och göra vissa specifika uppgifter mer användbara än vad som är lönt att göra på webbplatsen. I de flesta fall slipper man inte göra en webbplats och ska man ändå ha en webbplats är det dumt att göra en som stöter bort besökare på grund av att man gjort ett halvhjärtat jobb.

Stirra dig inte blind på mobiler

Ditt mobila ögonblick kanske aldrig kommer. Istället kan det vara så att andelen besökare med Playstation 4 behöver din uppmärksamhet och att du förlorar besökare på grund av att det du erbjuder inte fungerar bra nog på en större tv-apparat. Att utgå enbart från sin statistik för att utesluta vissa besökargrupper är som att planera en bilbro baserat på hur många som simmar samma sträcka.

Har du testat att navigera på din webbplats med en handkontroll till Playstation?

Bild 83: Besökare till 1177.se under 2011-2012 där mobil/tablet-trafiken femdubblades på två år.

Bild 83: Besökare till 1177.se under 2011-2012 där mobil/tablet-trafiken femdubblades på två år.

Exemplifierat med vårdwebbplatsen 1177.se ökade antalet mobila besökare varje månad under 2011 och 2012. Andelen varierade lite då trafiken från skrivbordsdatorer beror ganska mycket på hur lyckade de olika informationskampanjerna blev. Årsskiftet 2012-2013 använde ganska precis hälften av besökarna en mobil eller surfplatta för att besöka webbplatsen.

När tror du att 1177.se blev responsiv eller mer användbar i mobilen? Den responsiva versionen släpptes under våren 2013 efter månader av förberedelser. Då använde redan en majoritet av besökarna en enhet med touchskärm, cirka 42 % mobil och 10 % surfplatta. Med tanke på hur snabbt användarnas beteende kan förändras är det oerhört viktigt att man hänger med i förändringarna och kan göra små justeringar löpande för att möta upp besökarnas förväntan. De stora webbprojektens tid är förbi, nu gäller det att släppa sina förbättringar i en stadig ström.

Din webbplats är ett magasin, inte en bok!

Det den här boken tagit upp kring utformning av en webbplats, och bakomliggande informationssystem, är visserligen mycket mer än ett skrapande på ytan men det är först nu när jag skrivit ner dessa sidor jag ändå insett hur mycket det är att tänka på. Men ska jag ändå välja ut en enda sak kring utformning av webbplatser som är viktigare än allt annat så är det att från första början vara beredd på att göra många justeringar av webbplatsen. Det handlar verkligen inte om att vart femte år fräscha upp designen och all tid däremellan fokusera på att producera bra innehåll. En webbplats är inte heller i detta avseende en statisk trycksak då trycksaker är något som försvinner in i glömskan på ett bättre sätt än en hopplöst utdaterad webbplats som är allt för lätt att snubbla över. Varje webbplats bör vara mer av ett magasin som kommer ut i ny upplaga varje månad.

I detta ingår förstås kontinuerlig webbdesign. Man bör inte tvingas till att ha ett omdesign-projekt över huvud taget för att designen känns gammal, eller att man efter 2 års spänd väntan till sist har en majoritet mobila besökare och då skyndar fram ett responsivt utseende. Allt detta är något man kan göra löpande och jobbar man enligt en agil projektmetodik, exempelvis Scrum, bör det inte ens vara en särskilt stor omställning att i varje sprint faktiskt släppa ny kod ut på den skarpa webbplatsen. Mellan dessa publiceringar designar man tester för att avgöra om kommande förbättringar verkligen är förbättringar, följer upp tidigare aktiviteter och ser till att planera för nästa iteration.

Kontinuerlig webbdesign har fördelen att återkommande besökare känner igen sig vid varje besök då respektive ändring är ganska liten. Man behöver en huvuddesign dokumenterad med de vanligaste grafiska elementen, det som sedan saknas när man bygger nytt uppfinns vid behov och testas på riktiga besökare med hjälp av A/B-tester.

Liknelsen med ett magasin ger också att man löpande måste jobba med innehållet, vårda det man har och producera nytt. Därmed bör förhoppningsvis färre få för sig den dåliga idén att ge upp sitt innehåll och börja på ny kula – oavsett om man byter publiceringssystem eller inte. Det är som att redaktörernas verktyg för att producera innehåll har ett stryptag på den synliga webbplatsen. Man ska förstås inte prioritera redaktörernas verktyg framför sina besökares behov. Därför är det viktigt att man konstant är beredd att byta publiceringssystem så att man inte fastnar i något systems proprietära standard vilket i framtiden går ut över besökarnas upplevelse.

Ordlista – Djuplänkar:
Länkar från andra webbplatser till sidor som ligger en bit bort från startsidan på din webbplats. Det vill säga inte din startsida, de sidor som länkas från startsidan eller i huvudmenyn. Dessa länkar är värdefulla signaler till sökmotorer då de pekar på kvalitativt innehåll någon annan än webbplatsägaren uppskattar.

Ett typiskt exempel som nu till sist tycks vara ur världen är att publiceringssystemen tenderat att vilja bestämma hur adresserna skulle se ut på den publika webben – när man sedan ska byta system bryter man samtliga av de ovärderliga djuplänkar man samlat på sig.

Genom att webbplatsen är i konstant förändring har man bättre beredskap för incidenter och alla inblandade har mer av lösningens intrikata detaljer i närminnet. Samtidigt är det en mindre sak att då kontinuerligt få tekniska uppdateringar vilket ibland betalar sig omgående när ett säkerhetshål drabbar den plattform man använder.

Din webbplats är alltid under konstruktion, eller borde åtminstone vara det. Ha en utvecklare, webbdesigner och gränssnittskodare lätt tillgängligt. Precis som man inte vinkar adjö till marknadsavdelningen mellan varje marknadsföringskampanj bör man hålla sin webbkompetens nära till hands.

Fortsätt läsningen i kapitel 4 – om webbprestanda ›

Hoppa till andra kapitel