Sluta bygga webbplatser med oändlig scroll!

TL;DR: medan infinite scroll ger en lösning i vissa fall kan den vara mindre än idealisk för användare.

oändlig rullning kan vara desorienterande, okontrollerbar och kan orsaka dina användare stress.

i den här artikeln kommer vi att förklara varför du behöver sluta bygga webbplatser med oändlig rullning. Men för att börja, låt oss titta på en kort historia av rullning.

en kort historik med rullning

för att förstå vad rullning verkligen är, låt oss se var termen rullning kommer ifrån.

bläddra (n.): c. 1400,”rulle av pergament eller papper”

rullar användes ursprungligen för när informationen blev lång (som religiöst innehåll). Så mycket innehåll blev svårt att hantera, läsa och skriva.

när datorer kom in i våra liv behövde vi fortfarande ett sätt att navigera genom stora delar av innehållet.

utvecklingen av rullar i datorer

linjer (och kolumner)

under de första åren av internet uppfann/utforskade UX-designers många sätt att söka/rulla innehållet. Innan webben var populär rullade vi linjer på vår skärm.

horisontella rullar gjorde rullning ett verktyg inte bara för att läsa innehållet, men också ett sätt att navigera på datorskärmen.

Windows (inte OS one)

använda rullar för att navigera på skärmen uppmuntrade människor att skapa windows. Med windows skulle du kunna se flera innehållsbitar samtidigt.

Windows 3.1 ”Program Manager” har flera rullar.

webbsidor

rullning löser ett mycket grundläggande problem vi har när du surfar webbsidor. Rullning kan dock orsaka många problem för användare och kan påverka användarupplevelsen negativt. Låt oss ta en närmare titt.

upplevelserna uppfann för att navigera på webbsidor

jag ska försöka definiera hur utvecklare och designers skapade upplevelser för att navigera på användare på sina webbsidor.

Låt oss börja med att lära oss några back-end paginationssystem:

Offsetbaserad pagination

Detta är det mest kända paginationssystemet. I den här tekniken måste vi först hitta hur många objekt vi måste paginera:

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

efter att ha räknat alla objekt måste vi beräkna sidorna. Låt oss anta att vi visar 10 objekt per sida:

-- First page itemsSELECT * FROM posts LIMIT 10

och om vi vill hoppa till sidan 3, måste vi hoppa över första 30 objekt med OFFSET:

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

och vi skickar pagineringsinformationen till kunden enligt följande:

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

fördelar och nackdelar med offsetbaserad pagination

  • 👍 bra: lätt att hoppa till vilken sida som helst
  • Brasilien bra: klientupplevelsen är mer fri
  • Brasilien dåligt: prestandaproblem
  • Brasilien dåligt: Dubbletter kan visas om data ändras

markörbaserad pagination

Big data gjorde det svårt att beräkna tabellräkningen eftersom det ständigt växer (tänk på Twitter). Så, utvecklare kom med nyare tekniker för att paginera data: markörer.

varje rad måste ha en unik markör. Du behöver inte räkna hela tabellen vilket gör det omöjligt att veta faktiska sidantal:

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

Antag att varje inlägg har ett unikt markörfält (eller dess ID i det här exemplet) för att hjälpa paginering. Klienten kommer att ha paginationsinformation enligt följande:

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

och du kan be om nästa sida med markören:

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

fördelar och nackdelar med markörbaserad paginering

  • 👍 Bra: mer presterande, ingen tabell räknas
  • bisexuell bra: visar dubbletter är inte möjligt om någon infogar en rad i mitten av tabellen
  • bisexuell dåligt: omöjligt att hoppa till någon sida
  • bisexuell dåligt: klienten är inte gratis med erfarenhet, totalt sida och aktuell sida beräknas inte

Låt oss ta en titt på några navigeringstekniker.

upplevelsen: klickbaserad

tekniken: offset-baserad eller markörbaserad

detta används främst för att navigera i bloggar. Detta är den äldsta versionen av oändlig rullning. Med hjälp av detta tillvägagångssätt kanske användaren inte vet var innehållet slutar.

WordPress pagination.

numrerad pagination

upplevelsen: klickbaserad

tekniken: offsetbaserad

detta är den mest användbara (enligt mig) navigationstypen. Den använder offset baserad pagination som låter dig hoppa till den sida du vill, eller gå till slutet eller börjar med bara ett klick.

Bootstrap stil pagination bar exempel.

Google använder denna typ av navigering i sökresultaten:

Googles pagination.

ladda mer

upplevelsen: klicka på triggerbaserad

tekniken: markörbaserad-kan också vara offsetbaserad men skulle vara besvärlig

detta är en av de nyaste pagineringsteknikerna, och den använder också den tidigare versionen av infinite scrolls.

en” ladda mer ” – knapp.

i exemplet ovan klickar användaren på knappen ”Ladda mer” för att se mer innehåll.

oändliga rullar

upplevelsen: rullningsbaserad

tekniken: markörbaserad-kan också vara offsetbaserad men skulle vara mycket besvärlig

oändliga rullar är den senaste upplevelsen av markörbaserade pagineringstekniker.

Hugh E. Williams hävdar att han uppfann infinite scroll 2005 på Microsoft.

