Del 2: Analytisk vinkel på design, ydeevne og indhold

Som webstedsejer eller indholdsproducent kan en stilguide være det naturlige sted at dokumentere den kommunikative stil, man har til hensigt at bruge i digitale sammenhænge. I stilguiden rummes også andre ting, som organisationens webretningslinjer, designmønstre, ydeevnebudget og meget mere. Hvor den grafiske profil slutter i digitale sammenhænge, tager stilguiden over. Som for eksempel at kravstille interaktion, noget der kaldes for et ydeevnebudget.

Et ydeevnebudget er stedet, hvor man sætter sit minimumsniveau, altså hvilken standard man mindst vil holde på sit websted. Dette niveau kan dække hvad som helst, du vil definere for, hvordan webstedet skal præstere. Et par få overskridelser af dette budget er ikke noget at hidse sig op over, men samtidig skal projekter ikke gennemføres i strid med det budget, man har sat op.

Jeg indser, at jeg kan have brug for at forklare, hvordan design hænger sammen med analyse og opfølgning i almindelighed. Grunden til, at denne del er værd at betragte, er, at hvis man ikke har et konsekvent eller bevidst design og kravstilling, bliver det sværere at udelukke designfaktorer som støj i sine indsamlede data. For eksempel kan man spørge sig selv, hvor meningsfuldt det er at teste en ny farve på call to action-knapper, hvis man allerede er meget inkonsekvent.

Hvis man hverken følger designkonventioner, som brugerne har lært sig, eller selv er konsekvent i sit eget design, gør man ikke det bedst mulige ud af brugeroplevelsen. Det bliver også svært at følge op på, hvordan webstedet præsterer. Det er grunden til, at en webanalytiker bør interessere sig i hvert fald en lille smule for designspørgsmål i store træk og indimellem være lidt spørgende omkring grafiske detaljer inden for formgivning.

Min egen arbejdsgivers websted havde frem til 2016 masser af forskellige måder at formgive links på. Jeg ved ikke, hvor mange der var i det oprindelige layout, men det blev flere og flere over tiden. Antageligvis skyldtes dette, at der manglede styring i designspørgsmål. Den styring, der fandtes, gik ud på, at man ikke måtte placere links i brødteksten. Indimellem var et link understreget, mens linket i kolonnen ved siden af ikke var det. Det skete også, at links i lister havde et farverigt ikon ved siden af, men indimellem bestod de af almindelige punktlister. Visse links var sorte, andre var blå, hvis de da ikke var hvide. Det, der skete, når man førte musen over et link, varierede også, indimellem fik de links, der manglede understregning, tildelt en sådan, men det var ikke noget, man kunne regne med. Udover de billeder, der var klikbare, kunne links have tre forskellige farver, have fed skrift eller normal tekst, indimellem overskrifter, eller være understregede. Linkede billeder var ligeledes en blanding af alt muligt, dels det dengang almindeligt forekommende flade design, men indimellem en form for billede med skyggeeffekt bagved - såkaldt skeuomorfisk design, altså det der efterligner, hvordan en fysisk pendant kan tænkes at se ud.

: Billede 21: Et udpluk af links fra startsiden på vgregion.se, mange forskellige udseender, ikke altid tydeligt hvad der er et link (2015).

Ved næste redesign, i 2015, greb vi chancen for at forsøge at begynde at styre designet, og Västra Götalandsregionens stilguide var født. Som sædvanligt udgivet med fri licens, så andre kan lave en kopi og tilpasse den efter egne behov.

Det vi ofte finder i en stilguide er sprogretningslinjer, som tips om længde på sætninger, hvordan ting skal se ud, såkaldte designmønstre samt generelle tips. Vi skal straks gennemgå de respektive dele.

: Billede 22: Første version af Västra Götalandsregionens stilguide.

Et mere ekstremt eksempel netop, hvad angår farvevalg, hørte jeg fra Expressens lead frontend-udvikler. De havde bare på startsiden af expressen.se hele 24 forskellige nuancer af deres røde farve. Dette skyldtes ikke noget krav fra dem, der bestiller design til webstedet, men snarere at udviklerne selv valgte en rød farve, når de skulle lave noget rødt. Måske var det den indsigt, der fik Expressen til at udarbejde en stilguide og standardisere, hvilke farver der er de rigtige. Med en stilguide tog de kontrol over, hvordan brugerne skulle forstå og tolke deres websted.

Stilguider er i sig selv ikke noget nyt. Dog er det en af få ting, som webben ikke arvede fra tryksagsproducenterne allerede i 1990'erne. Stilguide kan være et paraplybegreb og samlingssted for al dokumentation om, hvordan man bedriver sin kommunikation i digitale sammenhænge. Inden for etablerede virksomheder har man sikkert allerede nogle dele af det, der kan udgøre en stilguide. Muligvis kaldes de for retningslinjer, vejledninger, designmanualer eller lignende. Indimellem gælder disse kun den fysiske virkelighed som skilte eller tryksager, og indimellem gælder de mere digitale ting. Et meget relevant og yderst kommunikativt eksempel på indhold at overveje til sin stilguide er New York Times' dokument med "forbudte" ord. Altså deres sproglige stil.

: Billede 23: New York Times' liste med ord, der bør undgås.

Grunden til, at man bør samle al dokumentation ét fælles sted, er, at hvis folk slipper for at lede flere steder, vil efterlevelsen af disse dokumenterede klogskaber sandsynligvis øges. Derfor tror jeg, at det er smart at være inkluderende i, hvad man vælger at tage med i sin stilguide, selv det, der ikke er særligt digitalt, kan sikkert gøre nytte.

Det er lidt underligt, at stilguider ikke blev en selvfølge samtidig med, at responsivt webdesign slog igennem. I og med at man i designfasen for et responsivt websted er nødt til at begynde at tale om, hvordan et designelement skal se ud på forskellige store skærme, burde behovet for et dokumenteret design være næsten indlysende. Hvordan skal man ellers vide, hvordan et designmønster, som hovedmenuen, opfører sig og ser ud på forskellige skærme? I begyndelsen, hos visse organisationer, blev disse nedtegnet i noget, der kaldes pattern libraries. Altså organisationens bibliotek af designmønstre. Nu synes designmønstre stadig oftere at være en del af de offentligt tilgængelige stilguider, vi kan finde på webben.

: Billede 24: Designmønster for et søgefelt.

I 2000-tallets første årti har nok mange organisationer stået og stamped lidt i webarbejdet. Mange er måske halvvejs inde i at modne i sit webarbejde, men mangler alligevel visse dele, man har i det "almindelige" kommunikations- og marketingarbejde. Få synes at være kommet særlig langt med en lige så fuldendt digital del i sin grafiske manual, i hvert fald sammenlignet med det, der gælder tryksager.

Nyt design? Lav et designbudget!

Hvis du har fordelen af at kunne samkøre arbejdet med at udvikle et nyt websted, eller i det mindste redesigne det, og tage fat i arbejdet med en stilguides designmønstre, skal du takke din lykkestjerne. En måde at have konkrete og forståelige begrænsninger i sit designarbejde er at arbejde med noget, der kan kaldes for et designbudget. Det er en måde at undgå de ofte forekommende diskussioner om, at det er svært at prioritere, da tilsyneladende alt altid er vigtigst.

Fremvoksende praksis inden for webdesign er at påbegynde designarbejdet med at opstille et designbudget. Et designbudget går ud på at designe sider og skabeloner på en tilbageholdende måde. For at konkretisere denne tilbageholdenhed har man et pointsystem, der styrer, hvor mange designkomponenter der havner for eksempel på en landingsside. Sig, at man starter med at sætte et loft på tyve point som budget for hver enkelt sidevisning. Skal du så hive et stort blok med billede og call to action-knap ind? Så vil du have brugt seks point bare på det store billede. Skal du derefter have en billedkarrusel, forsvinder måske ti point mere på grund af flere tunge billeder, men også en ekstra Javascript-afhængighed til selve billedbladringen.

En fordel ved at lave et designbudget er, at det er svært at reparere denne type mangler bagefter, når alle beslutninger er taget. Samt at man nok er mere kompromisvillig i begyndelsen af et projekt.

Barbara Bermes har nedenstående forslag til pointsystem i sin fremragende bog Lean Websites²⁰.

Designmønster	Point	Beskrivelse
Lille påvirkning	1	Små billeder, statisk indhold, enklere grafik, knapper og tekstfelter.
Mellemstor påvirkning	2	Halvstore billeder og enklere scripts.
Stor påvirkning	6	Store billeder, tredjepartstjenester, annoncer fra tredjepart.

Den største gevinst ved et designbudget er at konkretisere hvert designbesluts påvirkning på webstedet, det bliver konkret for dem, der ikke har anledning til at tale om dette i mere tekniske vendinger (dér kommer ydeevnebudgettet ind, noget vi straks kommer ind på).

Vil man selv spille djævlens advokat ved designbeslutninger, kan man konstant foreslå at A/B-teste brugernes accept af den respektive idé. Måske fungerer sider med højere point. Måske kan jeres loft være femogtyve point snarere end tyve for en landingsside, og den præsterer på samme niveau? Men test for alt i verden også antagelsen om, at færre designpoint giver mere nytte, og hvor grænsen går.

