Issue Details (XML | Word | Printable)

Key: MBS-341
Type: Improvement Improvement
Status: Decision Required Decision Required
Priority: High High
Assignee: Unassigned
Reporter: Paul C. Bryan
Votes: 17
Watchers: 12
Operations

If you were logged in you would be able to see more operations.
MusicBrainz Server

Pagination is painful

Created: 22/Jan/10 07:27 PM   Updated: 31/Jul/13 01:04 AM
Component/s: Data display, JavaScript, User interface
Affects Version/s: NGS - Beta 1
Fix Version/s: Within 3 months

Issue Links:
Duplicate
 
Relates

Size Estimate: City


 Description  « Hide

Compared to current MB, pagination in NGS can be quite painful.

Example:
1. Go to Artist: Ludwig van Beethoven
2. In his release groups, try to go to the beginning of his compilations.

Possible solutions:
1. Allow user-selectable page size.
2. Allow suppression of pagination.
3. For example above, allow selection of release group type to jump to.



Sort Order: Descending order - Click to sort in ascending order
Frederic Da Vitoria added a comment - 04/Apr/13 10:10 AM

@Václav: I agree. I was fearing something like what Google does when browsing images, where you don't have in advance an idea of the size of the whole range and the scroll bar change scale as you browse. A scroll bar which gives the user a visual clue of the total size would meet my concern as well as the pagination system. But you gave a good technical argument against loading the whole range at once. I also agree that having some way to search the results could be useful.


Václav Brožík added a comment - 04/Apr/13 09:51 AM

Ian: when you do not implement pagination you are leaving the work to the web browser. This can bring some technical difficulties especially on resource-limited platforms like mobile device browsers, browsers embedded into TV etc. Also some browsers/environments can be difficult to use with long pages. I do not use such browsers/environments.
Also pagination based on the first 1, 2 or 3 letters of the title would make the navigation much easier. AFAIK this could also be implemented by JavaScript on a single long page.

Frederic: That is true mainly when you visually see the range of all the pages which is in fact more easier with the web browser scroll-bar than with the subset of 10 pages shown in MB currently. As you mentioned symphonies - Many composers can have substantial amount of works which names begin with the same letter like "S" this spoils the empirical guess you mentioned and pagination based on the first 1, 2 or 3 letters of the title would work much better here.


Oliver Charles added a comment - 04/Apr/13 09:23 AM

The pagination was added under the assumption that it was necessary to reduce server load, which is something I don't think was ever truly measured. NES made big changes in the architecture and a lot of things got faster (mostly due to reducing O(n+1) style queries to O(1) queries).

Generally, there was no real conscious decision to add pagination, it was just done as part of the NES rewrite.


Frederic Da Vitoria added a comment - 04/Apr/13 06:58 AM

Pagination offers an important feature IMO: it allows the user to jump to a page based on an empirical guess, just like you would open a dictionary around the middle if you are looking for a word that starts with the letter "M". When I am looking for a symphony, I jump to a little after the middle page, then I choose the my next jump based on the results I get. Manual version of the dichotomic search If we decide to use some other browsing method, it should offer a similar feature.


Ian McEwen added a comment - 04/Apr/13 06:39 AM

