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

Задачи

1. Дать возможность в одно действие переключать страницу.
2. Удобный переход на последнюю и первую страницу.
3. Правильное переключение на следующую и предыдущую страницы.
4. Удобочитаемый вывод списка страниц.
5. Выделение активной страницы.
6. Сделать всё вышеперечисленное по возможности в простом и симпатичном виде.

Решение задач:

Перед началом решения вышесказанных задач нужно определиться с тем, что нам нужно улучшать. Для этого перейдем на сайты, у которых есть навигация по страницам, и этих страниц явно больше 100. Для того, чтобы их найти, достаточно перейти в google и набрать поисковый запрос вида «719 720 721». После этого выбираем наиболее интересные примеры и изучаем их.

Я выбрал в качестве примеров недоработанной навигации по страницам следующие сайты:

1. PhotoUA
Украинское агентство цифровой фотографии создано с целью предоставления цифрового новостного фото.

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

2. EuroLine
Довольно известная грузинская авиакомпания EuroLine предоставляет перелеты в Европу и Азию.

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

3. Пресс-КIT
Украинское независимое агенство, предлагающее широкий спектр информационных, рекламных услуг, и разнообразные возможности фото-службы.

Увы и ах. Опять информационное агенство, которое должно дать возможность быстро путешествовать по страницам сайта, но… не дает. Более или менее интуитивные, стрелочки не позволяют быстро выбрать нужную страницу. Прибавьте к этому слабое выделение текущей страницы и возможности пролистать все сразу.

4. Форум посвященный Гарри Поттеру.
Кому-то может показаться смешным то, что я выбрал в качестве примера этот сайт, но должен вас разочаровать: выбрал я его потому, что он имеет огромное количество страниц.

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

5. Фишки.Нет
Аннотации за ненадобностью тут не будет. Все знают, что это за сайт и с чем его едят.

Этот сайт, по сути — кошмарный сон юзабилиста, но навигация по его страницам дает ему анти-фору еще больше. Судите сами: простой список из страниц. Более идиотского способа вывести почти 900 чисел найти сложно. При этом страницы расположены в шахматном порядке, что, по идее, должно было улучшить навигационные качества, но не улучшает. Активная страница выделяется, но банально теряется среди такого массива информации. Создатели сайта решили не делать ссылки на последнюю\первую страницы и на следующие\предыдущие. Видимо, посчитав их ненужными при возможности быстро (как им казалось) выбрать нужную пользователю страницу.

Итак, с проблемами мы разобрались. Теперь стоит перейти к решению поставленных нами задач.

Дать возможность в одно действие переключать страницу
Под этой фразой я понимаю функцию быстрого выбора нужной страницы в 3 клика и меньше. Т.е. если пользователю нужно найти 761-ю страницу, не нужно его гонять по 10 страниц за раз. Нужно просто дать ему эту страницу выбрать.

Решить эту ситуацию довольно просто: либо выпадающим списком с прокруткой (прокрутка для того, чтобы список был меньше чем 2000px при 1000 страницах), или же перемоткой списка движениями мыши. Тут всё зависит от личных предпочтений дизайнера. Лично я предпочитаю движения курсором. Что я подразумеваю под этим — смотрите на картинку сверху.

Удобный переход на последнюю и первую страницу.
Если пользователь забрел вглубь сайта и хочет вернуться на первую страницу из списка, нужно дать ему способ сделать это быстро. По статистике, это одна из самых часто используемых функций навигации. Единственное ограничение в данном случае состоит в том, чтобы называть вещи своими именами и писать слова «Первая» и «Последняя» словами.

При этом желательно эти ссылки выводить полярно: “Первая” справа, “Последняя”слева .

Также при создании этих ссылок учитывайте, что они не должны забирать внимание у ссылок «Следующая»/«Предыдущая» — ведь они самые важные в навигации по страницам.

