Overvejer du responsive design? Sådan gjorde Jyske Bank

Ét website til både mobil, tablet og pc. Læs Jyske Banks gode råd til, hvordan du kommer i mål.

Da Jyske Bank stod over for at give sin gamle hjemmeside en tiltrængt overhaling, kunne man vælge to veje:

Den ene var at designe særskilte hjemmesider til pc'er og mobile enheder. Den anden var at designe ét site, som klarer begge dele uden at blinke.

Beslutningen var egentlig ikke svær, for presset voksede fra flere sider. For det første var Jyske Banks website ved at være slidt i kanten - og skulle alligevel lægges om og på ny platform. For det andet kom en stadig stigende andel af trafikken fra mobile enheder.

Løsningen blev teknikken responsive design, som bruges til at designe websider, der automatisk tilpasser sig forskellige skærmstørrelser.

På den måde kan hjemmesiden kodes én gang, men samtidig optimeres til at blive vist på både pc'er, mobiler og tablets.

»Vi vidste, vi skulle lægge hele det bedagede jyskebank.dk om. Spørgsmålet var bare, om vi skulle udvikle to separate sites, eller om vi skulle gå efter responsive webdesign, der dengang var bleeding edge-teknologi. Vores egen oplevelse med mange mobilsites var, at de føltes amputerede. Du føler, du bliver snydt for indhold - og sidder bare og kigger efter ”Se den fulde version”. Du kan jo lige så godt sidde hjemme i sofaen med mobilen fordi du ikke gider rejse dig og finde den bærbare computer«, siger Gorm Ruge, der er onlinestrateg i Jyske Banks kommunikationsafdeling.

Responsive design adskiller sig på den måde fra modellen, hvor man udvikler separate hjemmesider til de forskellige platforme.

Dertil kom hele udfordringen ved at skulle holde to websites opdaterede, og så blev beslutningen endnu lettere at træffe.

»Vi kiggede med glubske øjne på responsive web og traf den endelige beslutning i foråret 2011,« siger Gorm Ruge til Version2.

Men hvordan griber man så projektet an? Giver det for eksempel mening af lancere en ny responsiv forside, hvis alle undersiderne stadig ligger på det gamle system?

»Vi har kørt en iterativ proces, hvor vi løbende har udskiftet sider og indholdsområder bid for bid. Men vi ventede til december 2011 med at lancere forsiden, så bagkataloget havde en vis størrelse. Vi frygtede lidt, at brugerne ville blive forvirrede, hvis vi blandede de to koncepter for meget, men en brugertest viste, at de ikke engang bemærkede skiftet mellem det gamle og det nye,« siger Claus Stadel, der er produkt- og designpsykolog af uddannelse og arbejder med webdesign og user experience i Jyske Banks it-afdeling.

Jyske Bank havde indtil relanceringen baseret hjemmesiden på et egetudviklet cms, der går under navnet "webredigering". I forbindelse med hele projektet flyttede man sitet over på IBM Portal Server, der er en teknologi, Jyske Bank har brugt i flere år.

Mobile first og færre sider

En af de store udfordringer, da Jyske Bank skulle omlægge hjemmesiden var at få skåret et meget stort site til, som i årenes løb var vokset og vokset i omfang. “Build the site, you can manage”, var mantraet.

Dette fokus på at skære ind til benet og fokusere på det vigtigste, det viste sig at gå hånd i hånd med at bygge enkle elastiske websider, der er optimeret til både en stor desktop-skærm men også en lille mobil-skærm.

»Vi gik fra at tænke desktop, hvor indhold og komponenter kan strække sig mageligt over flere kilometers bredde - men når du bygger responsive sider, så er du altså nødt til at bygge noget, der kan foldes ud og foldes sammen. Det starter med, at du tænker mobile first«, siger Claus Stadel.

Erfaringen har været, at hver gang et indholdsområde er blevet lagt om fra gammelt til nyt, så er der ca. 50% færre sider.

»'Less is more' - blev et andet mantra for os i projektet. Det har faktisk overrasket os, at vi har kunne skære så meget indhold væk, uden vi føler, at vi er gået på kompromis i forhold til at vise, hvad vi har på de finansielle hylder. Men det har været vigtigt for os at reducere mængden af indhold for at få en mere overskuelig hjemmeside med “skarpere” sider med klarere call-to-action”, forklarer Gorm Ruge

