Responsiv webb

Att välja typsnitt till den responsiva webbplatsen

Typsnitt har genom alla tider väckt mycket känslor. De är en stark bärare av ett kommunikativt budskap och det är inte konstigt att kända varumärken använder typsnitt som sin främsta identitetsbärare genom sin logotyp. Ericsson gör det, IKEA gör det, Coca-Cola gör det, Disney gör det och så vidare.

Men hur ska man tänka när det kommer till typsnitt på den egna webbplatsen? Gäller fortfarande de standarder som var aktuella runt år 2000 då de flesta valde Arial eller Verdana till sin webbplats? Och hur ska man tänka kring den responsiva webbplats som ska kunna läsas från en mängd olika digitala enheter så som mobil, surfplatta, smartphone, smartTV och spelkonsollen?

En sak att fundera på vad gäller den responsiva webbplatsen är att sajten behöver ladda snabbt. Hur påverkas då den responsiva webbplatsen av olika typsnittslösningar?

Nedan redogör jag för några tankegångar, för- och nackdelar och ger förslag på olika lösningar. Jag avslutar också med ett test där jag tittar på hur snabbt en sajt laddar med olika typsnittslösningar (standard och en onlinetjänst).

STANDARDTYPSNITT FÖR DEN RESPONSIVA WEBBPLATSEN

Din webbplats ska kunna läsas från en mängd olika enheter så som mobil, desktop och surfplatta. Om du vill välja bland standardtypsnitt som kommer att finnas installerade på dessa enheter kan du välja på följande i listan:

  • Arial/Helvetica
  • Courier/Courier New
  • Georgia
  • Times/Times New Roman
  • Trebuchet MS
  • Verdana

Dessa anses vara mobilsäkra typsnitt. Äldre versioner av Android kommer dock att byta ut serif fonts till Droid Serif och sans-serif till Droid Sans.

FÖRETAGETS EGNA TYPSNITT

Med tjänster som https://typekit.com/ har vi länge kunnat erbjuda företagets egna typsnitt på webbplatsen. Typekit är en onlinetjänst där man prenumerar på ett typsnitt som då läses upp på den egna webbplatsen. På så sätt behöver besökaren inte ha det specifika typsnittet installerat på sin dator för att få se det på webben (eller i mobilen).

Ett annat alternativ är också att lägga upp det egna typsnittet på webbservern och låta webben läsa därifrån. Oavsett tillvägagångssätt finns det både för- och nackdelar.

Prenumeration på en onlinetypsnittstjänst kostar en liten summa, men du kan aldrig vara säker på att tjänsten är uppe och rullar 24-7 eller att det inte blir någon delay på typsnittsrenderingen på din webbplats. Speciellt problem med å,ä och ö kan uppstå emellanåt.

Att lägga typsnittet på sin egen webbserver är då lite säkrare men å andra sidan kan det vara kostsamt att köpa loss ett typsnitt för detta ändamål.

Ett alternativ till ovanstående är att välja ett typsnitt från http://www.google.com/fonts (en gratis prenumerationstjänst från Google) och primärt köra det som en onlineprenumeration med fallbacklösning på den egna servern. Man kan alltså ladda ner typsnittet och lägga upp det på den egna servern. Dock bör man kolla på rättigheterna och i de flesta fall kreditera fontdesignern på sin egen webbplats.

MEN TILLGÄNGLIGHETSASPEKTERNA DÅ? ”GOD LÄSBARHET PÅ WEBBEN”

Vilket typsnitt är egentligen lättast att läsa på skärmen? Detta är en omdebatterad fråga och det beror på vem du frågar, i vilket land du ställer frågan och vad läsarna är vana vid sedan tidigare. Det beror inte bara på typsnittets form utan också på storlek, avstånd mellan bokstäverna, färgval, hur lång texten är etc. Det finns många aspekter att ta hänsyn till.

Ett förslag är att välja ett vanligt standardtypsnitt till brödtexter men våga leka lite med rubrikerna. Korta rubriker kan absolut fungera med ett specifikt framtaget företagstypsnitt men det bästa är förstås att testa detta på användarna innan man bestämmer sig.