Som Karen McGrane påpeger i sin bog Going Responsive²¹, i kapitlet Clean up your content, er det i design- eller evalueringsfasen, man har en gylden mulighed for at sætte sig ned sammen og foretage de svære prioriteringer om, hvilket indhold der skal findes, og hvad der faktisk er vigtigst. Det er nu, man også tænker mobile first, små skærme, langsom forbindelse osv. Svar på disse spørgsmål får man ikke per e-mail – man skal mødes. Under et sådant møde må man kunne træffe beslutninger. Det er også nu, det er muligt at adressere den manglende evne, der ofte findes, til at udpege én eneste ting som vigtigst per side. Hvis kun én ting får plads på en skærm, hvad skal det så være, man vælger. Der er ingen delte førstepladser i mobile first.

We've remade the Internet in our own image, which, in the United States, is obese.
- Jason Grigsby²²

Du har nok regnet ud, at man med denne tilgang har brug for at husholdere med ressourcerne i sidehoved og sidefod. Ellers bliver der meget lidt tilbage for det unikke på hver webside at gøre brug af.

Orker man ikke holde på med pointsystemet ved designbeslutninger, kan man i stedet have et batteri af spørgsmål, der afklarer, hvordan design påvirker oplevelsens hurtighed, om det gør det hele til en øget kognitiv byrde for brugeren. For eksempel suppleres spørgsmål om, hvordan designforslaget påvirker varemærket, eller går ud over eksisterende designmønstre, med spørgsmål som:

Kommer det til at påvirke antallet af filer, der skal downloades?
Bliver sidevisningen tungere?
Hvordan påvirkes den oplevede ydeevne?
Vil brugeren blive mentalt overbelastet eller have svært ved at tolke de alternativer, der findes?

Pointen er i højere grad at konkretisere design i flere dimensioner end det strengt æstetiske. Vi er fra tidligere vant til at stille forretningsmæssige spørgsmål som, hvad det kan tænkes at koste, hvor lang tid det tager at færdiggøre, og hvad man tror, det har af værdi for virksomheden. Mange organisationer er klart dårligere til at stille designspørgsmål, som hvorfor farve bruges på en bestemt måde, eller nødvendigheden af udsmykning.

En tilføjelse til dette er det, som Lara Hogan tager op i sin bog Designing for Performance²³. Hun viser, at man gør sit designbudget specifikt per breakpoint på webstedet. For dig, der ikke er bevandret i webdesign, kan det være værd at vide, at breakpoint er de magiske bredder på webstedet, hvor designet ændres for at udnytte den tilgængelige plads bedst muligt. Det er en del af konceptet responsivt webdesign. En lille skærm har mindre mulighed for at vise meget på én gang, og derfor bliver det måske endnu mere relevant ikke at være ødsel.

Det her med grundlæggende design er også en gylden mulighed for at planlægge sin kontinuerlige webanalyse. For eksempel kan flere hypoteser om, hvor stor påvirkning antallet af designelementer har på mobile brugere, evalueres metodisk med A/B-tests, når designet er færdigt og publiceret. Så kan man begynde at teste, hvad der virker på faktiske brugere, hvis man da ikke allerede arbejder med tidlige designprototyper, inden det er bygget.

At evaluere, hvordan et design præsterer, kan være meget teknisk. Det vil du bemærke straks, når vi tager begrebet ydeevnebudget op. Designbudgettet er den chance, man har, for at tale ydeevne og præstation i relation til, hvordan noget kommer til at se ud i grove træk.

Som webanalytiker kan du bidrage på mange måder til diskussionen om et designbudget. Ikke mindst med at planlægge en sammenligning mellem sider, der har drastisk forskelligt antal designelementer, eller hvilke kontraster du finder nysgerrighed overfor at undersøge. En interessant anekdote, jeg hørte fra Expressens lead frontend-udvikler, var, at de A/B-testede, hvor godt deres besøgende konverterede, og mærkeligt nok var der højere konverteringsrate på de rodede sider. Da de derefter gjorde de ikke helt så rodede sider lidt "dårligere", fik også de sider højere konverteringsrate.

Det er vigtigt at udfordre sine antagelser, beviselig!

Indholdsbudget

Du, der har læst min bog Webbstrategi för alla²⁴ eller følger min blog, har nok bemærket, hvor ofte jeg refererer til alt det gode, engelske Gov.uk gør. Nu er de ganske vist ikke de eneste, der har tjeklister for, hvordan man tænker omkring sit indhold på webben, men de er gode til at tale åbent om, hvorfor de gør, som de gør.

De fleste organisationer, jeg har mødt, har ganske vist vejledninger til, hvordan man skriver, men meget få har som Gov.uk gået langt i at gøre denne klogskab tilpasset webben. Sådan beskriver de for eksempel, hvordan en sidetitel skal formuleres²⁵:

clear and specific
optimised for search
under 65 characters (including spaces)
unique within the site (check search results on GOV.UK)
in sentence case
written in plain English (no jargon)

Endnu mere interessant er måske retningslinjerne for brødtekst:

begin with what's most important to users (not to government)
be concise and easy to scan (with sub-heads every 3-5 paragraphs)
be written in plain English (no jargon) and easy to understand
use short sentences (around 25 words)
define acronyms and abbreviations the first time they're used (with Markdown)
explain any technical terms
be shorter than 500 words, if possible

Som du kan se i disse eksempler, sættes visse begrænsninger for, hvordan man arbejder med indhold og dets forskellige mængder. Ikke helt ulikt et budget. Dit indholdsbudget vil helt sikkert blive udfordret og sat spørgsmålstegn ved. Gov.uks beslutning om at holde en brødtekst til under 500 ord er nok i skudlinjen med det samme, hvis de henter en konsulent ind til lidt søgemaskineoptimering. SEO-praksis er på det tidspunkt, denne bog skrives, at en tekst skal være mindst trehundrede ord - men helst omkring tusind. Jeg synes, at pointen med at have et indholdsbudget er selve diskussionen om, hvordan man ser på sit indhold. Man dokumenterer sin hensigt, så alle idéer kommer til overfladen, og at det ved behov er muligt at diskutere og revidere dem.

Nu er der jo altid konkurrerende synspunkter, og forskellige faggrupper kommer gerne med deres egne fakta, praksis eller underlag ind i en diskussion. Indholdsbudgettet er organisationens egne dokumenterede gode praksis i indholdsspørgsmål, de skal ikke ændres vilkårligt. En måde er selvfølgelig at ændre sig baseret på egne tests, men indtil da er forskning og ekstern praksis det bedste, man har at gå efter.

Grunden til, at Gov.uk valgte, at sætninger ikke skal overstige femogtyve ord²⁶, er baseret på forskning. Forskning viser, at når den gennemsnitlige sætningslængde er fjorten ord, forstår mindst 90% af læserne, hvad de læser. Ved treogfyrre ord per sætning falder det til under 10%. Studier viser også, at ved enogtyve ord per sætning begynder en tekst at være lidt halvt kompleks at tilegne sig. At vælge femogtyve ord per sætning som grænse må anses for ret generøst, synes jeg, men jeg tipper også på, at de fleste ikke har nogen ambition overhovedet på dette område.

Arbejder du efter mantraet content first²⁷, er et indholdsbudget det tilsvarende af, hvad et designbudget er for dem, der begynder med designet. Du, der undrer dig over, hvordan fanden man følger op på, at dette overholdes, må væbne dig med tålmodighed, senere i bogen vil du finde tips om, hvordan du arbejder med indholdsanalyse, eller indeksanalyse, som søgefolk ofte kalder det.

Stilguide = kommunikativ stil, mønsterbibliotek og ydeevnebudget

Vi har allerede i denne del af bogen gennemgået en del af den dokumenterede ambitionsniveau, man kan have med sin webtilstedeværelse, men der er selvfølgelig flere ting at sætte på skrift (digitalt).

En organisations stilguide bør, synes jeg, være et samlebegreb for al den dokumentation, der vedrører organisationens kommunikative stil – i bred forstand. I dette kan masser af forskellige dele indgå, hvor få fælles nævnere findes. Ofte er der i forvejen tips og retningslinjer omkring det sproglige, ikke sjældent noget om typografi i digitale sammenhænge, indimellem designskitser, der fortæller præcis, hvordan logoet og andre designelementer skal håndteres for at værne om organisationens identitet.

I nyere tid er det blevet stadig mere almindeligt også at dokumentere en mere teknisk håndbog indeholdende kodeeksempler til webudvikling, nøgletal til opfølgning af webstedet og ydeevnebudget for de prioriterede kvalitetskriterier, der er valgt ud.

Mange kommunikative dele bør nok tages op. Måske ikke ordvalg i sig selv, men snarere hvordan man finder ud af, hvilket sprogbrug der forventes, og at de ord, man faktisk har valgt, har forudsætning for at nå frem. For eksempel at der er begrænset plads til, hvor mange ord der vises hos Google, i brugerens browser m.m. Stilguiden kan faktisk komme med både pisk og gulerod. Pisken bestående af retningslinjerne, der siger, hvad man har lov til at gøre, og guleroden, der er tipsene om, hvordan man gør for at lykkes godt under gældende forudsætninger på webben.

Mønsterbibliotek

: Billede 25: Eksempel på stilguide. Intro med tips om, hvordan den bruges, derefter mønsterbibliotek til genanvendelse.

I stedet for at designe hele sider plejer man at blive anbefalet at designe sine designmønstre først, begrebet for dette er Atomic Design²⁸. Du kan have stødt på dette koncept under andre navne, det mest almindelige synonym i Sverige er nok komponentbaseret design. Det er lidt som, hvilke byggeklodser man har brug for i sit lager for at kunne bygge noget. Disse kaldes stadig oftere på svensk for designmønstre (på engelsk design patterns), og samlingen af designmønstre for mønsterbibliotek (eller pattern library).

