Następna strona czy przewijanie bez końca? Wybierz sposób przeglądania katalogu

Przycisk „Pokaż więcej” zajmuje na makiecie jeden wiersz. Po obejrzeniu czterdziestu modeli ujawnia znacznie większe zobowiązanie: kolejną porcję, możliwość wrócenia do już przejrzanych pozycji i jakiś rozpoznawalny koniec. Jeśli po otwarciu produktu wszystko zaczyna się od nowa, oszczędzony klik kosztuje odbiorcę ponowne szukanie.

Nie ma potrzeby zaczynać od plebiscytu na najbardziej nowoczesny wzorzec. Najpierw ustal zadanie. Osoba szukająca instrukcji konkretnego urządzenia, kupująca porównująca kilka lamp i czytelnik oglądający fotografie mogą potrzebować innych sposobów przeglądania. Nawet na tej samej stronie. Mechanizm ma podtrzymać ich pracę, a nie jedynie przedłużyć listę.

Paginacja dzieli zbiór na strony wyników. „Pokaż więcej” dokłada zawartość po świadomej czynności. Nieskończone przewijanie doczytuje ją w związku z ruchem w dół. Różnica dotyczy kontroli, orientacji i powrotu; sama obecność jednego przycisku nie rozstrzyga wszystkich tych cech. Poniższe przykłady są propozycjami projektowymi, bez przypisywania im nieprzeprowadzonych pomiarów.

Wybór sposobu przeglądania wynika z tego, co trzeba zachować

W katalogu instrukcji użytkownik może chcieć sprawdzić kilka kolejnych pozycji i przekazać komuś określony fragment wyników. Paginacja może dać taki punkt odniesienia: stronę w ustalonej kolejności. Ma jednak sens dopiero wraz z czytelnym oznaczeniem bieżącej strony i sposobem powrotu. Rząd samych numerów nie objaśnia zakresu listy.

Przy numerach nie pokazuj pozornej dokładności. Jeżeli system nie zna jeszcze całkowitej liczby wyników, projekt nie powinien wymyślać ostatniej strony. Można udostępnić przejście dalej bez deklarowania końca. Odbiorca musi rozumieć, że widzi następny fragment, a nie ostatni z policzonej całości.

USWDS rozróżnia paginację ze znaną ostatnią stroną i zbiór bez obliczonej liczby stron. Zaleca wskazanie aktualnego miejsca i rozpoznawalnego zakresu nawigacji. Własny projekt powinien odpowiadać rzeczywiście dostępnej informacji o wynikach, zamiast kopiować komplet liczb z przykładu komponentu.

Przycisk doczytywania może natomiast zachować wcześniejsze pozycje na jednym ekranie. To propozycja dla sytuacji, w której porównujemy kolejne materiały i chcemy swobodnie wracać trochę wyżej. Nie zwalnia z ustalenia, co dzieje się po kilku porcjach. Trzeba wiedzieć, czy wcześniejsza zawartość nadal istnieje i czy użytkownik może odnaleźć jej początek.

Przy automatycznym doczytywaniu odbiorca nie podejmuje osobnej decyzji o następnej porcji. Taki układ może odpowiadać swobodnemu oglądaniu, ale gorzej opisywać zadanie „sprawdź cały wskazany zestaw”. Nie przyjmuj, że sam dalszy ruch oznacza chęć załadowania dowolnej liczby pozycji. Dostęp do stopki lub informacji pod listą również powinien pozostać możliwy.

Przy wyborze liczby pozycji na stronie rozważ także jej późniejszą zmianę. Użytkownik przełącza po dwadzieścia na po pięćdziesiąt. Dawny numer strony nie wskazuje już tego samego zakresu. Projekt może wrócić do początku albo zachować rozpoznawalną pozycję inną ustaloną drogą. Nowy licznik i zawartość muszą się zgadzać, a zmiana nie powinna wyglądać jak utrata części katalogu. W specyfikacji zapisz wybrany skutek i przykład rekordu, który pozwoli go sprawdzić.

Nie trzeba stosować identycznego mechanizmu dla wszystkich ekranów katalogu. Zespół może wybrać strony dla listy dokumentów i doczytywanie dla galerii inspiracji. Spójność ma tu dotyczyć rozpoznawalnych działań i zachowania stanu. Jednolity wygląd nie wymaga narzucenia każdemu zadaniu tej samej drogi.

Jeżeli chodzi o odnalezienie konkretnego materiału, sam sposób porcjowania listy nie zastąpi wyszukiwarki wewnętrznej. Użytkownik znający kod nie powinien przechodzić przez siedemnaście stron, żeby wykazać cierpliwość. Nawigacja po wynikach i ich trafne zawężenie rozwiązują inne części zadania.

