Комментарии 63
Притом, что ссылки выглядят как [1][2][3], номера страниц в URL можно сделать абсолютными, то есть 2075, 2074 и 2073.
НЛО прилетело и опубликовало эту надпись здесь
Сам был огорчен подобным. Но думаю это было вызвано объективными причинами.
что бы содержимое страниц не менялось можно в названии страицы указывать дату
Согласен с Вами, раньше было удобнее. И просматривать было удобнее и вообще было видно развитие Хабра ))
Я тоже согласен. Раньше с постраничкой было лучше. Можно было запомнить — что на какй странице находится.
Вообще, по собственному опыту обычно переходят с прямой постранички на обратную. С той целью, что номер страницы на которой расположено что-то никогда не меняется. И соответственно, что поисковым системам отдавать всегда актуальную информацию.
Вообще, по собственному опыту обычно переходят с прямой постранички на обратную. С той целью, что номер страницы на которой расположено что-то никогда не меняется. И соответственно, что поисковым системам отдавать всегда актуальную информацию.
Ленту новостей вообще поисковики не должны читать — noindex, follow.
Сам недавно думал над этим вопросом…
Мне кажется, что не все так однозначно — ведь лента может быть не только хронологическая, но и тематическая. Например, лента постов по тегу «fallout». С точки зрения соответствия поисковому запросу «новости fallout» — очень релевантная страница. Жалко ее закрывать для индексации.
Что скажете?
Мне кажется, что не все так однозначно — ведь лента может быть не только хронологическая, но и тематическая. Например, лента постов по тегу «fallout». С точки зрения соответствия поисковому запросу «новости fallout» — очень релевантная страница. Жалко ее закрывать для индексации.
Что скажете?
Индексировать надо стабильный контент — то есть, сами записи. И noindex, follow как-раз это и декларирует (судя, например, по www.webdesign.site3k.net/?/docs/robots_txt.html)
А нестабильный контент индексировать вредно — потому как это замусоривает результаты поиска быстроустаревающими (и поэтому зачастую на момент поиска уже невалидными) ссылками.
В ленте стабильным контентом на странице является только заголовок и правила отбора содержимого из имеющегося. В ленту обычно легко перейти с любой стабильной страницы, в неё входящей. И название ленты зачастую на странице поста есть, так что в индексы попадёт, и по поиску типа «новости fallout» Вы увидите какую-нибудь свежую новость именно по этой теме, и в ней ссылку на другие такие же, если на том сайте есть тематический лист. Это вместо того, чтобы увидеть общую ленту, в которой интересующая новость пролетала (и оказалась проиндексирована) три дня назад, а нынче отсутствует.
А нестабильный контент индексировать вредно — потому как это замусоривает результаты поиска быстроустаревающими (и поэтому зачастую на момент поиска уже невалидными) ссылками.
В ленте стабильным контентом на странице является только заголовок и правила отбора содержимого из имеющегося. В ленту обычно легко перейти с любой стабильной страницы, в неё входящей. И название ленты зачастую на странице поста есть, так что в индексы попадёт, и по поиску типа «новости fallout» Вы увидите какую-нибудь свежую новость именно по этой теме, и в ней ссылку на другие такие же, если на том сайте есть тематический лист. Это вместо того, чтобы увидеть общую ленту, в которой интересующая новость пролетала (и оказалась проиндексирована) три дня назад, а нынче отсутствует.
кста, вот тут тож человек про вредность индекса ленты ругается: habrahabr.ru/blogs/habrahabr_ideas/42634/#comment_1051692 — правда, решение предлагает встречное, похожее на то, о чём субж — делать страницы ленты стабильными. Это действительно удобно при чтении ленты, это решает беду устаревающей индексации, но, ИМХО, по-прежнему не привносит смысла в индексацию ленты поисковиками.
Я бы ввел нумерацию постов (можно не сильно заметную для глаза, чтобы не отвлекала). На базе их ID, например. И сделал бы поиск по номеру или диапазону номеров.
я как-то тоже рассуждал про способы нумераций страниц:
unixway.in.ua/2008/01/15/pages-numeration/
unixway.in.ua/2008/01/18/pages-numeration-2/
unixway.in.ua/2008/01/15/pages-numeration/
unixway.in.ua/2008/01/18/pages-numeration-2/
Поддерживаю. Из-за этого пришлось перейти на rss-reader
Кстати на счет индексации — если есть задача индексировать эти страницы, то могут возникнуть проблемы. Дело в том что для поисковика контент страниц будет меняться, и он будет считать их новыми, постоянно переиндксируюя. Проблема появится когда будет достигнут лимит «новых» страниц (исходя из эмпирического посыла — за раз робот забирает с сайта конечное число новых страниц), которые по сути старые, и начнут выпадать страницы с большими номерами.
habrahabr.ru/blogs/habrahabr_ideas/42634/#comment_1051097 — задачи индексировать не должно быть.
Алё, народ! чё минусовать-то? по существу б лучше возразили…
Интересно ваше мнение:
habrahabr.ru/blogs/habrahabr_ideas/42634/#comment_1051382
habrahabr.ru/blogs/habrahabr_ideas/42634/#comment_1051382
Думаю, не стоит разбивать информацию на порции постранично везде. Гораздо выгоднее учитывать контекст самой информации.
Например, если речь идет о постах на блоге, (коллективном или персональном — неважно), то я, скорее всего, хотел бы иметь возможность разбивать посты не постранично, а по дате. По дням, неделям, месяцам и т. д. Это позволит иметь красивые неизменные адреса на эти посты. А вот в случае если за конкретный месяц или неделю, постов набирается больше чем уместиться на одну страницу — делить посты постранично в рамках уже выбранного времени написания.
И еще: мне кажется, гораздо информативнее сделать ссылку «предыдущие 20 постов», чем смотреть на неясные цифры с неясным порядком.
Например, если речь идет о постах на блоге, (коллективном или персональном — неважно), то я, скорее всего, хотел бы иметь возможность разбивать посты не постранично, а по дате. По дням, неделям, месяцам и т. д. Это позволит иметь красивые неизменные адреса на эти посты. А вот в случае если за конкретный месяц или неделю, постов набирается больше чем уместиться на одну страницу — делить посты постранично в рамках уже выбранного времени написания.
И еще: мне кажется, гораздо информативнее сделать ссылку «предыдущие 20 постов», чем смотреть на неясные цифры с неясным порядком.
Что меня больше всего бесит, так это представление некоторых дизайнеров о направлении течения времени, которое у них почему-то противоположно направлению текста в русском языке. Да простят меня левши и семиты, но если мы пишем слева направо, то и будущее у нас находится справа, а поэтому ссылка на более свежий материал в области хронологической навигации должна находиться правее ссылки на более старый.
Сделать
[1] -> /page599
[2] -> /page598
[3] -> /page597
Как вариант.
[1] -> /page599
[2] -> /page598
[3] -> /page597
Как вариант.
Поддерживаю! Главный плюс обратной нумерации страниц в том, что конткент каждой из страниц никогда не поменяется.
Это плюс для поисковиков (а то часто находишь что-то старое, переходишь по ссылке на страницу, а там все уже уехало)
И плюс для «тормозов» )) например захожу я не часто, зайдя дочитал до 3-й страницы, потом пошел пообедать, возвращаюсь, перехожу на 4-ю и вижу половину страницу топиков, которые я уже читал.
Да и в реальной жизни, если вы ведете например дневник — новые записи появляются не на первой странице, а на последней!
Это плюс для поисковиков (а то часто находишь что-то старое, переходишь по ссылке на страницу, а там все уже уехало)
И плюс для «тормозов» )) например захожу я не часто, зайдя дочитал до 3-й страницы, потом пошел пообедать, возвращаюсь, перехожу на 4-ю и вижу половину страницу топиков, которые я уже читал.
Да и в реальной жизни, если вы ведете например дневник — новые записи появляются не на первой странице, а на последней!
А не проще ли пользоваться RSS?
С точки зрения красивости отображения листинга — [1] [2] [3] намного приятнее смотрится, нежели [289] [288] [287]… Но если же смотреть со стороны удобности пользования — обратный отсчёт действительно выигрывает. Как было уже замечено, на dirty.ru достаточно неплохо отображено «понимание», но так же не реализовано «передование». Актуальность ссылки по истечению времени, ИМХО, перевшивает красивость.
Меня жутко раздражает когда при чтении одной страницы, и затем перехода на другую появляются топики, которые были на предыдущей страницы из-за того что там превысился лимит постов.
Какая разница, прямой порядок в навигации или обратный, вправо мотать или влево, если через неделю ты по ссылке найдешь совсем не то, что было там раньше? Почему ссылка вида /page/1 ведет не на исторически первые топики на сайте вообще, а на последние? Как поисковики должны относиться к страницам, контент которых постоянно меняется? Как должен реагировать я, найдя что-то в поисковике и открыв страницу обнаружить что то, что я там планировал обнаружить съехало на десяток страниц вправо или влево?
Короче. Ссылки обзывать можно в любом порядке, хот цифрами, хоть буквами, хоть римскими, хоть стрелочками, чем угодно и как угодно, это всё зависит от идеологии ресурса. Главное чтобы ссылка ведущая на 5 последовательных постов отображала именно эти же 5 постов и через год. Топишь страница по адресу /page/1 — это исторически первые 5 постов а не 5 последних.
* Самое забавное, что понимая это, я никак не удосужусь сделать точно так же у себя: )
Короче. Ссылки обзывать можно в любом порядке, хот цифрами, хоть буквами, хоть римскими, хоть стрелочками, чем угодно и как угодно, это всё зависит от идеологии ресурса. Главное чтобы ссылка ведущая на 5 последовательных постов отображала именно эти же 5 постов и через год. Топишь страница по адресу /page/1 — это исторически первые 5 постов а не 5 последних.
* Самое забавное, что понимая это, я никак не удосужусь сделать точно так же у себя: )
Читаю хабр с начала, остановился на определенной странице, закладку эту не закрываю, потом возвращаюсь на неё и читаю дальше. А тут обнаружил, что на той странице незнакомые совсем посты. Давай листать, нашел. На следующий день тоже самое.
Так зачем это новшество вообще? Кто-нибудь попросил или создателям действительно так больше нравится или удобней?
В общем, я вас полностью поддерживаю :)
Так зачем это новшество вообще? Кто-нибудь попросил или создателям действительно так больше нравится или удобней?
В общем, я вас полностью поддерживаю :)
Это атавизм двухлетней давности и одна из последних вещей, который нужно сделать для оптимизации производительности базы данных. После 10-20 страниц нумерация должна переходить, например, на дни, а дни считаться, например, со времени первой публикации.
Хм… меня в ЖЖ жутко парит, когда читая ленту вдруг натыкаюсь на то, что на очередной странице я вижу не 50 постов, а вдруг 3, которые относятся к одному какому-то дню. И особенно неприятно, когда эти посты оказываются не следующими, которые были бы, если б чтение ленты продолжалось по-прежнему, и когда не видно ссылки перехода на предыдущий заполненный постами день, и надо лезть через календарь, обращая внимание на даты, и внимательно просматривая таблицу дней чтоб не пропустить очередную подчёркнутую дату.
Технически ленту с обратным отсчётом страниц на лету формировать тяжко, а вот с прямой стабильной нумерацией страниц можно совершенно ненапряжно заранее индекс в базе поддерживать. В общем, нумерация страниц ленты блога от старых к новым рулит неподецки!
Технически ленту с обратным отсчётом страниц на лету формировать тяжко, а вот с прямой стабильной нумерацией страниц можно совершенно ненапряжно заранее индекс в базе поддерживать. В общем, нумерация страниц ленты блога от старых к новым рулит неподецки!
Ну, парить, может, и парит, но от реальности не убежать.
Представьте условие: private_blog_id IN (0, x1, x2, x3,… xn) причем набор идентификаторов для каждого пользователя свой.
Небольшой проект на 1000 записей и 500 пользователей имеет ряд своих плюсов: можно делать что хочешь и как хочешь, но вот когда растёт набор данных и число просмотров, то тут уже приходится подстраиваться под другие правила и особого выбора в этом деле нет.
совершенно ненапряжно заранее индекс в базе поддерживать
Представьте условие: private_blog_id IN (0, x1, x2, x3,… xn) причем набор идентификаторов для каждого пользователя свой.
Небольшой проект на 1000 записей и 500 пользователей имеет ряд своих плюсов: можно делать что хочешь и как хочешь, но вот когда растёт набор данных и число просмотров, то тут уже приходится подстраиваться под другие правила и особого выбора в этом деле нет.
Запомнить в базе перечень записей на каждой статичной странице каждой ленты, когда ленты заранее определены — задача даже не тяжёлая. И вполне решает проблему. Единственное возможное противопоказание — это естественное желание иметь фиксированное число последних записей на первой странице. А с таким индексом получится только, как тут ниже назвали, «пульсирующая морда», что ИМХО, не очень критичное неудобство. %)
Это отлично, что для вас она не тяжёлая, для меня, честно скажу, очень тяжёлая.
Я так на пальцаъ не могу предельно точно представить чего будет стоить периодический обсчёт примерно в 50 000 х 5 000 = 250000000 страниц (и это без учёта всех лент, просто общее количество постов, пользователей, по 10 на страницу, грубое приближение) итераций и последующее хранение результата, грубо могу сказать, что обойдётся он очень дорого, на фоне того, что есть, это будет самой дорогой вычислительной операцией, обеспечивать которую будет самый огромный набор данных (если взять среднюю длину ряда из похожей таблицы с похожим распределением, то это примерно 160 гигабайт данных без индексов против размера всей базы около гигабайта).
Можно, конечно, сказать, что не все пользователи активные, что надо считать не для всех, но веселья от этого, уверяю, будет не меньше.
Давайте на чистоту: вы часто ходите дальше двадцатой страницы?
Я так на пальцаъ не могу предельно точно представить чего будет стоить периодический обсчёт примерно в 50 000 х 5 000 = 250000000 страниц (и это без учёта всех лент, просто общее количество постов, пользователей, по 10 на страницу, грубое приближение) итераций и последующее хранение результата, грубо могу сказать, что обойдётся он очень дорого, на фоне того, что есть, это будет самой дорогой вычислительной операцией, обеспечивать которую будет самый огромный набор данных (если взять среднюю длину ряда из похожей таблицы с похожим распределением, то это примерно 160 гигабайт данных без индексов против размера всей базы около гигабайта).
Можно, конечно, сказать, что не все пользователи активные, что надо считать не для всех, но веселья от этого, уверяю, будет не меньше.
Давайте на чистоту: вы часто ходите дальше двадцатой страницы?
Вот блин…
Ладно. Простая арифметика.
На странице 10 постов
Всего 11 постов.
Сколько на первой странице?
Ответ — 10. А на второй — 1.
Тепреь всего 12 постов.
Сколько на первой?
Ответ — опять 10. А на торой 2.
Где был второй пост второй страницы до последней публикации?
Ответ — на первой.
Как страницы не нумеровать — всё равно контент меняется.
Не меняться он будет только в том случае, если на первой странице сначала будет 1 пост, потом 2 и тд. пока количество не дойдёт до 10. А это не понравится никому.
Другой вариант — тот что предложил Juks — навигация по датам
Надеюсь, больше не будет вопросов?
Ладно. Простая арифметика.
На странице 10 постов
Всего 11 постов.
Сколько на первой странице?
Ответ — 10. А на второй — 1.
Тепреь всего 12 постов.
Сколько на первой?
Ответ — опять 10. А на торой 2.
Где был второй пост второй страницы до последней публикации?
Ответ — на первой.
Как страницы не нумеровать — всё равно контент меняется.
Не меняться он будет только в том случае, если на первой странице сначала будет 1 пост, потом 2 и тд. пока количество не дойдёт до 10. А это не понравится никому.
Другой вариант — тот что предложил Juks — навигация по датам
Надеюсь, больше не будет вопросов?
Совершенно верно. Но для решения конкретно моей задачи второй вариант нумерации подходит куда больше по той причине, что максимальное смещение постов на 75-й (или любой другой) странице будет равно 10 (кол-во постов на странице), а не бесконечности, как в первом варианте.
Выводить на первой странице от 10 до 19 постов и отрезать в архив по десятку. Ага, «пульсирующая морда». ;]
Господи, экономить один SELECT.
Глупо. Несколько раз писал в support, ответов ноль.
Было лучше, удобнее и FAVORITEстее, однозначно.
Ну сделайте, ну пАжаааааааааааааааааааааааааалуйста :)
Глупо. Несколько раз писал в support, ответов ноль.
Было лучше, удобнее и FAVORITEстее, однозначно.
Ну сделайте, ну пАжаааааааааааааааааааааааааалуйста :)
Мне нравилось как было раньше. А теперь мне ссыкотно и грустно.
Можно же в настройках пользователя сделать выбор, как отображать пейджинг внизу страницы: прямой или же обратный порядок вывода. А дальше каждый выбрал бы сам.
Чтобы были однозначные ссылки на страницы, то заменить адресацию вида habr.ru/page/12/ на habr.ru/page-desc/12/ и habr.ru/page-asc/12/ (или же как-то подобно, на усмотрение владельцев хабра)
Чтобы были однозначные ссылки на страницы, то заменить адресацию вида habr.ru/page/12/ на habr.ru/page-desc/12/ и habr.ru/page-asc/12/ (или же как-то подобно, на усмотрение владельцев хабра)
Делал один из своих проектов и тоже встала проблема постраничного вывода
Пришла в голову идея, но, наверное, подойдет не всем…
У меня на сайте есть новостная лента, которая активно и постоянно обновляется. Поэтому при прямом выводе страниц пользователь регулярно оказывается в недоумении — все страницы сдвинулись и он читает опять то же самое, что уже читал. При обратном выводе страниц получается некрасиво: номер первой страницы большой и вводит в замешательство, а первая страница регулярно получается незаполненной (можно исправить, но все же...).
Решение было принято такое:
1. на главной выводить последние 10 новостей (без указания страницы, конечно).
2. при нажатии на кнопку «дальше» или выборе следующей страницы вычисляется порядковый номер нужного элемента с конца, и уже начиная от него выводятся следующие 10 новостей.
На примере:
У нас 256 новостей. Сортировка по дате: новые идут первыми.
1) Первая страница: site.com/ (выводятся записи с порядковыми номерами 255-246)
2) Следующая страница: site.com/245 (выводятся записи с порядковыми номерами 245-236)
3) Еще следующая страница: site.com/235 (выводятся записи с порядковыми номерами 235-226)
и т.д.
Номер страницы при этом можно вычислять следующим образом: ***
PageIndex = TOTAL_PAGE_COUNT — floor(ITEM_SERIAL_NUM/ITEMS_PER_PAGE),
где
TOTAL_PAGE_COUNT — общее количество страниц = ceil(TOTAL_ITEMS_COUNT/ITEMS_PER_PAGE).
ITEM_SERIAL_NUM — порядковый номер элемента, начиная с конца
ITEMS_PER_PAGE — количество элементов на одной странице.
Важный момент:
При добавлении новых записей они становятся в начало нашего списка, но на навигацию пользователя при помощи стрелок «дальше» и «назад» это никак не влияет — они углубляется внутрь и возвращается как хочет — это те же страницы. Для поисковых систем тоже хорошо: страницы с определенным URL не изменяют своего содержимого (при условии неизменности элементов и их порядка/наличия).
*** Проблема здесь остается лишь с индексом страницы. Так как та страница, которая для пользователя была №1 после обновления (добавления новых записей) становится уже 2й, 3й или 10й…
На данном этапе решили просто отказаться от вывода номера страницы — ограничиться стрелками и ссылкой «перейти к началу».
P.S. Буду рад, если кому-то пригодится.
Пришла в голову идея, но, наверное, подойдет не всем…
У меня на сайте есть новостная лента, которая активно и постоянно обновляется. Поэтому при прямом выводе страниц пользователь регулярно оказывается в недоумении — все страницы сдвинулись и он читает опять то же самое, что уже читал. При обратном выводе страниц получается некрасиво: номер первой страницы большой и вводит в замешательство, а первая страница регулярно получается незаполненной (можно исправить, но все же...).
Решение было принято такое:
1. на главной выводить последние 10 новостей (без указания страницы, конечно).
2. при нажатии на кнопку «дальше» или выборе следующей страницы вычисляется порядковый номер нужного элемента с конца, и уже начиная от него выводятся следующие 10 новостей.
На примере:
У нас 256 новостей. Сортировка по дате: новые идут первыми.
1) Первая страница: site.com/ (выводятся записи с порядковыми номерами 255-246)
2) Следующая страница: site.com/245 (выводятся записи с порядковыми номерами 245-236)
3) Еще следующая страница: site.com/235 (выводятся записи с порядковыми номерами 235-226)
и т.д.
Номер страницы при этом можно вычислять следующим образом: ***
PageIndex = TOTAL_PAGE_COUNT — floor(ITEM_SERIAL_NUM/ITEMS_PER_PAGE),
где
TOTAL_PAGE_COUNT — общее количество страниц = ceil(TOTAL_ITEMS_COUNT/ITEMS_PER_PAGE).
ITEM_SERIAL_NUM — порядковый номер элемента, начиная с конца
ITEMS_PER_PAGE — количество элементов на одной странице.
Важный момент:
При добавлении новых записей они становятся в начало нашего списка, но на навигацию пользователя при помощи стрелок «дальше» и «назад» это никак не влияет — они углубляется внутрь и возвращается как хочет — это те же страницы. Для поисковых систем тоже хорошо: страницы с определенным URL не изменяют своего содержимого (при условии неизменности элементов и их порядка/наличия).
*** Проблема здесь остается лишь с индексом страницы. Так как та страница, которая для пользователя была №1 после обновления (добавления новых записей) становится уже 2й, 3й или 10й…
На данном этапе решили просто отказаться от вывода номера страницы — ограничиться стрелками и ссылкой «перейти к началу».
P.S. Буду рад, если кому-то пригодится.
Еще когда не был хабраюзером, читал эту тему и была идейка.
При посещении главной страницы — ставить юзеру куку с датой.
При переходе на какую-либо из страниц, вести отсчет от этой даты.
При переходе снова на главную — заменять куку.
:)
При посещении главной страницы — ставить юзеру куку с датой.
При переходе на какую-либо из страниц, вести отсчет от этой даты.
При переходе снова на главную — заменять куку.
:)
Имхо, страницы могут нумероваться как угодно, а вот ссылка должна ссылаться на ID первого поста на этой странице, а не на ее номер. И при загрузке вычислять номер страницы, на которой размещен этот пост. Если этого поста нет, то последний перед ним, который еще существует (в случаях, когда пост может быть удален). В таком и только в таком случае при загрузке страницы я гарантированно (может быть и не первым постом) увижу материал, на который я ссылаюсь (который я видел и хотел запомнить).
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Постраничная навигация