Eksempler på designmønstre kan være, hvordan søgefunktionen ser ud, det vil sige søgefeltet, knappen og det, der er rundt omkring. Eller hvordan et billede ser ud sammen med dets billedtekst. Dette er nyttigt, præcis som specialiserede Legobrikker, når man vil genanvende noget i en anden sammenhæng ved en senere lejlighed. Så er dele af arbejdet allerede gjort. Man behøver ikke overveje, hvor mange pixels radius søgefeltets afrundede hjørner bør have, det er bare at kopiere det, der allerede er udarbejdet.

Hvis man ikke sammen med sit designmønster også har bestemt præcis, hvilken interfacekode der skal bruges, har man kun gjort halvdelen af arbejdet. Det er ikke nødvendigvis sådan, at koden skal stå i fokus, men hvis ingen kode gives, bliver det svært, da alle udviklere selv må opfinde egen kode, der får noget til at se ud og fungere som ønsket. Du kan roligt regne med, at ikke alle er lige motiverede til at vælge den rigtige farve, eller sørge for at det skalerer godt på forskellige store skærme, eller bare at det bliver tilgængeligt nok til at opfylde diskriminationslovgivningen. Det er altså anbefalet, at kode findes i tilknytning til designmønstret, og at man forsøger at sørge for, at de bruges.

Hvad er så pointen med at arbejde med et mønsterbibliotek af genanvendelige designmønstre? Jo, man skaber en organisatorisk standard for, hvordan ting ser ud og fungerer. Udover åbenlyse gevinster omkring ens organisations identitet kan denne form for standardisering faktisk bidrage til tryghed hos brugerne. Hvis nogen havner på en phishing-side, får de forhåbentlig muligheden for at indse, at noget er galt, at noget i den visuelle eller funktionelle identitet er forkert. Det er vigtigt at have en tydelig identitet, så de trofaste brugere indser, når noget ikke helt stemmer. Hvis man ikke arbejder med et mønsterbibliotek, vil man have fuldt op med at efterligne sig selv for ikke selv at fremstå som en dårlig imitator.

: Billede 26: Prototype af kliniksøgning. En kombination af flere designmønstre giver hurtigt prototypearbejde.

Du, der er lidt vågen, er allerede begyndt at tænke på, at visse af disse dele indgår i noget, der indimellem kaldes for en organisations grafiske manual. Forskellen er, at en stilguide tager mere op end det, der handler om det grafiske. Jeg vil både påstå og anbefale, at ens stilguide erstatter ens grafiske manual. Den manual kan faktisk indgå i stilguiden, og det, man kalder for grafisk manual, kan i stedet kaldes for designguide. Suppleret med de dokumenterede designmønstre er man kommet et godt stykke med en stilguide – visuelt i hvert fald.

Fordele ved et mønsterbibliotek (hvis det bruges) er i hvert fald, at det:

Borger for et ensartet udseende. Gennem en mindsket variation i, hvordan noget ser ud, bliver ens design mere forudsigeligt for brugerne. Det er muligt at holde styr på, om et nyt design fungerer bedre, det samme eller dårligere end den variant, man har kørt med tidligere.
Er lettere at forvalte, hvordan hvert designmønster fungerer med de krav, man har, ikke mindst når man vil teste dem. For eksempel hvis der kommer en ny gadget på markedet, kan man tjekke, at alle ens designmønstre flyder godt og responsivt også på den nye gadget.
Evaluerer prototyper enklere. Når du har standardiserede designmønstre at genanvende, går det hurtigt at få en testbar prototype frem. Bare genanvend det, der ikke er det nye, du skal evaluere (se prototypen af kliniksøgning her ved siden af).
Giver højere kvalitet. Hvis man sørger for at holde høj klasse på sine designmønstre, og at de følger gældende praksis, kan man regne med, at nybyggerier vil holde en høj kvalitet. Det er altså vigtigt, at man har et højt og forudsigeligt niveau på det, der tages med i mønsterbiblioteket.

En fælles undertone i ovenstående punkter er, at det sandsynligvis er ressourceeffektivt på sigt, hvis man sørger for at bruge sit mønsterbibliotek. For at lykkes kan det sikkert kræves lidt opmuntring fra dem, der styrer virksomheden, og en del hårdt arbejde og interesse fra alle involverede.

Er en stilguide ikke det samme som en kommunikationspolicy?

Det kunne det måske godt være, men det er ikke helt det samme mål. Forskellen ligger i, hvor aktivt brugen er, og hvilken status den respektive dokumentation har inden for organisationen. En policy er sandsynligvis mere afgrænset og fuld af juridisk eller bureaukratisk fagsprog. En stilguide derimod kan være en levende dokumentation med udførlige tips og eksempler på, hvordan man går til værks ved digital kommunikation.

I sin stilguide kan man også tage mere bløde ting med. Som hvilke værdier man har. Eller som Mailchimps stilguide, der har dokumenteret det opmuntrende sprog, som er en væsentlig del af brugeroplevelsen hos dem.

: Billede 27: Mailchimp forklarer sin tonalitet i sin stilguide. At en del af tjenestens oplevelse kan handle om sproglige nuancer.

En stilguide er med fordel bygget som et lille websted, hvor man kan udforske alle dele, se eksempler og hente hjælp til at følge organisationens praksis omkring at udforme noget.

For at komme i gang med sit arbejde med en stilguide behøver de fleste at begynde med en inventering af, hvad der allerede findes dokumenteret inden for den virksomhed, man arbejder i, og hvordan det kan passe ind i denne nye virkelighed. Hvis du ikke har regnet det ud allerede, er en stilguide noget, der primært har et oppefra-og-ned-perspektiv, så hvis du ikke arbejder i toppen af din organisation, er det sandsynligt, at du har brug for hjælp fra kollegaer for at etablere jeres stilguide, eller få tilladelse til at lave en egen, lokal stilguide.

Mange har sikkert allerede dokumentation om, hvordan man tiltaler kunder og modtagere. Dette bør man inkludere i sin stilguide, og derefter kan man se bort fra det dokument. Lad stilguiden være startpunktet for alt, der vedrører kommunikation, design til digitalt og tryksager, samt guider til, hvordan det hele foregår i praksis, og hvem man henvender sig til for støtte eller spørgsmål.

Stilguide er som sagt en form for paraplybegreb for flere ting. For at begynde at beskrive det lidt mere "webagtige", der indgår i ens stilguide, kan man tale om stilguidens basale elementer, nemlig:

Hvordan kolonne- og gridsystemet fungerer for mobiler og computere.
Standardudseende på almindelige HTML-elementer. Hvordan ser for eksempel lister ud, billeder og deres billedtekster?
Typografi omkring tekstafsnit, overskriftsniveauer, skrifttyper, etc.
Hvordan man håndterer tabeller, formularer og så videre.
Designspørgsmål som farver, udseende på fejl- og advarselsmeddelelser, osv.
Hvilke ikoner bruger man til hvad, og hvordan placeres de korrekt designmæssigt.
Hvordan indlejres mediefiler.

En stilguide bør foregå med godt eksempel omkring, hvordan webkode håndteres. Det er et sted for dem, der bygger websteder, at hente kodestykker, så det bliver rigtigt med det samme. Har man en veludbygget stilguide, bliver det lettere at bygge et midlertidigt mikrosite til en kampagne, eller hvis man af en anden grund har brug for at bygge et nyt websted. Så kan udviklerne hente kvalitetstestede komponenter, frameworks og færdige kodestykker, som alle er robust konstruerede og tilgængelighedsvurderede. Det er i hvert fald tanken, at man som bestiller skal kunne levere sin stilguide som en form for referencepunkt for en leverandør at forholde sig til.

: Billede 28: Stilguide for Bootstrap forklarer, hvordan billeder bliver responsive, og angiver, hvilken kode der skal bruges.

Stilguiden bør også forklare, hvilke stillingtagen der er gjort omkring designvalg. Blandt andet hvor gamle browsere man tænker at understøtte, og eventuelle afvigelser, man er kommet frem til. Eksempler på sådanne afvigelser er, hvordan ældre browsere uden understøttelse af media queries skal håndtere en responsiv virkelighed, eller hvis man har valgt at bruge SVG-formatet til billeder, er den understøttelse ikke fantastisk i gamle Internet Explorer. I stilguiden fortæller man, om man har tænkt at bruge noget bestemt polyfill²⁹ for at løse bagudkompatibiliteten.

Primært handler denne bog om webben, men selvfølgelig kan en stilguide lige så godt inkludere apps, sociale kanaler, etc.

Ærligt talt er det heller ikke i webudvikleres kredse sådan, at stilguider er noget nyt. Men ordvalget har ofte tidligere været kodemanual eller lignende, dog stadig med målet, at man skal være ensartet i, hvordan man producerer sit resultat. For en udvikler er det af højeste vigtighed, hvordan man navngiver ting i kode, dette dels for at det skal være forklarende for en anden, der senere skal rette koden, men også for ikke at risikere at få sammenstød mellem ting, der bliver døbt til det samme navn. Vil du nørde ned i dette, så tjek bogen Code Complete³⁰, hvis du vil give dig i kast med teknikaliteter som navngivning af variabler til Javascript.

