Ne építsen weboldalakat végtelen görgetéssel!

TL;DR: bár az infinite scroll bizonyos esetekben megoldást nyújt, a felhasználók számára kevésbé ideális lehet.

a végtelen görgetés zavaró lehet, ellenőrizhetetlen, és stresszt okozhat a felhasználók számára.

ebben a cikkben elmagyarázzuk, miért kell abbahagynia a webhelyek építését végtelen görgetéssel. De először nézzük meg a görgetés rövid történetét.

a görgetés rövid története

hogy megértsük, mi is valójában a görgetés, nézzük meg, honnan származik a görgetés kifejezés.

görgetés (n.): c. 1400,”pergamen vagy papír tekercs”

a tekercseket eredetileg arra használták, amikor az információk hosszadalmasakká váltak (például vallási tartalmak). Olyan sok tartalom lett nehéz kezelni, olvasni és írni.

amikor a számítógépek beléptek az életünkbe, még mindig szükségünk volt egy módra, hogy navigáljunk a nagy mennyiségű tartalom között.

a tekercsek fejlődése a számítógépekben

sorok (és oszlopok)

az internet korai éveiben az UX tervezők feltalálták/felfedezték a tartalom lapozásának/görgetésének számos módját. Mielőtt az Internet népszerű lett volna, sorokat görgettünk a képernyőn.

vízszintes scrolls készült görgetés eszköz nem csak olvasni a tartalmat, hanem egy módja annak, hogy navigálni a számítógép képernyőjén.

Windows (nem az operációs rendszer)

a görgetések használata a képernyőn való navigáláshoz ösztönözte az embereket a windows létrehozására. A windows használatával egyszerre több tartalom is megtekinthető.

A Windows 3.1 “Programkezelő” több tekercset tartalmaz.

weboldalak

a görgetés nagyon alapvető problémát old meg a weboldalak böngészése közben. A görgetés azonban számos problémát okozhat a felhasználók számára, és negatívan befolyásolhatja a felhasználói élményt. Nézzük meg közelebbről.

a weboldalakon való navigáláshoz kitalált élmények

megpróbálom meghatározni, hogy a fejlesztők és a tervezők hogyan hoztak létre élményeket a felhasználók navigálásához a weboldalukon.

kezdjük néhány back-end lapszámozási rendszer tanulásával:

Offset-alapú lapszámozás

ez a legismertebb lapszámozási rendszer. Ebben a technikában először meg kell találnunk, hogy hány elemet kell lapoznunk:

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

az összes elem megszámlálása után ki kell számolnunk az oldalakat. Tegyük fel, hogy 10 elemet jelenítünk meg oldalanként:

-- First page itemsSELECT * FROM posts LIMIT 10

Ha pedig a 3 oldalra akarunk ugrani, akkor először a 30 elemeket kell kihagynunk OFFSET:

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

a lapszámozási információkat az alábbiak szerint küldjük el az ügyfélnek:

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

az offset-alapú lapozás előnyei és hátrányai

  • 👍 jó: könnyű bármely oldalra ugrani
  • GmbH jó: az ügyfélélmény szabadabb
  • GmbH rossz: teljesítménnyel kapcsolatos problémák
  • GmbH rossz: Ismétlődő elemek jelenhetnek meg, ha az adatok változása

kurzor alapú lapozás

a Big data megnehezítette a táblázat számának kiszámítását, mivel folyamatosan növekszik (gondolj a Twitterre). Tehát a fejlesztők újabb technikákkal álltak elő az adatok lapozásához: kurzorok.

minden sornak egyedi kurzorral kell rendelkeznie. Nem kell az egész táblázatot megszámolni, ami lehetetlenné teszi a tényleges oldalszám megismerését:

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

tegyük fel, hogy minden bejegyzésnek van egy egyedi kurzormezője (vagy azonosítója ebben a példában) a lapozás elősegítésére. Az ügyfél a következő lapozási információkkal rendelkezik:

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

és a kurzor segítségével kérheti a következő oldalt:

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

