search

dukechronicle / chronjs

Source code for a former version of dukechronicle.com
dukechronicle.com
8 stars 1 forks source link

Pagination #302

Closed jimpo closed 12 years ago

jimpo commented 12 years ago

Simplied the scrollLoad script a lot to make it easier to use in the future. Also, changed the way taxonomy pagination works to make it easier.

deanchen commented 12 years ago

@jodoglevy

jodoglevy commented 12 years ago

i'll take a look, but my computer is epically messed up so it'l take me a little...

On Thu, Apr 19, 2012 at 2:33 PM, Dean Chen < reply@reply.github.com

wrote:

@jodoglevy

Reply to this email directly or view it on GitHub: https://github.com/thechronicle/chronjs/pull/302#issuecomment-5228735

Joe Levy Duke University, Computer Science 919.886.6563 jal50@duke.edu

deanchen commented 12 years ago

I'm really starting to hate the infinite scroll, leaning towards prefetched pagination would going to 2nd or 3nd page is done in javascript. The ux feels really unsatisfactory and the user can't link to specific pages. Also going back to older articles quickly is also impossible.

ParkerK commented 12 years ago

I agree with Dean on the pagination. I don't like sites with default infinite scroll, for the reasons mentioned; plus it makes the search page inconsistant as the footer is inaccessible and no matter how fast the user scrolls down they never catch it :(

jodoglevy commented 12 years ago

I think there are bigger things to work on than fixing this. Parker, why do people need to see the bottom links on the search and section pages? Is that really where they are going to look for this info? Not a main page or article page? Also, Twitter and Facebook both use it, amoung lots of others, so obviously there's a reason for it, including much faster loading of the articles, and it looking cool (which users like even ithought its not really a valid reason). Also, Dean, as far as your concerns, going back to older articles quickly is impossible no matter how we do it. Couch db pagination goes based on start key, not page number, so we can't generate links to much older pages without fetching all that content from the db. So we could only have a next and previous link, and they'd have to navigate page by page by clicking next to keep going far back. Also, how often do you think users are linking to specific pages for search results or section pages, rather than the articles those pages contain? Especially considering the content of these pages will change as new articles get added no matter what the link points to, so the page content is going to change anyway. I think we could change scrollLoad so it fades in all the new articles one at a time, to make things faster for the user, but I'm not sure rearchitecting pagination is really worth it.

On Thu, Apr 19, 2012 at 9:45 PM, Parker K < reply@reply.github.com

wrote:

I agree with Dean on the pagination. I don't like sites with default infinite scroll, for the reasons Dean mentioned; plus it makes the search page inconsistant as the footer is inaccessible and no matter how fast the user scrolls down they never catch it :(

Reply to this email directly or view it on GitHub: https://github.com/thechronicle/chronjs/pull/302#issuecomment-5236375

Joe Levy Duke University, Computer Science 919.886.6563 jal50@duke.edu