Lidt afhængigt af, hvem du spørger, hvad en stilguide er, vil du få lidt forskellige svar. Følger du bloggere inden for webdesign, bemærker du hurtigt, at en stilguide faktisk kan være mange ting. Det, jeg fik igennem på min arbejdsplads, da vi lavede vores stilguide, handler om følgende:

Organisationens webstandard, værdier og ambition. For eksempel hvordan man ser på tilgængelighed, hvordan kode skal skrives, med mere.
Et bibliotek af designmønstre for webben og andre digitale kanaler. Har du skiftet tema i Wordpress nogen sinde, har du garanteret set, hvordan de vælger at præsentere temaet. Du får se ting som typografi, hvordan billeder vises med mere. Du får overblik over, hvordan forskellige dele af et websted kan tænkes at se ud.
Ydeevnebudget, og her skal vi ikke tage ydeevne bogstaveligt. Den engelske term er performance budget, så muligvis skal vi også inkludere alt, der har med præstation at gøre.

Jeg vil tydeliggøre, at ingen af ovenstående punkter på nogen måde er obligatoriske i en stilguide, man kan gøre lidt, hvad man vil af sin egen stilguide. Men for denne bogs argumentation kan du regne med, at en stilguide i det mindste vedrører indhold, webdesign og ydeevnebudget. Ovenstående punkter var det, jeg fik gehør for, dér hvor jeg arbejder, et sted hvor meget få havde hørt om en stilguide før. Hvilket måske kan tages som et tegn på, hvilke dele der er forståelige i en større kreds af mennesker, der alle arbejder med webben på den ene eller den anden måde. Det, der ikke kom igennem nåleøjet i stilguidens første version, var webredaktørernes håndbog, den ville man gerne have separat – muligvis fordi man ikke kan se, at stilguiden vil blive brugt eller være af interesse længere ude i organisationen.

Stilguiden er nok primært til for indholdsproducenter og måske dem, der ejer webstedet fra en ledelsesposition. Den skal tage det op, der skaber forudsætninger for, at et websted kan levere resultater. Skal man pege på en ejer af stilguiden i en større organisation, er det nok marketingchefen eller kommunikationschefen, der skal bekymre sig mest. Og dem, der vedligeholder stilguidens indhold, er dem på den tilsvarende afdeling, muligvis sammen med dem, der udvikler webstedet.

En stilguide bør ikke være et dokument, man stopper ind i et arkiv. Snarere bør man lade den være noget, man arbejder aktivt med. Stilguide kaldes ofte for living style guide på engelsk. Det er tænkt at være noget levende, noget foranderligt. Pointen med ens designmønstre (som udgør ens webdesign) er, at de kontinuerligt skal forbedres for at leve op til webbens konstant foranderlige krav og brugernes forventninger.

Hvis du har brug for at henvise til en autoritet for at få lov til at arbejde med jeres stilguide, så kør med Brad Frost. Hans koncept med Atomic Design har vi nævnt tidligere. Det er et logisk komponentbaseret syn på webdesign. Det tilbyder en forklaringsmodel fra den mindst tænkelige komponent, som en knap til søgning, op til hvordan en eksempelside kan se ud.

Eksempler på problemstillinger at tage op

Der er en række spørgsmål at besvare, når man sætter sin ambitionsniveau i et webprojekt. Lidt afhængigt af, hvilken faggruppe man henvender sig til, kan man kalde denne ambition for forskellige ting.

Stilguide er måske nærmere indholdsproducentens syn på ambitionsniveau, mens ydeevnebudget er udviklerens vinkel (men i stigende grad af interesse for dem, der vil konvertere sine brugere). Jeg foreslår, at vi betragter ydeevnebudget som et bilag til stilguiden. Det handler trods alt om organisationens kommunikative stil i digitale kanaler, og ydeevnen er i højeste grad en vigtig del.

En stilguide indeholder ofte eksempler på typografi, design, tiltale med mere, mens et ydeevnebudget ofte fokuserer på målbare ting, der er kvantificerbare. Ting der kan analyseres og sendes som målbare krav til leverandører. For eksempel hvor lang tid der er acceptabelt for at modtage en webside. Sammen med den visuelle identitet, organisationens tonalitet i sproget, hører absolut en "teknisk" identitet hjemme for at danne en fælles oplevelse. Hvad man kan forvente sig fra din organisation i digitale sammenhænge, mere om det læser du i kommende afsnit om ydeevnebudget.

En bonusproblemstilling, vi på min arbejdsplads fik omkring stilguide, er blandt andet den granskning af integritet inden for offentlig sektor, som Dagens Nyheter kørte som en serie artikler, samtidig med at vi udarbejdede stilguiden i efteråret 2015. Det blev en diskussion om, hvilke værdier vi havde, om vores bekvemmelighed i valg af værktøjer og integrationer kunne veje tungere end brugernes integritet. Spørgsmålet opstod, om man i offentlig sektor nogensinde skal have tredjeparter på sine websteder, hvis man ikke har styr på eventuelle følgevirkninger for sine brugere. Det kan være meget mere end, om man skal have Google Analytics. Det gælder jo også, hvordan websteder designes, om man bruger eksterne skrifttypetjenester, indlejrer Facebook-feedet, sociale dele-knapper, m.m.

Desuden har webstedets stil også med brugervenlighed omkring indholdet at gøre. Om længden på sidetitler fungerer i alle tænkelige sammenhænge, hvordan man ser på responsiv billedhåndtering og meget mere.

Disse spørgsmål havde vi på min arbejdsplads, da vi først begyndte at arbejde med vores stilguide. Nogle af spørgsmålene er sikkert relevante også, hvor du arbejder. En test på, om et spørgsmål er meningsfuldt at tage med i stilguiden, er "og hvad så-testen", altså at man kan besvare "Og hvad så, hvem bekymrer sig?" Man har brug for at kunne have en saglig diskussion omkring hvert punkt, man vælger at tage med. For hvem det er til, og hvorfor det er vigtigt.

Hvordan skal vores typografi være for at garantere en god læseoplevelse på alle platforme?
Skal vi indlejre tredjepartstjenester, der eventuelt truer brugerens integritet?
Længde på sidetitler. Maksimalt 60 tegn?
Skal billeder vises i retina-opløsning eller "normal opløsning"?
Tillade dekorative billeder, eller ej?
Hvornår er det begrundet at bruge tabeller?
Skal alle vigtige sider angive meta-description og mindst ét nøgleord (noget vores egen søgemaskine behøver for at webstedssøgningen skal fungere godt)?
Mindst én call-to-action synlig uden scrolling på landingssider? Synlig for alle slags enheder, der bruges?

Forvaltning af stilguiden

En udfordring, man må forsøge at håndtere gennem arbejdet med sin stilguide, er, hvordan den skal forvaltes over tid. Præcis som at retningslinjer for sociale medier, og andre hurtigtrørlige ting, kan blive komisk forældede ret hurtigt, gælder det, at stilguiden ikke bliver noget, man stopper i skrivebordsskuffen og kigger på hvert andet år. Selvom jeg synes, at én person bør udpeges som stilguidens forvalter, bør stilguiden være alles anliggende. I hvert fald dem, der arbejder med en eller anden form for kommunikation eller udvikling i digitale kanaler.

En måde at undgå, at stilguiden samler støv, er at putte vejledning, eksempler, tips og andet ind, der gør, at berørte kigger ind i stilguiden lidt oftere. Derefter bør den, der er udpeget som forvalter, hvert kvartal gennemgå alt materiale, mest for en sikkerheds skyld.

Et tydeligt eksempel på noget, der kalder på opmærksomhed lidt løbende, er de designmønstre, man putter ind i stilguidens mønsterbibliotek. Efterspørgsel efter nye designmønstre må afvejes mod genanvendelse af de eksisterende, ellers bliver det let vildtvoksende rent visuelt omkring organisationens identitet.

Mønsterbibliotek giver tydeligere krav til leverandørerne

Som leverandør kan en stilguide gøre det lettere at forstå, hvilke forventninger der er. Samt at man ikke behøver at genopfinde ting som, hvilken responsiv adfærd man har kørt med siden tidligere, og andet der rimeligvis burde kunne standardiseres inden for den organisation, der har skabt stilguiden. Dette borger også for en konsekvent oplevelse mellem forskellige websteder fra samme organisation.

: Billede 29: Webrammeværket Bootstraps stilguide er også dens dokumentation.

Et utroligt hyppigt brugt (og udskældt) standardiserende framework for webben er Bootstrap. Deres dokumentation er præcis, hvad man kunne betragte som en stilguide. Dér kan man se præcis, hvordan kode skal udformes for at leve op til designkonventionen mobile first. Hvordan formularer både ser ud og skal kodes, og alt andet der har med interfacekode som HTML, Javascript og CSS at gøre.

Grunden til, at Bootstrap er udskældt, er, at dets enorme gennemslag har gjort, at rigtig mange websteder ser ens ud. Javist, det er måske ikke en designers drøm at være tvunget til at forholde sig til et udseende, der er fælles for alle mulige organisationer. Men dette konsekvente design er jo præcis, hvad vi er ude efter, når afsenderen er én og samme organisation.

Mest grundlæggende i ens mønsterbibliotek er, hvordan de mest almindelige designelementer ser ud og reagerer responsivt, for eksempel hvordan sidehovedet svarer på de forskellige store skærme, brugerne kan tænkes at bruge. Dette er en af de største pointer med en stilguide og dens mønsterbibliotek. At man dels kan teste, hvordan det fungerer i dag, men også være det sted, hvor man i sin aktive forvaltning af stilguiden kan udvikle nye designmønstre og sørge for, at de holder mål.

