http://www.getpersonas.com/store/gallery/Music/All/1 currently only has one page, but has pagination functionality; others, such as http://www.getpersonas.com/store/gallery/Sports/Popular, which also only have one page, don't.
Is this a bug? Unclear to me. /All has pagination, whereas /Popular doesn't, so I'm not sure whether we should show 1 of 1.
Lack of consistency sounds like a bug to me :-)
Yeah, but which consistency - pagination on /All pages, or not paginating single ones? ;)
(In reply to comment #3) > Yeah, but which consistency - pagination on /All pages, or not paginating > single ones? ;) Ah, yeah; well, that sounds like a project-manager decision to me :)
IMHO, pagination is considered harmful and should be avoided in most cases.
we decided against pagination on all pages early on, though it wasn't tracked well. my fault. let's remove pagination throughout the gallery.
Did we decide against pagination? I only see the no-pagination on the all/all page, and we planned pagination on the others. (the all/all page s becoming problematic, too. There are 2000 images on it, and it's causing problems at least for my browser.)
goal is to choose an approach and be consistent with that approach. per comment 5, and other arguments that have been made off-line, it seems like "no-pagination" is the best approach. the downside is potential performance issues, which Toby seems to be alluding to in comment 7. but it seems like performance issues would apply most significantly to All/All, which we decided early on would have no pagination. unless anyone has a strong argument on why we should implement pagination across the entire gallery, let's remove pagination.
FWIW, I don't think consistency should be a goal here. It's helpful to use pagination in exceptional cases, of which All/All may be one. For the majority of pages on the site, however, pagination would be a worse user experience. So I suggest removing it for pages generally, while providing it where browser limitations mean that pagination provides a better user experience. To avoid the complexity of multiple code paths, one strategy for implementing this is to apply pagination to all pages, set a high default limit (f.e. 500 personas), and hide the pagination navigation UI for pages that don't hit that limit.
Also note: paginating All/All removes the one mechanism currently available on the site for searching for a specific persona. If we do so--which, as I noted in my previous comment, may be reasonable given browser (and computer) limitations--we should prioritize a persona search feature for the next release (the one whose dynamicity presumably supports it, unless we want to do something simple like linking to a Google site search, which we can do with the current implementation) so one can search for a persona whose name/description matches a particular string.
OK, here's what I ended up doing after watching FF grind to a halt on the big pending pages. At this point, having 4300 personas on a single page is not viable. 'All' paginates in 500-persona chunks, and pagination only appears if there are multiple pages. Recent and popular remain at 42, with no pagination.
Status: NEW → RESOLVED
Last Resolved: 9 years ago
Resolution: --- → FIXED
Trivial correction: 501-persona chunks (since it's divisible by 3).
Agreed, and will prioritize search for the next release.
Toby, is it possible to get a production dump on staging, so we can test what happens in comment 11? (http://sm-weave-proxy01.services.mozilla.com/gallery/All/All/1).
Done. Note that you'll need to use your logins from the live server, or create a new account I can make admin.
Verified FIXED; thanks Toby -- that helped a bunch.
Status: RESOLVED → VERIFIED
Product: Mozilla Labs → Mozilla Labs Graveyard
You need to log in before you can comment on or make changes to this bug.