Både Gorm Ruge og Claus Stadel erkender, at mobiltrafikken på jyskebank.dk næppe kandiderer til at komme i Guiness rekordbog, men dette skyldes for en stor dels vedkommende, at banken har en dedikeret app til netbank.

En af de største mundfulde, når man giver sig i kast med responsive webdesign er test.

»Man skal virkelig spænde hjelmen i forhold til test. Der er vildt mange devices derude,« siger Claus Stadel og bliver suppleret af Gorm Ruge og uddyber:

»Det er en stor opgave at teste. For du kan ikke regne med det, du ser i et resized vindue. Du skal regne med op mod 20 procent større omkostninger til udvikling af markup og CSS – men når du først har alle standarder og skabeloner på plads – så kan en webredaktør sprøjte de responsive sider ud, helt som var det almindeligt web uden merudvikling,« fortæller Gorm Ruge.

Jyske Bank har testet og tester løbende på iPad, iPhone, en Android 4.0- og en Android 2.3-telefon. Windows Phone er endnu ikke med i testene, men det er på vej.

»Et praktisk tip: Adobe har lavet et smart program, der hedder Shadow, som kan mirror'e, hvad du gør på desktoppen over på en række devices, der er tilkoblet via wifi. På den måde kan du ret hurtigt klikke dig igennem 50 sider,« siger Claus Stadel.

Tips og korrekturforslag til denne historie sendes til tip@version2.dk
Følg forløbet
Kommentarer (23)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
Michael Lykke

Det virker som om Jyske Bank har fat i den lange ende når det kommer til at gøres deres systemer tilgængelige. Ikke alene har de investeret store summer i en gennemført mobil app i samarbejde med Trifork og Design IT, men de viser også en stor forståelse for at arbejdet fortsætter med deres website.
Det er godt gået og bør være et eksempel til efterfølgelse af andre, ikke kun banker.

  • 6
  • 0
Martin Hintzmann

Det er et rigtig godt lavet Responsive Web Design med brug af Progressive Enhancement.

Lækker HTML5-kode — HTML5 form elementer/attributter, HTML5 semantik, HTML5 microdata, WAI-ARIA, etc.

Smuk CSS3-kode — Gradienter, runde hjørner, transitions, box-/text-shadow etc.

Kudos til frontend-udviklerne... dyb respekt... Den sidder fandme lige i skabet :D

  • 7
  • 0
Lars Bjerregaard

Nu er det muligt at jeg har misforstået kernekonceptet i "Responsive Design" fuldstændig, og det hører jeg gerne om.

Men....

Som jeg har forstået RD, så går det fundamentalt ud på, at ved at anvende mulighederne i nye web-standarder (primært CSS og javascript), samt mulighederne i den nyeste generation af (mobile+desktop) webbrowsere, så kan man, for den samme/identiske genererede HTML, få et UI som automatisk er tilpasset/"optimeret" til den pågældende enhed.

Glimrende! Og det er da afgjort en slags fremmskridt.

Men.....

Der hvor kæden hopper helt af for mig er følgende: Optimeret til en mobil-enhed, lad os sige en smartphone du bruger i bussen på vej til arbejde, handler om mere end hvordan UI ser ud. Optimeret har i ekstrem grad også at gøre med de datamængder (og dermed CPU-forbrug, batteriforbrug, load-tid, båndbredde-pris, etc.) du overfører til enheden. Så det er fint nok, at du med samme kodebase/HTML-generator på serverside, kan præsentere et UI som er tilpasset enheden, hvad udseende angår, men det er (IMHO) totalt no-go, hvis det betyder at datamængden er uændret.

Fint nok at overføre 50, 100, whatever KB ialt,for at vise et site til en desktop browser, eller til nød en tablet på WIFI. Til en smartphone, på mobil-data? No f*cking way!

Fortæl mig at jeg har misforstået noget, please....

  • 4
  • 4
Morten Hansen

