Рассуждения о пагинации

Я долго копил в голове разрозненные мысли касательно пагинации, и наконец, решил организовать их в статью.

Стабильное расположение ссылок или кнопок

Если есть возможность сделать так, чтобы ваши элементы управления постраничной навигацией оставались на одном месте страницы – сделайте именно так, пожалуйста.

Это же так здорово, когда клик на одном и том же месте вызывает одно и то же действие! И когда страницы закончились, последующий клик не делает чего-то неожиданного, не налетает на новую ссылку, а приходиться на безопасную пустую область страницы:

Если положение кнопок на странице взаимозависимо, то не убирайте ненужные кнопки совсем, а вовремя запрещайте их, не забыв обозначить запрещённый статус изменением цвета или прозрачности: ‘opacity: 0.5’. Или даже так: ‘visibility: hidden’ – тогда кнопка перестанет мозолить глаза, но всё ещё будет занимать своё место в документе.

Устойчивое вертикальное положение не менее важно. Неприятно, когда управление пагинацией скачет вверх-вниз по странице в зависимости от неопределённой высоты контентных блоков.

Если такое поведение кнопок неизбежно, скажем, потому что они располагаются под массивом результатов, то почему бы не продублировать навигацию над контентом? Это очень удобно, когда приходится пользоваться скроллом:

Конечно, ситуации бывают разные, но идеальным (пусть не всегда достижимым) вариантом для постраничной навигации было бы ‘position: fixed’.

Надписи

Надписи на кнопках могут помочь быстро определить, что именно пагинирует наша пагинация (почти скороговорка). Например:

<- старые посты | новые посты ->
<- предыдущая страница | следующая страница ->

Пока неплохо. А как насчёт:

<- более популярные статьи | менее популярные статьи ->
<- более релевантные документы | менее релевантные документы ->

Может быть, это и отражает смысл пагинации, но выглядит уж слишком громоздко. Поэтому и тогда, когда пагинация очевидна, и когда её смысл не объяснить двумя словами, просто используйте стрелки:

Однако в отсутствии надписей кроется маленькая проблема. Иногда трудно определить направление, в котором мы движемся. Особенно если пользователь, попав на сайт по внешней ссылке, начинает просмотр не с первой страницы. В таком случае хорошо бы дать ему какую-нибудь подсказку.

Направление

Говоря о стрелках, неплохо было бы выяснить, в какую сторону они должны показывать. Мои наблюдения говорят о том, что в подавляющем большинстве случаев пагинация начинается со стрелки, смотрящей направо, как, например, в поисковой выдаче Google. В то же время я наблюдал немало жарких споров на эту тему, и аргументы обеих сторон были достаточно состоятельны.

Если представить сайт в виде шкалы, по которой ведётся отсчёт времени, то стрелка, отсылающая нас к более ранним материалам должна показывать влево. Но стрелка влево прочно ассоциируется с кнопкой браузера «Назад», которая очень популярна и почти интуитивно воспринимается как переход на предыдущую страницу:

Если у пользователя есть шанс перепутать направления, то я опять-таки украсил бы кнопки пояснительными надписями, даже рискнув при этом чистотой дизайна.

Структура URL

Пагинация зачастую основана на последовательности ссылок вроде:

и так далее. Это не так уж ужасно: по крайней мере, ссылки выглядят понятно. Беда в том, что URL не содержит информации о том, какие данные разбиваются на страницы. Хуже того, содержимое страниц может измениться. Вчерашний контент с первой страницы завтра окажется на третьей. Такая ситуация крайне распространена, если контент разбит по датам.

Мы – старожилы глобальной деревни – всегда начинаем беспокоиться, если где-то вдруг ломается какая-то ссылка. Но если ссылка каждый день ведёт на разный контент, значит, она с самого начала была сломана?

Эта проблема и в самом деле может быть неразрешимой при определённых типах пагинации, но она точно разрешима при пагинации по датам; и более того, она может быть решена несколькими способами. Например, постраничная навигация по блогам сети Gawker происходит при помощи кнопок с такими URL-адресами:

