Bleau Blog

I Vejle søger borgere lejebolig på mobilen

Peter Terkildsen — Mon, 20 Feb 2012 08:44:45 +0000

Boligsøgning efter lejemål er ofte kendt for sine utallige timer foran computeren. Man skal hele tiden holde sig opdateret på seneste lejemål, opdateringer på ventelister osv. Men tænk hvis det var muligt at finde sit næste lejemål, selvom man altid var på farten. Tænk hvis tiden foran computeren kunne minimeres til et minimum, og i stedet kunne borgere lade de ledige lejemål dumpe ind i mailboksen.

Vi har netop implementeret en mobil hjemmeside for ØsterBO, hvor brugere har mulighed for at besvare tilbud om ledige lejemål via deres smartphone.

Vil du leje denne bolig?

For at skabe den bedste oplevelse for brugeren, leverer vi en mobil hjemmeside, hvor simplicitet er nøgleordet for navigationsstrukturen. Vi har besluttet at fokus særligt skal lægges på én opgave – at brugeren skal kunne acceptere eller afslå et ledigt lejemål på sin smartphone. Den mobile hjemmeside indeholder derfor en begrænset mængde information i forhold til ØsterBOs almindelige hjemmeside, hvilket effektiviserer den specifikke søgning.

Fokus på design og brugervenlighed

Ovenstående betyder ligeledes, at den mobile hjemmeside er begrænset til at indeholde oplysninger om boligforeningen, seneste boliger, indtastning af egne præferencer til et lejemål og kontaktoplysninger. Ring-op-knappen ligger som en direkte genvej til boligforeningen, så man kun er et tryk fra at få svar på spørgsmål, som ikke kunne findes på den mobile hjemmeside. Indtastningsfelterne er begrænset til kun at kunne indeholde, hvad der giver mening at indtaste. Det vil f. eks. sige, at huslejen skal indtastes med tal, for at den mobile hjemmeside forstår det.

Løsningen tillader effektiv boligsøgning, da det giver nogle helt nye muligheder for at holde sig opdateret, uden brug af sene timer foran skærmen. Samtidig er afstanden mellem ØsterBO og deres brugere minimeret, da det kun kræver et enkelt klik, før man er personligt igennem til boligforeningen.

Læs også referencen for casen her

Peter Terkildsen

Partner og forretningskonsulent i Bleau A/S, far til tre børn, ivrig marathonløber og særdeles interesseret i al ny teknologi. Har i Bleau ansvaret for at udvikle nye spændende koncepter til vores kunder. Jeg skriver om alt, der interesserer mig, og som jeg falder over, når jeg arbejder med vores kunder.

Webanalyse case [2 af 3]: Hvordan fikser jeg mine fejlsider

Esben Rasmussen — Wed, 15 Feb 2012 11:00:41 +0000

I del 1 af denne webanalyse case gennemgik jeg, hvordan vi opdagede årsagen til de mange besøg på fejlsider (404) hos en af vores kunder. I denne fortsættelse gennemgår jeg, hvordan vi fik løst problemet ved at sende brugerne ind på de rigtige sider alligevel.

Som tidligere nævnt var problemet, at langt de fleste brugere fik en fejl, fordi de forsøgte at tilgå sider, hvis url tidligere indeholdt oplysninger om det valgte sprog – men hvor informationen om sproget nyligt var blevet udeladt for at undgå duplicate content.

Kundens url før ændring: www.kundensWebsite.com/en-IE/enEngelskWebside.aspx
Kundens url efter ændring: www.kundensWebsite.com/enEngelskWebside.aspx

Det væsentligste af problemerne var alle fejlene, som strukturændringen af url’erne medførte.

I samråd med kunden løste vi det ved, at vi på serverniveau (dvs. uden om deres CMS – af hensyn til kompleksitet) oprettede følgende generelle regler:

/en-IE/ -> www.kunde.com
/nl-NL/ -> www.kunde.nl
/en-GB/ -> www.kunde.co.uk
/de-DE/ -> www.kunde.de
/en-US/ -> www.kunde.com
/cs-CZ/ -> www.kunde.cz

Dvs. forsøgte en bruger at tilgå www.kunde.de/en-IE/nogetEngelskIndhold.aspx ville brugeren i stedet blive sendt til www.kunde.com.

Det ideelle havde selvfølgelig været, at sende brugeren over på den tilsvarende side i stedet for bare forsiden, men da siderne adskiller sig fra land til land, var der ingen garanti for, at der fandtes en tilsvarende side. Efter økonomiske og strategiske overvejelser blev denne løsning valgt som den mest passende i kundens situation.