Der er store forskelle på siden ud fra de forskellige screenshots.
Jeg vil da mene at der er nogen der har siddet og bestemt hvordan elementer skal opdeles og gøres til og fra alt efter den real-estate skærmplads man har til rådighed. Er her så virkelig tale om ét website til alle devices?
Det kommer an på hvordan rokeringen er gjort. Jeg tvivler på med de store forskelle vi ser her at det er sket "automagisk", der er nogen der sidder og fedter med fingrende i gruset for at få det til at være helt rigtigt.

  • 0
  • 0
Martin Kofoed

Er her så virkelig tale om ét website til alle devices?

Ja, det vil jeg afgjort mene. Og den bedste måde at se "magien" på, er ved at loade siden i en almindelig browser, tage fat i siden af vinduet og så ellers trække det frem og tilbage for derved at manipulere sidebredden.

Som nævnt er hele molevitten bygget op med fleksible grids med 12 kolonner i bredden. I praksis kan redaktørerne nu selv bestemme, hvor mange kolonner en given container skal fylde. Det kunne være en "3-3-6"-container, hvor de to første under-moduler i DOM'en vil optage 3 kolonner hver, og den sidste vil optage 6. Media queries definerer herefter, hvornår kolonnerne kollapses ind under hinanden.

Helt konkret er det hele bygget op med et custom theme til WebSphere Portal, og de enkelte celler i grid'et fyldes ud med de portlets, som er portalens grundlæggende byggeklodser. Portlets kan naturligvis klones, konfigureres og genbruges på tværs af både sider og sites.

PS: Jeg skulle hilse og sige tak for de fine kommentarer fra hele teamet :)

  • 4
  • 0
Morten Maate

Først og fremmest tilslutter jeg mig gerne begejstringskoret. Good work - og wauw, hvor trængte den gamle hjemmeside da også til en overhaling :-D

Men jeg synes faktisk, at Lars Bjerregaard har en pointe her. Når vi optimerer til mobil, skal vi selvfølgelig både optimere til brugerens design-oplevelse OG til brugerens oplevelse af svartider m.v. (altså til ikke-funktionelle krav, som netop er anderledes på en mobil platform).

Jeg mener godt, at man inden for rammerne af responsive design kan løse begge problemer, så her er jeg ikke helt enig med Lars' problematisering - det er altså ikke nødvendigvis et uløseligt problem ved responsive design. Men på trods af det fine site, falder JyskeBank tilsyneladende i netop denne fælde alligevel.

Et hurtigt kald til JyskeBank.dk i mobil-opløsningen afslører, at der foretages 74 requests mellem klient og server. Det kan min almindelige pc klare på 8 sekunder (hvilket er lidt i overkanten, men ok). Min smart phone derimod bliver tvunget helt i knæ med 30 sekunders load + 8 sekunders rendering (hvilket ikke kun er lidt i overkanten) og dog 10-15 sekunder hurtigere herefter, men stadig 18 - 24 sekunder i alt. Til sammenligning loader mobilsiderne af Politiken, Berlingske og Version2 på 5 - 10 sekunder i samme smart phone.

Der er heller ikke kun tale om 50 eller 100 kb, men (i skrivende stund) om hele 500 kb data, som hovedsageligt udgøres af tre forsidebilleder, der ikke vises i mobil-opløsningen. Hvorfor skal de så loades?

Forstå mig ret - good work, guys - det ser sgu lækkert ud. Der er ingen pegen fingre herfra! Og moderne web sites er jo heller ikke skruet sådan sammen, at de er komplette fra dag ét - disse problemer kommer teamet sikkert til at se nærmere på, men det er en relevant debat for netop denne artikel, at en del af brugeroplevelsen også er den ikke-funktionelle opførsel, som måske ofte overses i netop Responsive Deisgn-debatten, og som faktisk heller ikke er helt enkel at gøre perfekt:-)

  • 5
  • 0
Martin Kofoed

Ja, Lars' pointe er helt valid, og jeg er grundlæggende enig i, at der ikke bør sendes overflødig data ud pga. support for forskellige platforme. Men lige nu går det faktisk begge veje - eksempelvis er mange billeder sendt til desktop browsers dobbeltstørrelse af hensyn til iPad3'ens retina-display. Altså ikke noget, desktop-browserne får glæde af overhovedet. I processen med at gøre oplevelsen så lækker som mulig på alle platforme, er brugeroplevelsen prioriteret over netværksload i første omgang.