lifehacker.com/?startTime=1411848000454
lifehacker.com/?startTime=1411848000413

Эти ссылки всегда будут указывать на один и тот же контент, поскольку они содержат время публикации первой записи из выводимого списка.

Ссылки в вашем личном блоге не обязательно должны быть расписаны по секундам. В зависимости от частоты появления записей, можно сослаться на месяц, неделю или день публикации. Тогда пагинация, начиная с главной страницы, может использовать ссылки следующего вида:

По окончанию соответствующего периода содержимое, на которое ведет ссылка, больше не будет изменяться.

И даже если по какой-то причине вы предпочитаете использовать целые числа в хронологическом порядке, вы ведь всегда можете начинать считать наоборот, не правда ли? Вместо 1, 2, 3… начинайте с максимальной цифры, которая будет зависеть от количества имеющегося контента:

Странно, что такой способ пагинации применяется относительно редко. Может быть это связано с тем, что для вывода пагинации необходимо будет сначала запросить у базы данных количество записей, что снизит скорость выдачи страницы?

Количество страниц

Насчёт запроса количества записей: насколько необходимо показывать количество страниц при пагинации? Чтобы это сделать, вам точно придётся подсчитывать общее количество контента:

<- Page 1 of 302 ->

Насколько это полезно? Например, по этому индикатору вы можете судить о том, начать ли вам просматривать результаты поиска или стоит уточнить запрос. Или такой индикатор может пригодиться при построении REST API для выдачи тех же данных.

Наверняка можно найти и другие причины. С другой стороны, в случае поиска Google, который находит миллионы страниц практически на любой запрос, такой счётчик не слишком полезен.

Кроме отображения количества контента можно использовать цифры для быстрого перемещения:

<- [1] … [5] 6 [7] … [302]  ->

Подобная навигация по страницам всегда казалась мне излишне усложнённой, почти до бесполезности. Не говоря уже о нарушениях консистентности положения кнопок или ссылок.

Не то, чтобы возможность переместиться к последней странице была бы совсем лишней, но ограничивать возможность быстрого перемещения определённым набором страниц не кажется мне хорошей тенденцией фронтенд-разработки.

Ajax

Пагинация без обновления всей страницы поначалу кажется отличной идеей. Но она привносит в дело множество дополнительных вопросов:

• Заменять контент или добавлять его к существующему?
• Если заменять, то нужно ли при этом скроллить страницу к началу нового контента? Есть ли хороший кроссбраузерный способ сделать это?
• Если добавлять, то не вырастет ли страница настолько, что браузер начнёт тормозить?
• Не потеряем ли мы в таком случае возможность сделать ссылку на конкретную страницу? Можем ли мы надёжно реализовать те вещи, которые и так делала перезагрузка всей страницы (ротацию баннеров, например)? И как всё это будет индексировать поисковый бот?
• Нужно ли изменять внешний вид элементов управления пагинацией? Например, сменить надпись «дальше» на «загрузить контент»?
• Будет ли работать навигация в обратную сторону?
• Меняется ли URL-адрес в зависимости от позиции?
• Будет ли пагинация работать в текстовых браузерах, мобильных устройствах, интернет-киосках, игровых консолях и т. д.?

Иными словами, будет ли такой интерфейс соответствовать принципам отказоустойчивости и прогрессивного улучшения?

Новые темы на WordPress.com двигаются в опасном направлении. Например, многие из них имеют Ajax-кнопку «Older Posts» (предыдущие посты):

Конкретно в этой теме («Eighties» – «Восьмидесятые») навигация по страницам вообще невозможна без JavaScript. Можно только перейти к началу месяца по календарным ссылкам в подвале. Весьма опрометчивое решение, на мой взгляд.

Последовательность

Какое бы стратегическое решение касательно пагинации вы не приняли, старайтесь придерживаться его во всех частях сайта.