Som det fremgår af grafikken opdagede vi også to andre tendenser til fejlsider:

At der kom mange besøg på fejlsider, fordi folk forsøgte at tilgå kundens forrige website (hvor siderne alle endte på “.asp”, mens siderne på de nye website ender på “.aspx”).
At andre eksterne hjemmesider sendte linkkærlighed, brugere og SEO-værdi til bestemte sider på kundens hjemmeside – sider som ikke længere findes fordi de enten er blevet fjernet eller omdøbt sidenhen.

Disse fejl kan kunden heldigvis selv fange ved i sit CMS at opsætte det, som i fagsprog hedder 301-redirect. En 301-redirect er i virkeligheden en måde, hvorpå man fortæller serveren, at hvis brugeren beder om at få vist indholdet på adresse A, så skal serveren i stedet vise indholdet på adresse B.

Lad os sige, at vi har flyttet siden “Medarbejdere” fra www.kunde.com/Om-os/Medarbejdere.aspx til www.kunde.com/Medarbejdere.aspx.

Hvis andre hjemmesider har linket til den tidligere placering, vil disse link nu ikke længere virke.

I Dynamicweb kan man heldigvis opsætte de nødvendige 301-redirects, så linkene alligevel virker:

Naviger hen til "Management Center"
Vælg "Direkte stier"
Vælg "Tilføj"
Opsæt din redirect
Afslut med at klikke på OK-knappen

Nu er der oprettet en redirect, så folk der forsøger at tilgå www.kunde.com/Om-os/Medarbejdere.aspx bliver sendt ind på www.kunde.com/Medarbejdere.aspx.

Det gode ved redirects er, at de virker for tid og evighed, når først de er sat op. Dvs. når kunden har sat dem op én gang, behøver de ikke gøre det igen.

Dog skal redirects vedligeholdes, hvis man igen skifter url-struktur. Dvs. hvis de url’er, redirect’en sender brugerne ind på, stopper med at virke efter ny strukturændring, skal man vedligeholde redirect’en så den fortsætter med at sende folk ind på url’er der virker.

Via redirects kunne vores kunde heldigvis fange de resterende besøg på fejlsiderne ved at omdirigere og dermed beholde brugerne og den gode SEO-værdi, som blev sendt ind på hjemmesiden.

Opsummeret betyder det altså, at det både lykkedes os at fjerne kundens voldsomme problem med duplicate contet OG at sikre en god oplevelse for de brugere, som forsøgte at benytte url’erne fra den gamle struktur. Som en sidegevinst opdagede kunden, at der var gode indkomne links, som pegede på døde sider hvilket gav mulighed for en quickwin både i forhold til brugervenlighed og ikke mindst også SEO ved at omdirrigere trafik fra disse links.

Alt dette skulle kun løses én gang, hvilket betyder, at kunden i fremtiden ikke behøver at bekymre sig – nu er det sat op, og det virker helt automatisk.

I det næste og sidste indlæg i denne case, vil jeg gennemgå, hvordan kunden kan forhindre at sådanne situationer kommer som ubehagelige overraskelser, som de tilfældigt opdager.

Relaterede indlæg

Esben Rasmussen

Konsulent med speciale i markedsføring og kommunikation på nettet. Udenlandsk gift og lidt af en sprog- og kommunikationsnørd. Har ansvaret for webanalyse, SEO og user experience. Blogger bl.a. om Google Analytics, neuromarketing og generel webanalyse.

Mail | Web | Twitter | LinkedIn

Skab en bedre brugeroplevelse med bedre knapper – del 2

Peter Terkildsen — Thu, 02 Feb 2012 18:43:18 +0000

Denne artikel er en fortsættelse af et blogindlæg, som handler om knapper i formularer, og om hvordan dårligt designede knapper kan føre til en forringet brugeroplevelse. Hvis du ønsker at læse første del, så kan du gå til siden her.

Pas på med slette- og reset-knapper

HTML-standarden åbner op for muligheden for, at man kan anvende en reset-knap, som gendanner alle standardindstillinger i formularen, og som dermed sletter alt det, som brugeren netop har indtastet. Det er en farlig knap!

Grunden til at den er farlig er naturligvis, at den kan slette alt det, som brugeren har indtastet – til stor frustration for brugeren. Risikoen for at dette sker, bliver større jo mere identisk knapperne er. Det vil sige, at hvis både den primære knap, som leder brugeren videre, og den sekundære knap, som sletter alt indhold i formularen, er identiske, så er der en vis risiko for, at brugeren kommer til at trykke på den forkerte knap. Og hvis de to knapper står i forkert rækkefølge, så er risikoen endnu større.

