пагинация в приложении это
Бесконечная прокрутка или пагинация
У каждого способа есть свои плюсы и минусы. В этой статье разберем их подробнее и узнаем, какой метод стоит использовать.
Бесконечная прокрутка.
Страница просто обновляется, когда вы прокручиваете ее вниз. Этот способ позволяет просматривать бесконечное количество контента без видимой финишной черты.
Автор: Claudio-Scotto
Плюсы бесконечной прокрутки:
1. Вовлечение пользователей.
При использовании бесконечной прокрутки пользователь может дольше оставаться на странице. В социальных сетях огромные объемы данных, которые эффективно просматривать с помощью бесконечной прокрутки. В том случае, когда пользователь не ищет что-то конкретное, а просто выбирает из множества представленных вариантов, бесконечная прокрутка — отличный вариант. Преимущества бесконечной прокрутки можно увидеть на примере Instagram. Пользователи сканируют информацию, не отвлекаясь на переход к следующей странице и полностью вовлечены в процесс.
2. Прокрутка проще клика.
На десктопе и на мобильном устройстве прокрутка для пользователя проще, чем нажатие. Для длинного или непрерывного контента (книга, учебный материал или новостная лента) бесконечная прокрутка обеспечивает большее удобство для пользователя.
3. Прокрутка хороша для мобильных устройств.
Чем меньше экран, тем длиннее прокрутка. Просмотр с мобильных устройств набирает популярность, это один из важных факторов внедрения бесконечной прокрутки. Благодаря возможности управлять жестами на мобильном устройстве, пользователи получают удобный интерфейс.
Минусы:
1. Поиск товара и местоположения.
Когда пользователь находится в определенном месте потока информации без пагинации, он не может добавить в закладки свое местоположение и вернуться к нему позже. Если пользователь закроет сайт, то потом ему придется вновь прокручивать вниз, чтобы найти то место, на котором закончил. Это раздражает и портит общее впечатление от сайта. Проблему можно частично решить, если пользователь переходя со страницы на товар, а потом обратно, оказывается в том же месте, где остановился, а не в начале страницы.
2. Неактуальная полоса прокрутки.
При бесконечной прокрутке полоса прокрутки не отражает реальный объем данных.
3. Отсутствие футера.
В футере находится информация, которая иногда нужна пользователю. При бесконечной прокрутке футер недоступен. Одним из решений этой проблемы может быть кнопка «загрузить еще». Пока пользователь не нажмет эту кнопку, контент не будет загружаться и футер будет виден.
Пагинация
Делит контент на отдельные страницы. Чтобы посмотреть больше контента, в пагинации нужно перейти на следующую страницу.
Пагинация на google.com
Плюсы пагинации:
1. Хорошая конверсия.
Пагинация подходит при поиске чего-то конкретного. При анализе результатов пользователь знает точное количество результатов поиска, может принять решение о том, где остановиться, на какую именно страницу вернуться назад или сколько результатов посмотреть.
2. Чувство контроля.
3. Местоположение предмета.
В контенте, разбитом на страницы, проще ориентироваться и пользователь помнит о местонахождении предмета хотя бы приблизительно. Поэтому для коммерческих сайтов и приложений с большим количеством товаров лучше использовать пагинацию.
Минусы:
1. Дополнительные действия.
Для того, чтобы перейти на следующую страницу, нужно найти ссылку для перехода на новую страницу, навести курсор, щелкнуть и дождаться загрузки страницы. Это занимает время и может отвлечь внимание.
Кнопка «Ещё»
Компромиссный вариант между бесконечной прокруткой и пагинацией. Позволяет решить проблему с отсутствием футера при бесконечной прокрутке и уменьшает количество дополнительных действий, как при пагинации. Увеличьте количество контента на одной странице, чтобы пользователю не пришлось часто нажимать на кнопку, но в то же время у него будет возможность долистать до футера
На сайте blue-dream.ru используется кнопка «Ещё». Пользователь совершает минимум дополнительных действий и видит футер. При этом, если он заходит на страницу товара, а потом возвращается назад, он попадает в то же место, а не в начало страницы
С точки зрения SEO
Выводы
Перед выбором стоит взвесить все достоинства и недостатки методов и учесть специфику вашего продукта. Бесконечная прокрутка эффективна лишь в некоторых случаях — для сайтов и приложений с потоком пользовательского контента, например, таких как instagram, pinterest и facebook. Пагинация хорошо подходит для коммерции и целевых сайтов и приложений. Способ с добавлением кнопки «Ещё» более гибкий и универсальный.
Сравнение достоинств и недостатков трех методов
Пагинация списков в Android с RxJava. Часть I
Часто при разработке клиента мы сталкиваемся с задачей отображения какой-либо информации с сервера, базы данных или еще чего-нибудь в виде списка. И при прокручивании списка данные должны автоматически подгружаться и вставляться в список незаметно для пользователя. У пользователя вообще должно сложиться впечатление, что он скроллит бесконечный список.
В данной статье я бы хотел рассказать вам о том, как сделать автоподгружаемый список простейшим в реализации для разработчика и максимально эффективным и быстрым для пользователя. А также о том, как нам в этом здорово поможет RxJava с ее главной догмой — «Everything is Stream!»
Как нам реализовать такое в Android?
Помните, я в начале говорил про главную догму Rx — «Everything is Stream!». Если в ООП мы мыслим категориями объектов, то в Реактивном — категориями потоков.
RxJava подобно огромному набору «конструкторов», из которых разработчик может создавать самые различные конструкции. Начало конструкции уже положено — список «выпускает» элементы, являющиеся номерами последней видимой строки списка. Далее можно вставить конструктора (они же по сути и потоки), отвечающие за обработку полученных значений, отправку запросов на подгрузку новых данных и встраивания их в список. Ну обо всем по порядку.
Даешь реактивный код!
А теперь к практической части.
Теперь AutoLoadingRecyclerView должен «излучать» порядковый номер последнего видимого на экране элемента.
Уже лучше. А теперь уменьшим «флуд» канала. Пусть канал «излучает» элементы только тогда, когда это необходимо, то есть когда нужно подгрузить новую порцию данных.
Вы, наверное, хотите спросить, откуда я взял вот это условие:
Но все равно полностью от флуда канала мы не избавились. Когда условие начала подгрузки выполняется и скроллинг продолжается, канал продолжает нас «заваливать» сообщениями. И мы имеем все возможности послать несколько раз одинаковые запросы на подгрузку данных, да и backpressure никто не отменял — сетевой клиент может сломаться. Поэтому, как только мы получаем первое сообщение от канала, мы сразу же отписываемся от него, запускаем подгрузку данных, обновляем адаптер и список, и потом снова подписываемся к каналу, который уже не будет «флудить», так как поменяется условие (количество элементов в списке увеличится):
И так по циклу. А теперь внимание на код:
А для того, чтобы у нас сложилось целостное впечатление, внимание на полный код ниже:
Страх и ненависть и пагинация
А в чем проблема?
Как бы нам не хотелось этого отрицать, практика показывает, что подавляющее большинство своего времени типичный iOS-разработчик проводит за работой с табличками. Проектирование сервисного слоя — это интригующе, разработка универсального роутинга в приложении — захватывающе, а от настройки гибких политик кэширования вообще крышу сносит, но работа с табличными интерфейсами — это наши серые будни. Иногда луч света все же попадает и в эту область, и вместо очередной возни с constraint’ами перед нами может встать задача реализации постраничной загрузки — или, как это модно называть в мобильных приложениях, infinite scroll’а.
Грузить сразу все новости, объявления, списки фильмов с удаленного ресурса как минимум не эффективно, поэтому в большинстве случаев сервер предоставляет клиентам различные механизмы разбития всего объема данных на части ограниченного размера.
Как говорится, so far so good. Мы загружаем первую партию данных, отображаем их в таблице, прокручиваем её до конца, загружаем следующую партию — и так до бесконечности. К сожалению — ну или к счастью, мы же любим вызов — на этом все только начинается.
В зависимости от сложности проекта и степени костыльности API, достаточно простая задача рискует переродиться в Нечто. Нечто именно с большой буквы, потому что это создание в итоге обретает свою собственную жизнь и начинает рушить судьбы всех, кто его коснется. Ближе к делу — приведу пример из реальной жизни, случившийся, тем не менее, в совсем абстрактном проекте.
Условия, с которыми нужно было работать:
Плохие новости — сделать в подобных случаях все правильно сложно. Хорошие новости — у меня в запасе есть целый структурированный арсенал костылей, который помогает справиться с большинством возникающих вопросов и проблем.
Декомпозиция
Сколь угодно сложная проблема или задача становится решаемой, если разбить её на ограниченное количество шагов. Наш случай не исключение. Чтобы понять принцип работы всей системы постраничной загрузки в вашем приложении достаточно декомпозировать её на несколько секций:
Задача реализации постраничной загрузки чаще всего делится на две крупные части: подгрузка данных вниз и обновление ленты, обычно совершаемое при pull-to-refresh. К каждой из этих задач требуется свой подход, целиком зависящий от приведенной выше схемы.
Костыли
Этот раздел — ключевая часть всего материала. Я собрал все костыли, которые вынужденно использовал при реализации сложного механизма постраничной загрузки на limit/offset.
Небольшой ликбез. Limit/offset — это наиболее часто встречающийся подход к реализации постраничной загрузки данных. Offset — это сдвиг относительно первого элемента. Limit — количество загружаемых данных.
Пример: пользователь хочет загрузить 10 новостей, начиная с двадцатой. offset: 20, limit: 10.
Подгрузка вниз / Лента изменяется
Если лента может быть изменена, не важно каким образом, то при попытке запросить следующую страницу мы можем столкнуться со сдвигом элементов вверх или вниз. Решение проблемы состоит из двух шагов. Первый относится к смещениям вниз. Представим ситуацию, при которой у нас уже загружена первая страница из пяти элементов. До следующего запроса структура данных на сервере изменилась и сверху выдачи добавились два новых элемента. Теперь при загрузке следующей страницы мы получим два элемента, которые у нас уже есть в кэше.
Ситуация может быть и хуже, если за время отсутствия синхронизации на сервер добавилось элементов больше, чем установлено в свойстве limit — тогда мы не получим ни одного нового элемента. Если в качестве offset’а мы будем использовать общее количество элементов в кэше, то застрянем в этой точке навсегда, так как продолжим запрашивать те элементы, которые уже были загружены.
Проблема решается достаточно просто. При получении очередной порции данных мы подсчитываем количество пересечений с закэшированным контентом — и в дальнейшем используем полученное значение как сдвиг offset’а. В приведенном выше примере этот сдвиг будет равен 2.
Подгрузка вниз / Любая часть выдачи может быть изменена
Рассмотрим следующую ситуацию: мы загрузили страницу, но затем первые два элемента были удалены. Запросив следующую порцию данных, получаем дырку в два элемента. Если ничего не предпринять, приложение об этом ничего не узнает — и данные никогда не загрузятся.
Выход из этой ситуации — всегда запрашивать данные с наложением в один элемент. Если при получении данных мы не найдем пересечений — можно либо отменить результат запроса, либо повторить его с другими параметрами.
Небольшой лайфхак в копилку — если какие-то элементы в ленте потеряются, всегда можно сделать серьезное лицо и прочитать лекцию про интеллектуальное ранжирование данных, выполняемое на клиенте. Не поверят — покажите Facebook, у которых одна и та же выдача на каждом устройстве всегда выглядит абсолютно по-разному.
Подгрузка вниз / Выдача может быть реструктуризована в случайный момент времени
В таком случае самым простым вариантом реализации будет работа с так называемым слепком ленты. Под этим термином обычно понимают список идентификаторов всех записей выдачи. При первом открытии мы запрашиваем такой слепок и сохраняем его в базе, либо просто держим в памяти. Теперь для получения следующей страницы мы будем пользоваться не стандартным limit/offset, а более сложным запросом — просить сервер отдать посты по конкретным 20 идентификаторам.
Даже если выдача неожиданно будет реструктуризована, нам это не помешает — мы работаем с тем слепком, который был актуален на момент первого запроса — и для клиента лента будет отсортирована точно также, как в момент первого открытия.
Обновление ленты / Элементы добавляются сверху
В этом случае нам в первую очередь необходимо уметь определять наличие дырок, образующихся в том случае, если со времени последней синхронизации было добавлено большое количество новых элементов.
Мы запрашиваем константное количество данных и проверяем наличие пересечений с данными из кэша. Если пересечения есть — все хорошо, можно продолжать работать в обычном режиме. Если пересечений нет — это значит, что мы пропустили несколько постов.
Что делать в этом случае — нужно решать для каждого конкретного приложения. Можно сбросить все данные, кроме запрошенных пяти элементов. Можно продолжать подгружать элементы сверху постранично, пока не будут обнаружены пересечения.
Обновление ленты / Любая часть выдачи может быть изменена
У проблемы есть два способа решения:
Сервер отдает diff’ы изменений в ленте, к примеру, основываясь на сохраненном Last-Modified последнего синхронизированного состояния выдачи. Параметр Last-Modified мы получаем из заголовков ответа сервера. Клиенту в таком случае останется просто применить эти изменения на состояние базы.
Если сервер так не умеет — приходится снова писать дополнительную сотню строк на клиенте. Нам нужно получить слепок постов (прямо как в одном из предыдущих пунктов) и сравнить его с текущим состоянием хранимых в кэше данных.
Все отсутствующие в слепке элементы — удалить, все недостающие — загрузить.
Обновление ленты / Меняется сортировка
Если выдача была реструктуризована, мы должны об этом узнать. Проще всего это сделать, послав на сервер head-запрос и сравнив параметры etag или Last-Modified с сохраненными значениями.
Если результат сравнения отрицательный — состояние кэша сбрасывается, слепок id обновляется.
Обновление ленты / Элементы выдачи могут меняться
Если элементы списка содержат изменяющиеся со временем данные, вроде рейтинга или количества лайков — их нужно обновлять. Решение проблемы, в принципе, коррелирует с одним из предыдущих пунктов — мы работаем либо с diff’ом, возвращенным сервером, либо запрашиваем краткие структуры данных, содержащие только значимые поля. После этого вручную обновляем состояние элементов.
Главное — максимально сократить количество передаваемых данных.
Советы на будущее
В завершении хочу дать несколько советов разной степени полезности.
Совет 1, очевидный
Бывает очень удобно иметь специальный объект, описывающий текущую выдачу. Назовите его списком, категорией, фидом — не важно.
Он может содержать текущий offset, максимальное количество элементов ленты, дату Last-Modified, слепок id — все, что нужно для описания списка элементов.
Совет 2, архитектурный
Не стоит смешивать в одном месте запросы на получение данных и обработку результатов. Если пытаться сразу же отображать полученные от сервера данные, вы наверняка столкнетесь с рядом проблем и ограничений.
Отделяйте логику запроса данных от логики их получения, обработки и отображения.
Абстрагируйтесь от сложностей и костылей, которые мы обсудили в этой статье. Наша главная цель — обеспечить постоянную синхронизацию состояния кэша и отображения. Если на экране отображается то же самое, что находится в базе данных — жизнь становится намного проще.
Совет 3, маскировочный
Инкапсулируйте всю логику обновления ленты и пагинации в отдельном объекте — фасаде над сервисами, занимающимися непосредственной загрузкой.
Именно в этом объекте находятся самые страшные вещи — вложенные блоки, сверка индексов и пересечений, логические ветвления. Для потребителей интерфейс фасада выглядит предельно простым и предоставляет основные методы для работы с постраничными данными — загрузка следующей страницы, обновление списка и полная его перезагрузка. Обратите особое внимание на то, что этот объект должен быть максимально хорошо протестирован.
Совет 4, самый главный
До последнего пытайтесь настоять на нормальной реализации постраничной загрузки на сервере. Limit/offset это, конечно, достаточно гибкое решение, однако клиент должен быть простым. Нет, правда, максимально простым!
Бесконечный скроллинг или пагинация — какой прием использовать для сайта
Разработчик Ник Бабич проанализировал два подхода к представлению данных на веб-страницах и сделал вывод, в каких случаях уместнее использовать нумерацию, а в каких — бесконечную прокрутку.
Редакция рубрики «Интерфейсы» публикует перевод материала.
Представить большое количество информации удобным для пользователей способом может быть довольно непросто.
Стоит ли использовать бесконечную загрузку для данных или все-таки остановиться на нумерованных страницах? Такой вопрос мучает многих дизайнеров. И действительно, выбор не из простых, ведь у каждого из методов свои сильные и слабые стороны, причем не всегда очевидные с первого взгляда. Рассмотрим оба метода, чтобы вам было проще делать выбор.
Бесконечный скроллинг
Бесконечный скроллинг — это механизм, позволяющий пользователям просматривать массивный поток контента как единое целое, без видимой финишной черты. Приложение просто подгружает новые данные, по мере того как пользователь прокручивает страницу вниз. Как бы соблазнительно это ни звучало, бесконечный скроллинг не является универсальным решением для любого сайта или приложения.
Преимущество 1: Вовлеченность пользователя и естественное желание глубже изучать материал
Если скроллинг используется как основной метод навигации по данным, это может положительно сказаться на времени нахождения пользователя на сайте или использования приложения. Увеличивается вовлеченность целевой аудитории. С ростом популярности социальных медиа пользователи часто имеют дело с массивными потоками данных, и бесконечный скроллинг предлагает довольно эффективный способ потребления этого океана информации. Независимо от используемого устройства люди склонны глубже изучать материал, когда это не требует от них дополнительных усилий.
Бесконечный скроллинг — почти жизненно необходимый метод для дискавери-интерфейсов, с помощью которых пользователь не ищет что-то конкретное. Ему просто нужно просмотреть большое количество элементов, чтобы найти то, что нравится.
Pinterest с его бескрайним океаном «пинов»
Преимущества бесконечного скроллинга можно наглядно оценить на примере новостной ленты Facebook. Очевидно, что пользователи никогда не смогут просмотреть абсолютно всю информацию в ленте, потому что контент обновляется непрерывно. С помощью бесконечного скроллинга Facebook старается показать максимум информации, и пользователи охотно пользуются лентой.
Новостная лента Facebook практически вынуждает пользователей скроллить еще и еще в поисках контента
Преимущество 2: Скроллить легче, чем кликать
С помощью колеса мышки или сенсорного экрана пользователям удобнее скроллить, чем кликать. Для длинной секции единого контента — например, гайдлайна — скроллинг куда удобнее, чем деление текста на несколько отдельных страниц. Кроме того, скроллинг требует меньшей точности, чем нажатие на ссылку или кнопку.
Когда контент разделен между несколькими страницами, каждый переход между ними требует дополнительного клика и времени на загрузку новой страницы. При скроллинге же обновление контента производится непрерывно, и для этого нужно всего одно действие
Преимущество 3: Скроллинг хорошо подходит для мобильных устройств
Чем меньше экран, тем длиннее скролл. Популяризация устройств с сенсорным экраном также выступает в пользу скроллинга. Для современных пользователей скроллинг стал практически интуитивным действием. В случае со скроллингом данные и действие по их получению (скролл) напрямую связаны друг с другом, поэтому пользователи получают по-настоящему отзывчивое взаимодействие от интерфейса вне зависимости от используемого устройства.
Источник изображения — Dribbble
Недостаток 1: Производительность страницы и ресурсы устройства
Скорость загрузки страницы во многом определяет то, как приложение или сайт воспринимает конечный пользователь. Многие исследования демонстрируют, что из-за медленной загрузки люди просто уходят с сайта или удаляют приложение, а это ведет к низкому коэффициенту конверсий. И это плохая новость для тех, кто использует бесконечный скроллинг.
Чем дальше пользователь прокручивает страницу вниз, тем больше контента загружается на одной странице. Это делает ее заметно «тяжелее» и в большинстве случаев негативно сказывается на работоспособности браузера или приложения.
Еще одна проблема — ограниченные ресурсы пользовательского устройства. На многих сайтах с бесконечным скроллом, особенно на тех, где много изображений, устройства с ограниченными ресурсами, такие как iPad, начинают работать заметно медленнее из-за огромного количества загруженных данных.
Недостаток 2: Поиск и местоположение объекта в потоке данных
Еще одна проблема с бесконечным скроллингом проявляется, когда пользователи доходят до определенной точки в потоке. Они не могут добавить свое местоположение в закладки, чтобы вернуться к нему позже. Покинув сайт или закрыв приложение, они потеряют свой прогресс: чтобы попасть в эту же самую точку снова, им придется проделать весь путь с самого начала. Отчасти это решается внедрением закладок, но корневая проблема остается в силе.
В интерфейсе сервиса Pinterest есть опция закладок
Невозможность определить свое положение при скроллинге вызывает у пользователей неудобства и в результате портит весь опыт взаимодействия с продуктом.
В 2012 году в Etsy вложила много сил в реализацию скролл-интерфейса и, к своему удивлению, обнаружили, что новый интерфейс не работал так же хорошо, как старый вариант с пагинацией. Хотя количество продаж осталось почти без изменений, вовлеченность пользователя была меньше: люди не использовали поиск так же активно, как раньше.
Интерфейс поиска с бесконечным скроллингом на Etsy. Текущая версия построена на пагинации
Дмитрий Фадеев отмечает: «Люди захотят вернуться к результатам поиска, чтобы вновь увидеть вещи, которые они выбрали раньше, и сравнить их с теми, которые нашли после. Бесконечный скроллинг не только нарушает эту динамику — он усложняет передвижение вниз и вверх по списку, особенно когда пользователь возвращается к странице в другое время и начинает поиск с самого верха. Ему вновь приходится прокручивать вниз и ждать загрузки контента. Поэтому интерфейс с бесконечным скроллингом на самом деле медленнее, чем с пагинацией».
Недостаток 3: Нерелевантный скроллбар
Пользователей может раздражать то, что скроллбар не отражает реального объема доступных данных. Вы думаете, что уже близки к концу, что само по себе заставляет прокрутить страницу еще немного вниз, — и когда вы уже практически «достигли дна», внезапно видите, что результаты просто удвоились в количестве. С точки зрения доступности и понятности интерфейса это, мягко говоря, не очень хорошо.
Полоса прокрутки должна отражать истинную длину страницы
Недостаток 4: Отсутствие футера
«Подвалы» существуют не просто так — они содержат контент, который может быть полезен для пользователей. Если пользователи не могут что-то отыскать или им нужна дополнительная информация, чаще всего они пытаются найти это в футере. Но лента скроллится бесконечно: когда пользователь добирается до футера, загружается еще одна порция данных, и вытесненный ими футер уходит из поля зрения.
Возьмем, к примеру, сервис Bing Images. Футер сервиса содержит ссылки Learn More и Help, но пользователям вряд ли удастся перейти по ним, так как ссылки будут постоянно «убегать» от них из-за загружаемого контента.
На сайтах с бесконечным скроллом «подвал» должен быть легкодоступным для пользователей. Этого можно добиться, сделав его «липким» либо вообще переместив в шапку или боковую панель, как это сделал Facebook.
Facebook перенес все ссылки из подвала (например, Legal, Careers) в панель справа от новостной ленты
Еще один вариант доступной подачи — загрузка контента по запросу с помощью кнопки Load More. В этом случае новый контент не будет загружаться автоматически, пока пользователь сам так не решит.
Instagram использует кнопку Load More, чтобы подвал был доступен пользователям
Пагинация
Пагинация — это механизм, который делит контент на отдельные страницы. Если, проскроллив вниз страницы, вы видите ряд цифр — это и есть пагинация сайта или приложения.
Преимущество 1: Хорошая конверсия
Пагинация хорошо работает, когда пользователь ищет в списке объектов что-то определенное, а не просто просматривает поток данных.
Основное преимущество пагинации наглядно показывает поиск Google. Поиск наиболее подходящих результатов может занять секунду или час — все в зависимости от ваших потребностей. Но, когда вы решите прекратить поиск, вы будете точно знать количество просмотренных результатов, и сможете сделать вывод, где остановиться или сколько результатов еще изучить.
Данные результатов поиска Google
Преимущество 2: Ощущение контроля
Бесконечный скроллинг похож на бесконечную игру: неважно, как далеко вы в итоге пройдете, вас всегда будет преследовать ощущение, что вы никогда не доберетесь до конца. Когда пользователи заранее знают количество доступных результатов, они могут принять более осмысленное решение. Дэвид Кирас в своем исследовании «Психология взаимодействия человек — компьютер» отмечает: «Достижение конечной точки дает ощущение контроля».
Исследование также поясняет: когда у пользователей есть ограниченные, но при этом релевантные результаты, им проще понять, ищут ли они то, что нужно. Кроме того, когда пользователи видят общее количество результатов (разумеется, если оно не бесконечно), им проще оценить, сколько времени займут поиски нужного материала.
Преимущество 3: Положение элемента
Постраничный интерфейс дает возможность держать в голове местоположение элемента. Естесвенно, пользователи не обязательно будут помнить точный номер страницы, но они будут примерно ориентироваться в списке результатов, а пронумерованные ссылки помогут быстрее туда добраться.
С пагинацией пользователи контролируют навигацию, потому что знают, какую страницу выбрать, чтобы попасть в нужное место.
Пагинация хорошо работает для коммерческих сайтов и приложений. При онлайн-покупках пользователям нужна возможность вернуться на место, откуда они ушли, чтобы сравнить вещи или купить ранее понравившийся товар.
Онлайн-магазин MR Porter использует пагинацию для представления товаров
Недостаток: Дополнительные действия
Чтобы перейти на новую страницу, используя пагинацию, пользователь должен найти целевую ссылку (например, «Next»), навести на нее мышкой, кликнуть и ждать, пока страница загрузится.
Для получения контента нужно кликнуть
Основная проблема в том, что большая часть сайтов в рамках одной страницы показывает пользователям очень ограниченное количество контента. Сделав страницы длиннее без ущерба для скорости загрузки, вы обеспечите пользователям большее количество контента на странице и сократите количество необходимых переходов между страницами.
В каких случаях что использовать
Есть всего несколько случаев, когда бесконечный скроллинг эффективен. Он лучше всего подходит для сайтов и приложений с контентом, который генерируют пользователи (Twitter, Facebook) или с визуальным контентом (Pinterest, Instagram). Пагинация же надежна и хорошо подходит для сайтов и приложений, которые удовлетворяют целенаправленным действиям пользователей.
Сервисы компании Google — наглядное подтверждение этого правила. Google Images использует бесконечный скролл, потому что восприятие изображений происходит гораздо быстрее, чем чтение текстовых результатов поиска. Это и есть основная причина, почему результаты Google Search до сих пор отображаются в более традиционной манере.
Заключение
Дизайнеры должны взвешивать плюсы и минусы бесконечного скроллинга и пагинации, перед тем как сделать окончательный выбор. Этот выбор будет зависеть как от контекста использования, так и от того, как будет поставляться сам контент.
Бесконечный скроллинг хорошо работает для проектов вроде Twitter, где пользователи поглощают бесконечный поток данных без поиска чего-либо конкретного, в то время как пагинация подходит для страниц результатов поиска, где люди ищут что-то конкретное и положение элементов имеет большую роль.