Comments 152
Переход по страницам можно делать и не перезагружая всю страницу. 2ой плюс пропадает
Не совсем вас понял. Имелось ввиду что грузиться будет только часть контента, а не вся страница. Имеется ввиду, конечно, если пользователь смотрит больше одной страницы.
При клике на страницу мы можем не перезагружать всю страницу, а подгружать только контент через ajax. К слову такая практика очень распространенная.
Главное — URI менять соответствующим образом. А то наступаем на тот же «3 минус».
Очень удобно открывать кучу ссылок во вкладках нажатием колеска мыши — а иные ajax варианты подгрузки контента эту привычку не поддерживают. Так что, если мы внизу страницы, скажем, видим ссылки «страницы: 1, 2, 3», и на циферки навешаны ссылки для открывания контента нужно страницы, то ссылки эти, будучи открыты в новом окне/новой вкладке, должны приводить к загрузке полной соответствующей страницы контента, с полным оформлением.
Очень удобно открывать кучу ссылок во вкладках нажатием колеска мыши — а иные ajax варианты подгрузки контента эту привычку не поддерживают. Так что, если мы внизу страницы, скажем, видим ссылки «страницы: 1, 2, 3», и на циферки навешаны ссылки для открывания контента нужно страницы, то ссылки эти, будучи открыты в новом окне/новой вкладке, должны приводить к загрузке полной соответствующей страницы контента, с полным оформлением.
Конечно должны. И в «правильном» пагинаторе все это реализовано. Или с использованием хеш-урлов или через replaceState. Во втором варианте так вообще нету разницы включен js или нет. Работа будет идентичной. А вообще ajax подгрузку контента при пагинации я не считаю столь важным преимуществом. Сейчас все браузеры работают так что пользователю сложно заметить ajax загрузка была или просто перезагрузилась страница. Ну а на счет нагрузки на сервер. В большинстве случаев этот момент не есть краеугольным. А при увеличении нагрузки обычно включают кеширование что опять же понижает прирост производительности при использовании этого метода.
Ну, насчет «зачем оно вообще нужно» я придерживаюсь консервативной позиции — ajax нужен очень не всегда и не во всем, и уж в листании страниц почти никогда не нужен.
Я-то так говорю, потому что мне нравится наблюдать, как отрисовывается страница(-ы) в браузере, но ведь есть, уверен, и те, кому нравится не видеть отрисовки, и здесь ajax как раз «в тему». :)
Я-то так говорю, потому что мне нравится наблюдать, как отрисовывается страница(-ы) в браузере, но ведь есть, уверен, и те, кому нравится не видеть отрисовки, и здесь ajax как раз «в тему». :)
И первый плюс пропадает. При постраничном выводе тоже подгружается только нужный контент.
идеальным был бы вариант где скролл выглядел бы как то так.
| 1 |
| 1 |
Случайно запостил предыдущее, тоесть мы видим таки некий скролл, но в нем у нас видно текущую псевдо страницу с возможностью быстрой навигации, например методом схватил-тащи, можно дополнить инпутом для ввода страницы. Листать хреновы свитки вконтакте незная края иконца — это треш полный, и когда свиток закончился трудно понять то ли он реально кончился то ли он не догрузился еще!
| 1 | текст текст текст текст текст текст текст текст
| | текст текст текст текст текст текст текст текст текст текст
|__| текст текст текст текст текст текст текст текст
|.2.| текст текст текст текст текст текст текст текст текст текст
| | текст текст текст текст текст текст текст текст текст текст
| | текст текст текст текст текст текст текст текст текст текст
| 3 | текст текст текст текст текст текст текст текст текст текст
| | текст текст текст текст текст текст текст текст текст текст
| | текст текст текст текст текст текст текст текст текст текст
| 4 | текст текст текст текст текст текст текст текст текст текст
| | текст текст текст текст текст текст текст текст текст текст
| | текст текст текст текст текст текст текст текст текст текст
| 5 | текст текст текст текст текст текст текст текст текст текст
| 1 | текст текст текст текст текст текст текст текст
| | текст текст текст текст текст текст текст текст текст текст
|__| текст текст текст текст текст текст текст текст
|.2.| текст текст текст текст текст текст текст текст текст текст
| | текст текст текст текст текст текст текст текст текст текст
| | текст текст текст текст текст текст текст текст текст текст
| 3 | текст текст текст текст текст текст текст текст текст текст
| | текст текст текст текст текст текст текст текст текст текст
| | текст текст текст текст текст текст текст текст текст текст
| 4 | текст текст текст текст текст текст текст текст текст текст
| | текст текст текст текст текст текст текст текст текст текст
| | текст текст текст текст текст текст текст текст текст текст
| 5 | текст текст текст текст текст текст текст текст текст текст
Не вижу смысла смешивать два метода. В том случае если 1.нам важна возможность перехода на конкретную страницу 2. если количество страниц не так велико что можно говорить про их порядок 3. если пользователь может захотеть просмотреть все записи 4. или остановится на определенном этапе что бы потом продолжить. Лучше использовать старую проверенную пагинацию. Если же пользователя обычно интересуют самые последние записи. И может возникать вопрос а что было немного раньше. Лучше использовать прокрутку. Потому использование прокрутки в новостях вконтакта я считаю хорошим применением. Гуглы изображения в поиске скорее всего сделали так же потому что количество картинок на страницу разнится (из за специфики их отображения). Да и это весьма удобно в той реализации.
Каждому решению своё место. Наприме, у блога Tumblr бесконечный скролл и он там вполне уместен. Так как предполагаемого конца практически нет (т.е. он очень и очень далеко). Тоже самое касается твиттера. С другой стороны пейджинг уместен для конечных страничных документов, и то довольно сомнительное удобство. Обычно нужны начало и конец. Какой смысл прыгать на середину?
Например, сегодня я прочитал от начала до какой-то части, и завтра хочу продолжить. Что делать? Состояние они не сохраняют, получается я должен скроллить и искать нужное место вручную?
Ну вы же можете написать js код, чтобы сохранял номер страницы.
Вы говорите о слишком абстрактных данных. Уточните что вы читаете. Новостную ленту друзей? Ну извините, ваша страница №3 уже через час может стать страницей №5, а через сутки №125. Каталог товаров с бесконечным скроллингом? Сортировка и фильтрация в помощь. Если речь идёт о большой-пребольшой статье, то хорошей практикой для такого подхода было бы содержание и расстановка якорей (anchor), которые можно сохранять в закладки. Если речь идёт о книге, читаемой через Web, то такой сервис должен предоставлять установку закладки в любом месте. Может есть еще что добавить?
Я вижу бесконечный скролл в большинстве ситуаций намного удобнее пейджинга. Может это касается только меня, но тыкать в ссылки «Следующая», «Дальше», «Туда», etc. напрягает гораздо больше, чем крутить колесо мыши ни о чём не думая. Это правильный юзер экспириенс — не заставлять пользователя делать лишних действий.
Я вижу бесконечный скролл в большинстве ситуаций намного удобнее пейджинга. Может это касается только меня, но тыкать в ссылки «Следующая», «Дальше», «Туда», etc. напрягает гораздо больше, чем крутить колесо мыши ни о чём не думая. Это правильный юзер экспириенс — не заставлять пользователя делать лишних действий.
нигде такого не видел — мне кажется это неудобно и собьет с толку. Мне кажется бесконечный скролл вполне уместен в небольших поисковых страницах — все равно мало кто глубоко переходит, интересны первые две-три страницы — мне как пользователю действительно проще только крутить колесиком, чем клацать по кнопкам, а с тачпадом на ноуте предпочитаю управление с клавиатуры.
На Хабре была когда-то такая нумерация.
Все форумы так работают)
Первая страница с сообщением — топикстартером. На последних по номерам — свежие сообщения.
Кроме того видел это на каких то новостных сайтах, специализированных.
В общем, в зависимости от специфики контента. Если предполагается, что пользователь будет возвращаться к контенту неоднократно, то лучше дать ему такую возможность. В крайнем случае сделать «избранное» с постраничной нумерацией.
Первая страница с сообщением — топикстартером. На последних по номерам — свежие сообщения.
Кроме того видел это на каких то новостных сайтах, специализированных.
В общем, в зависимости от специфики контента. Если предполагается, что пользователь будет возвращаться к контенту неоднократно, то лучше дать ему такую возможность. В крайнем случае сделать «избранное» с постраничной нумерацией.
зашел на два первых попавшихся «форума»: рутрекер и веломания — на обоих нумерация с единицы и в общем списке и внутри поста. На форумах возможна ссылка на пост и коммент.
Здесь, на Хабре, комменты вообще полностью загружаются — что лично меня очень даже устраивает — можно спокойно читать. Проблема — когда контента запредельно много — те же посты уже постранично разбиты.
Здесь, на Хабре, комменты вообще полностью загружаются — что лично меня очень даже устраивает — можно спокойно читать. Проблема — когда контента запредельно много — те же посты уже постранично разбиты.
На рутрекере внутри поста нумерация с единицы. Но при этом на первой первый комментария самый старый. Он будет всегда на первой странице, только если его не удалят.
В то время как у большинства блоговых движков на первой странице самый свежий пост, который через неделю съедет на вторую или десятую, в зависимости от скорости написания постов.
В то время как у большинства блоговых движков на первой странице самый свежий пост, который через неделю съедет на вторую или десятую, в зависимости от скорости написания постов.
BOR
bash.org.ru
shortiki.com
первое, что в голову пришло.
shortiki.com
первое, что в голову пришло.
При этом, количество записей на последней (наиболее актуальной) странице будет плавать. Не очень приятно, когда открываешь актуальные новости, а там только одна запись.
А вы сохраните на хабре вторую страницу как нить, и через пару дней почитайте =)
Я открыл каталог инет магаза, отсортировал список товаров по нужным мне параметрам и начинаю бродить по страницам. Чаще отсортировано по цене. По паре открытых страниц я приблизительно вижу динамику изменения цен на страницу и могу достаточно точно перейти на нужно мне страницу. Если бы мне предложили это в виде бесконечно скрола, ушел бы сразу.
При постраничной разбивке я всегда могу скопировать/скинуть линк на середину с тем, что бы список открылся на Х странице. В типичной реализации бесконечного скрола подобной возможности нет, хотя технически она реализуема.
При постраничной разбивке я всегда могу скопировать/скинуть линк на середину с тем, что бы список открылся на Х странице. В типичной реализации бесконечного скрола подобной возможности нет, хотя технически она реализуема.
Вопрос на засыпку: какой должен быть размер страницы?
Для психологическим лимитом является 100 постов на phpBB/vBulletin :)
А вообще, для итеративного контента (списки товаров, поисковая выдача, но не сплошнойтекст) обычно 10 или 20 позиций на страницу.
А вообще, никто не мешает делать виртуальное рвзбиение на страницы,
например отмотал20 фоток слева появился якорь «Стр. 2». Просто и плю ы обеих систем
А вообще, для итеративного контента (списки товаров, поисковая выдача, но не сплошнойтекст) обычно 10 или 20 позиций на страницу.
А вообще, никто не мешает делать виртуальное рвзбиение на страницы,
например отмотал20 фоток слева появился якорь «Стр. 2». Просто и плю ы обеих систем
*Для меня
Извините за ошибки, маршрутка не лучшее место для комментирования
Извините за ошибки, маршрутка не лучшее место для комментирования
Помочь человеку найти что-то конкретное — задача фильтров, а не переключателя страниц. Если я хочу найти товар с определенной ценой, то я ставлю ограничение и сортировку по цене и сразу получаю то, что мне нужно.
А если хочется смотреть все подряд, то «бесконечный» скролл удобнее.
Не вижу большого смысла в переключателе страниц.
А если хочется смотреть все подряд, то «бесконечный» скролл удобнее.
Не вижу большого смысла в переключателе страниц.
Бесконечный скролл меня очень радует когда вконтакте я хочу попасть на страницу для разработчиков которая находится в футере страницы. Бывает даже успеваю прокрутить страницу и перейти по ссылке.
Главное преимущество — экономия времени, потому что меньше кликов, особенно в узкие циферки пагинатора.
И есть еще один недостаток — невозможно доскроллить до футера, поэтому требуется какой-то другое интерфейсное решение, либо вообще футер убрать и перенести все го элементы в другое место.
И есть еще один недостаток — невозможно доскроллить до футера, поэтому требуется какой-то другое интерфейсное решение, либо вообще футер убрать и перенести все го элементы в другое место.
«Узкие циферки пагинатора» это уже проблема дизайнера или юзабилити-проектировщика. Можно сделать удобный пэджинатор и всем будет хорошо.
Но телодвижений всё-таки меньше. Давайте лучше подумаем что сделать, что бы такое поведение стало интуитивно понятным для всех. Например:
1. Нету понимания всего объема информации
Нету информации о объёме: текущая «страница», всего «страниц». По мне должно быть как-то так: скроллишь, а некий фиксированный блок обновляется автоматом. Проблема решается при правильном UI.
2. Бо́льшая нагрузка на интерфейс браузера
Страницы, которые не видны пользователю, можно удалять из DOM, и хранить в JS, что облегчит рендеринг. Для экономии памяти можно складывать страницы в localStorage, либо не сохранять вообще, а подгружать заново по мере надобности (с настроенным кешированием в браузере). При этом можно контролировать высоту самого ползунка и не давать ему сжиматься до минимальных размеров.
3. Т.к нету деления на условные элементы информации
Как вы правильно заметили — это косяки реализаций и к самой идее бесконечного скролла отношение не имеет. Другими словами — решаемо.
4. Не всегда корректно срабатывает скроллирование самой страницы
Если реализовать то, что я описал во втором пункте, этого можно будет избежать — отрезать сверху столько же, сколько вставилось снизу.
Всё это мысли в слух, чего-то мог не учесть. Сам не делал подобную фичу.
1. Нету понимания всего объема информации
Нету информации о объёме: текущая «страница», всего «страниц». По мне должно быть как-то так: скроллишь, а некий фиксированный блок обновляется автоматом. Проблема решается при правильном UI.
2. Бо́льшая нагрузка на интерфейс браузера
Страницы, которые не видны пользователю, можно удалять из DOM, и хранить в JS, что облегчит рендеринг. Для экономии памяти можно складывать страницы в localStorage, либо не сохранять вообще, а подгружать заново по мере надобности (с настроенным кешированием в браузере). При этом можно контролировать высоту самого ползунка и не давать ему сжиматься до минимальных размеров.
3. Т.к нету деления на условные элементы информации
Как вы правильно заметили — это косяки реализаций и к самой идее бесконечного скролла отношение не имеет. Другими словами — решаемо.
4. Не всегда корректно срабатывает скроллирование самой страницы
Если реализовать то, что я описал во втором пункте, этого можно будет избежать — отрезать сверху столько же, сколько вставилось снизу.
Всё это мысли в слух, чего-то мог не учесть. Сам не делал подобную фичу.
По пункту 2. Меня бесит бесконечный скролл на ноуте, когда нужная часть страницы не влезает на экран и нужно проскролится чуть чуть.
И пока я пытаюсь стянуть страницу вниз, что даже с жестами не всегда удобно, браузер радостно тормозит.
Хотя тут проблема не в том, что бесконечный скролл, а в оптимизации оного. Если бы все делали запасец пикселов в 300 и не спешили аякснуться и отрендериться при микросдвиге страницы, то я не против бесконечных скролов.
И пока я пытаюсь стянуть страницу вниз, что даже с жестами не всегда удобно, браузер радостно тормозит.
Хотя тут проблема не в том, что бесконечный скролл, а в оптимизации оного. Если бы все делали запасец пикселов в 300 и не спешили аякснуться и отрендериться при микросдвиге страницы, то я не против бесконечных скролов.
Можно исхитриться и пейджинг вставить (скажем сбоку, при нажатии на нужную страницу список сам отматывается/укорачивается/фильтруется и т.п.). Это уже зависит от реализации. Может выйти очень удобно.
Мне нравится бесконечный скролл. Лично у меня очень редко возникают ситуации, когда «надо отмотать назад», тут да, минус. Я готов с ним мириться. Остальное не существенно.
Мне нравится бесконечный скролл. Лично у меня очень редко возникают ситуации, когда «надо отмотать назад», тут да, минус. Я готов с ним мириться. Остальное не существенно.
Да, возможно идея неплохая, сделать «виртуальный пагинатор». Но что если я на нем выбираю условно «страницу 100», то он чтоли должен грузить сразу все предыдущие 99 чтобы показать мне результат?
Если грузить только 100-ю «страницу», то и подключать на место ниже «текущей», то такое поведение ломает правильный порядок записей.
Если грузить только 100-ю «страницу», то и подключать на место ниже «текущей», то такое поведение ломает правильный порядок записей.
Это уже выйдет обычный пагинатор только с ajax подгрузкой контента. Ну разве что без анимации прокрутки но это уже совсем с другой истории.
По-моему, во вконтакте есть такое. Зайдите в обсуждения в группах, где много комментов.
такую паджинацию видел на сайте smotra.ru, например:
smotra.ru/users/erik_davidych/#c_pg14
На странице 29 страниц комментариев, слева можно выбирать любую страницу и она яаксом подгружается, по-умолчанию открыта последняя.
Но там нет бесконечного скролла :)
smotra.ru/users/erik_davidych/#c_pg14
На странице 29 страниц комментариев, слева можно выбирать любую страницу и она яаксом подгружается, по-умолчанию открыта последняя.
Но там нет бесконечного скролла :)
Нету понимания всего объема информации (так сколько же мне еще нужно листать этот проклятый скролл, чтобы дойти до конца!?)
Сервер же знает сколько реально информации есть — можно сообщать «показано N элементов из M», как-то так.
Какая-то анти-статья
> Нету понимания всего объема информации
В том посте (лень искать) который был недавно на хабре предложили варианты, как это показать
> Бо́льшая нагрузка на интерфейс браузера
Лишние данные можно убирать, оставив только окно, например, в 100 записей.
> Т.к нету деления на условные элементы информации, т.е страницы
Это не минус, а просто пока не реализовано (опять же см. тот пост) в наших соц. сетях. Технически это можно сделать.
> Подгружается только нужный контент, следовательно меньше нагрузки на сервер
Спорно, часто как раз прокручивают всё до конца, лишь бы уйти вниз страницы, тогда как на циферки страниц кликают осознано. К тому же не вижу особой нагрузки, чтобы выдать закэшированные данные разметки…
> Быстрее грузится дополнительный контент, чем бы перезагружалась новая страница
Так скажем пользователь быстрее воспринимает эти данные, т. к. человеку не приходится переводить куда-нибудь взгляд, пока страничка обновляется, всё идёт единой лентой и подгружается в «область взгляда».
> Нету понимания всего объема информации
В том посте (лень искать) который был недавно на хабре предложили варианты, как это показать
> Бо́льшая нагрузка на интерфейс браузера
Лишние данные можно убирать, оставив только окно, например, в 100 записей.
> Т.к нету деления на условные элементы информации, т.е страницы
Это не минус, а просто пока не реализовано (опять же см. тот пост) в наших соц. сетях. Технически это можно сделать.
> Подгружается только нужный контент, следовательно меньше нагрузки на сервер
Спорно, часто как раз прокручивают всё до конца, лишь бы уйти вниз страницы, тогда как на циферки страниц кликают осознано. К тому же не вижу особой нагрузки, чтобы выдать закэшированные данные разметки…
> Быстрее грузится дополнительный контент, чем бы перезагружалась новая страница
Так скажем пользователь быстрее воспринимает эти данные, т. к. человеку не приходится переводить куда-нибудь взгляд, пока страничка обновляется, всё идёт единой лентой и подгружается в «область взгляда».
Могу сказать, что у Яндекса он был в своё время и они от него отказались, про Google не могу сказать точно, но вроде тоже был где-то кроме Google Images, как раз в последнем скролл вполне уместен, как и писал hVostt про Tumblr — по тем же причинам.
Могу сказать одно — по мне его можно использовать, когда у вас не более 2-3-х страниц подгружается, иначе, действительно, превращается во что-то непонятное. И, конечно, тема холиварная.
Как решение — можно где-нибудь в углу показывать подсказку — на какой странице пользователь сейчас и сколько всего. Как-то так.
Могу сказать одно — по мне его можно использовать, когда у вас не более 2-3-х страниц подгружается, иначе, действительно, превращается во что-то непонятное. И, конечно, тема холиварная.
Как решение — можно где-нибудь в углу показывать подсказку — на какой странице пользователь сейчас и сколько всего. Как-то так.
Варианты смеси бесконечного скрола с пагинацией вполне реализуемы, и есть на некоторых сайтах.
А причина почему поисковики и многие крупные сайты этого не делают имхо банальна — с бесконечной прокруткой будет показываться намного меньше рекламы посетителям, и даже если вставлять рекламые блоки в подгружаемый контент, то кликабельность по ним, подозреваю, будет в разы меньше.
А причина почему поисковики и многие крупные сайты этого не делают имхо банальна — с бесконечной прокруткой будет показываться намного меньше рекламы посетителям, и даже если вставлять рекламые блоки в подгружаемый контент, то кликабельность по ним, подозреваю, будет в разы меньше.
Вконтакте где то реализован гибридный вариант навигации, с использованием всплывющего пейджера.
+ технически довольно трудно реализовать сохранение позиции, номер подгруженной страницы, так как последняя страница получается всегда в начале, массив информации постоянно пополняется новыми постами, старые данные тоже удаляются или архивируются (знаю по твиттеру). Поэтому начала и конца всего объема информации мы не знаем. Можно только ореентироваться на идентификатор последней (сверху/снизу) подгруженной записи в ленте.
+ технически довольно трудно реализовать сохранение позиции, номер подгруженной страницы, так как последняя страница получается всегда в начале, массив информации постоянно пополняется новыми постами, старые данные тоже удаляются или архивируются (знаю по твиттеру). Поэтому начала и конца всего объема информации мы не знаем. Можно только ореентироваться на идентификатор последней (сверху/снизу) подгруженной записи в ленте.
Бо́льшая нагрузка на интерфейс браузера, из-за чего начинают возникать тормоза когда скролл становится огромных размеров
При появлении достаточно большого числа элементов в списке при движении по нему вниз — можно начинать постепенно убирать «лишние» элементы сверху, показав кнопку «Ранее» или «Предыдущие» или т.п.
А при движении обратно, вверх — нажимая эту появившуюся кнопку — убирать лишние элементы снизу.
То есть в любом случае количество видимых элементов можно сделать не более какого-то определённого разумного числа.
Может так? :)
Пагинатор + бесконечный скролл?
При прокрутке, контент так и подгружается автоматически, но страницы группируются:
Пагинатор + бесконечный скролл?
При прокрутке, контент так и подгружается автоматически, но страницы группируются:
Пагинатор, получается, должен быть только сверху страницы?
Он может быть фиксировано прилеплен внизу окна (не страницы). В общем решений — масса. Всё слишком сильно зависит от предметной области, от контента и его динамики, чтобы вот так запросто объявлять современный интерфейс злом :)
Ну я и не объявляю его абсолютным злом.) Просто в большинстве случаев не вижу его приемуществ (и даже более, вижу дополнительные неудобства) перед «старым дедовским способом» на разбивки на страницы.
Тоже самое говорила моя покойная бабушка, когда её пытались научить пользоваться пультом :) Не обязательно скроллинг должен быть бесконечным, можно добавить большую кнопку «Ещё» и подгружать контент по нажатию, а в ссылку добавлять якорь текущей позиции. Но делить на страницы и пейджинг это прошлый век :)
Тормоза это может и уберет, но при этом:
1) Скролл будет дополнительно прыгать и раздражать
2) Надо будет сохранять удаленные записи чтобы в случае прокрутки вверх не грузить их заново и обновлять из кэша
1) Скролл будет дополнительно прыгать и раздражать
2) Надо будет сохранять удаленные записи чтобы в случае прокрутки вверх не грузить их заново и обновлять из кэша
Скролл можно реализовать самостоятельно, как в GMail. А стандартный спрятать.
По-моему, в GMail скролл не реализован самостоятельно, а просто стилизован «обычный» скролл при помощи CSS и всяких селекторов вендорных -webkit- псевдоэлементов. Во всяком случае в Хроме точно так, в то время как в FF в Убунте показывается стандартный скролл. Имхо, реализовывать скролл на JS — это очень и очень плохо, ни разу еще не видел, чтобы такая штука работала на 100% правильно и приятно для пользователя.
Да, вы правы, в GMail'е скроллбары стилизированны при помощи -webkit-scrollbar*.
В таком случае, также соглашусь по поводу того, что реализовывать кастмный скроллбар — плохо. Просто раньше я думал, что есть хороший пример такой реализации в GMail'е.
В таком случае, также соглашусь по поводу того, что реализовывать кастмный скроллбар — плохо. Просто раньше я думал, что есть хороший пример такой реализации в GMail'е.
JS по определению однопоточный, поэтому «параллельно» ни как не получится. Но вообще «добавить новых Х записей, убрать Х старых записей» вполне реализуемая через DOM штука.
Я просто оставлю это здесь
В минус забыли добавить, что сложно добраться до футера. Например facebook и vk содержат в нем ссылки: Разработчикам, вакансии и т.д.
Интересует ваше мнение:
Стоит ли вводить в новостном сайте (новости, обзоры, инструкции) бесконечный скроллинг, включающий в себя кнопку «Подгрузить еще» и рядом стоящий чекбокс «Подгружать автоматически / вручную»?
Стоит ли вводить в новостном сайте (новости, обзоры, инструкции) бесконечный скроллинг, включающий в себя кнопку «Подгрузить еще» и рядом стоящий чекбокс «Подгружать автоматически / вручную»?
Стоит/не стоит решать вам.
Единственное что важно:
1) Как сказал кто-то выше, не заставляем пользователя думать
2) Реализуем бесконечный скролл без потери всех преимуществ обычной постраничной разбивки
Единственное что важно:
1) Как сказал кто-то выше, не заставляем пользователя думать
2) Реализуем бесконечный скролл без потери всех преимуществ обычной постраничной разбивки
Решать мне, причем решать нужно в ближайшие дни, поэтому и спрашиваю совета.
Просто бесконечный скрол не подходит из-за потери футера.
Просто бесконечный скрол не подходит из-за потери футера.
Подгрузить еще, это уже не бесконечный скроллинг, это кнопка «давай следующую страницу», т.е. обрезанный пейджинатор. «Подгружать автоматически / вручную» не может быть чекбоксом, только радиобаттонами, если вы решили так делать. А как вы будете менять значение, если пользователь выберет автоматическое подгружение? Оно же навсегда у него автоматическим и останется.
Боитесь за футер — ставьте кнопку «Показать еще N новостей»
Если в футере ничего важного нет (контакты, правообдладатель, автор страницы не в счет — это важно только создателям) — бесконечный скрол вполне годное решение.
Ну и автор не учел самого главного на мой взгляд: все зависит от контента и от контекста.
Новости, как и каталоги / обзоры могут быть очень разными. Где-то выигрывает бесконечный скролл где-то удобный пейджинатор
Боитесь за футер — ставьте кнопку «Показать еще N новостей»
Если в футере ничего важного нет (контакты, правообдладатель, автор страницы не в счет — это важно только создателям) — бесконечный скрол вполне годное решение.
Ну и автор не учел самого главного на мой взгляд: все зависит от контента и от контекста.
Новости, как и каталоги / обзоры могут быть очень разными. Где-то выигрывает бесконечный скролл где-то удобный пейджинатор
Для этого сайта, по Вашему мнению, подойдет бесконечный?
Смущает, что у популярных разубежных ресурсов такой же тематики реалзации бесконечного скроллинга не встречал.
Смущает, что у популярных разубежных ресурсов такой же тематики реалзации бесконечного скроллинга не встречал.
Давайте возьмем новости этого сайта, какие бывают сценарии на мой взгляд:
1. я захожу раз в день или раз в неделю на сайт и мне интересно глянуть новости за время моего отсутствия. В таком случае удобен бесконечный скролл, будет прекрасно если сделать календарь чтобы я мог выбрать дату и отскролиться к нужному дню.
2. я захожу раз в месяц или раз в год. в таком случае я никогда не буду читать, даже просматривать заголовки всех новостей, их там слишком много! В лучшем случае я пробегусь по ним, пока не надоест. Если делать пейджинатор — вероятность того что надоест быстрее увеличивается.
1. я захожу раз в день или раз в неделю на сайт и мне интересно глянуть новости за время моего отсутствия. В таком случае удобен бесконечный скролл, будет прекрасно если сделать календарь чтобы я мог выбрать дату и отскролиться к нужному дню.
2. я захожу раз в месяц или раз в год. в таком случае я никогда не буду читать, даже просматривать заголовки всех новостей, их там слишком много! В лучшем случае я пробегусь по ним, пока не надоест. Если делать пейджинатор — вероятность того что надоест быстрее увеличивается.
Большинство заходит как минимум раз в день, чуть меньше — раз в несколько дней. За несколько дней новостей может быть не больше двух страниц. Есть ли смысл в этом случае?
Смысл в чем? Смысла делать пейджинацию нет, НО если у вас она уже сделана и описаный вами сценарий самый распространенный — то и переделывать ради просто переделки тоже сомнительное удовольствие.
Вы можете прикрутить сборщик статистики нажатий на пейджинатор? сколько людей жмет на цифру 2, на цифру 3 и так далее? Если это число внушительное — ради этих людей стоит переделывать, если нет — то зачем это вам?
Вы можете прикрутить сборщик статистики нажатий на пейджинатор? сколько людей жмет на цифру 2, на цифру 3 и так далее? Если это число внушительное — ради этих людей стоит переделывать, если нет — то зачем это вам?
Сейчас создается новый дизайн, верстка. Поэтому задумались о бесконечном скроллинге.
Те кто жали на 2 и 3 ведь могут жать на «Подгрузить еще». Контент в этом случае подгружается без перезагрузки страницы, не перепрыгивает вверх к шапке.
Те кто жали на 2 и 3 ведь могут жать на «Подгрузить еще». Контент в этом случае подгружается без перезагрузки страницы, не перепрыгивает вверх к шапке.
Да, совершенно верно, могут. И плюсы будут, как вы и описали — не будет скачков.
Останется под вопросом только сценарий, например, «посмотреть новости за март», вдруг кто-то видел там, в новостях, интересную статью / ссылку и хочет ее найти. Способ быстро переключиться на март не помешал бы. Это те самые «якоря» о которых тут писали.
должна быть кнопка «подгрузить еще»
ненавижу бесконечный скролл
ненавижу бесконечный скролл
Почему бы рядом с кнопкой «Ещё» не добавить галочку «Подгружать автоматически»? Положим плашмя всех зайцев разом! :)
Чуть выше это предлагал. Кажется — опимальный вариант. Не хватает только меток для навигации.
На счёт меток. У Twiter Bootstrap есть плавающий хедер, стыкующийся к верхнему краю окна. При прокрутки вниз он может висеть, пока его не вытолкнет следующий хедер. Это и будет концептом «страницы», на хедере можно повесить несколько полезных кнопок: добавить в закладки, расшарить и т.п. Нужную страницу всегда можно будет сохранить и в случае чего открыть.
Можете предоставить пример какого-то работающего сайта с такой системой?
twitter.github.com/bootstrap/scaffolding.html
покрутите немного вниз, второе меню прилепится к верхнему меню, а во время скроллинга меню будет переключаться. во-первых это уже готовое решение, можете пользоваться. во-вторых крайне удобно, я считаю.
покрутите немного вниз, второе меню прилепится к верхнему меню, а во время скроллинга меню будет переключаться. во-первых это уже готовое решение, можете пользоваться. во-вторых крайне удобно, я считаю.
Надеюсь автор понимает, что это только его взгляд на плюсы и минусы, который может сильно отличаться от объективных плюсов и минусов в каждом конкретном случае? -)
У «привычной и понятной» организации переходов по страницам есть только один бесспорный плюс. Он так давно и долго используются, что стал привычным и понятным большинству активных пользователей сети. При этом никакой логичности в этом подходе нет.
Ну подумайте сами, что может быть логичного в необходимости перемещении по одному и тому же массиву данных сразу в 2 направлениях? Сверху вниз, плюс между страницами? -)
Если говорить серьезно, то бесконечный скролл хорошее решение для новостных лент с частым обновлением и показа больших списков из которых вам надо выбрать только пару пунктов. А бесконечный скролл + визуальные якори + возможность быстрого перехода к ним это хорошее решение для всех остальных случаев.
Потому что циферки с номерами страниц нужны очень мало кому. Зато все хотят знать где они сейчас находятся и как сюда вернуться, вот и используют для этой цели костыль в виде пейджинаторов. Нормальных-то инструментов разработчики не давали.
У «привычной и понятной» организации переходов по страницам есть только один бесспорный плюс. Он так давно и долго используются, что стал привычным и понятным большинству активных пользователей сети. При этом никакой логичности в этом подходе нет.
Ну подумайте сами, что может быть логичного в необходимости перемещении по одному и тому же массиву данных сразу в 2 направлениях? Сверху вниз, плюс между страницами? -)
Если говорить серьезно, то бесконечный скролл хорошее решение для новостных лент с частым обновлением и показа больших списков из которых вам надо выбрать только пару пунктов. А бесконечный скролл + визуальные якори + возможность быстрого перехода к ним это хорошее решение для всех остальных случаев.
Потому что циферки с номерами страниц нужны очень мало кому. Зато все хотят знать где они сейчас находятся и как сюда вернуться, вот и используют для этой цели костыль в виде пейджинаторов. Нормальных-то инструментов разработчики не давали.
БЕСИТ БЕСИТ БЕСИТ!!! Ну потому что раньше было, я закончил читать где-то на 5ой странице, а сейчас надо сделать пейдждаун до самого конца и искать контрол-Ф! БЕСИТ БЕСИТ!
Что хабрасообщество думает по поводу идеи сделать следующую кнопку? Пропорционально продолжительности нажатия по ней подгружать разное количество данных. Прототипа нету, ибо не силён в JS. Есть секретные чертежи:
[ Показать ещё… ] → Жмём и держим. Цифры побежали… → [ Показать ещё 12… ] → …ещё немножко ждём… → [ Показать ещё 27… ] → …ждём… → [ Показать ещё 45… ] → …ждём… → [ Показать ещё 82… ] → Отпускаем кнопку мыши → Подгружается 82 записи. Скорость регулируем по вкусу, можно ускорять счётчик… 1-10-100-1000. По дабл-клику можно подгружать все записи.
Если кто скодит, буду рад понажимать на такую штуку. Ваши замечания?
[ Показать ещё… ] → Жмём и держим. Цифры побежали… → [ Показать ещё 12… ] → …ещё немножко ждём… → [ Показать ещё 27… ] → …ждём… → [ Показать ещё 45… ] → …ждём… → [ Показать ещё 82… ] → Отпускаем кнопку мыши → Подгружается 82 записи. Скорость регулируем по вкусу, можно ускорять счётчик… 1-10-100-1000. По дабл-клику можно подгружать все записи.
Если кто скодит, буду рад понажимать на такую штуку. Ваши замечания?
Круто! Но как интуитивно понятно показать способ использования данной кнопки? Нажмите и удерживайте? Вообще, надо подумать.
Ну как только происходит onMouseDown сразу появляется число — далее методом тыка любопытствующие догадаются. Еще есть вариант: нажал — отвёл курсор. Удаление так же пропорционально кол-ву подгружаемых материалов. В целом, досточно начать тенденцию, её подхватят, народ сам обучится.
Или же! При наведении курсора начинает крутиться счётчик с ускорением по логарифмическому алгоритму? Надо потестить :)
Тоже вариант.
Забыл добавить, что имеет смысл задать минимальный порог, т.е. начинать считать с заданного минимума, например, с 10 записей. Чтобы быстрый клик подгружал хоть что-то.
Забыл добавить, что имеет смысл задать минимальный порог, т.е. начинать считать с заданного минимума, например, с 10 записей. Чтобы быстрый клик подгружал хоть что-то.
Т.е. на счетчике сразу отображается, допустим, 10 записей, а снизу идёт полоска как при подгрузке, секунды 2-3 (или больше, надо поэкспериментировать). Когда полоска дойдет до конца начнется увеличение счетчика. Тогда и быстрый клик будет работать и произвольное количество записей без селекта 25,50,100 (бесявый, если честно).
Клик совершается где-то за 0.2 с. Пауза на 2 сек — много. Надо бы просто подобрать значения скорости/ускорения так, чтобы в первые 0.5 с счётчик не улетал далеко, тогда получится, что за среднестатистический по продолжительности клик подгрузится тот самый минимум плюс иногда еще будет проскакивать дополнительно ~ 1-2-3-4 записи.
Как вариант, сделать эту кнопку в виде ползунка, и не в зависимости от времени нажатия инкрементировать количество записей, а как обычный слайдер использовать, или стрелочки увеличить-уменьшить количество записей чуть правее отображения числа записей.
А это не лишнее? Выбор авто/вручную с кнопкой, мне кажется, более удобен.
Все тоже самое, + возможность загрузить сразу и много. Это к тому, что бывает полезно сделать Ctrl-F на большом куске контента. Что-то из разряда «Где-то здесь это было, надо бы найти...». Или большой кусок загруженного контента сохранить и читать, допустим, в PDF.
Вам виднее, что вам больше нравится. Меня сильно раздражает скакание ползунка у скролла при автоподгрузке данных.
Лучше не так, а по нажатию на кнопку появляется горизонтальная линейка справа; двигая мышь вправо, выбираем нужное число подгружаемого контента (в экранах или условных страницах или в числе сообщений).
Ещё один минус в копилку бесконечной перемотки: вы когда-нибудь пробовали перематывать в бесконечность с помощью полосы прокрутки? У мышки колёсико заело, глючит, поэтому приходится тянуться за старую-добрую серую полосочку сбоку. И тут начинается веселье: только ты подводишь мышь к нижней границе, как внезапно всплывает новый кусок страницы и тебя переносит чёрт знает куда. Если не повезёт, то через пару секунд ты можешь оказаться на три-четыре страницы впереди, и перемотать назад с помощью полосы прокрутки ты не сможешь, придётся тыкать стрелочки на клавиатуре.
Ленивые разрабы хоть как-то научились делать сносную паджинацию. Научились — пусть делают. Если их тянет на новенькое и при этом ле-е-ень делать это новенькое грамотно, то их надо бить по рукам и давать подзатыльник, чтобы не портили жизнь людям из-за своей «любви» к неопробованным новинкам.
Оставьте бесконечную прокрутку тем, кто может сделать её грамотно: с хэшами страницы в урле, с альтернативной паджинацией, с полноценным поиском.
В целом: бесконечная прокрутка имеет право на жизнь только при грамотной реализации. В том виде, в котором она есть сейчас на 99% сайтов — нет пути!
Ленивые разрабы хоть как-то научились делать сносную паджинацию. Научились — пусть делают. Если их тянет на новенькое и при этом ле-е-ень делать это новенькое грамотно, то их надо бить по рукам и давать подзатыльник, чтобы не портили жизнь людям из-за своей «любви» к неопробованным новинкам.
Оставьте бесконечную прокрутку тем, кто может сделать её грамотно: с хэшами страницы в урле, с альтернативной паджинацией, с полноценным поиском.
В целом: бесконечная прокрутка имеет право на жизнь только при грамотной реализации. В том виде, в котором она есть сейчас на 99% сайтов — нет пути!
Согласен со всеми доводами. Кстати «бесконечный» скролл стены в фейсбуке доводит до белого каления, когда я хочу дотянуться до ссылки Developers в подвале страницы… Вот где пример как не нужно делать в мировом масштабе.
Можно открыть страничку ФБ, где нет скролла :)
Можно. Можно и адрес в браузере нужный набрать. Я говорю о первом опыте. Когда столкнулся впервые — в душе был только чистый русский мат. Нелепо сделано. Я так считаю — еслы вы уж вынесли в подвал что-то стоящее (тем более подвал не высокий) — можно было бы при скроллинге его фиксировать внизу экрана. А так — крайне неудобно…
Согласен, что бесконечный ск(т)роллинг без разрешения — не хорошо. Либо должна висеть на видном месте кнопка отключения, или включать с разрешения.
И всё-таки на счёт ФБ, рядовому пользователю незачем подвал. А нерядовой найдёт способ туда попасть. Так уж, если по существу, ФБ не самый удачный пример для придирательства :)
И всё-таки на счёт ФБ, рядовому пользователю незачем подвал. А нерядовой найдёт способ туда попасть. Так уж, если по существу, ФБ не самый удачный пример для придирательства :)
Похоже, ваш комментарий исчерпывающе описывает мое отношение к бесконечному скроллу :)
последнее время все чаще пользуюсь Page Up, Page Down, Home, End
Сколько негатива люди высказали по поводу бесконечного скролла =) Но ведь в самом деле, проблема скорее в реализации, а не в идее. У бесконечного скролла есть свои подводные камни, у обычной пагинации — свои, другое дело, что второй подход «живет» дольше, и поэтому шишек набить на нем уже успели все =) Но вот пример: пользователь прокрутил страницу до конца, жмакнул на заветную ссылку на вторую страницу и… Вот что тут должно произойти? Если это обычная ссылка, то мы конечно же увидим новую страницу и окажемся в самом ее начале. При этом пользователю приходится переключать свое внимание, чтобы вновь найти то место, откуда ему, собственно, и нужно продолжать читать. Если же подгрузка асинхронная, то что должен делать программист? Прокручивать страницу в начало (ну просто до верхнего края области интереса), либо оставлять как есть? Второй вариант, конечно, вообще бредовый, но я не раз такое встречал. Первый имеет все тот же недостаток — пользователю приходится заново пробегаться глазами по странице, чтобы найти, откуда читать.
В это же время бесконечный скролл лишен этого недостатка, но имеет свои.
В это же время бесконечный скролл лишен этого недостатка, но имеет свои.
Да, можно написать ещё статью о достоинствах и недостатках обычного пагинатора — получится того и другого больше, чем перечислено для бесконечного скролла.
+ надо меньше скроллить и меньше времени ожидать окончательной загрузки
+ к списку страниц легко перейти и выбрать нужную
— а кто его знает, что на 38-й странице?
— переход между страницами — разрыв контекста
— если страниц много, проблематично выбрать нужную страницу (если нет специальных механизмов)
— страница иногда больше высоты окна, а иногда меньше; надо или скроллить, или видеть пустое место
— при переходе назад попадают на верх предыдущей страницы (если нет специального скрипта) — разрыв контекста
— висящий короткий кусок текста на последней странице малоинформативен и, как говорилось, тоже оторван от контекста
+ легко сделать и сказать, что проблема длинных страниц решена
— не ищется по Ctrl-F по всем страницам и никто этим не занимается, интеграцией клиентского и серверного поиска
— чаще всего не думают о скриптовом кешировании подгруженного ранее, чтобы не слать ненужный повторный запрос
— …
+ надо меньше скроллить и меньше времени ожидать окончательной загрузки
+ к списку страниц легко перейти и выбрать нужную
— а кто его знает, что на 38-й странице?
— переход между страницами — разрыв контекста
— если страниц много, проблематично выбрать нужную страницу (если нет специальных механизмов)
— страница иногда больше высоты окна, а иногда меньше; надо или скроллить, или видеть пустое место
— при переходе назад попадают на верх предыдущей страницы (если нет специального скрипта) — разрыв контекста
— висящий короткий кусок текста на последней странице малоинформативен и, как говорилось, тоже оторван от контекста
+ легко сделать и сказать, что проблема длинных страниц решена
— не ищется по Ctrl-F по всем страницам и никто этим не занимается, интеграцией клиентского и серверного поиска
— чаще всего не думают о скриптовом кешировании подгруженного ранее, чтобы не слать ненужный повторный запрос
— …
Если у мыши есть кинетическая прокрутка, то бесконечный скролл гораздо удобнее
В обсуждениях на вКонтакте проблема была решена довольно оригинально.
как раз это — не плюс — и неправильно работает, выше spmbt верно отметил, что «не ищется по Ctrl-F по всем страницам и никто этим не занимается, интеграцией клиентского и серверного поиска»
Может попробовать совместить оба варианта? Мне кажется это возможно.
Друзья, сразу скажу, комменты не читал, но мой воспаленный алкоголем мозг на половине прочтения статьи решил, что было бы гораздо удобней при прокрутке к концу страницы перелистывать на следующую страницу, а не подгружать дополнительный контент. Здесь, конечно, есть свои трудности, но их можно решить.
Тоже заранее предупрежу, что читал только статью и последний комментарий, но лично на мой взгляд невозможность текстового поиска по странице и возможность запомнить, на какой части страницы ты остановился, перечеркивают все плюсы
В копилку минусов — распечатка страницы. Как распечатать кусок от 682 по 695 сообщение? Только скопировав в текстовый редактор. Не дай бог, вы автоматом щелкнули на «распечатать»…
Прочитал половину комментов и чтобы не отвечать каждому, не распыляться и не повторяться отпишусь отдельно.
Вы когда писали свою статью, то имели ввиду конкретные реализации бесконечного скроллинга, которые вы видели. Но это не значит, что нет нормальных. Например, в одной моей реализации, нету ни одного упомянутого вами минуса. Конечно моя реализация не применима для случая бесконечных данных, но тогда и ваши минусы смысла не имеют. Для большего, но конечного количества данных работает это следующим образом:
Работа ведется таки постранично, которые «склеены» в длинную ленту. У сервиса запрашивается количество страниц и в эту ленту вставляются пустые страницы примерного(или точного в случае табличных данных) размера.
Таким образом лента имеет размер соответствующий количеству данных и всегда можно отмотать до конца или нужного места.
Каждая пустая страница имеет номер, который в нее прописан. При скроллинге можно быстро найти нужную страницу или запомнить где ты был.
Данные загружаются на лету, замещают пустые страницы и сохраняются в кэше. Поэтому можно легко прыгать между загруженными страницами без дополнительных обращений к серверу.
Кэш имеет ограниченный размер. По достижению лимита новые данные вытесняют старые страницы( старые по времени обращения, а не загрузки), старые страницы в ленте замещаются пустыми.
Итак:
1. есть понимание объема информации по размеру скроллбара
2. нагрузка регулируется размером кэша (даже динамически в зависимости от отзывчивости интерфейса)
3. есть деление на условные страницы
4. корректно отрабатывается скролл без прыжков
5. все происходит в контейнере, поэтому любые футеры/хедеры находятся вне скролируемой области
Вы когда писали свою статью, то имели ввиду конкретные реализации бесконечного скроллинга, которые вы видели. Но это не значит, что нет нормальных. Например, в одной моей реализации, нету ни одного упомянутого вами минуса. Конечно моя реализация не применима для случая бесконечных данных, но тогда и ваши минусы смысла не имеют. Для большего, но конечного количества данных работает это следующим образом:
Работа ведется таки постранично, которые «склеены» в длинную ленту. У сервиса запрашивается количество страниц и в эту ленту вставляются пустые страницы примерного(или точного в случае табличных данных) размера.
Таким образом лента имеет размер соответствующий количеству данных и всегда можно отмотать до конца или нужного места.
Каждая пустая страница имеет номер, который в нее прописан. При скроллинге можно быстро найти нужную страницу или запомнить где ты был.
Данные загружаются на лету, замещают пустые страницы и сохраняются в кэше. Поэтому можно легко прыгать между загруженными страницами без дополнительных обращений к серверу.
Кэш имеет ограниченный размер. По достижению лимита новые данные вытесняют старые страницы( старые по времени обращения, а не загрузки), старые страницы в ленте замещаются пустыми.
Итак:
1. есть понимание объема информации по размеру скроллбара
2. нагрузка регулируется размером кэша (даже динамически в зависимости от отзывчивости интерфейса)
3. есть деление на условные страницы
4. корректно отрабатывается скролл без прыжков
5. все происходит в контейнере, поэтому любые футеры/хедеры находятся вне скролируемой области
Минусы 1-3 и 5 устранены в ходе обсуждения этой темы: habrahabr.ru/post/143574/
4 — пока неустранимо
4 — пока неустранимо
Мне кажется, лучше совместить все три способа: постраничную навигацию, кнопку «еще!» и бесконечный скролл. Все это когда-то раньше было во вконтактах и прочем, но в разное время.
То есть, например, в настройках задается один из двух последних способов, т.е. или кнопка внизу, или бесконечный скролл. А постраничная навигация есть всегда (как сейчас в обсуждениях вконтакте).
Галочку около кнопки «еще» нет смысла делать, т.к. при включении автоподгрузки до нее уже не дойти будет.
Мне тоже не всегда нравится бесконечный скролл. Ну если на страниц пять назад — удобно, но когда смотреть историю с самого начала — моя древняя машина уже не выдерживает и начинаются лютые тормоза.
То есть, например, в настройках задается один из двух последних способов, т.е. или кнопка внизу, или бесконечный скролл. А постраничная навигация есть всегда (как сейчас в обсуждениях вконтакте).
Галочку около кнопки «еще» нет смысла делать, т.к. при включении автоподгрузки до нее уже не дойти будет.
Мне тоже не всегда нравится бесконечный скролл. Ну если на страниц пять назад — удобно, но когда смотреть историю с самого начала — моя древняя машина уже не выдерживает и начинаются лютые тормоза.
Солидарен, бесконечный скролл ломает привычный юзкейс веба и сильно напрягает.
Пока спасает NoScript — если на сайте не разрешать скрипты, будет постраничное листание.
Пока спасает NoScript — если на сайте не разрешать скрипты, будет постраничное листание.
Жалобы на то, что у туалетной бумаги нет маркеров «осталось до конца рулона». Есть же у fb так называемый activity feed, где ± идея свести infinity scroll и старую добрую пагинацию во едино нашли точки соприкосновения: вниз — скролит, справа — годы/месяцы пагинацией. Их скролл «мудронеудобный» имеет и техническое, и смысловое обоснования. Естественно, не всегда можно засовывать эту технику куда попало.
Sign up to leave a comment.
Бесконечный скролл, как сомнительное улучшение интерфейса