Eksempel på slette-knap fra www.bilka.dk

Hvis man endelig skal anvende den slags knapper, så sørg i det mindste for, at der er stor visuel forskel imellem de to. Dette princip ses i nedenstående eksempel fra danski.dk.

En anden god ide er, at give mulighed for at brugeren kan fortryde sin sletning. Dette kan ske ved, at man sørger for at browseren husker de slettede data, så brugeren kan gendanne dem igen.

Eksempel på stor visuel forskel imellem primær knap og slette-knap

Vis brugeren at formularen er under behandling

Brugere er notorisk utålmodige og langsomme formularer kan hurtigt blive årsag til mindre raserianfald. Hvis webserveren skal bruge lang tid på at behandle de indtastede data, så sørg for at det er tydeligt for brugeren, at webserveren er i gang med at arbejde. Dette kan eksempelvis ske ved, at man skjuler formularen bag et ikon, som indikerer, at serveren arbejder.

Når man lægger en bolig i kurv på www.kab-bolig.dk vises denne grafik

Samtidig så sørg for, at deaktivere godkend-knappen, så brugeren ikke kan indsende flere gange. Risikoen er, at data kan indsendes mange gange, hvilket fører til korrupte data.

Sørg for at teksten på knappen fortæller hvad knappen gør

Rigtigt mange knapper har standardteksterne “Godkend”, “Ok” eller “Videre”. Det er naturligvis ikke særligt sigende. Det er langt bedre at fortælle mere om den handling, som foretages, når formularen indsendes. På www.danski.dk benyttes teksten “Bestil” ved bestilling af rejsekataloger.

Eksempel på knap med tekst, der har fokus på handling

Og på www.toejeksperten.dk anvendes teksten “Fortsæt bestilling”.

Et andet eksempel fra Tøjeksperten

Et lille forbehold

Som i første artikel, så skal det understreges, at ovenstående eksempler på best practices er generelle guidelines, som er indsamlet af eksperter i usability. Disse guidelines er verificeret igennem undersøgelser, som har dokumenteret, at det virkelig forholder sig som beskrevet ovenfor. Men derfor skal man dog alligevel være opmærksom på, at når man bygger formularer på sin egen hjemmeside, så skal disse formularer selvfølgelig testes af.

Hvis du har spørgsmål til dette indlæg, så skriv gerne en kommentar nedenfor, eller kontakt mig på pt@bleau.dk eller 29 47 91 09.

Relaterede indlæg

Peter Terkildsen

Skab en bedre brugeroplevelse med bedre knapper – del 1

Peter Terkildsen — Thu, 02 Feb 2012 14:17:18 +0000

Har du tænkt over, at knapper i formularer kan være afgørende for hvor mange, der rent faktisk ender med at indsende formularen?

Formularer er en så integreret og vigtig del af hjemmesider, at de fleste af os sjældent lægger rigtigt mærke til dem. Det vil sige – vi lægger først rigtigt mærke til dem, når de ikke fungerer, og når det er besværligt for os at gennemføre vores handlinger. Uanset om der er tale om en søgning eller indtastning af en leveringsadresse.

Formularer anvendes, fordi der er et ønske om at få brugeren til at foretage en handling. Det kan være i form af en søgning (Google) eller i form af indtastning af data. Når brugerne får en dårlig oplevelse på grund af en formular, så kan det føre til, at der er færre brugere, som rent faktisk gennemfører handlingen, og dermed opnås et dårligere resultat.

Der er derfor en stor interesse i at udvikle formularer, som er så brugervenlige som muligt. I det følgende – og i kommende blogindlæg – tager jeg derfor fat på forskellige delelementer af det at konstruere en brugervenlig formular, som giver en højere konvertering.

I dette blogindlæg er emnet knapper. Det er ikke et særligt sexet emne, men dårligt designede knapper i en formular kan være med til at reducere brugen af formularen, og derfor bør man som ejer af en hjemmeside fokusere på det. Der er tale om første del ud af to.

Det skal ikke være nogen hemmelighed, at inspirationen til nedenstående eksempler på korrekt anvendelse af knapper kommer fra Luke Wroblewski, som er tidligere Lead User Interface Designer hos Ebay og Chief Design Architect hos Yahoo! Han har skrevet flere bøger om usability – en af de mest interessante er bogen ”Web Form Design: Filling in the Blanks” fra 2008. Denne bog er baseret på Luke’s store erfaring og på en lang række usability tests, som Luke gennemførte på henholdsvis eBay’s og Yahoo’s hjemmesider. Du bør læse denne bog, som kan købes her: http://rosenfeldmedia.com/books/webforms/. Den kan varmt anbefales!