Правильное переключение на следующую и предыдущую страницы
Самый важный пункт списка. По статистике, при наблюдении за пользователями, эти ссылки используют чаще всего. Именно поэтому они должны быть довольно большого размера (не огромного, но такого, чтобы пользователю не нужно было прицеливаться). Их не стоит представлять в виде одиночных стрелочек, как это любят делать создатели движков.

Лучше всего совместить с помощью типографического форматирования стрелочку (они есть почти во всех стандартных шрифтах Windows) и надпись. Т.е. вот так: ← Следующая | Предыдущая →

Удобочитаемый вывод списка страниц
Тут всё просто. Не стоит показывать массив из всех страниц сайта сразу. Пример сайта Фишки.Нет ясно показывает нам, что навигация по такому списку — не из легких. Лучше всего выводить 5-7 страниц, которые находятся по соседству.

У некоторых людей существуют трудности с восприятием списка, если в нем находится больше семи элементов, поэтому выводить более семи соседних страниц не стоит.

Выделение активной страницы

Принципы те же, что и для всех остальных ссылок. Чтобы человек быстро понял, где он находится, выделять активную страницу нужно также активно: полужирным начертанием, изменением цвета и, что немаловажно, стоит убирать ссылку с этой цифры. Ведь ссылаться на страницу, на который пользователь уже находится — плохой тон.

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

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

Автор: Ярослав Бирзул
URL сайта: http://www.birzool.com

Кстати, тест происходит на виртуальной машинке, работаю я с СУБД под рутом, версия MySQL – 5.0.32.

1 Начнем с данных

Для тестирования создадим небольшую табличку и наполним ее чем-нибудь.

CREATE TABLE items (
id INT UNSIGNED NOT NULL AUTO_INCREMENT PRIMARY KEY,
height INT UNSIGNED NOT NULL DEFAULT 0,
width INT UNSIGNED NOT NULL DEFAULT 0,
price DECIMAL(10,2) NOT NULL DEFAULT 0.0,
title VARCHAR(255) NOT NULL
) ENGINE=InnoDB DEFAULT CHARSET=UTF8;


Небольшим скриптом на PHP был сгенерирован INSERT 100000 записей. Данные такого вида:
— порядок полей в INSERT:
height, width, price, title
— шаблон для полей:
$val_tmpl = “\t(%d, %d, %f, ‘Item %d’)”;
— тестовые значения ($i = 1..100000):
sprintf($val_tmpl, rand(0, 120), rand(0, 220), 10 * rand(0, $i) / $i, $i);

Заносим это все в нашу БД. И можно начинать…

2 Обычный метод постраничного вывода

Все, кто уже знает, чем плохи COUNT(*) и LIMIT… OFFSET, могут пропустить эту часть.

Прежде, чем рисовать навигатор, мы делаем SELECT COUNT(*) … WHERE (условия_выборки). Многие, почему-то уверены, что даже если у нас миллионы записей, но условия_выборки позволяют использовать индекс, то такой запрос отработает очень быстро. Проведем эксперимент. Выберем количество записей, у которых height больше 100. Для начала посмотрим, что будет, если индекса по полю height нет.

FLUSH STATUS;

SELECT SQL_NO_CACHE COUNT(*) FROM items WHERE height>100;
+———-+
| count(*) |
+———-+
| 16405 |
+———-+
1 row in set (0.09 sec)

SHOW STATUS LIKE ‘handler%’;

Последняя команда покажет, сколько же, и каких действий пришлось сделать СУБД, чтобы выполнить наш запрос. Так как индекса у нас нет, MySQL пришлось читать данные прямо из таблицы, поэтому нас интересует строка:
…
| Handler_read_rnd_next | 100001 |
…

То есть, MySQL пришлось сделать 100001 операцию перехода к следующей записи, чтобы найти все, соответствующие запросу.

Везде ниже перед каждым SELECT подразумевается выполнение FLUSH STATUS, а после: SHOW STATUS LIKE ‘handler%’.