Når alle områder af jyskebank.dk er blevet moderniseret, ligger der masser af optimeringsopgaver og venter, både mht. interne servicekald, netværksload, loading af scripts etc. etc.

  • 3
  • 0
Martin Hintzmann

Morten har ret, der er plads til optimering på antallet af filer og størrelserne.

Billeder og Javascript filer er det der fylder mest på jyskebank.

ySlow siger ved empty cache 61 HTTP request og fylder 1.439 kb
og ved primed cache 17 request og 482kb, hvor 471kb er billeder der IKKE er cachet.

På serversiden bør der sættes gzip op på JS-filerne.
Der er 6 JS-filer af i alt 257 Kb som ikke bliver gzip'et.
Det kan komme et godt stykke under 100 Kb ved gzip.

Der er en lille optimering på PNG-sprite-fil der kan gøres mindre fra 126kb til 117kb (92%) ved hjælp af punnyPNG eller PNGOUTwin

Men spritene kan optimeres yderligere.
F.eks. produkterne til produkthylden, her kan man nøjes med selve ikonet og lade CSS3 gradient og box-shadow håndtere mouse-over på kasserne bagved ikonet.

Der er 3 PNG forside billeder, som til sammen fylder 381 Kb.
Jeg ved godt hvorfor der er valgt alpha PNG-billeder, men det er altså mega tungt.
Jeg vil anbefale at konvertere dem til JPG-billeder.
JPG-billederne vil nok fylde under en 5-del af PNG'erne, altså under 80 Kb.

Lige nu bliver de 3 forside billeder hentet på alle enheder.
Dette findes der flere løsninger til.
Jeg har brugt følgende førhen med succes.

Indsætte et div-element i HTML-koden istedet for et img-element.
Og så i CSS via media-queries indsætte billederne kun til store skærme.
Enten via background-image eller content.
Hvis CMS'en kræver det kan CSS'en evt. indsættes direkte i HTML-koden i en style-block.

For at nedsætte HTTP-request bør CSS- og JS-filer samles, enten manuelt eller lave et system der kan håndtere det automatisk.

Man bør også være opmærksom på at der kommer rigtig mange CSS- og JS-filer fra facebook.

Der er sikkert flere ting der kan optimeres, men ovenstående er et godt sted at starte.

  • 6
  • 0
René Pjengaard

Først og fremmest rigtig flot løsning. Godt arbejde! Det er en super oplevelse af "lege" med browser-vinduet og se magien.

Responsive Design er en god teknologi, men jeg synes (som mange af de andre der har kommenteret på denne tråd), at idéen med det mobile forsvinder i de store datamængder. Det er selvfølgelig smart, at man kan bruge den samme side til alle platforme, men det kan også løses ved at bruge enheds optimeret "kanalvalg". Dvs at serveren finder ud af hvilken enhed der besøger sitet og servere så den markup/css/js der er optimeret til enheden. Det er stadig den samme side og data, men serveret på en optimeret markup. Derudover, kan man så bruge RD til at fintune inden for de forskellige kanaler (f.eks. de forskellige skærmopløsningen inden for telefoner / tablets / desktops). Så kan man i sit kanalvalg tage stilling til hvilke elementer/data der skal med i markup´en, og så style det forskelligt med RD ud fra skærmstørrelse.

  • 1
  • 0
Claus Stadel

Først og fremmest tak for de mange positive tilbagemeldinger og den konstruktive kritik af jyskebank.dk.

... og indrømmet der er så absolut rum for performance forbedringer både på mobile enheder og teknologisk bedagede desktop browsere. Indførelsen af responsivt design på jyskebank.dk har i høj grad været en designdrevet proces snare end en teknologidrevet proces.

Et af vores mantra i projektet har været build the site you can manage primært vendt mod indholdssiden. Man kan måske sige at vi også har arbejdet efter build the site you can manage TO BUILD. Omlægning til responsivt design har trods alt kun været et del-element i hele projektet med at omlægge jyskebank.dk. Der er også blevet udviklet læssevis af moderne web applikationer, som f.eks. instant medarbejder- og afdelingssøg. Fokus har altså ligget på at komme i luften med et nyt og tidsvarende site, fremfor at lade lanceringen afvente et større teknologi projekt om hvordan vi loader forskellige billedeopløsninger mv. afhængig af device og båndbredde. Når det så er sagt, så nærmer vi os så småt at hele jyskebank.dk er omlagt til nyt design. Som næste skridt vil det være oplagt at kigge på hvordan perfomance kan optimeres i forhold til device og båndbredde.