Oliver (probably): my main question, on this ticket, is: why do we have pagination? I think we aren't equipped to discuss solutions here until we know the constraints of the problem, which aren't laid out here. Is pagination required in order to reduce server load (it doesn't appear we limit in the SQL)? Is it an attempt to reduce the mental scope for those browsing? Is it something we added because pagination is the standard thing to do?

I think once we have that answer, and thereby a picture of the constraints, we're actually in a position to consider user scenarios, which looks like the next step here.


Nicolás Tamargo added a comment - 17/Oct/12 11:19 AM

Moving to 3mo as per due date


Oliver Charles added a comment - 13/Jun/12 01:58 PM

This is not actionable, so I am moving it to decision required


Oliver Charles added a comment - 28/Dec/11 12:13 AM

Setting due date based on when this task was moved to 12mo bucket.


Oliver Charles added a comment - 05/Dec/11 01:53 PM

We really need to stop making decisions based on how fast it can be implemented, in the long run it just complicates the problem. I don't see much benefit variably changing the per-page limit. I'd rather sort out navigation problems (jump to certain predicates, inline "show more" links, per entity search) and spend time discussing them.


Johannes Weißl added a comment - 05/Dec/11 03:45 AM

Just a short question: Would it be ok to let the user decide how many pages he wants to see (like on discogs, e.g. "50, 200, 500"). That could be implemented really fast.


Oliver Charles added a comment - 18/Nov/11 06:01 PM

Certainly not a small project, so I'm calling it city-sized for now. Certainly something to consider for releases in 2012, if not sooner.


Oliver Charles added a comment - 26/Jul/11 02:29 PM

No, not at all. We are simply not at a stage to be looking at these kind of improvements though, sadly.


T. For added a comment - 26/Jul/11 02:19 PM - edited

It would be a great help if pagination could be disabled because it has become a real pain to track down incomplete and misspelt title collections. Unfortunately the Search does not help when only manual comparison can lead to the one entry that really fits.
I truly hope this request hasn't been forgotten.


Elliot Chance added a comment - 10/Jul/11 11:49 PM

It would be nice if there were an option to turn off paging completely (like pre-NSG). For example Armin van Buuren has hundreds of ASOT releases that are sorted by release title (live releases) - finding one episode in series requires lots of page clicking until you narrow down the page it's on, very annoying.

Yes I know I can search for the episode directly but often i'll want to go back/forward one episode at a time.


Václav Brožík added a comment - 03/Jun/11 04:17 AM

Linking to the issue describing problem of searching certain work in a long list.

I think that the sub-search function suggested by Meloria would be great. IMHO loading whole list (of releases, works etc.) as one web page is bad because it could load slowly and some web browsers support only limited web page lengths.

Besides to the sub-search there should still be the possibility to jump to the beginning of selected section (otherwise the division to sections is useless on long lists) and I would also welcome jumping according to selected first (and maybe second, third...) letters. Be aware of the fact that some lists have thousands of items.

Maybe the jumping is easier to implement and it could be realised first?


Andrew John Hughes added a comment - 14/Apr/11 01:42 PM

Whether or not it works depends on what it's trying to achieve. I can't see what this gains over the existing MB layout from the user perspective. I assume it helps server load, but that's largely negated if the user has to load every page anyway to find what they want.

Given this has now been reported four times, wouldn't it be better to disable pagination until a more appropriate solution is provided?


Oliver Charles added a comment - 10/Feb/10 01:09 PM

Think this is gonna have to go post-NGS now. We have pagination that does work, although is clunky...


Oliver Charles added a comment - 06/Feb/10 01:52 PM

Excellent, thanks Meloria - I'll keep this all in mind when I come to work on this


Meloria added a comment - 06/Feb/10 01:46 PM - edited

This would only help when you know in which section to look. (And if the section itself does not span too many pages - which it does for popular artists.) But in many cases you just wouldn't know where to look, and even if you knew, you couldn't be sure that the release would have actually been inserted into that section.

I think one must be able to use searching in these cases. Either by doing it with browser search (which means that all releases must be shown on one page only), or with an extra search field for 'view searches'. In the best case these view searches should be Ajax based, although I don't know what load that would cause on the server, and also give results based on the ARs. (Maybe also on Tracks.) Ideally, the results page should then also show, why any result had been found. E.g.

View: Ludwig van Beethoven
Subsearch: Bernstein
Results:
"Symphony No. 9 (Wiener Philharmoniker)"
~ was conducted by Leonard Bernstein

"33 Sonates (10 CD Box)"
~ CD 2, Track 5: Bernstein-Sonate, Op. 139a
~ CD 2, Track 6: Bernstein-Sonate (revised 1811), Op. 139b

This would be fabulous. (Edit: Strange, why does jira change my curly quotes to straight ones?)


Oliver Charles added a comment - 06/Feb/10 01:03 PM

I am thinking of having a little drop down box near the pagination controls to jump to sections of the page. Would this help?