Webbriktlinjerna eller WCAG 2.0 säger inget om vilket typsnitt som ska användas mer än att det ska vara god läsbarhet.

HUR PÅVERKAS DEN RESPONSIVA WEBBPLATSEN AV OLIKA TYPSNITTSLÖSNINGAR?

Vi vet att en responsiv webbplats ska kunna besökas från många olika enheter och att laddningstiden kan ha stort effekt på upplevelsen. En webbplats har ungefär 4 sekunder på sig att väcka en besökares intresse. En webbplats som besöks via mobilen kanske mindre än så. Hur påverkas då laddningstiden beroende på vilka typsnitt vi använder? Är det skillnad på om typsnittet finns installerat i besökarens digitala enhet eller inte.

Svar ja, det är stor skillnad! Tänk på en hel webbplats med script, grafik, dataanrop etc. som allt ska summeras till den totala laddningstiden. Är det då värt det lilla extra att krångla till det med unika typsnitt? Kanske – om typsnittet är så tungt för varumärkets totala identitet. Men det tål ju att tänkas på.

Här är resultatet av mina tester: 

Test 1

Standardtypsnittet Arial på både rubrik och brödtext. Typsnittet finns installerat på besökarens enhet.

Laddningstid: 140 msk

Test 2

Googles onlinefont (som att prenumerera), Roboto Condensed på rubrik, Lato på brödtext

Laddningstid: 730 msk (!)

Test 3

Kombination av Googles onlinefont och standardtyspnitt, Roboto Condensed på rubrik och Arial på brödtext

Laddningstid: 336 msk

 

TAKE AWAYS

  •  Välj ett typsnitt som ger en skön läsupplevelse, fråga gärna användarna
  •  Egna typsnitt påverkar hur snabbt sidan kommer att ladda
  •  Välj ett standardtypsnitt som är mobilsäkert för brödtexten
  •  En kombination av eget typsnitt på rubriker och standard på brödtext kanske räcker för att ändå bära upp varumärkets identitet

BRA LÄNKAR

http://www.webpagetest.org/ (testa hur snabbt en sida laddar)

http://developers.google.com/speed/pagespeed/insights/ (få tips på vad du kan göra för att förbättra laddningstiden på din sida)

http://www.webbriktlinjer.se/r/39-ge-webbplatsen-en-god-lasbarhet/ (om riktlinjer för god läsbarhet)

Mobilanpassa din responsiva webbplats, på riktigt

Responsiv design stod högt på företag och organisationers ”att göra”-lista 2014. Enligt Web Service Awards trendrapport från 2014 fanns planerna att göra om var fjärde Svensk webbplats till responsiv design.

Med idén om responsiv design gick det en lättnadens suck genom webbsverige. Ett tämligen okomplicerat och enkelt sätt att, rent kodmässigt, anpassa innehållet efter den skärmstorlek som besökaren använde sig av för att konsumera innehållet. Addera en mobilanpassad meny och så är det klart, eller?

Hur bra blev det egentligen? Och vad var det som gick fel?

Låt oss backa bandet.

När responsiv var ungt

Att anpassa innehållet efter skärmstorlekar är ingen ny teknik. Detta gjorde vi redan runt 2000 när vi byggde intranät för företag som ännu inte hade någon policy om vilka datorer som skulle få köpas in (dvs. ingen enhetlig skärmstorlek som gällde generellt på företaget). Det vi använde oss av då var flytande innehåll som delades upp i procent. Eftersom man ännu inte hade kommit på konceptet med de fantastiska puff- och högerspaltsutfyllarna så fanns det inte så mycket layout att anpassa sig till. Därför fungerade teknik för flytande innehåll hyfsat bra.

Termen responsiv design kom 2010 när Ethan Marcotte skrev ett blogginlägg om webbtekniker för olika enheter – flytande layout, flexibla bilder och media queries. Ett bra sätt att anpassa innehåll och layout efter vilken skärmstorlek som besöken kommer ifrån.

Men det fanns redan då en omognad i sättet att se på responsiv design eller responsiv webb – det är först och främst en teknik – inte ett mål i sig.

Varför blir det fel med dagens responsiva webbplatser?