Powrót ma prowadzić do rozpoznawalnego miejsca

W hipotetycznej próbie kupująca ogląda trzecią porcję lamp, otwiera jeden model i wraca. Powinna móc wskazać obejrzaną pozycję oraz kontynuować porównanie. Nie wystarczy odtworzyć pionową odległość od początku strony. Inne rozmiary obrazów albo zmiana zawartości mogą sprawić, że ta sama wysokość pokaże inny model.

Ustal, co dokładnie wraca: warunki listy, kolejność, wcześniej doczytany zakres i punkt odniesienia. Dopiero taki zestaw pozwala opisać oczekiwany efekt. Mechanizm techniczny dobiera wykonawca. Projekt ma podać wynik do sprawdzenia, zamiast zakładać, że przycisk przeglądarki automatycznie odzyska wszystko.

MDN opisuje właściwość scrollRestoration, która rozróżnia automatyczne odtwarzanie przewinięcia i tryb ręczny oznaczony jako manual przy nawigacji w historii. Dotyczy ona zachowania przewinięcia. Nie jest samodzielną obietnicą odtworzenia danych, filtrów i doczytanych pozycji dowolnej aplikacji.

W próbie trzeba więc użyć zarówno przycisku „Wstecz” przeglądarki, jak i ewentualnego „Wróć do wyników” w karcie produktu. Dwa różne działania mogą prowadzić innymi drogami. Jeśli jedno wraca do zachowanego zestawu, a drugie otwiera kategorię od początku, użytkownik powinien rozpoznać ten skutek z etykiety.

Powrót z historii to także inny przypadek niż otwarcie udostępnionego adresu w nowej karcie. Osoba, która dostała link, nie ma wcześniejszej historii przeglądania. Jeżeli adres ma wskazywać konkretny fragment wyników, strona powinna umieć odtworzyć go bez tej historii albo jasno pokazać inny uzgodniony zakres. Oddziel obietnicę chwilowej kontynuacji od obietnicy adresu, który można zapisać i przekazać. Sprawdzenie jednej drogi nie zastępuje drugiej, nawet gdy po obu widzimy ten sam tytuł katalogu.

Dla zapisanych widoków tabeli odtworzenie osobistego układu nie wystarcza do odtworzenia miejsca przeglądania. Podobnie zapamiętany wybór kategorii nie dowodzi, że wróciła trzecia porcja listy. Te informacje można przechowywać osobno, ale z perspektywy użytkownika muszą tworzyć zrozumiałą kontynuację.

Jeżeli oglądany produkt zniknął lub zmienił pozycję, nie udawaj niezmienionego stanu. Projekt może zachować kontekst i pokazać aktualizację przy powrocie. Chodzi o uczciwe wyjaśnienie różnicy. Użytkownik nie powinien przeglądać listy w poszukiwaniu elementu, który został wycofany, podczas gdy system zna już tę zmianę.

Tu przydaje się projekt list i interakcji w Aeneia Design. Możemy rozrysować przejście do szczegółu, powrót i aktualizację wyników na tych samych przykładowych rekordach. Zachowanie prototypu trzeba następnie połączyć z odczytem danych oraz historią nawigacji w uzgodnionym wdrożeniu.

Kolejna porcja nie jest jeszcze dowodem końca

Pod listą mogą pojawić się różne stany: pobieranie, błąd następnego fragmentu albo rzeczywisty koniec. Pusty fragment pod listą nie pozwala ich rozróżnić. Przy nieudanym odczycie zachowaj już dostępną zawartość i zaprojektuj ponowienie dotyczące brakującej porcji. Odbiorca nie powinien ponownie wyszukiwać produktu, który przed chwilą widział.

Szybkie kolejne uruchomienie doczytywania nie powinno dopisać tej samej porcji dwa razy. Projekt potrzebuje widocznego oczekiwania i reakcji zgodnej z możliwościami aplikacji. Przy błędzie ponowienie ma dotyczyć brakującego fragmentu, a nie automatycznie następnego. W próbie porównaj identyfikatory pozycji przed i po, bo dwa podobne zdjęcia mogą utrudnić zauważenie powtórzenia. Ten sam problem sprawdź przy spóźnionej odpowiedzi, która wraca po zmianie kategorii: nie powinna dołączyć dawnego materiału do nowej listy.

Informacja „Pokazano wszystkie wyniki” musi mieć podstawę w odpowiedzi systemu. Brak dalszych wierszy na ekranie nie jest taką podstawą, jeżeli trwa żądanie lub zadziałał limit. Gdy proces korzysta także z agenta, osobny odbiór kompletności pobranej listy dotyczy technicznego zakresu odczytu. Projekt interfejsu ma wiernie przekazać potwierdzony stan użytkownikowi.

