Reaktiv Web Design: Hemmeligheden bag at oprette webapps, der føles forbløffende

I det sidste år har jeg observeret to subtile teknikker, der bruges af nogle udviklere, der tager en webapp fra at føle sig langsom og uhyggelig til meget reaktiv og poleret.

Jeg mener, at disse teknikker er vigtige nok til, at de har brug for et navn: Reaktiv Web Design.

I resumé er reaktiv webdesign et sæt teknikker, der kan bruges til at opbygge websteder, der altid føles hurtig og reagerer på brugerinput uanset netværkets hastighed eller latenstid.

Som webudviklere og rammeforfattere tror jeg, at det at finde måder til at gøre disse mønstre standard i alt, hvad vi bygger, er en højeste prioritet for at forbedre UX og opfattet ydelse på nettet.

Teknik 1: Øjeblikkelig belastning med skeletskærme

Når den bruges godt, bemærkes denne teknik næsten aldrig, men har en enorm indflydelse på den opfattede ydelse af et websted.

Interessant nok bruges teknikken af ​​næsten alle indfødte apps og får dem til at føle sig meget reaktive selv på forfærdelige netværk, men den bruges næsten aldrig på nettet!

Muligheden på denne måde ligger!

Kort sagt, skeletskærme sikrer, at når brugeren banker på en knap eller et link, reagerer siden straks ved at overføre brugeren til den nye side og derefter indlæse indholdet til den side, når indholdet bliver tilgængeligt.

Facebook bruger en skeletskærm for at forbedre den opfattede ydelse, når du først åbner den

Skeletskærme er en vigtig opfattet ydelsesteknik, da de får applikationer til at føle sig meget hurtigere, hvilket dramatisk reducerer antallet af øjeblikke, hvor brugeren lader undre sig:

Hvad sker der? Er det endda lastning? Tappede jeg det rigtigt?

Flipkart.com er et sjældent eksempel på et websted, der gør brug af denne tilgang. Gennemse kategorier eller tappe på produkter føles derfor lynhurtigt, selv når de faktiske resultater tager et par sekunder at indlæse:

En screencapture af flipkart.com lanceret fra startskærmen i standalone-tilstand på Android

Når denne teknik bruges bedst, kan indhold, der allerede er tilgængeligt, såsom miniaturebilleder eller artikeltitler, genbruges til at forbedre den opfattede ydelse yderligere, hvilket får belastninger til at føle sig virkelig øjeblikkelige.

app.jalantikus.com bruger Skeleton Screens mønster og genbruger titler og miniaturer på tværs af overgange

Teststeder med skeletskærme

Det er let at teste, hvor godt sider bruger denne teknik: Brug simpelthen Chrome-netværksemulering for at gøre netværket så langsomt som muligt og klik derefter rundt på et websted. Hvis det gør det godt, vil webstedet stadig føles snappet og lydhør over for dit input.

Den langsomste hastighed, der understøttes i Chrome-netværksemulering

Teknik 2: “Stabil belastning” via foruddefinerede størrelser på elementer

Kender du den følelse, hvor et websted springer rundt, mens du prøver at bruge det? Du prøver bare at læse en artikel, og teksten bevæger sig stadig rundt? Det er hvad vi kalder en "ustabil belastning", og vi er nødt til at brænde den med fire.

slate.com-indhold springer rundt meget aggressivt, når siden indlæses. Jo langsommere det netværk, du er på, jo længere springer det på.

Ustabile belastninger gør websteder svære at interagere med og får dem til at føle sig ... vel… ustabil!

Gennemse et ustabilt sted minder mig altid om, hvordan jeg forestiller mig, at det ville føles at gå rundt under et jordskælv

Ustabile belastninger er forårsaget af billeder og annoncer, der er integreret på en side, men inkluderer ikke størrelsesoplysninger. Som standard ved browseren kun størrelsen på disse, når de først er indlæst, så så snart et billede indlæses, THUNK !, glider hele siden ned .

For at forhindre dette skal alle -koder på en side proaktivt indeholde dimensionerne på det billede, de vil indeholde.

I mange tilfælde er billeder, der bruges på bestemte sider, altid den samme størrelse, og derfor kan deres størrelse simpelthen inkluderes i HTML-skabelonen, men i nogle tilfælde er størrelsen på billeder dynamisk, og derfor skal deres størrelse beregnes, når billedet uploades og derefter templeres i HTML, når det oprettes.


Det samme gælder for annoncer, ofte en skyldige, når det kommer til ustabile belastninger. Hvor det er muligt, skal du oprette en div, der vil indeholde en annonce, og indstil den i din templering til at blive dimensioneret med dit bedste gæt på, hvor stor denne annonce bliver.

Bemærk, at ustabile belastninger er deres værste på langsomme netværk, da du lige har slået dig ned i at læse indhold, når det pludselig springer, og du kan aldrig helt være sikker på, at du er sikker.

Samler det hele

Jeg har oprettet et lille demosite på reactive.surge.sh for at demonstrere forskellen mellem konventionel og reaktiv webdesign.

Konventionel indlæsning af artikler

Bemærk, hvor træg det føles, og hvor frustrerende indholdshopping er. Interessant synes jeg, at disse størrelsesordrer er mere irriterende på mobile enheder, når jeg banker på skærmen og ikke ser den reagere.

Indlæser en artikel med reaktivt webdesign

Ved reaktivt design føles belastningen øjeblikkeligt, og webstedet forbliver reaktivt, når man tapper på bagsideikonet og artikeltitlen flere gange

Afslutter

Jo langsommere netværket er, jo værre bliver brugeroplevelsen, når sideovergange blokeres på netværket og sider springer rundt i længere perioder.

Med Reactive Web Design kan vi få vores oplevelse til at føle snacks og lydhør (“Responsive Design”, som et navn allerede blev taget, d’oh!), Selv på langsomme og smertefulde netværk.

Jeg ville meget gerne høre om data fra lokalsamfundet om effekten af ​​den opfattede ydelse på KPI'er som engagement og indtægter!

Derudover vil jeg opfordre ramme- og bibliotekforfattere til at overveje, hvordan man gør skeletskærme og stabile belastninger til standard, også kendt som pit for succes.

Hvis du har tanker om dette, bedes du twitre mig @owencm, og hvis du nød det, så giv det en ♥!

P. S. Sørg for at tjekke demo-stedet reactive.surge.sh på en mobilenhed for det er fuld glans!