Stop med at bygge hjemmesider med uendelig rulle!

TL;DR: mens uendelig rulle giver en løsning i nogle tilfælde, kan den være mindre end ideel for brugerne.

uendelig rulle kan være desorienterende, ukontrollerbar og kan forårsage dine brugere stress.

i denne artikel vil vi forklare, hvorfor du skal stoppe med at opbygge hjemmesider med uendelig rulle. Men for at starte, lad os se på en kort historie med rulning.

en kort historie med rulning

for at forstå, hvad rulle virkelig er, lad os se, hvor udtrykket rulle kommer fra.

rul (n.): c. 1400,”rulle af pergament eller papir”

ruller blev oprindeligt brugt til, når informationen blev lang (som religiøst indhold). Så meget indhold blev svært at styre, læse og skrive.

da computere kom ind i vores liv, havde vi stadig brug for en måde at navigere gennem store stykker indhold.

udviklingen af ruller i computere

linjer (og kolonner)

i de tidlige år af internettet opfandt/udforskede designere mange måder at søge/rulle indholdet på. Før internettet var populært, rullede vi linjer på vores skærm.

horisontale ruller gjorde at rulle et værktøj ikke kun til læsning af indholdet, men også en måde at navigere på computerskærmen.

vinduer (ikke OS one)

brug af ruller til at navigere på skærmen opfordrede folk til at oprette vinduer. Ved hjælp af vinduer kan du se flere stykker indhold ad gangen.

vinduer 3.1 “Program Manager” har flere ruller.

hjemmesider

rulning løser et meget grundlæggende problem, vi har, mens vi gennemser hjemmesider. Rulning kan dog forårsage mange problemer for brugerne og kan påvirke brugeroplevelsen negativt. Lad os se nærmere på.

oplevelserne opfundet for at navigere på hjemmesider

jeg vil forsøge at definere, hvordan udviklere og designere skabte oplevelser for at navigere brugere på deres hjemmesider.

lad os starte med at lære nogle back-end paginationssystemer:

Offsetbaseret paginering

dette er det mest kendte paginationssystem. I denne teknik skal vi først finde ud af, hvor mange ting vi skal paginere:

-- All posts countSELECT COUNT(*) AS total FROM posts

efter at have talt alle elementerne, skal vi beregne siderne. Lad os antage, at vi viser 10 varer pr. side:

-- First page itemsSELECT * FROM posts LIMIT 10

og hvis vi vil springe til siden 3, skal vi springe først 30 varer ved hjælp af OFFSET:

-- Third page itemsSELECT * FROM posts LIMIT 10 OFFSET 30

og vi sender paginationsoplysningerne til klienten som følger:

{ "pagination": { "items_count": 100, "current": 3, "total_pages": 10 }, "items": }

fordele og ulemper ved offsetbaseret paginering

  • 👍 godt: let at springe til enhver side
  • kur god: klientoplevelsen er mere gratis
  • kur dårlig: ydelsesproblemer
  • kur dårlig: Duplikatelementer kan vises, hvis data ændres

Markørbaseret paginering

Big data gjorde det svært at beregne tabelantalet, da det konstant vokser (tænk på kvidre). Så udviklere kom med nyere teknikker til at paginere dataene: markører.

hver række skal have en unik markør. Du behøver ikke at tælle hele tabellen, hvilket gør det umuligt at kende den faktiske sidetælling:

-- Get extra 1 item to get its cursor.SELECT * FROM posts ORDER BY id DESC LIMIT 11

Antag, at hvert indlæg har et unikt markørfelt (eller dets ID i dette eksempel) for at hjælpe paginering. Klienten vil have paginering oplysninger som følger:

{ "pagination": { "next": 1234 // extra item's ID (cursor), null if end of data. }, "items": }

og du kan bede om den næste side ved hjælp af markøren:

-- Offsetting records using 1234 cursorSELECT * FROM posts WHERE id >= 1234 ORDER BY id LIMIT 11

fordele og ulemper ved markørbaseret paginering

  • 👍 God: mere performant, ingen tabel tæller
  • kur god: viser dublerede elementer er ikke muligt, hvis nogen indsætter en række i midten af tabellen
  • kur Bad: umuligt at hoppe til enhver side
  • kur Bad: klient er ikke gratis med oplevelsen, Total side og aktuelle side er ikke beregnet

lad os tage et kig på nogle navigation teknikker.

oplevelsen: klikbaseret

teknikken: offsetbaseret eller markørbaseret

dette bruges hovedsageligt til at navigere i blogs. Dette er den ældste version af uendelig rulning. Ved hjælp af denne tilgang ved brugeren muligvis ikke, hvor indholdet slutter.

sideinddeling.

nummereret paginering

oplevelsen: klikbaseret

teknikken: offsetbaseret

dette er den mest anvendelige (ifølge mig) navigationstype. Det bruger offsetbaseret paginering, som giver dig mulighed for at hoppe til den ønskede side, eller gå til slutningen eller begyndelsen med et enkelt klik.

Bootstrap stylet paginering bar eksempler.

Google bruger denne form for navigation i søgeresultater:

Googles pagination.

Indlæs mere

oplevelsen: klik på trigger-baseret

teknikken: cursor-baseret — kan også være offsetbaseret, men ville være akavet

dette er en af de nyeste pagineringsteknikker, og den bruger også den tidligere version af infinite scrolls.

en” Load more ” – knap.

i eksemplet ovenfor klikker brugeren på knappen “Indlæs mere” for at se mere indhold.

uendelige ruller

oplevelsen: rullebaseret

teknikken: markørbaseret-kan også være offsetbaseret, men ville være meget akavet

uendelige ruller er den nyeste oplevelse af markørbaserede pagineringsteknikker.

Hugh E. Vilhelms hævder, at han opfandt infinite scroll i 2005 på Microsoft.

et værktøj til at hjælpe udviklere med at opbygge infinite scrolls.

uendelig rulning får brugerne til at rulle siden til uendelig.

Stop med at bygge hjemmesider med uendelig rulle!

indtil dette afsnit har vi gennemgået, hvordan vi kom her. Lad os nu tale om hvorfor her suger.

Finding footer

Footer er en meget grundlæggende enhed af hjemmeside anatomi, ligesom en header. Steder holde nogle detaljerede oplysninger og links i sidefoden såsom telefonnumre, adresser, og hjælp og support links. Hvis brugerne søger efter disse detaljerede oplysninger, ruller de for det meste ned for at finde sidefoden.

med infinite scrolls kan brugerne have svært ved at finde sidefoden. Uendelig rulle gør det umuligt at finde slutningen af siden. Ikke at kunne nå bunden af en hjemmeside kan gøre brugeren stresset (hvilket ikke er godt).

de steder med en uendelig foder (ligesom kvidre) løse sidefoden problem at sætte denne nødvendige oplysninger og links i sidebjælken. Sidebjælken er en løsning på dette problem, men ikke en god. Footer skal forblive på footer.

kvidre sidefod på højre sidebjælke.

brug ikke uendelig rulle, hvis du ikke har en tidslinje eller feed

sociale medier applikationer arbejder med tiden. Brugernes hensigt er at navigere i fortiden. I dette tilfælde gør uendelig rulle navigationen lettere. Her er uendelig rulle god til ydeevne, især i mobil.

men hvis du har en e-handel, nyheder, magasin, eller en blog hjemmeside, og brugerens hensigt er at bevæge sig rundt de elementer eller artikler, uendelig rulle bliver et mareridt for dem. På en tidslinjebaseret liste, folk ser for det meste ikke efter en dato eller et unikt øjeblik. På varebaserede lister ønsker brugeren at finde en vare. Uendelige ruller gør dine varer næsten umulige for dine brugere at finde.

Giv brugerne mere kontrol

brugere kan generelt ikke lide UIs, når de føler, at de ikke kan kontrollere det.

en rullebegivenhed er ikke særlig forsætlig at gøre noget. Folk navigerer på siden, og hvis de vil kalde en handling, klikker eller rører de for det meste (kendt som udløsere). De informerer UI om deres beslutning. Men rulle udløses uden nogen beslutning.

uendelige ruller gør siderne mindre kontrollerbare for brugerne. Brugere kan også støde på springfejl.

i stedet for uendelig rulning skal du sætte en “load more” – knap, som er en trigger. Dette vil give kontrol til brugeren. (Jeg foretrækker gammel stil nummereret pagination, men vi antager, at vi bruger markørbaseret paginering lige nu).

Tillad brugere at gå, hvor de vil

folk navigerer mellem sider, bogmærker nogle af dem, deler sider med deres venner osv.

dog kan uendelige ruller ikke holde staten ved dens design. Brugere kan ikke dele deres nuværende tilstand-hvilket også betyder, at du ikke kan spore brugernes handlinger ved hjælp af analyseværktøjer.

hvis din back-end paginationsteknik er markørbaseret, er det næsten umuligt at lade dine brugere gå overalt. Hvis du har en e-handel hjemmeside, give brugerne kontrol til at navigere til de produkter, de ønsker.

hvis du har en “Sorter efter” – funktionalitet i din fortegnelse, skal du desuden vise brugeren en paginering. I en alfabetisk ordnet liste, Du må ikke tvinge brugerne til at rulle ned til produkter, der starter med K. de vil blive gale med denne oplevelse.

du bør give brugerne mulighed for at se, hvor de er. Brugere rulle for en tid, og fordi det er en statsløs design, de ved ikke, hvor mange gange den “næste side” indlæst. Når de opdaterer siden, nulstilles de helt tilbage til den oprindelige side. Brugeren skal derefter rulle ned igen for at finde, hvor de var før.

konklusion

uendelige ruller er gode i nogle få tilfælde, men de er normalt ikke problemløsere, men problemskabere. Folk bør ikke overveje uendelig rulning som en sølvkugle for at løse deres paginationsproblemer. Stop med at opbygge hjemmesider med uendelig rulle.

LogRocket: fuld synlighed i din hjemmeside apps

LogRocket Dashboard GRATIS Prøveversion Banner

LogRocket er en frontend program overvågning løsning, der lader dig afspille problemer, som om de skete i din egen bro.ser. I stedet for at gætte, hvorfor der sker fejl, eller bede brugerne om skærmbilleder og logdumper, LogRocket giver dig mulighed for at afspille sessionen igen for hurtigt at forstå, hvad der gik galt. Det fungerer perfekt med enhver app, uanset ramme, og har plugins til at logge yderligere kontekst fra .

ud over logføring af handlinger og tilstand registrerer LogRocket konsollogfiler, JavaScript-fejl, stacktraces, netværksanmodninger/svar med overskrifter + organer, bro.ser metadata og brugerdefinerede logfiler. Det instruerer også DOM til at optage HTML og CSS på siden og genskabe perfekte videoer af selv de mest komplekse apps på en side.

prøv det gratis.

Skriv et svar

Din e-mailadresse vil ikke blive publiceret.