Det er måske ikke rimeligt at tro, at man vil tage sig tiden til at køre hvert eneste lille designbeslutning igennem denne proces og få det dokumenteret. Desuden tager det nok en ret stor investering i tid og penge at komme til et godt niveau. Da jeg i foråret 2015 sonderede markedet for at bestille dette til min arbejdsgiver, var det tydeligt, at ingen af de leverandører, jeg talte med, syntes, det var lønnende at lægge mindre end 200 timer på et sådant arbejde. Deres tid altså, da som eksperter i webdesign og interfaceprogrammering. Jeg forestiller mig, at vi som bestiller nok ville have måttet lægge mindst lige så meget tid selv. For de timer ville man få de mest almindelige designkomponenter ind i sin stilguides del med mønsterbibliotek. Altså følgende dele af et websted:

Overordnet responsivitet, gridsystem og ydre rammer for udseendet.
Grundlæggende typografi.
Sidehoved, dets dele som logo, søgefelt og hovednavigation.
Nogle få komponenter, der er inden for en sides unikke indhold. Sandsynligvis kan man vælge at få sin startside vellavet, samt et eksempel på en underside, der er tungere på tekst.
Sidefod med dens kontaktoplysninger med mere.

Der er ingen egentlig øvre grænse for, hvad der skal puttes ind i mønsterbiblioteket. For at prioritere og begynde at tage fat på dette arbejde er Atomic design til hjælp. At man kigger på de mindste bestanddele, og i hvilke kombinationer de kan forekomme på et websted.

Nogle eksempler på sådanne atomiske designmønstre kan være:

Billedkarruseller (denne skændsel af et kompromis for at få ro fra alle dem, der kræver, at netop deres indhold skal være på startsiden).
Præsentation af kalenderhændelser og begivenheder. Kan være dels i kompakt listeform, men også hvordan den sideskabelon ser ud.
Søgeordsforslag, der dukker op, når nogen er begyndt at skrive søgeord i et søgefelt.
Megamenu. Du ved, de der store udfoldbare menuer, der kan indeholde flere kolonner med lister af undersider, relateret indhold m.m.
Kortfunktioner og indlejrede videoklip.
Lidt mere komplicerede formularer, visualiseringer og tabeller, der kan indeholde finurligheder som filtrering og sortering.

Når et mønsterbibliotek findes, kan man kombinere disse designkomponenter til komplette eksempelsider. Så bliver det nemmere at få en fornemmelse for udseendet.

: Billede 30: Code for Americas stilguide viser eksempler på, hvordan en side kan se ud, med nogle udvalgte designmønstre.

Det, man i tilknytning til mønsterbiblioteket har brug for at dokumentere, er, hvordan det foregår at få et nyt designmønster med. Hvilke krav de skal leve op til, hvordan de skal testes med mere. Forhåbentlig åbenlyse krav er, at det skal være tilgængelighedstestet, validere den valgte kodestandard og være kompatibelt med mønsterbiblioteket i stort. Det, der indgår i ens stilguide, skal være organisationens bedste praksis for digital kommunikation, så det gælder om at lægge ribben højt.

: Billede 31: Starbucks' stilguide viser designmønstret for, hvordan advarselsmeddelelser skal se ud.

Et eksempel på et scenarie omkring dette, som jeg selv har arbejdet med, er, at vi prototype-byggede en lille søgefunktion direkte i stilguiden. Alternativet ville være at gøre som vanligt, altså sende en lang liste med krav til vores webudviklere, og så havde de bygget en prototype direkte i vores publiceringssystem. I stedet koblede vi en ekspert i webdesign ind og udvidede vores stilguide. Det gjorde, at vi kunne overdrage noget meget konkret til webudviklerne (hvis primære styrke måske ikke er konceptuelt design) at bygge ind i vores CMS. Med andre ord havde vi allerede redet ud, præcis hvordan det skulle se ud, fungere på forskellige slags enheder, præcis hvordan interfacekoden behøvede at være, lavet brugervenlighedstests på levende brugere samt testet tilgængeligheden. Så opgaven til vores webkyndige systemudviklere blev meget konkret – "gør præcis som det fremgår af stilguiden, få det til at fungere i vores websted". På denne måde gør alle det, de er bedst til.

Browsing should be as simple and fast as turning a page in a magazine.
- Larry Page, grundlægger af Google

Ydeevnebudget, tekniske vurderinger og kvalitetsretningslinjer

Tidligere arbejdede jeg som webkonsulent. Mit største forbillede i, hvordan man agerer som konsulent (og som leder i stort), er David Maister, tidligere professor ved Harvard Business School. Han har skrevet den fremragende bog Managing The Professional Service Firm³¹. Han konstaterer ofte det åbenlyse, man endnu ikke selv har formået at sætte fingeren på.

En ting, han tager op, er yderst relevant for ydeevne, nemlig hvordan en tjeneste eller vare opleves af sine brugere. Det hele er jo ret subjektivt, da enhver har forskellige forventninger på forhånd. Han foreslog en formel, som jeg måske har forvansket lidt i min oversættelse, nemlig:

Tilfredshed = Oplevelsen – Forventningen.

Sådan som jeg agerede på dette, som konsulent, var altid at forsøge at overleverere en lille smule. Det skulle altid blive lidt bedre end forventet. Give det lille ekstra (forkortet DLX). Der blev spøgt frit om, hvad DLX skulle være i et specifikt projekt, men at det var vigtigt, var vi alle enige om. Udviklere begyndte pludselig at tale om vores kunders oplevelse af vores leverancer. Det var en god ting.

Underpromising – overdelivering.

Hvis du kan påvirke forventningen, bliver oplevelsen i sig selv ikke lige så afgørende, men hvis forventningen er skyhøj, bliver det næsten umuligt at gøre et godt stykke arbejde uanset indsats. Det er her, et ydeevnebudget kommer ind – tidligt i processen! Hvis alle designbeslutninger allerede er taget, hele molevitten er bygget, og man kommer frem til, at resultatet blev alt for langsomt, ja, hvor sandsynligt er det så, at man kan løse det bagefter? Det kan sikkert lade sig gøre, men det bliver bestemt dyrere at forsøge at fixe noget, der allerede er i stykker. Smartere ville det være at tænke sig om fra begyndelsen.

Hvilket niveau skal du vælge? Lav lidt efterforskning om, på hvilket niveau dine konkurrenter eller tilsvarende organisationer holder, og så sørger du for at overgå dem en smule. Noget nybygget bør vel rimeligvis være bedre end det, der allerede er etableret?

At understøtte noget behøver ikke at indebære en vilje til at optimere

I fortiden så vi ofte tekster som "Denne websted fungerer bedst i Netscape 4.0 med en skærmopløsning på 1024x768 pixels på en 17"-skærm".

Hvilke krav tænker du at stille til dine brugere og det udstyr, de vælger? Det er værd at huske, at bare fordi man tænker at understøtte et bestemt udstyr, en browser eller en enhed, betyder det ikke automatisk, at man tænker at lægge kræfterne i og optimere den oplevelse. Se understøttelsen som, at noget skal være muligt at bruge, men derefter er der andre tilfælde, hvor man anser, at det er værd at arbejde med optimering. I ydeevnebudgettet dokumenterer du dette minimumsniveau.

En designprincip, som vi i den gamle garde af webudviklere har levet efter, og som er en del af konceptet med at følge webstandard, plejer at kaldes for progressive enhancements. Det indebærer, at en god grundfunktion skal tilbydes alle, og hvis der stadig er engagement tilbage, kan man begynde at optimere for de brugere, der er vigtigst for en, eller har bestemt udstyr, der kan have brug for lidt mere omsorg for at fungere optimalt.

Ydeevnebudgettet må som sagt mere end gerne indføjes i organisationens stilguide. Primært er ydeevnebudgettet rettet mod udviklere. Alle andre skal slippe for at snakke teknik, men det kan også fungere godt som en afklaring om organisationens forventning til sine leverandører. Stræb efter, at ydeevnebudgettet giver svar på tiltale nok til, at ikke-udviklere kan stille modspørgsmålet "lever det op til ydeevnebudgettet?" ved enhver teknisk problemstilling. Man kan ikke forvente, at alle har anledning til at kende til alle bestanddele af ydeevnebudgettet.

Dette dokument kan ses som en retningslinje omkring webstedets kvalitet og laveste acceptable niveau inden for en række områder, man specificerer, for eksempel tilgængelighed. Ydeevnebudgettet bør gerne lanceres på en højtidelig måde, så alle involverede forstår, at fra nu af har man en målbar virkelighed at forholde sig til. At det gælder såvel webudviklerne, IT, redaktørerne og alle andre, der påvirker webstedet. Personligt synes jeg, at man desuden bør gøre det offentligt tilgængeligt på webben, så bliver det endnu sværere at ignorere eller glemme.

Du undrer dig måske over, hvad pointen er med et ydeevnebudget? Dit ydeevnebudget er din måde at klargøre organisationens serviceniveau i digitale kanaler, men også de målepunkter, du kontrollerer, når du laver din tilbagevendende indholdsrevision. Som at sidetitler er passende lange, etc.