Jag har de senaste åren läst åtskilliga kravspecifikationer, anbuds- och offertförfrågningar med ett kort stycke om ”Responsiv design”.

Kravet ser ofta ut så här: ”Responsiv design – Webbplatsen ska byggas med responsiv design och fungera på mobil, surfplatta och desktop”. That´s it!

Jag vill inte raljera, jag fattar vad kunderna är ute efter, men det blir så fel redan från början när kraven ställs på det här sättet. Oftast har man heller inte budget för att titta på sitt innehåll utifrån ett mobile first-perspektiv, utan befintligt innehåll ska enligt kraven migreras över i en ny lösning. Vilka problem har vi då egentligen löst för användarna? För handen på hjärtat – det är väl för användarna vi gör det – inte för tekniken?

Vad användarna (vi) vill ha

Enligt Gartner kommer mobilsurfningen att ha gått om desktop surf 2018.
Du ser redan nu trenden i ditt eget användande – du besöker webbplatser med mobilen och använder appar för olika bankärenden och tjänster. Datorn blir allt mer ett arbetsredskap som det en gång i tiden var. En god vän till mig sa nyligen att ”jag använder mest datorn för ordbehandling och göra presentationer och tar sällan fram datorn hemma”.

Men… ”Dina användare skiter i om din webbplats är responsiv” Brad Frost

Vad våra användare vill ha är något som är snabbt och enkelt att använda oavsett vilken situation de befinner sig i och oavsett vilken skärmstorlek de vilar ögonen och fingrarna på.

Några problem med dagens responsiva webbplatser (responsiv design)

• Sajten är framtagen utifrån ett tydligt tekniskt perspektiv där målet är ”responsiv design”
• Sajten är inte testad fullt ut med olika enheter, skärmstorlekar, laddningstider, situationer etc. (Läs gärna mitt blogginlägg om att testa responsiva gränssnitt)

• Innehållet har migrerats från en gammal webbplats med totalt avsaknad av mobilt fokus

• Navigeringen är helt svettframkallande och ångestladdad – man har ingen som helst aning om var i strukturen man befinner sig på webbplatsen när man surfar på mobilen

• Tryckytor är alldeles för små liksom länkar ligger för tajt mot varandra. Man trycker fel, svettas lite till, går tillbaka till startsidan via logotypen och börjar om, trycker fel och skiter i det..

• Bilder/ikoner är tunga och äter både tålamod och skapar frustration. Jag bryr mig helt enkelt inte om stora branding bilder i motljus i karuseller med nonsens text på. Men det kanske bara är jag!

• Bilder – igen – de flesta mobiler och många datorskärmar för den delen har retina skärmar. Du vill inte ha suddiga bilder på din sajt, fixa dem men komprimera och optimera bilder för snabb laddning.

• Snabba laddningstider och tillgänglighetsfokus är något som lyser med sin frånvaro. Tänk rätt från början. Testa testa testa. Både med användare och vedertagna verktyg.

• Script och CSS:er till förbannelse – rensa upp! Mobila enheter kommer att läsa in ALLT även om detta är kodkommentrerat som ”ska ej visas på skärmstorlekar under 480”

• Inbäddat innehåll – vart ska jag börja? Har du någon gång testat att scrolla på en mobil som har en inbäddad karta från Google maps.. hur funkar det tycker du?

• Inte allt innehåll är responsivt – nä precis. Vid en test av myndigheters webbplatser ser det ganska bra ut på ytan men när man sedan försöker att ansluta till en tjänst via mobilen visar det sig att det man kom dit för att göra från första början inte alls är responsivt eller tillgängligt via mobilen.

Slutsats

Mobilanpassa din responsiva webbplats! Utgå från besökaren, din målgrupp och anpassa innehållet, funktioner och formgivning utifrån att webbplatsen kommer att konsumeras från olika skärmstorlekar, olika webbläsare, olika enheter, i olika situationer, med olika prestanda och uppkoppling, utifrån olika behov och förutsättningar.

Navigationskoncept för responsiva webbplatser