A kurzor alapú lapozás előnyei és hátrányai

  • 👍 jó: nagyobb teljesítményű, nincs táblázat számít
  • GmbH jó: a következő ismétlődő elemek nem lehetséges, ha valaki beszúr egy sort a táblázat közepén
  • GmbH rossz: lehetetlen ugrani bármely oldalra
  • GmbH: ügyfél nem szabad a tapasztalat, a teljes oldal és az aktuális oldal nem számított

vessünk egy pillantást néhány navigációs technikák.

a tapasztalat: kattintson-alapú

a technika: offset-alapú vagy kurzor alapú

ezt elsősorban a blogok navigálására használják. Ez a végtelen görgetés legrégebbi verziója. Ezzel a megközelítéssel a felhasználó nem tudja, hol ér véget a tartalom.

WordPress oldalszámozás.

számozott lapozás

a tapasztalat: click-alapú

a technika: offset-alapú

ez a leginkább használható (nekem) navigációs típus. Ez használ ofszet alapú lapozás, amely lehetővé teszi, hogy ugrik a kívánt oldalra, vagy megy a végén vagy elején csak egy kattintás.

Bootstrap stílusú lapozási sáv példák.

a Google ezt a fajta navigációt használja a keresési eredmények között:

a Google oldalszámozása.

Load more

a tapasztalat: click trigger-alapú

a technika: kurzor-alapú — lehet offset-alapú is, de kínos lenne

ez az egyik legújabb lapozási technika, és az infinite scrolls korábbi verzióját is használja.

A “Load more” gomb.

a fenti példában a felhasználó a “több betöltése” gombra kattintva további tartalmat láthat.

végtelen scrolls

a tapasztalat: scroll-alapú

a technika: kurzor-alapú — is offset-alapú, de nagyon kínos lenne

végtelen scrolls a legújabb élmény a kurzor alapú lapozás technikákat.

Hugh E. Williams azt állítja, hogy 2005-ben találta fel az infinite scrollt a Microsofton.

a Metafizzy létrehozott egy eszközt is, amely segít a fejlesztőknek végtelen tekercsek készítésében.

Végtelen görgetés teszi a felhasználók lapozzunk az oldalt a végtelenbe.

ne építsen weboldalakat végtelen görgetéssel!

e szakaszig áttekintettük, hogyan jutottunk ide. Most beszéljünk arról, hogy miért szar itt.

lábléc keresése

a lábléc a weboldal anatómiájának nagyon alapvető egysége, akárcsak a fejléc. A webhelyek részletes információkat és linkeket tartalmaznak a láblécben, például telefonszámokat, címeket, valamint Súgó-és támogatási linkeket. Ha a felhasználók ezt a részletes információt keresik, akkor többnyire lefelé görgetnek, hogy megtalálják a láblécet.

az infinite scrolls segítségével a felhasználók nehezen találhatják meg a láblécet. A végtelen görgetés lehetetlenné teszi az oldal végének megtalálását. Ha nem tudja elérni a weboldal alját, a felhasználó stresszt okozhat (ami nem nagyszerű).

a végtelen hírcsatornával rendelkező webhelyek (például a Twitter) megoldják a lábléc problémáját, ha ezeket a szükséges információkat és linkeket az oldalsávba helyezik. Az oldalsáv megoldást jelent erre a kérdésre, de nem jó. A láblécnek a láblécen kell maradnia.

Twitter lábléc a jobb oldalsávon.

ne használja a végtelen görgetést, ha nincs idővonala vagy hírcsatornája

a közösségi média alkalmazások idővel működnek. A felhasználók célja a múltban való navigálás. Ebben az esetben a végtelen görgetés megkönnyíti a navigációt. Itt az infinite scroll jó teljesítményt nyújt, különösen a mobilban.

de ha van egy e-kereskedelem, hírek, magazin, vagy egy blog honlapján, és a felhasználó szándéka, hogy mozogni a tételek vagy cikkek, végtelen scroll válik rémálom számukra. Idővonal-alapú listában, az emberek többnyire nem keresnek dátumot vagy egyedi pillanatot. Az elemalapú listákon a felhasználó meg akar találni egy elemet. A végtelen tekercsek szinte lehetetlenné teszik az elemek megtalálását a felhasználók számára.