Checkliste for knapper i formularer

Når du skal konstruere en formular, så bør du tage hensyn til følgende best practices for knapper:

Undgå sekundære knapper
Visuel afstand mellem primær og sekundær knap
Primær knap leder brugeren imod målet
Gør det nemt at se den primære knap
Pas på med slette- og reset-knapper
Vis brugeren at formularen er under behandling
Sørg for at teksten på knappen fortæller hvad knappen gør

Dette blogindlæg handler om de primære og sekundære knapper i en formular.

Undgå sekundære knapper

Når man har en formular, så er der altid én knap, som gemmer formularens data på webserveren, eller som sender brugeren videre i forløbet. Dette er den primære knap, og det er den knap, som man ønsker, at brugeren skal benytte. Alle andre knapper er sekundære.

Det er vigtigt, at brugeren nemt kan finde ud af hvordan formularen udfyldes og indsendes. Derfor er der ingen grund til at skabe unødig forvirring ved at introducere flere forskellige knapper på siden. Brugeren skal hurtigt kunne finde frem til den primære knap, og flere knapper gør det blot mere besværligt.

Stofa har en primær knap og en sekundær, som er næsten identisk

Ovenstående skærmbillede, som er taget fra stofa.dk, viser et eksempel på brugen af primære og sekundære knapper. Da de to knapper har samme farve og størrelse, så er brugeren nødt til at forholde sig til begge knapper – hvilket betyder, at brugeren skal bruge endnu mere tid på at scanne indholdet.

Det er i øvrigt værd at bemærke, at disse knapper dukker frem på den første side i indkøbsforløbet på stofa.dk – hvilket dermed betyder, at det ikke er muligt at gå tilbage i forløbet. Derfor er knappen “Tilbage” ikke relevant i denne del af forløbet og kunne med fordel fjernes.

Tøjeksperten har næsten identiske primær og sekundære knapper

Problemet med den primære og den sekundære knap ses også på Tøjekspertens hjemmeside www.toejeksperten.dk, hvor der er en primær knap med teksten “Næste” og en anden med teksten “Indløs rabat”. Man kan godt se, at der er en lille forskel i størrelsen på de to knapper, men det er ikke en stor forskel, og problemet forværres af, at der er tale om samme farve på knapperne og de er placeret i samme kolonne.

Visuel afstand mellem primær og sekundær knap

Der er naturligvis tilfælde, hvor der er behov for at anvende en primær og en sekundær knap. Dette ses ofte i indkøbsforløb, hvor der er behov for at gå frem og tilbage i forløbet. Men pointen er, at hvis der er behov for at anvende en primær og en sekundær knap, så sørg for, at der visuelt er stor afstand imellem dem.

På Smartguys hjemmeside er der stor visuel forskel imellem knapperne

I indkøbskurven på www.smartguy.dk er der to knapper. Den ene har teksten “Shop videre” og den anden “Gå til kassen”. Der er ingen tvivl om hvilken knap, der er den primære knap i dette tilfælde. “Gå til kassen” er både større og mere markant end “Shop videre”. Derfor kan brugeren ret hurtigt danne sig et indtryk af, hvad der skal ske nu.

Primær knap leder brugeren imod målet

Når en formular spænder over flere forskellige sider, så udgør den primære knap den knap, som leder brugeren videre i forløbet. Eksemplet nedenfor viser en formular fra stofa.dk:

Eksempel på at den primære knap leder brugeren videre

Gør det nemt at se den primære knap

Det skal være så nemt som muligt for brugeren at overskue formularen. Derfor anbefales det at justere formularen, så de enkelte indtastningsfelter står i én kolonne, og derfor bør man også placere knappen, så denne står i samme kolonne som felterne. I ovenstående eksempel fra stofa.dk står knappen yderst til højre hvilket gør, at brugeren skal bruge længere tid på at scanne formularen.

Et lille forbehold

Det skal naturligvis understreges, at ovenstående eksempler på best practices er generelle guidelines, som er indsamlet af eksperter i usability. Disse guidelines er verificeret igennem undersøgelser, som har dokumenteret, at det virkelig forholder sig som beskrevet ovenfor. Men derfor skal man dog alligevel være opmærksom på, at når man bygger formularer på sin egen hjemmeside, så skal disse formularer selvfølgelig testes af.

Hvis du har spørgsmål til dette indlæg, så skriv gerne en kommentar nedenfor, eller kontakt mig på pt@bleau.dk eller 29 47 91 09.

Relaterede indlæg

Peter Terkildsen