Hvis du undrer dig over, om webydeevne egentlig spiller nogen rolle, vil du snart få beviser i overflod. Men hvis vi for øjeblikket nøjes med den yderst objektive og kvantitative måde at se på sagen, kan jeg henvise til en undersøgelse, som Walmart har lavet. De har fundet en meget tydelig sammenhæng mellem indlæsningstiden for en webside og, hvor godt disse brugere konverterer, det vil sige at brugerne gør noget ønskeligt på webstedet.

: Billede 32: Walmart har fundet en sammenhæng mellem ydeevne og konvertering.

Det er altid værd at minde sig selv om, at med ydeevne skal man også tænke ind ordet præstation, i stort, det handler ikke kun om hastighed.

Eksempel på et ydeevnebudget

Nedenfor kan du se de punkter, vi valgte ud på min arbejdsplads til vores første ydeevnebudget³², som jeg udarbejdede for Västra Götalandsregionen i 2015.

Start på citat.

Ydeevnebudget og målbar webkvalitet for www.vgregion.se

Dette er indledende dokumentation og aftale omkring projektet for opgradering til Episerver CMS samt det nye interface.

Læs nedenstående krav som, at de måles med repræsentativt indhold på testsider, som udviklerne udarbejder forud for afstemning med projektets udpegede webanalytiker. Disse testsider skal ikke kunne påvirkes nævneværdigt af VGR's redaktører mellem testtidspunkterne, de skal være sammenlignelige over tid.

En leverance, der ikke opfylder disse krav, skal ikke sættes i produktion og skal ikke accepteres af VGR.

1. Værdier, prioriteringer og præstation for hele webstedet

Følge designkonventionerne progressive enhancement samt mobile first, det vil sige fokusere på tilgængelighed først og finesser bagefter, samt at det er det mobile scenarie, der sætter behovene omkring design og funktion.
Funktion før form, og oplevelsen frem for teknikaliteter. Det vil sige inkluderende design, både for handicappedes mulighed for at deltage, men også for at nå så mange slags udstyr som muligt.

2. Målbart ydeevnebudget

Max 399kb for en sidevisning.
Under 3 sekunder for komplet indlæsning af side, målt fra gunstig kabelforbindelse.
Under 10 sekunder for komplet indlæsning af side målt på 3G-forbindelse.

3. Minimumsniveau for web

Disse punkter beskriver det laveste accepterede niveau for den første iteration af www.vgregion.se, det niveau må ikke forringes under kommende opdateringer, snarere skal disse krav skærpes løbende i samråd med udviklerne.

Alle skabeloner/views/komponenter på webstedet skal som allermindst:

Være testet og sikret mod WCAG 2 niveau AA.
Anses for at være mobilvenlige ifølge Googles mobilvenlighedstest.
Med eksempelindhold opnå mindst 85 af 100 i Google Pagespeed med mobile indstillinger, og mindst 90 for computer.
Max 2 CSS-filer indlæses.
Max 3 Javascript-filer indlæses.
Bruge CSS Sprites (eller tilsvarende teknik) for at reducere antallet af billedfiler, der skal downloades.
Strukturel CSS-kode inkluderes i HTML-koden ifølge god ydeevnepraksis for hurtig initial visning af indholdet.

Slut citat.

Ja, dette var, hvad vi inden projektet blev enige om internt og også sammen med vores webkonsulenter. Du undrer dig måske over, hvordan det gik? Jo, den første version af ydeevnebudgettet, jeg har arbejdet igennem på min arbejdsplads, har vi sat det absolutte krav om at følge tilgængelighedsretningslinjen WCAG 2.0 som mindst på niveau AA. Det burde ikke direkte være kontroversielt, i betragtning af at mangelfuld tilgængelighed siden 2015 anses for diskrimination ifølge loven, og siden 2016 er noget, EU har besluttet som bindende for alle myndigheder - inklusive intranet og ekstranet.

Desuden nogle mål for, hvor hurtigt det skal gå at downloade en side. Dér blev det vel en pludselig opvågnen i designarbejdet for vores kommende websted, at man ikke kan spilde, som man vil, med dekorative elementer. Vi har sat grænsen ved 399 Kb, og da bør redaktøren have mindst 140 Kb til at kunne lægge et tungere billede op.

Et punkt, der måtte vige i den første version af ydeevnebudgettet, var en værdi om at "Værne om besøgendes integritet. Ingen som helst tredjepartstjenester, for eksempel Google Analytics, sociale dele-knapper, etc." Det spørgsmål skulle håndteres separat. Men værdien som sådan omkring integritet fandtes alligevel i andre dokumenter, blandt andet i IT-sikkerhedspolicyen.

: Billede 33: Grafen fra Pingdom viser, at en driftsættelse af ny kode midt i marts gjorde webstedet i gennemsnit 0,3 sekunder langsommere.

Vi begyndte at måle allerede under udviklingsfasen. Et interessant fund var, at en opdatering af det kommende websted gjorde det i gennemsnit 0,3 sekunder langsommere ifølge Pingdoms værktøj til at måle svartid. Jeg synes, det er et fund, fordi man nu kan tale tal i stedet for subjektiv mavefornemmelse. På denne måde har man mulighed for at afveje fordele og ulemper, om de nyheder, der blev introduceret, faktisk er 0,3 sekunder langsommere svartid værd. Det er de måske, men man kan ikke lægge 0,3 sekunder i ekstra svartid på hver eneste opdatering. Før eller siden vil man ramme loftet for den sideindlæsningstid, man har sat op i ydeevnebudgettet. Ved at have lang historik af data kan man have et bedre underlag end ellers til, hvad man tror, man har brug for at udbedre for ikke konstant at forværre situationen.

I vores tilfælde regner jeg koldt med, at vi kan kaste penge efter problemet og købe mere hardware, men samtidig havde vi en storstilet cache-løsning på vej, som IT-afdelingen var begejstret for. Den skal som allerdårligst halvere tiden for at vise siderne.

Men der er selvfølgelig masser af andre problemstillinger, hvor man kan have nytte af på forhånd at specificere sin ambition omkring ydeevne og præstation. Selvfølgelig skal et websted af i dag anses for mobilvenligt. I det er der mange ting, man har brug for at måle, både designet i stort, men også det, der havner på webstedet. Vi har præciseret dette til dels, at Googles testværktøj skal anse, at alle typer skabeloner i vores publiceringssystem er mobilvenlige, med en form for eksempelindhold. Dette er kravet til dem, der bygger vores web. Derefter bliver det til at følge op på, at redaktørerne ikke ødelægger den oplevelse ved at lægge kæmpestore tabeller ind og så videre.

Kontinuerligt måle kvaliteten af websiden

For at være tydelige og forudsigelige over for vores leverandører har vi sammen sat testsider op. Disse testsider skal som minimum have 85 af 100 i karakter ifølge værktøjet Google Pagespeed, da med mobile indstillinger. For en computer skal det være mindst 90 af 100 i karakter. Disse tal bør de tjekke, allerede inden de driftsætter noget nyt. Det er ikke acceptabelt, at noget forringer karakteren. I hvert fald skal intet, der ikke er begrundet, have lov til at forringe karakteren.

Grunden til, at det er netop 85 af 100, er, at Google har sat det som det niveau, hvor de synes, webstedet er velkonstrueret. Vi vil gerne leve op til dette niveau, da det ikke er helt uvæsentligt, hvad Google mener om ens websted, hvis man vil have besøgende fra deres søgemaskine.

Vi har også sat begrænsning på antallet af filer, der kræves for at indlæse en side. Grunden til dette er, at for hver fil, der skal downloades, er der en ventetid, jo flere filer desto længere bliver den totale venten på, at siden bliver færdig. Dette er ikke et særlig stort problem under gunstige forhold, når vi sidder på kontoret, men det mærkes virkelig forskel, når man er på en ustabil 3G- eller Edge-forbindelse ude i yderområderne. Jeg, der plukker masser af svampe, mærker dette, når jeg tager en pause og slapsurfer lidt. Tænk så, hvis man har et vigtigere ærinde end at læse en artikel på The Verge. For eksempel finde nummeret til Giftinformationen, eller lave en billedsøgning efter, hvilke svampe man ikke skal smage på?

Tag ikke vores tal og krav direkte til brug derhjemme. Tag den dialog med jeres leverandør om, hvad der er en rimelig ambition på den platform, I har. Måske skal I lægge kræfterne i ved næste lidt større indgreb på webstedet, snarere end at pudse på det, der snart skal laves om.

Pointen med at oprette en liste over ydeevnekrav til sin stilguide er at have en målbar måde at sikre, at ens websted ikke forringes over tid, eller efter lancering. Snarere at det kontinuerligt forbedres for hver opdatering.

En liste som dette ydeevnebudget kan supplere de testprotokoller, som webudviklerne har, i hvert fald for større websteder, for at verificere, at et webprojekt holder den rette kvalitet. Desuden har mange af os tjeklister for det kommunikative, det vil sige, hvordan tiltalen skal være, og hvilke skriveregler man skal følge, hvilket betyder, at dette bliver en naturlig del af den kontinuerlige opfølgning og refleksion om, hvordan det går for webstedet. Hvis der ikke er en udpeget webanalytiker, er det sandsynligvis en webudvikler, man har brug for til at sammenstille rapporten om, hvordan webstedet præsterer, eller om man bare vælger værktøjer som Pingdom, som de fleste klarer selv. Vi kommer til at tale mere om specifikke værktøjer i næste del af bogen.

