GNOME Bugzilla – Bug 699832
Replace Load More with autoloading on pressure
Last modified: 2014-05-08 23:50:31 UTC
Use behaviour to load the next batch of results on pressure the bottom. This would be similar to gnome-shell's message tray behaviour (see bug 677215) and be touchscreen-friendly. Initial place to start implementing this might be https://developer.gnome.org/pygtk/stable/class-gdkevent.html#method-gdkevent--get-axis
A possibly different solution, which might be worth considering, is behaving a bit like Google Music does for large collections (e.g. in Album view). They pre-compute the total height of the viewport to have scrollbars already of the right size (just by counting the number of elements returned by a query → rows of fixed height). When you scroll down to a certain position, and stop for a fraction of a second, they load the corresponding range of items. That reduces the waiting time for the user, e.g. if he is interested in something starting with the letter "Z" and they have hundreds of results the user would scroll directly to the end; plus, it avoids the problem of "pressure at the bottom", which I personally find not completely intuitive (as it changes the scrollbar position and size, and introduces a noticeable lag in browsing a large collection looking for something to listen to, etc.).
(In reply to comment #1) >When you scroll down to a certain position, and stop for a fraction of a >second, they load the corresponding range of items. That reduces the waiting >time for the user That sounds like a really good idea, it is extremely tedious to get to the end of the list at the moment as you have to press 'load more' many times to get there & loading more on pressure would still be slow to get to the end.
Created attachment 253489 [details] [review] Remove Load More button and it remains
(In reply to comment #3) > Created an attachment (id=253489) [details] [review] > Remove Load More button and it remains I'm afraid that goes against the app design; I already attempted to propose (a simplified version of) your patch in bug #699831 and it was turned down.
Review of attachment 253489 [details] [review]: Indeed, I think we need something like the patch in bug #706947 then we could let the Load More button stay or change it to autoload on pressure. Otherwise this will block bug #700726 too.
This does not seem to fix the root of the problem to me: whether you need to click on a button or scroll to the end of the list and wait for it to fill, it's still very painful to get to, say, the last third of the list if it is of more than 100 albums (common case). Are you actually using the current design with such a library to test? The list should really allow you to scroll easily to items that are very far. how about a list of letters in alphbetical order, like the iPhone does, so that in one click you get close to the artist you want? This requires pre-computing the height of the list of course.
(In reply to comment #6) > Are you actually using the current design > with such a library to test? About 30 albums, but I extensively use search, as a result I click 'Load more' no more than two times > The list should really allow you to scroll easily to items that are very far. It does, but each time it queries tracker, so the bottleneck here is tracker
(In reply to comment #7) > (In reply to comment #6) > > Are you actually using the current design > > with such a library to test? > About 30 albums, but I extensively use search, as a result I click 'Load more' > no more than two times Sorry, but that's not a realistic use case at all. If you need to click "Load more" with such a small library, there's clearly a design issue. :-/ > > The list should really allow you to scroll easily to items that are very far. > It does, but each time it queries tracker, so the bottleneck here is tracker I think you should really get a list of all _local_ items (albums, artists) on start (maybe asynchronously, though). 300 or even 5000 names is not a big deal (Rhythmbox and Banshee load the names of all songs, about 6000 here, almost instantly). Remote content probably needs a special treatment anyway since the user may not be interested in all of it.
Maybe tracker is a very bad choice, if it is not able to provide a simple list of local artists in -- say -- less than 1 sec. Rhythmbox, and every other mature music player I know of, is more than capable of doing so. Remote sources should be retrieved and merged as they come in, maybe being cached. GNOME Documents does the same, I think (first showing local files, then it loads files from e.g. Google Drive). To give some numbers: * I have a local library with 19131 tracks, with 903 artists and 1452 albums. Rhythmbox, on my 4-years-old netbook, loads within a couple of seconds... * my whole library is replicated in the cloud. I'm not sure how you will be able to exclude duplicates anyway, but this is a problem for another day... I guess incidentally this is the reason there are not many apps out there that allow for handling more than one source at a time. * I've got another ~5000 songs on Google Music. * I've got about 400 songs on Amazon Cloud. So, if you're working only with 30 albums, you are really using a ridiculously small test case. I still think loading all artists in one shot is highly desirable, at least for local sources. Merging them with other hits coming from remote sources can be done asynchronously. If tracker is unable to respond in an acceptable time, it ought to be trashed. But I *think* it *is* able to give a result in < 1 sec, even with my library. If you'd like, I can try to come up with a script that will create a series of empty ogg files, using the metadata and directory structure from my own library. That will give you a more credible use case, and might beside prove useful for automated testing.
(In reply to comment #8) > If you need to click "Load more" with such a small library, there's clearly a design issue. :-/ Feel free to prepare a nice wireframe for new design. Patches are welcome too. > 300 or even 5000 names is not a big deal > (Rhythmbox and Banshee load the names of all songs, about 6000 here, almost > instantly). Sure, could you quickly patch gnome-music to remove 'Load more' button and make some performance metrics? I believe the biggest problem would be albums and artists views - as we use album thumbnails there - and displaying and showing 300-5000 images is a huge performance hit - but probably it might work.
Tracker is probably a good choice. It's exactly designed to retrieve meta-data as fast as possible, so it should work fine. Proof: $ time tracker-search --music-albums [...] real 0m0.085s user 0m0.036s sys 0m0.010s $tracker-search --music-albums | wc -l 454 $ time tracker-search --music-artists -l 100000 real 0m0.082s user 0m0.026s sys 0m0.014s $ tracker-search --music-artists -l 100000 | wc -l 593 Loading images will be more problematic. I think it would make sense to only load covers for the visible albums, plus the few next rows to prepare scrolling. I think this is a common pattern for GtkListView and such (sorry, I can't remember how it works right now). So as a first round the designs do not need many changes, except removing the 'Load more' button. For remote content, I'm not sure what should be done -- what do other similar applications do? Loading them as the user scrolls in the list is an option.
Created attachment 264554 [details] Script to populate a large library for testing purposes Yes, thanks Milan for the quick check on Tracker. I thought it was fast enough, too. I am attaching a small script and my rhythmdb. It is able to replicate a large library with some tags for testing purposes (you need ruby and the nokogiri gem installed, plus the id3v2 binary). tracker should then pick up the files, that are created in ~/Music/testcase/. This should provide some clue about why having artists with a "Load more" button is not a very nice UI design choice.
This would be a nice thing to experiment with. It's important to ensure that the core apps are consistent though: if we want to adopt it here, we have to be sure that it is appropriate for the other apps (and that they can be ported to the new behaviour).
(In reply to comment #13) > This would be a nice thing to experiment with. It's important to ensure that > the core apps are consistent though: if we want to adopt it here, we have to be > sure that it is appropriate for the other apps (and that they can be ported to > the new behaviour). That's true but assumes that the load more button is appropriate here in the first place. I'm not sure it is as if one's music collection is large enough that you have to press the button more than a couple of time it takes ages to get to the albums at the end of the collection. Automatically loading more content as the user scrolls down works nicely in Spotify and on some web search engines. Another way of solving this would be to cut down the total size of the collection in any given view by subdividing it by the starting letter of the album title or some other appropriate key if the undivided collection is above a certain size.
You don't need to load albums/artists when the user scrolls down, you can load all of them on start. The timings I provided above are ridiculously short. Allan, what design do you think is worth experimenting? Autoloading on pressure, or loading everything on start?
(In reply to comment #15) > You don't need to load albums/artists when the user scrolls down, you can load > all of them on start. The timings I provided above are ridiculously short. As we're planning to implement remote sources (such as Jamendo, remote media and UPnP) we can't remove 'Load More' / autoloading completely. Also as GNOME Music is a GNOME application it has to be consistent with other GNOME applications. I propose to discuss this as a global (yet minor) GNOME feature for 3.16, so other apps (such as gnome-photos or gnome-documents) would be updated during the same GNOME release.
(In reply to comment #16) > As we're planning to implement remote sources (such as Jamendo, remote media > and UPnP) we can't remove 'Load More' / autoloading completely. Once you have connacted to a remote service, getting the full list of artists/albums isn't going to take more time than getting only the first 50 entries. We're not talking about downloading files here, just a list of strings: with an artist name being on average less than 20 characters long, a list of 10000 artist names is about 200 KB, i.e. about the size of the Google home page people always load without noticing when starting their Web browsers. So I think the question is not performance here, it's really the user experience. And to me it makes no sense to treat differently the top of the list and the rest of it. Contrary to search results, when you're showing artists/albums in alphabetical order, the top of the list has no reason to be more relevant than the entries below them. Also, I think Jamendo is very different from your personal library: you typically want to go over the albums list of your library, since it contains songs you like, and choose something among them. On Jamendo, there are too many things you don't even know about: scrolling over an alphabetical list is not possible: a search is more appropriate, possibly combined with genre categories. But it must definitely be separate from personal music.
(In reply to comment #15) > You don't need to load albums/artists when the user scrolls down, you can load > all of them on start. The timings I provided above are ridiculously short. > > Allan, what design do you think is worth experimenting? Autoloading on > pressure, or loading everything on start? The "chunked loading" approach has two aims, as I understand it: 1. Make scrolling easier when you have large collections - we don't want the scroll bar growing too short, or small scroll movements moving the view wildly. 2. Avoid the scroll bar moving independently as the view is populated. To me it feels like the existing "chunks" are too small - the first thing to do is adjust the "chunk" size based on these criteria (I'm not sure what the best approach to 1 is). My suggestion would be to then look at autoloading on pressure.
For me the worst problem with the current design is that searching will only give results among what's already displayed... Not displaying everything could be a design choice, but not searching through everything is absolutely a bug, IMHO.
(In reply to comment #19) > For me the worst problem with the current design is that searching will only > give results among what's already displayed... Not displaying everything could > be a design choice, but not searching through everything is absolutely a bug, > IMHO. Doesn't seem related to this bug. :)
(In reply to comment #18) > The "chunked loading" approach has two aims, as I understand it: > > 1. Make scrolling easier when you have large collections - we don't want the > scroll bar growing too short, or small scroll movements moving the view wildly. Well, currently it doesn't seem to work too bad in Rhythmbox. After all, a list of artists/albums isn't that long compared to e.g. a text document or a Web page. And now we have the special "slow" scrolling mode when the user does small movements. > 2. Avoid the scroll bar moving independently as the view is populated. To me this isn't an issue since, as I said above, loading 50 items will take almost as much time as loading 500. > To me it feels like the existing "chunks" are too small - the first thing to do > is adjust the "chunk" size based on these criteria (I'm not sure what the best > approach to 1 is). My suggestion would be to then look at autoloading on > pressure. This would certainly reduce the pain, but the whole idea of loading by chunks is IMHO wrong. It will necessarily be frustrating when trying to access the end of the list; a small alphabetical list next to the scrollbar would make more sense. What other software has retained this UI pattern?
(In reply to comment #20) > (In reply to comment #19) > > For me the worst problem with the current design is that searching will only > > give results among what's already displayed... Not displaying everything could > > be a design choice, but not searching through everything is absolutely a bug, > > IMHO. > > Doesn't seem related to this bug. :) Well, sort of: it is related to Milan's comment #15: if you pre-load everything instead of using "load more", you fix this awful problem, so this is one more reason for removing this whole "load more" concept.
(In reply to comment #21) ... > > The "chunked loading" approach has two aims, as I understand it: > > > > 1. Make scrolling easier when you have large collections - we don't want the > > scroll bar growing too short, or small scroll movements moving the view wildly. > > Well, currently it doesn't seem to work too bad in Rhythmbox. After all, a list > of artists/albums isn't that long compared to e.g. a text document or a Web > page. And now we have the special "slow" scrolling mode when the user does > small movements. That obviously depends on a variety of factors: number of items, size of each item, size of the scrolled area. When I try this, it seems like 230 albums is around the upper limit before the scroll bar becomes a bit small and hard to use (that's with the window at its smallest possible size). Of course, using this approach to keep scrolling comfortable also requires that you have "load more" as you scroll up after scrolling down (it's more like paging than loading more). > > 2. Avoid the scroll bar moving independently as the view is populated. > To me this isn't an issue since, as I said above, loading 50 items will take > almost as much time as loading 500. Fair enough (although we need to accommodate collection bigger than this). > > To me it feels like the existing "chunks" are too small - the first thing to do > > is adjust the "chunk" size based on these criteria (I'm not sure what the best > > approach to 1 is). My suggestion would be to then look at autoloading on > > pressure. > > This would certainly reduce the pain, but the whole idea of loading by chunks > is IMHO wrong. It will necessarily be frustrating when trying to access the end > of the list; Again that depends on the size of the list. If the list is really long, then scrolling all the way to the bottom will be painful anyway, and search would be a better solution. If the list is short, chunking shouldn't be needed. > a small alphabetical list next to the scrollbar would make more > sense. That kind of approach doesn't help to make the scrollbar easy to use for long lists though, does it? > What other software has retained this UI pattern? The most obvious examples I can think of are from Google products, like Drive and Gmail.
(In reply to comment #22) > (In reply to comment #20) > > (In reply to comment #19) > > > For me the worst problem with the current design is that searching will only > > > give results among what's already displayed... Not displaying everything could > > > be a design choice, but not searching through everything is absolutely a bug, > > > IMHO. > > > > Doesn't seem related to this bug. :) > > Well, sort of: it is related to Milan's comment #15: if you pre-load everything > instead of using "load more", you fix this awful problem, so this is one more > reason for removing this whole "load more" concept. We will introduce Advance Search on 3.14 which is our GSoC 2014 Project. Currently it is just filtering (which causes this issue) but after the said feature is implemented, the search result will be taken straight from tracker instead of just filtering the currently displayed items. See bug 724021.
On the question of speed: while Tracker seems to be able to return the content fast enough, there are issues with presenting content quickly enough. Chunked loading is supposed to avoid the unpleasant loading behaviour described in bug 704257.
I don't think this is related. You only need to load the covers for the albums currently displayed (and a few more for smooth scrolling experience), so in effect you could do exactly the same disregarding the number of albums that are in the list, but not currently visible. I don't believe it would make sense to load covers for all albums in the list, even if the "load more" behavior was retained, as it would take time on start for no purpose -- except if only a very small number of items were listed before having to click "load more".
(In reply to comment #26) > I don't think this is related. You only need to load the covers for the albums > currently displayed (and a few more for smooth scrolling experience), so in > effect you could do exactly the same disregarding the number of albums that are > in the list, but not currently visible. Then that's bug 702565. Though the current code in master has album art cache rewritten which is really fast, so the album art is no longer a big issue, but the loading of the items retrieved from grilo.
Fixed in https://git.gnome.org/browse/gnome-music/commit/?id=e3a4591 Basically we're loading all albums now, but resolving thumbnails only for the visible ones + next 10 (see bug 702565). This fix will be a part of 3.13.1 and will soon be backported to 3.12 branch and will be a part of 3.12.2 release
Cool!
I am trying the new functionality in Fedora Rawhide (GNOME 3.13.1). While the UI from a design perpective now is *much* better (thanks!), I have very heavy CPU usage with around ~1600 albums to load. The whole application is unusable for me, as it takes minutes before switching to another view (and then, it does not get faster). Most of the time, I am asked to terminate the application because deemed unresponsive. It does not even respond anymore to mouse events. One of the culprits is that switching between artists/albums view does not pause the loading in the other view as far as I can tell. But it is imho not enough to fix it. I really think we should only determine the number of albums with a "count" query, and then load metadata for the albums which are inside the view (plus something extra above/below). Albums which come later because they are from remote sources, can be "merged" with the other ones as batches of results are fetched. Should I open a new bug, or reopen this one?
(In reply to comment #30) > I am trying the new functionality in Fedora Rawhide (GNOME 3.13.1). > > While the UI from a design perpective now is *much* better (thanks!), I have > very heavy CPU usage with around ~1600 albums to load. This partially has been addressed in https://git.gnome.org/browse/gnome-music/commit/?id=de554a4bca89d41c287151a424b7c0a7f4b8a56f, could you apply that patch and check the performance again? > Should I open a new bug, or reopen this one? Yeah, I guess we should discuss performance of this in a new bug
(In reply to comment #31) > (In reply to comment #30) > > While the UI from a design perpective now is *much* better (thanks!), I have > > very heavy CPU usage with around ~1600 albums to load. > This partially has been addressed in > https://git.gnome.org/browse/gnome-music/commit/?id=de554a4bca89d41c287151a424b7c0a7f4b8a56f, > could you apply that patch and check the performance again? Unfortunately it does not help much. I can now close the application without having to kill it (because too unresponsive), but it still takes some minutes to load the library, switch views, etc. > > Should I open a new bug, or reopen this one? > Yeah, I guess we should discuss performance of this in a new bug Okay, let's move the discussion in a new bug. I will post the bug number here as soon as I get around at profiling it.