Sprawdź też, co znaczy licznik. „60 z 120” może oznaczać sześćdziesiąt załadowanych produktów, lecz nie sześćdziesiąt świadomie obejrzanych. Jeżeli lista usuwa z pamięci wcześniejsze fragmenty, ten sam napis może sugerować dostępność, której już nie ma. Etykieta powinna opisywać właściwą wielkość, a zachowanie umożliwiać powrót zgodnie z obietnicą.

Przy paginacji nieudane przejście na stronę czwartą nie powinno oznaczać, że użytkownik ogląda już jej wyniki. Można zachować poprzednią stronę i pokazać błąd albo wyraźnie oznaczyć oczekiwanie na nową. Numer bieżącej strony, jej zawartość i adres powinny wskazywać ten sam stan. Podświetlenie „4” nad wierszami strony trzeciej tworzy fałszywy punkt odniesienia.

Nowy produkt dopisany na początku zbioru może przesunąć inne pozycje. W aplikacji trzeba ustalić stabilny sposób poruszania się po danych. Osoba projektująca nie musi wybierać konkretnej techniki zapytań. Powinna jednak zlecić próbę z dodaniem i usunięciem rekordu między porcjami. Wynik ma ujawnić powtórzenia oraz pominięcia, które utrudniłyby zadanie.

Tak samo filtry katalogu zmieniają zbiór, do którego odnosi się dalsze przeglądanie. Po zmianie warunków ustal skutek dla przeglądania: czy zaczynamy nową listę, jaki zakres doczytania zostaje wyczyszczony i co mówi etykieta wyniku. Dawna trzecia strona nie musi mieć sensu po zawężeniu do siedmiu produktów.

Działający pokaz nie kończy odbioru

Przycisk powinien dać się odnaleźć i uruchomić klawiaturą. Po doczytaniu osoba musi rozpoznać nową zawartość bez przeskakiwania całej wcześniejszej listy. Projekt potrzebuje uzgodnionego zachowania fokusu, czyli miejsca aktualnie obsługiwanego klawiaturą, i informacji o wyniku czynności. Automatyczna zmiana listy nie powinna przy okazji odbierać kontroli nad czytanym fragmentem.

Na telefonie sprawdź drogę w dół, otwarcie pozycji i powrót przy dłuższych tytułach. Powtórz ją po powiększeniu tekstu. To nie tylko test wyglądu dolnego przycisku. Inna wysokość kart ujawnia, czy aplikacja zachowuje rozpoznawalny rekord, czy jedynie wcześniej zapisaną odległość przewinięcia.

Publiczny katalog ma jeszcze innego odbiorcę: mechanizm wyszukiwarki zewnętrznej. Google wyjaśnia, że robot wyszukiwarki zwykle odkrywa adresy z odsyłaczy href i nie klika przycisków doczytujących zawartość. Dlatego wygoda ręcznego przeglądania nie potwierdza dostępności dalszych adresów dla tego mechanizmu.

Nie wyciągamy z tego obietnicy, że jeden wzorzec daje lepszą pozycję w wynikach. Do odbioru dochodzi odrębne sprawdzenie wykrywania właściwych adresów. Paginacja może być błędnie wdrożona, a doczytywanie może współistnieć z dostępną drogą odsyłaczy. Decyzja wizualna i warunki odczytu technicznego muszą zostać połączone dla konkretnej witryny.

Dla kupującej wracającej po kilku dniach przydatna może być lista zapisanych produktów. To inne narzędzie niż pamięć miejsca w historii przeglądarki. Nie obiecuj trwałego przechowania wyboru jedynie dlatego, że chwilę wcześniej udało się wrócić do trzeciej porcji katalogu.

Dwa warianty makiety porównuj na tych samych produktach i z tym samym poleceniem. Poproś o znalezienie wskazanego modelu, obejrzenie sąsiedniego i powrót do pierwszego. Potem daj osobne zadanie swobodnego przeglądania, bez wymuszania znalezienia konkretnej rzeczy. Obserwacje mogą prowadzić do różnych wyborów dla tych zadań. Mniejsza liczba kliknięć nie potwierdza jeszcze sprawniejszego znalezienia materiału, a dłuższe przewijanie nie musi oznaczać zadowolenia. Zapisz pomyłki oraz miejsca, w których osoba straciła orientację.

Wybór powinien wynikać z tego, przy którym wariancie odbiorca odnajduje materiał i odzyskuje miejsce bez pomyłki. W katalogu instrukcji może to być czytelna strona wyników z trwałym adresem, w galerii świadome doczytywanie z zachowanymi pozycjami. Każdy wariant potrzebuje dowodu powrotu i rozpoznania końca. Odbiorca ma kontynuować wybór, zamiast za każdym razem od początku zdawać egzamin z pamięci listy.