Hvis du driver et større websted, er det en god idé at interessere dig lidt for, hvilke tests udviklerne har for at sikre dig, at den rette kvalitet opnås. Disse tests kan være alt fra helt manuelle til fuldstændigt automatiserede. Visse af punkterne i dit ydeevnebudget påvirkes nemlig af den arbejdsgang, som webudviklerne har, og visse af punkterne er enkelt at løse gennem konfiguration af buildservere. Som Jenkins, eller andre værktøjer, som mange bruger til kontinuerlig levering, da mange produktionssætter opdateringer til webstedet - op til flere gange om dagen.

: Billede 34: Stadig flere 'deployer' opdateringer af sine websystemer dagligt.

Men hvorfor er ydeevne så pokkers vigtigt?

Der er mange, der har forsket i ydeevne (her læst som hastighed, ikke nødvendigvis som præstation). Primært plejer man at henvise til Nielsen-Norman Group³³, som har delt det op i tre dele, nemlig at brugeren ved:

0,1 sekunds svartid ophører med at opleve, at svaret er øjeblikkeligt.
1 sekunds svartid begynder tankestrømmen at blive hindret af en oplevet ventetid.
10 sekunders svartid har brugeren svært ved at være opmærksom og vil gøre noget andet i mellemtiden.

Med andre ord forårsager man en kognitiv byrde hos alle brugere, der har en langsom oplevelse. Og som Walmart har vist, er en langsom oplevelse mindre nyttig, ved at brugerne i mindre grad konverterer. Flere beviser for sammenhængen mellem hastighed og nytte kommer straks.

Da Google lavede et genoptag for sit ikke direkte verdensomvæltende sociale netværk Google+ i efteråret 2015, satte de et hårdt ydeevnebudget.

We hit our goal of never downloading more than 60k of HTML, 60k of JavaScript and 60k of CSS at any one time!
- Googles Developer sider³⁴

Google+ gik fra at have haft 22,6 Mb vægt på sin startside til 0,3 Mb (HTML og billeder). Fra 251 filer, der skulle downloades, til kun 45 stykker. 2,77 Mb Javascript og CSS til 0,11 Mb. For indlæsningstider gik de fra 12 sekunder i gennemsnit ned til 3 sekunder. Desuden trimmede de fedtet væk ved at gå fra 0,7 sekunder for brugeren at begynde at modtage filer ned til kun 0,1 sekunder, såkaldt time to first byte (TTFB).

Speed is irrelevant if you are going in the wrong direction.
- Mahatma Gandhi

Som om det ikke var nok, er der rigeligt med studier, der viser sammenhængen mellem ydeevne, og hvor nyttig brugerens session har været. Disse organisationer har delt ud af, hvad der skete med deres tjenester, da de forbedrede hastigheden. Se ydeevnereferencer i slutningen af bogen, for eksempel:

Google: 2% langsommere = 2% færre søgninger per bruger
Yahoo: 400 millisekunder hurtigere = 9% mere trafik
AOL: Hurtigere sider = flere sidevisninger
Amazon: 0,1 sekunder hurtigere = 1% mere omsætning
Shopzilla: 5 sekunder hurtigere = 25% flere sidevisninger, 7 til 12% mere omsætning
Aberdeen Group: 1 sekund langsommere = 11% færre sidevisninger, 7% færre konverteringer.
Gomez: 75 % af brugerne i webshops forlod hellere webstedet til fordel for en konkurrent end tålmodigt at vente.
Tagman: For hvert sekunds langsommere indlæsningstid mister man 6,7 % konvertering, interessant nok konverterer 1-2 sekunders indlæsningstid bedst, ikke de hurtigste (se graf nedenfor).
Etsy: 160 Kb billeder øgede afvisningsprocenten med 12 %.

Som prikken over i'et har Google webydeevne med i sin rangeringsalgoritme, så vil du ikke sakke bagud i søgeresultaterne, er måske også det en gulerod til at kæmpe lidt ekstra med ydeevnen.

: Billede 35: Tagman måler konverteringsniveau baseret på, hvor lang indlæsningstiden er.

For den, der hellere læser akademiske rapporter, så tjek referencerne i slutningen af bogen for at finde eksempler helt siden 1960'erne og frem til i dag. Dér finder du også links til ovenstående fakta, der er mere interessant at hente i de skrivelser.

Hvilke tidlige erfaringer findes fra Västra Götalandsregionens arbejde?

På min arbejdsplads har vi gennemført vores første projekt, der har skullet forholde sig til et ydeevnebudget, nemlig vores opgradering af Episerver CMS. Det er et ret omfattende og komplekst projekt. Der er masser af interessenter højt og lavt i organisationen, da det, der udarbejdes, er en fælles grundstamme for alle forskellige forvaltninger inden for denne meget store organisation med mange vidt forskellige virksomhedsretninger. Den fælles webskabelon skal udgøre grundstammen til et tiendedel ganske store websteder for vores forskellige hospitalsgrupper, primærsektoren, tandplejen og nogle kulturwebsteder.

Nu er jeg selvfølgelig noget partisk, men jeg oplever, at kollegaer og konsulenter efter et stykke tid er begyndt at sætte pris på den konkretisering, som ydeevnebudgettet har bidraget med i visse spørgsmål. Vores webkonsulenter har endda udtrykt, at de er entusiastiske omkring dette. Det glæder mig enormt.

1. "Nu kører vi med denne unikke skrifttype, den gør det hele pænere"

En anden nyttig konkretisering omkring design fik vi, da spørgsmålet om særlige skrifttyper var i overensstemmelse med vores ydeevnebudget. Værdierne omkring integritet spidsede diskussionen om egne skrifttyper til på en givende måde, udover det der havde med ydeevne at gøre. Det viste sig, at udover en årlig abonnementsomkostning for at have en egen skrifttype udelukkende til overskrifter, behøvede vi at inkludere en ekstern CSS-fil for at lade sælgeren af skrifttypen holde styr på, hvor mange sidevisninger vi har. Fordelen ved denne skrifttype var åbenlys, at den så godt ud. Ulemperne blev takket være ydeevnebudgettet ligeledes tydelige og kunne stå som modvægt i vores interne ræsonnement, nemlig at:

Vi var nødt til at have en tredjepartsfil med på alle vores sidevisninger. Det bringer integriteten i fare, at man ikke ved, hvem der ellers lytter med i den kommunikation. Er man ortodoks omkring cookieloven, har vi ikke lov til at bruge tredjeparter på denne måde, i hvert fald ikke uden et aktivt samtykke fra hver bruger, dette inden skrifttypen downloades og appliceres.
En ekstra fil behøvede at downloades, uden nogen direkte gevinst for vores brugere. Vi havde sat 2 stykker CSS-filer som grænse, skulle vi da afgive en af de to udelukkende for, at en ekstern part ville overvåge, at vi ikke overskred antallet af sidevisninger, vi havde købt til en skrifttype?
For at dække de forskellige varianter af skrifttypen, som kursiv, fed, etc., behøvedes op til 4 stykker filer at downloades til brugerne. Under mindre gunstige forhold kan disse filer tage nogle sekunder bare i ren ventetid, uanset hvor små de er. Med andre ord kunne man bare med disse filer sprænge budgettets tiltænkte maksimale tid for download.
Skrifttypefilerne ville samlet veje ind på cirka 80 Kb. Samlet for en hel sidevisning havde vi sat en grænse på 399 Kb. I de fleste sidevisninger ville denne unikke skrifttype blive vist på 2-3 overskrifter på en hel side. Var det da det værd, at 20 % af den totale vægt skulle gå til dette? Fandtes der andre skrifttyper, der fik jobbet gjort med mindre påvirkning?

Så spørgsmålet blev ret tydeligt. Var det det værd for at have en unik skrifttype? Indledningsvis blev svaret et rungende nej. Georgia måtte gå an, den fandtes trods alt allerede hos praktisk taget enhver af vores brugere i deres enheder, helt uden de ulemper, der i og med ydeevnebudgettet blev så åbenlyse for de involverede. Med andre ord blev det ikke udelukkende et spørgsmål om design, typografi og om omkostningen var ok. Diskussionen fik højst håndgribelig konsekvens i forhold til ydeevnebudgettet. I en fremtidig verden, hvor praksis ændrer sig omkring, hvordan vi håndterer de besøgendes integritet, er det ikke givet, at tredjepartsinvolvering overhovedet ville blive tilladt.

Svaret på spørgsmålet var i hvert fald indtil videre at lade være med unikke skrifttyper. Finder vi en løsning, der har mindre indvirkning på ydeevnen, vil beslutningen måske blive anderledes.

2. Sidehovedets baggrund vs kontrastforhold

Helt grundlæggende for god tilgængelighed er, at man har et kontrastforhold mellem forgrund og baggrund. Det mærker man ikke mindst selv, når man forsøger at bruge sin mobiltelefon i stærkt sollys udendørs.

Grunden til, at det kan være svært at leve op til god kontrast mellem tekst og baggrund på et responsivt websted, er, at ting ikke er fikserede i deres position. De flytter ligesom lidt rundt afhængigt af, hvilken plads der er til rådighed. Så i vores første designforslag var vi ikke kommet frem til en løsning, der ikke påvirkede dem med nedsat syn negativt, dermed blev der ikke noget baggrundsbillede. Her kom vi også lidt i konflikt med den grafiske manual, da den krævede dette baggrundsbillede, noget der ikke er et problem med tryksager gennem deres fikserede layout, da man ved præcis, hvor ting er placeret. Dette blev en nyttig øvelse i at diskutere design og pegede måske på behovet for et mere digitalt syn i den grafiske manual.