Hur svårt kan det vara? Det finns ju många snygga och responsiva navigationskoncept att inspireras av på nätet. En snabb sökning på Google ger drygt 4 miljoner träffar. Den ena vackrare än den andra. Menyer som följsamt och stilfullt animerat åker in från sidan och öppnar sig som en lotus blomma i dagsljus.

Kolla t ex in den här , den här  och den här (minska fönstret under 480 pixlar)

Problemet är just det. Att navigationskoncept ofta är sprunget ur formgivning och tekniska funktioner. Konceptet för den lilla skärmen har ofta tagits fram från hittepå innehåll och har lite förankring i verklighetens innehåll. För vad händer när du puttar in allt innehåll från en kommunwebb eller annan innehållsrik webbplats i den responsiva menyn? Hur upplever användarna att det är att navigera sig runt på webbplatsen i mobilen? Ofta ganska frustrerande.

Typiska problem som användare har när de navigerar på en webbplats i mobilen

• Hur hittar jag menyn? Alla är inte förtrogna med tre strecks-ikonen (aka hamburger-ikonen) som ska symbolisera en innehållsmeny längst upp till höger eller vänster på skärmen.

• Tryckytorna är för små och länkarna ligger för nära varandra. Användaren trycker och hamnar på helt fel sida.

• Typsnittet är inte responsivt och anpassas inte för skärmen. Texten är för liten och radbryter heller inte vid långa ord utan spänner över visuella avskärmingar. Får det att se rörigt ut.

• Var befinner jag mig i strukturen? Formgivningen tar lite hänsyn till att hjälpa användaren att förstå var hen befinner sig på webbplatsen.

• Låååååånga listor med innehållslänkar. Scrollning i långa banor innan man hittar rätt.

• JavaScript som förvisso gör menyn cool och snygg segar upp hela navigeringskonceptet och får menyn att ladda långsamt och med viss hackig fördröjning.

• Är sidan borttagen? Man har av någon anledning valt att dölja vissa sidor för mobilsurfarna som hen kommer åt via desktop.

Varför blir det så här?

När vi separerar innehåll från teknik och formgivning missar vi en stor del av användarperspektivet. Vi behöver göra användartester med målgruppen på det faktiska innehållet, veta att lösningen passar dem. Det blir också ett problem när vi ”designar som alla andra gör” – det klassiska – att titta på andra, inspireras och göra exakt samma sak utan att veta om det verkligen är den bästa lösningen.

Hur kan vi göra?

Involvera dina användare i framtagning av navigationskoncept för din responsiva webbplats. Testa, skruva, testa, skruva, arbeta med detaljerna. Tänk på tillgänglighet och prestanda. Våga designa med dina användare i fokus, jag slår vad om att ni tillsammans kommer fram till en lösning som är 10 gånger bättre än reklambyråns.

7 Tips för navigationskoncept för responsiva webbplatser

1. Använd gärna ord som Meny eller Innehåll i kombination med hamburger-ikonen (om du av någon anledning bara MÅSTE ha den).

 

2. Gör tryckytor minst 44 pixlar så att det blir tryckvänliga och öka avstånden mellan länkar till det samma.

 

3. Använd ett responsivt typsnitt och öka textstorleken i mobilen till minst 16 pixlar som standard på brödtext. Testa hur rubriker flödar på webbplatsen och att de inte sticker utanför skärmen

Läs Techniques for Responsive Typographic

4. Visa tydligt i menystrukturen var besökaren befinner sig på webbplatsen. Om användaren stängt menyn och öppnar den se då till att den scrollar ner automatiskt till den sida som användaren befann sig på, så att hen inte behöver leta.


5. Testa prestanda och komprimera JavaScript för snabb laddning.

Google Page Speed

6. Ta dig en extra funderare på varför du skulle plocka bort sidor för det lilla fönstret som återfinns på desktop.

Läs Not your only strategy

7. Testa med riktigt innehåll och tillsammans med användarna.

Läs Användningstesta responsiva webbplatser

Att användningstesta responsiva webbplatser

Att göra användningstest på responsiva gränssnitt innebär att testa funktion, design, innehåll, navigering och teknik på olika typer av enheter och skärmstorlekar.

Förberedelser Inför testning bör du tänka på följande:

· Identifiera målgrupper att testa på. Vilka är mest prioriterade?

· Hitta personer inom målgrupperna genom rekryteringsbyråer, egna nätverk, företagslistor eller t ex sociala medier

· Förbered någon form av ersättning till deltagarna för att visa uppskattning t ex presentkort eller biobiljetter

· Definiera omfattning av testerna, vilka delar ska vi fokusera att testa på? Förslagsvis de områden som ger mest affärsvärde och värde för besökaren.

· Identifiera vilka skärmstorlekar testarna ska utföras på samt vilka webbläsare.

Olika sätt att genomföra tester

· Mäta och observera användbarhet genom hur snabbt och effektivt nya besökare använder webbplatsen. Var och när kommer besökaren i kontakt med trösklar och var i flödet/innehållet/navigeringen uppstår problem?

· Subjektiv bedömning genom aktivitetsdriven testning som dokumenteras. Var klickar användaren någonstans? Och varför? Ställa frågor om navigering, upplevelse och funktionalitet.

· Inspelning av testning där användaren har olika uppgifter som ska utföras enligt ett givet flöde. Kan utföras lokalt eller på distans där skärmen och besökarens reaktioner spelas in.

Utformning av testplan för att få den feedback du vill ha

· Ta fram en testplan där du undviker partiskhet och förutfattade åsikter om din webbplats. Vi alla har dem!

· Utforma användningssenarios som är baserade på de kritiska affärs- och effektmål som du satt upp för din webbplats. Senarios kan t ex vara: utforskande aktiviteter med tydliga avslut eller med helt öppna avslut samt direkta uppgifter som ska utföras.

· Ta fram riktlinjer för testerna. Hur ska vi dokumentera och uppföra oss som testledare och observatörer?

Under testerna

· Testa inte isolerat, bjud in observatörer t ex från kunden som kan sitta med när testerna utförs

· Förbered användaren och introducera hen till hur du kommer att utföra testningen. Påpeka gärna en gång för mycket att det inte finns något som är rätt eller fel när testerna utförs.

· Ställ inte allt för ledande frågor under testerna. Om det dyker upp en fråga eller påstående från en användare svara: Intressant, vad tror du själv? Eller hur uppfattar du själv det med texten på den här knappen?

· Ta noteringar i strukturerad form. Skriv ner kärnfrågor och nyckelord under testningen, du behöver inte skriva ner allt. Sammanfatta testerna direkt efteråt, vi glömmer så lätt!

Analysera resultatet

· Använd kvantitativ data för att lokalisera problemområden och trösklar

· Värdera hur omfattande ett upptäckt problemområde är — Enkelt att åtgärda? Svårt, stort och komplex att åtgärda?

· Ta fram och visa exempel på hur problemen kan åtgärdas. T ex kan det vara hur andra webbplatser löst liknande problem. Du kan också ta fram rena koncept och formskisser med förslag till problemlösning.

· Iterera gärna resultatet med användarna. Har du uppfattat deras återkoppling under testerna korrekt? Något som behöver justeras?

Presentera resultatet

· Presentationen bör innehålla en beskrivning av uppdraget och dess upplägg och metodik. Vidare bör du redogöra för hur du kom i kontakt med målgruppens representanter och vad som inkluderas i testplanen och vilka frågeställningar som var aktuella under testningen.

· Visualisering från testerna — Visa med film, bilder och illustrationer hur testningen gick tillväga och reaktioner från användarna.

· Vid presentationen är det viktigt att fokusera på kärnområden som behöver extra kärlek för att leva upp till affärs- och användarmål. Visa gärna citat från användare.

· Visa förslag på lösningar och tänkbara flöden.

· Även om kunden inte efterfrågar det — ge förslag på nästa steg och hur man kommer vidare efter att leveransen är godkänd.

Var snäll

· Det finns ingen anledning att agera bad cop och utsätta användarna för tunga, svåra uppgifter på webbplatsen som ändå inte är ett tänkbart senario. Var lyhörd, nyfiken och ställ intresserade frågor. Visa att du bryr dig om din testperson och uppriktigt är spänd av förväntan på hens feedback.