I den sammenhæng vil jeg give Morten Maate fuldstændigt ret, når han skriver, at der ikke er noget uløseligt i problematiseringen af responsivt design i forhold til brugerens oplevelse af både design og performance. Tværtimod, på design-fronten er der bestemt også fordele i at loade mindre billeder til mindre skærmen.

På jyskebank.dk - der uden tvivl er et 1. generations responsivt site - har designstrategien i høj grad været at folde indhold i højre side ned under indhold i venstre side, efterhånden som skærmen gøres smallere. Dette øger naturligvis indholdets højde betydeligt, hvilket i mange tilfælde ikke harmonerer specielt godt med, at mobilskærme som oftest har mindre højde end en desktop skærm.

Jeg mener at vi kan blive langt bedre til at inddrage progressive enhancement i vores designstrategi. Progressive enhancement her at forstå som, at vise substansen på smalle skærmen, mens der kan fyldes på med billeder og grafikker på bredere skærme. Et godt eksempel her på er faktisk det store banner på forsiden af jyskebank.dk. Her får man netop vist de store billeder på desktop'en, mens telefonen kun viser den lille udgave. Herved opnår vi også at banneret har samme højde hvad end du kommer på en mobil eller en desktop browser. At vi så alligevel vælger at kaste 400kb billeder efter din mobiltelefon, når vi ikke har tænkt os at vise dem, må betegnes som en uhensigtsmæssighed af de større...

Jeg er fuldstændig enig i substansen af diskussionen ovenfor. Weltklasse brugeoplevelser opstår først når både design og performance sidder lige i skabet.

P.S. ang. højt opløslige billeder til Retina skærme, så er det altså endnu kun små UI-elementer, som pile, ikoner og logoer der ligger i denne opløsning OG disse grafikker bør blive loadet i enten SD eller HD alt efter dit device's pixel-densitet.

P.P.S. ang. hvad Facebook laver på et banksite. Så ER jyskebank.dk et salgs- og marketingssite. Jyske Netbank er en anden sag og her er Mr. Zuckerberg - endnu - forment adgang. Lad os dog se hvad fremtiden bringer på den front. Jeg vil blot henvise til iZettle og Movenbank, der begge har Facebook integreret i kernen af deres finansielle business. Anyway, det var blot et lille afsluttende ræb fra min side om hvad jeg tror fremtiden bringer med hensyn til den finansielle sektor og de sociale medier, lad nu debatten her handle om responsivt design :-)

  • 4
  • 0
Per Esmann Jensen

Den gode nyhed er, at der arbejdes på at udvide html-standarden med understøttelse af flere opløsninger af samme billede. Se fx denne artikel fra A List Apart. Den dårlige nyhed er, at der er mere end ét forslag til, hvordan den nye markup skal se ud - så sandsynligvis skal vi lige vente et par år på at de kloge hoveder bliver færdige med at skændes om dét...

  • 0
  • 0
Lars Bjerregaard
  • 0
  • 0
Martin Kofoed

Jøsses herre du milde....

Enig - hvis altså de 30 sekunders loadtid havde noget med billedstørrelser at gøre. Det kan lyde som en søgt forklaring, men vi havde faktisk hele fredag formiddag og en del af eftermiddagen bøvl med én af vores backends, der gav de bemeldte 30 sekunders timeout i mange tilfælde. 30 sekunders ventetid er naturligvis helt, helt uacceptabelt, og ville da også have været årsag til en rødstemplet stresstest lige med det samme.

Men som Claus siger ovenfor, handlede dette projekt i lige så høj grad om opgradering af backends og ny kernefunktionalitet, ikke mindst på grund af den store Bankdata-omlægning som I også har kunnet læse om her på V2. Derfor er der en del backend services, der lige pludselig er blevet udsat for en masse load. Det var der så noget af det, der ikke helt kunne holde til ...

  • 0
  • 0
Log ind eller Opret konto for at kommentere
IT Company Rank
maximize minimize