628339 - Paginate "all" dashboard lists

Status: RESOLVED WONTFIX

(support.mozilla.org :: Knowledge Base Software, task, P2)

Description

[James Socol [:jsocol, :james]]

Pages like /en-US/contributors/most-visited list all pages in a locale. Unbounded lists also mean unbounded load times, so we should paginate to 50 or 100 per page.

Comment 1

[Erik Rose [:erik][:erikrose]]

It's okay to return extra fields in Manager.raw(), so that's one possibility. Another is to return our own kind of object that's sliceable and uses OFFSET/LIMIT.

Comment 2

[[:Cww]]

FWIW, I like 50 over 100 but we can totally bikeshed this if you want.  Maybe start at 53 for the first page, 47 for the second, 43 for the third and so on.

Comment 3

[Erik Rose [:erik][:erikrose]]

Yes, let's stick to primes.

Comment 4

[James Socol [:jsocol, :james]]

In increasing number of primes. The first page would have 2, page 2 would have 3, page 3 would have 5, etc.

Comment 5

[Erik Rose [:erik][:erikrose]]

Someday I'd like to turn that paginate widget into leet JS-driven scroll-when-you-hit-the-bottom-ness.

Comment 6

[James Socol [:jsocol, :james]]

I don't think infinite scroll is appropriate for many of our use cases. Maybe on a page of answers but I don't think it's worthwhile for the very few cases when we have more than one page of answers.

Search is an interesting one but I think there are cooler things we can do.

Comment 7

[Paul Craciunoiu [:paulc]]

On the other hand, prefetching the next 50 articles post-page-load and showing then on-click with JS would make for less frustration, perhaps... while we're going overboard here :)

Comment 8

[James Socol [:jsocol, :james]]

Let's just paginate these at some point. Frankly I don't care if this slips to next quarter, as it's not horrible now, I just don't want page load times growing without end.

Comment 9

[Kadir Topal [:atopal]]

Tbh, the page feels pretty fast. Is the issue that it slows down other parts of our site? There is a lot of value in presenting information in context, paging removes that context. If it won't slow down other parts of the site, I'd go with putting as much of the list on one page as possible. If the concern is that an unbounded list will slow down the site in the future, let's go with 300 per page, that's about the limit for webtrends data anyway. And making paging less painfull with infinite scrolling sounds interesting.

Comment 10

[James Socol [:jsocol, :james]]

300 is fine. There just needs to be some cap on it. We can look at infinite scroll (how many people actually use this page?) but that doesn't solve findability via Ctrl/Cmd-F.

Comment 11

[Kadir Topal [:atopal]]

True, I didn't think about findability, but 300 per page is great, that should work for almost everyone.

Comment 12

[Erik Rose [:erik][:erikrose]]

IIRC, I ran into trouble with this due to the un-len()-li-ness of some of those raw querysets. Take a look at https://github.com/kumar303/zamboni/blob/306291e66e639edeb019c9052a6410e799259e55/apps/amo/models.py#L92 for a len()-able one.

Comment 13

[James Socol [:jsocol, :james]]

WONTFIX for now, these pages don't get used much. If that changes, we'll need to re-evaluate for load times.