At kombinere baggrundsbilleder i et responsivt sidehoved og garantere god kontrast viste sig at være en hård nød at knække. Fordi vi ikke følte os overbevist om, at dette kunne blive både flot og tilgængeligt, forsvandt sidehovedets baggrundsbillede med henvisning til overholdelse af tilgængelighedsretningslinjen WCAG.

De her subtile nuanceforskelle, som mange designere ofte er meget afhængige af, fungerer ikke så godt længere i en mobil virkelighed. Samtidig har de aldrig fungeret særlig godt for dem med nedsat syn, først nu opdager vi andre det også.

En relateret anekdote var, da en art director skulle vise det, han havde designet til os. Da nuancerne helt forsvandt, som projektoren viste det, beklagede han sig og forklarede, at det var pænere på hans skærm. Det hjælper ikke. Vi kan ikke forvente, at alle brugere har en sindssygt dyr Ultra-HD-skærm, der er farvekalibreret og har perfekte kontraster. Folk tjekker vores websteder på deres halvt mishandlede mobiltelefon, udendørs midt på dagen midsommer i stærkt solskin. Det er bare, vi vænner os, fortiden kommer ikke tilbage.

3. Hvordan hente eksterne nyhedskilder ind?

Jeg har mange gange irriteret udbrudt "hvor svært kan det være?", når noget har følt sig selvindlysende og simpelt. Et sådant spørgsmål, der syntes at være simpelt løst, fremstod lidt i et andet lys på grund af ydeevnebudgettets mål om sideindlæsningstid.

Der er nemlig et behov for at samle en eller flere eksterne nyhedskilder (via teknikken RSS) og vise dem som en nyhedsspalte på sit eget websted. Det slidte udtryk om, at ingen kæde er stærkere end det svageste led, er tydeligt, når man blander flere parter ind for at kunne vise sin webside. For eksempel, hvordan håndterer man, hvis en af de eksterne nyhedskilder ikke er oppe, eller svarer først efter 10 sekunder? Sådant sker. Ikke mindst under en samfundskrise kan disse problemer begynde at vise sig, men det er nok med, at enten dit eller deres websted får en øget belastning, for at dit websted går ned.

Hvis webstedet skal vise sig på under 3 sekunder, er det bare at begynde at lægge svartiderne sammen for det antal eksterne kilder, man gør sig afhængig af. Der er nok ingen grund til at være sikker på, at alle sammen garanteret svarer på mindre end 3 sekunder, og da har man alligevel brugt næsten hele sit budget for sideindlæsning bare på denne funktion.

Vi er ikke kommet frem til en klokkeklar løsning endnu, der er en passende stor udgift. Et alternativ, som IT undersøgte, er, om man kan bruge en teknisk løsning som mellemled mellem webstederne og de nyhedskilder, der skal overvåges. Så kan man for eksempel forsøge at isolere ventetid og fejlhåndtering til en software, der er god til den opgave, eller i hvert fald bedre end vores CMS.

Ved at indføre et mellemled for netop dette problem får man måske et mere sandt omkostningsestimat, så resten af webstedet ikke skal bære den omkostning. Den specialiserede løsning designes måske til at vente maksimalt 0,2 sekunder på at få svar fra de eksterne kilder. Og får man en isoleret prisseddel for netop denne funktion, kommer man måske frem til, at nyheder er så vigtigt, at det er det værd.

Hvordan få accept for et ydeevnearbejde?

Der er nok mange udfordringer med at sælge behovet for et ydeevnearbejde ind, særligt hvis dem, det berører, ikke har en kultur for målbarhed. Jeg selv har mødt en del modstand, tvivlende kollegaer og deltagere på konferencer, hvor jeg har holdt foredrag om emnet. Det er sundt at være skeptisk, også over for dette. Men jeg tænkte at komme med lidt tips om, hvilke bevæggrunde jeg tror, du kan finde hos dem, du har brug for at påvirke.

En webudviklende ven, på et ikke involveret webbureau, kommenterede, hvorfor han ville sætte pris på at levere i overensstemmelse med et ydeevnebudget, sådan her:

Når nogen stiller krav, betyder det, at de bekymrer sig og værner om resultatet.
- Filip Dalväg³⁵, frontend-udvikler på webbureauet Netrelations

Jeg tror, at mange udviklere er enige med Filip, i hvert fald så snart de har forstået, hvad det handler om. Praktisk taget alle vil gøre et så godt stykke arbejde som muligt, og dette er en målestok for godt arbejde, som udviklere nemt kan tage til sig, det er jo skrevet mestendels på deres sprog. Derefter er det absolut ikke sådan, at der ville herske enighed om præcis, hvad der er god praksis, hvis man spørger to forskellige udviklere. Mange valg er noget, der er en vurdering af, hvad man tror, giver mest nytte, og det er let at havne i nærmest religiøse diskussioner om rigtigt og forkert i, hvordan man mener, håndværket skal udføres.

Pointen med at tage denne diskussion blandt udviklerne, eller med sit bureau, er at forsøge at nå en fælles forståelse af, hvad der er godt, og derefter dokumenterer man det som udviklernes forslag til ydeevnebudget.

For alle, der er involveret i udviklingen eller forvaltningen af et websted, kan man have brug for at sørge for, at følgende aktiviteter gennemføres, muligvis i denne rækkefølge:

Evangelisér budskabet om, at man som gruppe kan gøre det endnu bedre, og vis referencer om, hvilken forskel ydeevne kan have for, at webstedet bidrager med endnu mere værdi til virksomheden. Glem for guds skyld ikke kagen, så folk holder sig vågne! :)
Arrangér foredrag, frokostmøder med diskussioner og uddann folk i emnet.
Workshop et første forslag til ydeevnebudget. Deltagere skal være dem, der kan drift, udvikling, design, og dem der følger op på virksomhedens nytte med webstedet.
Kommunikér ydeevnebudgettet ud! Hvis ikke alle berørte kender til det, vil ikke meget ske. Sørg for, at alle i webstedets "fra jord til bord" kender til ydeevnebudgettet og har fået lejlighed til at udtrykke eventuelle betænkeligheder ved, hvordan det er udformet.
Sørg for, at der er værktøjer til kontinuerlig opfølgning, det er noget, vi der arbejder specifikt med webanalyse, har brug for at gøre, uanset om vi er kommet i gang med aktivt at forbedre ydeevnen. I mit tilfælde, som forvalter af vores ydeevnebudget, planlægger jeg at tjekke vores efterlevelse én gang per kvartal, men mange ydeevnebudgetter vil sikkert udformes, så opfølgning kan ske automatisk hele tiden.
Giv opmærksomhed til de personer og teams, der lykkes med at forbedre ydeevnen på webstedet. Som konsulent plejede jeg selv ofte at fejre mit teams succeser ved at købe lagkage og tilegne fejringen til den, der havde gjort en indsats, der imponerede mig.
Hold dig ajour med udviklingen. Hvad der er praksis inden for webben, ændrer sig hurtigt, og med det også, hvad man gør for god ydeevne. Et spørgsmål er, hvordan en overgang til HTTP/2 påvirker den ydeevneoptimering, der er gjort. Mere om dette i del 4 af bogen.
Kommunikér ændringer. Ydeevnebudgettet vil have brug for at blive forvaltet og opdateret. Jeg selv har planlagt at se det over årligt på min arbejdsplads.

På min arbejdsplads gjorde jeg alt ovenstående selv. Som tidligere webudvikler havde jeg måske lidt lettere end mange andre webanalytikere ved at tage alle detaljer om ydeevneoptimering ind, men primært gjorde mine tidligere erfaringer det lettere at kunne forsvare og begrunde visse vejvalg. Det tog nogle måneder, derefter begyndte vores webkonsulenter at belære mig om nye ting, de havde lært. Som roundtrips over nettet, da alt sendes i 14 Kb-store pakker, samt at de havde forslag til, hvordan vi kunne gøre et endnu bedre stykke arbejde. På en eller anden måde blev konkurrenceinstinktet tændt om, hvordan de kunne overpræstere. Sådant kan jeg lide.

For at få beslutningstagere med på, at dette er værd at lægge lidt anstrengelse i, kan det være succesfuldt først at lave en konkurrenceanalyse. Derefter rapporterer du, hvordan I klarer jer i konkurrencen, og hvilke konkrete aktiviteter I bør tage fat på for at blive (endnu) bedre. Der er masser af værktøjer til dette, og flere af dem vil vi kigge nærmere på i de følgende dele af bogen. En visuel, og dermed meget pædagogisk, måde at vise forskellen mellem ens eget websted og andres er Webpagetest.orgs funktion Visual Comparison. Dér kan man tilføje et eller flere websteder for at se, hvor visuelt komplette de er, og sammenligne dem med hinanden.

: Billede 36: Sammenligner man Aftonbladet med Expressen, er Expressen meget hurtigere til at vise sit indhold på en langsom mobil forbindelse.

Lad os sige, at I er dårligere end den værste konkurrent, det burde være motivation nok til at få et mandat til at begynde at agere og med det et passende budget. Det er webanalytikerens job at undersøge, om der er grund nok til at arbejde med ydeevne, men også at kunne følge op på, at hver indsats er anstrengelsen værd.

Fortsæt med at læse – Del 3: Webanalyse: Fordybelse