Чем нам может помочь индекс.

ALTER TABLE items ADD INDEX height_idx (height);

SELECT SQL_NO_CACHE COUNT(*) FROM items FORCE INDEX(height_idx) WHERE height>100;
+———-+
| count(*) |
+———-+
| 16405 |
+———-+
1 row in set (0.04 sec)

В данном случае использовался индекс, поэтому Handler_read_rnd_next будет равен 0, а вот
…
| Handler_read_next | 16405 |
…
То есть индекс позволяет изначально посчитать только те записи, которые нужны, НО ему все равно требуется пробежаться по ним всем. Нет никакой магии, MySQL нигде не хранит количество записей, соответствующих запросу. Поэтому, если у вас миллионы записей, соответствующих условиям запроса, COUNT будет работать очень медленно.

Второй момент. LIMIT … OFFSET. Тот же эксперимент. Попросим нам 5 записей.

SELECT SQL_NO_CACHE * FROM items FORCE INDEX(height_idx) WHERE height>100 LIMIT 5;
…
5 rows in set (0.00 sec)
…
| Handler_read_next | 4 |
…
Вроде все логично. А теперь попросим вернуть другие 5 записей, начиная с 16401.

SELECT SQL_NO_CACHE * FROM items FORCE INDEX(height_idx) WHERE height>100 LIMIT 16400, 5;
…
5 rows in set (0.13 sec)

Видим, что время выборки значительно возросло. Смотрим статус:
…
| Handler_read_next | 16404 |
…
То есть, MySQL, прочитал все 16405, а только потом просто откинул все ненужные.
Как быть?

3 Как быть

Итак. От нас требуется вывести 10 записей, а так же нарисовать меню навигации. Мы поняли, что, чтобы дойти до записи, с которой необходимо начать отдавать нам результаты, MySQL тратит много лишних действий. Единственное, как это избежать – сразу перейти к нужной, изменив условия выборки.
Рассмотрим все на простом примере: пусть записи выдаются отсортированные по id. В этом случае нам нужно вместе со ссылкой передать id записи, на которой мы остановились. А остановимся мы на записи с id=10. То есть, в параметрах ссылки на следующую страницу нам нужно передать 10. Соответственно, для второй страницы запрос будет выглядеть так:

SELECT SQL_NO_CACHE id FROM items WHERE id>10 ORDER BY id LIMIT 10;

Кстати, в обоих случаях Handler_read_next будет равен 9. То есть, прыгнули на первую соответствующую запросу запись (благодаря индексу) и сделали 9 переходов на следующую. Самое главное, что какое бы число вместо 10 в условие мы не подставили – мы всегда в результате SHOW STATUS увидим одно и то же, и время выполнения такого запроса уже не будет зависеть от того, где мы находимся, а будет зависеть только от того, сколько и чего мы выбираем.
Надеюсь, смысл Вам понятен. Давайте тогда решим, что делать с меню навигации, а потом перейдем к более сложной ситуации. Пусть в url мы используем ключевые слова next, previous и last. В каких случаях показывать ссылки «вперед», «назад» и «последняя»?
Каждый раз, когда нам приходит next (запрос следующей страницы), мы выбираем не 10 записей, а 11, начиная с id, переданного в параметрах запроса. Если нам вернулось 11 записей, то следует показать ссылку вперед с id 10-й записи, а 11-ю откинуть. Если вернулось меньше 11 записей, то ссылку вперед показывать не надо. При этом мы всегда (всегда, когда пришло next) показываем ссылку назад (previous) с id первой записи из выборки. Ссылки «в начало» и «последняя» всегда показываются вместе с «назад» и «вперед» соответственно. То есть, если мы решили показывать «назад», то должны показать и «в начало».
Каждый раз, когда нам приходит previous (запрос на предыдущую страницу), мы выбираем 11 записей, у которых id меньше указанного в запросе, отсортированные в обратном порядке. То же самое: если вернулось 11 записей, то ссылку «назад» показываем. Ссылку вперед показываем всегда.
Надеюсь, понятно написал…
Что если нам пришел запрос «last»? Просто показать 10 записей, начиная с самой последней. То есть:

SELECT id FROM items ORDER BY id DESC LIMIT 10;

Думаете, у кого-нибудь из пользователей хватит сил промотать несколько сотен, а то и тысяч страниц, для того, чтобы обвинить Вас во лжи, обнаружив в итоге на первой странице не 10 записей? Даже если и хватит, то Вы можете ответить, что он слишком долго мотал…

Предыдущий пример был прост тем, что id – уникален. А что если требуется сортировка по полю, значения которого могут повторяться? Например, height в нашем случае. Простым запросом было выяснено, что в таблице каждое значения height встречается примерно 800 раз. Просто передать последний выведенный height в параметрах запроса уже мало. Поможет нам всё тот же id. От нас просят отсортировать записи по высоте, но это ведь не мешает нам отсортировать их потом еще и по id?
Для этого нам понадобится новый индекс:

ALTER TABLE items ADD KEY height_id_idx (height, id);

Запрос для первой страницы будет такой:

SELECT SQL_NO_CACHE id, height FROM items ORDER BY height, id LIMIT 10;

В моих результатах у последней записи height=0, id=1174. Так и надо передать следующей странице. Например, next_0_1174 или next/0/1074 – как Вам удобнее.
Теперь нам нужно выбрать записи, у которых либо height больше 0, либо height=0, а id>1174 (именно для этого мы и сделали дополнительную сортировку).
То есть:

SELECT SQL_NO_CACHE * FROM items WHERE (height>0) OR (height=0 AND id>1174) ORDER BY height, id LIMIT 10;

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

SELECT SQL_NO_CACHE * FROM items WHERE (price>5) OR (price=5 AND height>0) AND (price=5 AND height=0 AND id>1174) ORDER BY price, height, id LIMIT 10;

Остается только передавать все необходимые данные, правильно их обрабатывать и подставлять в запрос. И про индекс не забудьте.

4 Что делать с количеством результатов

Как быть, если мы хотим показать пользователям, сколько же результатов найдено? Так как речь идет о больших числах, то вряд ли нас кто-то будет проверять. Тот же гугл может выдать, что нашел 1000000 страниц, соответствующих запросу, но больше 1000 вы не увидите. Мы тоже можем выдать количество результатов лишь примерно. Где его взять и как оценить? Помните, мы выполняли запрос:

SELECT SQL_NO_CACHE COUNT(*) FROM items FORCE INDEX(height_idx) WHERE height>100;

А давайте сделаем так:
EXPLAIN SELECT SQL_NO_CACHE * FROM items FORCE INDEX(height_idx) WHERE height>100;

В результате получим что-то такое:
+—-+————-+——-+——-+—————+————+———+——+——-+————-+
| id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra |
+—-+————-+——-+——-+—————+————+———+——+——-+————-+
| 1 | SIMPLE | items | range | height_idx | height_idx | 4 | NULL | 22616 | Using where |
+—-+————-+——-+——-+—————+————+———+——+——-+————-+

Столбец rows как раз показывает оценочное число записей, которые нужно просмотреть. 22616 и 16405 – разница совсем не велика. Можно округлить до ~20000, да и ладно. Сойдёт. Только помните, что если используете, например, подзапросы и/или объединения, то EXPLAIN вернет несколько строк. Их все надо прочитать и перемножить значения rows.

Заключение

Данная проблема уже освещалась вскользь на хабре, но не так подробно.
Статья получилась больше, чем ожидал, хотя текст и разбавлен вставками запросов и результатов. В данный момент некуда выложить использованный для генерации данных скрипт + sql файлы. В общем… На заключение сил не осталось:)

Источник: http://habrahabr.ru/blogs/mysql/44608/