Міркування про пагинации

От

22.04.2020

831

Я довго збирав в голові розрізнені думки щодо пагинации, і нарешті, вирішив організувати їх у статтю.

Стабільне розташування посилань або кнопок

Якщо є можливість зробити так, щоб ваші елементи управління посторінкової навігації залишалися на одному місці сторінки – зробіть так, будь ласка.

Це ж так здорово, коли клік на одному і тому ж місці викликає одне і те ж дію! Та коли закінчилися сторінки, наступний клік не робить чогось несподіваного, не налітає на нове посилання, а припадати на безпечну порожню область сторінки:

Якщо положення кнопок на сторінці взаємозалежне, то не прибирайте непотрібні кнопки зовсім, а вчасно забороняйте їх, не забувши позначити заборонений статус зміною кольору або прозорості: ‘opacity: 0.5’. Або навіть так: ‘visibility: hidden’ – тоді кнопка перестане муляти очі, але все ще буде займати своє місце в документі.

Стійке вертикальне положення не менш важливо. Неприємно, коли управління пагінація скаче вгору-вниз по сторінці в залежності від невизначеної висоти тематичних блоків.

Якщо така поведінка кнопок неминуче, скажімо, тому що вони розташовуються під масивом результатів, то чому б не продублювати навігацію над контентом? Це дуже зручно, коли доводиться користуватися скроллом:

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

Написи

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

Поки непогано. А як щодо:

Може бути, це і відображає зміст пагинации, але виглядає аж надто громіздко. Тому й тоді, коли пагинация очевидна, і коли її зміст не пояснити двома словами, просто використовуйте стрілки:

Приклад – Dribbble. Текст тут просто не потрібен. Неписаний закон Інтернету говорить: клік по стрілці показує наступну частину контенту.

Однак у відсутності написів криється маленька проблема. Іноді важко визначити напрямок, в якому ми рухаємося. Особливо якщо користувач, потрапивши на сайт по зовнішньому посиланню, починає перегляд не з першої сторінки. В такому випадку добре б дати йому якусь підказку.

Напрямок

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

Якщо уявити сайт у вигляді шкали, за якою ведеться відлік часу, то стрілка, що відсилає нас до більш раннім матеріалів повинна показувати вліво. Але стрілка вліво міцно асоціюється з кнопкою браузера «Назад», яка дуже популярна і майже інтуїтивно сприймається як перехід на попередню сторінку:

Якщо у користувача є шанс переплутати напрямку, то я знову-таки прикрасив би кнопки пояснювальними написами, навіть ризикнувши при цьому чистотою дизайну.

Структура URL

Пагинация найчастіше заснована на послідовності посилань на кшталт:

website.com/page/1
website.com/page/2

і так далі. Це не так вже жахливо: принаймні, посилання виглядають зрозуміло. Біда в тому, що URL не містить інформації про те, які дані розбиваються на сторінки. Гірше того, вміст сторінок може змінитися. Вчорашній контент з першої сторінки завтра опиниться на третій. Така ситуація вкрай поширена, якщо контент розбитий по датах.

Ми – старожили глобального села – завжди починаємо турбуватися, якщо десь раптом ламається якась посилання. Але якщо посилання кожен день веде на різний контент, значить, вона з самого початку була зламана?

Ця проблема і справді може бути нерозв’язною при певних типах пагинации, але вона точно розв’язана при пагинации по датах; і більше того, вона може бути вирішена декількома способами. Наприклад, посторінкова навігація по блогах мережі Gawker відбувається за допомогою кнопок з такими URL-адресами:

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

Ці посилання завжди будуть вказувати на один і той же контент, оскільки вони містять час публікації першого запису з виведеного списку.

Посилання у вашому особистому блозі не обов’язково повинні бути розписані по секундах. В залежності від частоти появи записів, можна послатися на місяць, тиждень чи день публікації. Тоді пагинация, починаючи з головної сторінки, може використовувати посилання наступного виду:

website.com/blog/
website.com/blog/2014/09/
website.com/blog/2014/08/

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

І навіть якщо з якоїсь причини ви віддаєте перевагу використовувати цілі числа в хронологічному порядку, адже ви завжди можете починати рахувати навпаки, чи не правда? Замість 1, 2, 3… починайте з максимальною цифри, яка буде залежати від кількості наявного контенту:

website.com/blog/
website.com/blog/page/523/
website.com/blog/page/522/

Дивно, що такий спосіб пагинации застосовується відносно рідко. Може бути це пов’язано з тим, що для виведення пагинации необхідно буде спочатку запитати у бази даних кількість записів, що знизить швидкість видачі сторінки?

Кількість сторінок

Щодо запиту кількості записів: наскільки необхідно показувати кількість сторінок при пагинации? Щоб це зробити, вам точно доведеться підраховувати загальну кількість контенту:

Наскільки це корисно? Наприклад, за цим індикатором ви можете судити про те, почати вам переглядати результати пошуку чи варто уточнити запит. Або такий індикатор може стати в нагоді при побудові REST API для видачі даних.

Напевно можна знайти й інші причини. З іншого боку, у разі пошуку Google, який знаходить мільйони сторінок практично на будь-який запит, такий лічильник не дуже корисний.

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

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

Не те, щоб можливість перейти до останньої сторінки була б зовсім не зайвою, але обмежувати можливість швидкого переміщення певним набором сторінок не здається мені хорошою тенденцією фронтенд-розробки.

Ajax

Пагинация без оновлення всієї сторінки спочатку здається відмінною ідеєю. Але вона привносить у справу безліч додаткових запитань:

Замінювати контент або додавати його до існуючого?
Якщо замінювати, то чи потрібно при цьому скролл сторінку до початку нового контенту? Є хороший кросбраузерність спосіб зробити це?
Якщо додавати, то не виросте сторінка настільки, що браузер почне гальмувати?
Чи Не втратимо ми в такому випадку можливість зробити посилання на конкретну сторінку? Чи можемо ми надійно реалізувати ті речі, які і так робила перезавантаження всієї сторінки (ротацію банерів, наприклад)? І як все це буде індексувати пошуковий бот?
Потрібно змінювати зовнішній вигляд елементів управління пагінація? Наприклад, змінити напис «далі» на «завантажити контент»?
Чи буде працювати навігація у зворотний бік?
Змінюється URL-адресу в залежності від позиції?
Буде пагинация працювати в текстових браузерах, мобільних пристроях, інтернет-кіосках, ігрових консолях і т. д.?

Іншими словами, чи такий інтерфейс відповідати принципам відмовостійкості і прогресивного покращення?

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

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