adj a felhasználóknak több ellenőrzést

a felhasználók általában nem szeretik az UI-t, amikor úgy érzik, hogy nem tudják irányítani.

a görgetési esemény nem túl szándékos, hogy tegyen valamit. Az emberek navigálnak az oldalon, és ha meg akarnak hívni egy műveletet, akkor többnyire kattintanak vagy megérintenek (triggerek néven ismertek). Döntésükről tájékoztatják az UI-t. De a görgetés minden döntés nélkül elindul.

a végtelen tekercsek miatt az oldalak kevésbé irányíthatók a felhasználók számára. A felhasználók ugrási hibákkal is találkozhatnak.

a végtelen görgetés helyett tegyen egy “load more” gombot, amely egy trigger. Ez biztosítja az irányítást a felhasználó számára. (Inkább a régi stílusú számozott oldalszámozást részesítem előnyben, de feltételezzük, hogy most kurzor alapú oldalszámozást használunk).

lehetővé teszi a felhasználók számára, hogy bárhová menjenek

az emberek navigálnak az oldalak között, könyvjelzővel látják el őket, megosztják az oldalakat a barátaikkal stb.

a végtelen tekercsek azonban nem tudják megtartani az állapotot. A felhasználók nem oszthatják meg jelenlegi állapotukat — ami azt is jelenti, hogy az elemzési eszközök segítségével nem követheti nyomon a felhasználók műveleteit.

ha a back-end oldalszámozási technika kurzor alapú, szinte lehetetlen, hogy a felhasználók bárhová menjenek. Ha van e-kereskedelmi webhelye, adja meg a felhasználóknak, hogy navigáljanak a kívánt termékekhez.

Továbbá, ha van egy “rendezés” funkció az adatlapon, meg kell mutatnia a felhasználónak egy lapozást. Betűrendben rendezett listában nem szabad arra kényszeríteni a felhasználókat, hogy görgessenek le a K-vel kezdődő termékekhez.

engedélyeznie kell a felhasználók számára, hogy lássák, hol vannak. A felhasználók görgetni egy ideig, és mivel ez egy hontalan design, nem tudják, hogy hányszor a “Következő oldal” betöltött. Amikor frissítik az oldalt, teljesen visszaállnak az eredeti oldalra. Ezután a felhasználónak vissza kell görgetnie, hogy megtalálja, hol voltak korábban.

következtetés

a végtelen tekercsek néhány esetben szépek, de általában nem problémamegoldók, hanem problémakészítők. Az UX embereknek nem szabad a végtelen görgetést ezüst golyónak tekinteniük, hogy megoldják lapozási problémáikat. Ne építsen weboldalakat végtelen görgetéssel.

LogRocket: teljes láthatóság a web apps

LogRocket Dashboard Free Trial Banner

LogRocket egy frontend alkalmazás felügyeleti megoldás, amely lehetővé teszi, hogy visszajátszani problémákat, mintha történt a saját böngészőjében. Ahelyett, hogy kitalálná, miért történnek hibák, vagy képernyőképeket és naplózási hulladékokat kér a felhasználóktól, a LogRocket lehetővé teszi a munkamenet visszajátszását, hogy gyorsan megértse, mi történt rosszul. Tökéletesen működik minden alkalmazással, függetlenül a keretrendszertől, és pluginekkel rendelkezik a Redux, A Vuex és a @ngrx/store további kontextusának naplózásához.

A Redux műveletek és állapotok naplózása mellett a LogRocket rögzíti a konzolnaplókat, a JavaScript hibákat, a stacktraces-t, a hálózati kéréseket/válaszokat fejlécekkel + testekkel, böngésző metaadatokkal és egyéni naplókkal. A DOM-ot arra is használja, hogy rögzítse a HTML-t és a CSS-t az oldalon, pixel-tökéletes videókat hozva létre még a legösszetettebb egyoldalas alkalmazásokból is.

próbálja ki ingyen.

Vélemény, hozzászólás?

Az e-mail-címet nem tesszük közzé.