Webanalyse case [1 af 3]: Hvorfor ser mine besøgende fejlsider

Esben Rasmussen — Fri, 27 Jan 2012 10:48:18 +0000

Ved hjælp af webanalyse hjalp jeg for nyligt en af vores kunder med en sag, som jeg synes kunne være interessant at dele med jer her på bloggen.

Kort fortalt gik det ud på at kunden i sin Google Analytics opdagede, at der pludselig kom mange besøg på fejlsider – og rigtigt mange af disse var amerikanske brugere.

De vigtige spørgsmål var nu:

Hvordan var dette sket?
Hvordan kunne det fikses?
Hvordan undgår kunden at det sker igen?

Mange amerikanere fik vist fejlsider

I dette indlæg gennemgår jeg, hvordan vi kunne analysere os frem til, hvad årsagen var til de mange fejlsider. I de kommende indlæg vil jeg gennemgå, hvordan vi nedbragte antallet af fejlsider og hvordan du kan fremtidssikre dig mod, at dine ændringer forårsager fejlsider.

Som nævnt starter historien med, at kunden i sin statistik ser, at ca. halvdelen af alle amerikanske brugere rammer en fejlside (også kaldet en 404-side), hvorefter jeg bliver kontaktet af webmasteren med beskeden “Har vi et problem?”. (Jeg tvivler på, at jeg ville kunne have fremstået helt så cool i samme situation)

Efter et hurtigt kig på deres data måtte jeg jo give ham ret… De havde et problem.

Heldigvis havde vi seks måneder forinden hjulpet kunden med at opsætte et avanceret Google Analytics script, som bl.a. registrerer besøg på 404-sider med både den url, man forsøgte at nå og med den side man kom fra.

En normal 404-side kan ofte findes på url’en /404.html, men vores avancerede script tilføjer “?page=denSideManForsøgerAtTilgå&from=denSideManKomFra“. “from” baseres på oplysninger i brugerens browser. Kom brugeren f.eks. fra et link i en mail, der blev læst i Outlook, vil “from” være tom, da der ikke findes nogen forrige side i browserens historik.

Jeg kunne derfor relativt let finde frem til, hvad årsagen var ved at se på oversigten over kundens sider og lave en sortering på “404″.

Webanalysen afslørede fejlkilderne

Det viste sig ret hurtigt, at den primære synder på fejlsiderne var de tilfælde, hvor der indgik landekode i url’en.

I den undersøgte dataperiode (den sidste måned) stod de fejlsider, hvor landekoden indgik i url’en, for minimum 532 besøg på 404-siden mens der totalt set var 1207 besøg på 404-siden i perioden. Dvs. ca. 44% af alle fejl skyldes sider, hvori landekoden indgår.

Forklaringen på dette var, at kunden, for at undgå duplicate content (som vi alle ved skal undgås for enhver pris!), fornuftigt nok havde valgt at ændre sin url-struktur.

Tidligere var strukturen:

Engelsk website: www.kundensWebsite.com/en-IE/enEngelskWebside.aspx

Tysk website: www.kundensWebsite.de/de-DE/enTyskWebside.aspx

Her er problemet: www.kundesWebSite.com/de-DE/enTyskWebside.aspx

Altså fandtes det tyske indhold på både det tyske og det engelske domæne og omvendt. Det samme var tilfældet, hvis man f.eks. brugte den hollandske landekode (“nl-NL”) på kundens “.dk”, “.co.uk” eller et hvilket som helst andet internationalt domæne fra kunden; Så ville man kunne tilgå det hollandske indhold der.

Ændringen betød at url-strukturen ikke længere indeholdt landekoder og den nye struktur ser derfor således ud: www.kundensWebsite.de/enTyskWebside.aspx

Størstedelen af fejlsiderne skyldtes altså, at nogle af kundens brugere stadig forsøgte at tilgå websiderne via den gamle url-struktur, som netop indeholdt landekoder.

Kunden vurderede oprindeligt, at struktur-ændringen kun berørte interne links og at det derfor ikke ville skabe større problemer for brugerne.

Heldigvis var kunden vågen og opdagede efterfølgende, at der var noget, som ikke stemte.

Et nærmere kig på statistikken viser da også en klar stigning i besøg på fejlsiden efter en bestemt dato – og de fejl, der dominerer efter denne dato skyldes landekoder.

I det næste indlæg i rækken, kan du læse mere om, hvordan vi sammen med kunden rettede problemet, og hvad kunden selv kunne gøre for at mindske antallet af fejlsider.

Relaterede indlæg

Esben Rasmussen

Mail | Web | Twitter | LinkedIn