Metafizzy skapade också ett verktyg för att hjälpa utvecklare att bygga oändliga rullar.

oändlig rullning gör att användarna rullar sidan till oändligheten.

sluta bygga webbplatser med oändlig rullning!

fram till det här avsnittet har vi granskat hur vi kom hit. Låt oss nu prata om varför här suger.

hitta sidfot

sidfot är en mycket grundläggande enhet för webbsida anatomi, precis som en rubrik. Webbplatser har detaljerad information och länkar i sidfoten, till exempel telefonnummer, adresser och hjälp-och supportlänkar. Om användare söker efter den här detaljerade informationen rullar de oftast ner för att hitta sidfoten.

med oändliga rullar kan användare ha svårt att försöka hitta sidfoten. Oändlig rullning gör det omöjligt att hitta slutet på sidan. Att inte kunna nå botten av en webbplats kan göra användaren stressad (vilket inte är bra).

webbplatserna med ett oändligt flöde (som Twitter) löser sidfotsproblemet och lägger denna nödvändiga information och länkar i sidofältet. Sidofältet är en lösning på denna fråga, men inte en bra. Footer bör stanna på sidfoten.

Twitters sidfot på höger sidofält.

använd inte oändlig rullning om du inte har en tidslinje eller ett flöde

sociala medieapplikationer fungerar med tiden. Användarnas avsikt är att navigera i det förflutna. I det här fallet gör oändlig rullning navigeringen enklare. Här är oändlig rullning bra för prestanda, särskilt i mobilen.

men om du har en e-handel, nyheter, tidskrift eller en bloggwebbplats, och användarens avsikt är att flytta runt objekten eller artiklarna, blir oändlig rullning en mardröm för dem. I en tidslinjebaserad lista letar människor oftast inte efter ett datum eller ett unikt ögonblick. På artikelbaserade listor vill användaren hitta ett objekt. Oändliga rullar gör dina objekt nästan omöjliga för dina användare att hitta.

ge användarna mer kontroll

användare gillar vanligtvis inte användarvillkoren när de känner att de inte kan kontrollera det.

en rullningshändelse är inte särskilt avsiktlig att göra något. Människor navigerar på sidan, och om de vill ringa en åtgärd klickar eller trycker de oftast på (känd som triggers). De informerar UI om sitt beslut. Men rullning utlöses utan något beslut.

oändliga rullar gör sidorna mindre kontrollerbara för användarna. Användare kan också stöta på hoppfel.

istället för oändlig rullning, sätt en” ladda mer ” – knapp, vilket är en utlösare. Detta kommer att ge kontroll till användaren. (Jag föredrar gammal stil numrerad pagination men vi antar att vi använder markörbaserad pagination just nu).

Tillåt användare att gå vart de vill

människor navigerar mellan sidor, bokmärker några av dem, delar sidor med sina vänner etc.

men oändliga rullar kan inte hålla staten genom sin design. Användare kan inte dela sitt nuvarande tillstånd — vilket också innebär att du inte kan spåra användarnas åtgärder med hjälp av analysverktyg.

om din back-end-pagineringsteknik är markörbaserad är det nästan omöjligt att låta dina användare gå vart som helst. Om du har en e-handelswebbplats, ge användarna kontroll för att navigera till de produkter de vill ha.

dessutom, om du har en ”Sortera efter” – funktion i din lista, måste du visa användaren en paginering. I en alfabetiskt ordnad lista får du inte tvinga användare att rulla ner till produkter som börjar med K. De kommer att bli galna med den här upplevelsen.

du bör tillåta användare att se var de är. Användare bläddra för en tid, och eftersom det är en statslös design, de vet inte hur många gånger ”Nästa sida” laddad. När de uppdaterar sidan återställs de hela vägen tillbaka till den ursprungliga sidan. Användaren måste sedan rulla tillbaka för att hitta var de var tidigare.

slutsats

oändliga rullar är trevliga i några få fall, men de är vanligtvis inte problemlösare utan problemtillverkare. UX-personer bör inte överväga oändlig rullning som en silverkula för att lösa sina paginationsproblem. Sluta bygga webbplatser med oändlig rullning.

LogRocket: full insyn i dina webbappar

LogRocket Dashboard Free Trial Banner

LogRocket är en frontend applikationsövervakningslösning som låter dig spela upp problem som om de hände i din egen webbläsare. I stället för att gissa varför fel inträffar, eller be användare om skärmdumpar och loggdumpar, låter LogRocket dig spela upp sessionen för att snabbt förstå vad som gick fel. Det fungerar perfekt med alla appar, oavsett ramverk, och har plugins för att logga ytterligare sammanhang från Redux, Vuex och @ngrx/store.

förutom att logga Redux åtgärder och tillstånd, LogRocket registrerar konsolloggar, JavaScript fel, stacktraces, nätverksförfrågningar/svar med rubriker + organ, webbläsare metadata och anpassade loggar. Det instrument också DOM att spela in HTML och CSS på sidan, återskapa pixel perfekta videor av även de mest komplexa enda sida apps.

prova det gratis.

Lämna ett svar

Din e-postadress kommer inte publiceras.