UX: Improve performance of infinite scrolling for large photo collections #500
I discovered after importing my very large, pre-existing photo library and then trying to create some albums that very large collections will run into limitations in the browser. The first limitation is not terrible but I didn't see it documented: selecting multiple images is limited to 500. The second limitation was much more difficult to work within: I was unable to scroll past 2,222 photos in a single view (using mosaic view). This doesn't take into account the performance hit I saw while browsing and selecting, which I see is already reported in #477.
My entire photo library is around 15,000+ photographs and I presume without being able to move photos out of the primary view, it's not hard to get past that 2,222 image limit. Attempting to create an album for photographs from my wedding, for example (for which I have nearly 1,200 photographs alone in various color palettes and from various sources) became an exercise in finding limiting views to select the photos I wanted, sorting forward and then reverse for the month in question, etc.
Perhaps instead of a hard limit on the number of photos to load, the limit can be a rolling number, and as the limit is reached via the infinite scrolling, the previous ones are kicked out of cached memory. The process would then be reversed for scrolling in the opposite direction.
Thank you for this incredible software, both the web app and the Android mobile applications are far superior to anything else I've tried!
The text was updated successfully, but these errors were encountered:
First, let me thank you for your donation! Much appreciated.
As a quick solution, we can increase the limits to 3333 results and 999 clipboard items. Of course it is also possible to hit those limits and eventually your browser might run out of memory if you try to load all pictures. That happened to a user in the past, so we've added these limits.
Note that we provide a filter for finding pictures that have not been added to an album yet:
You can manually apply it everywhere by entering
Implementing a mix of infinite scrolling and pagination, as you suggest, doesn't seem to be a good idea in terms of code complexity and UX. I know Flickr has/had a relatively low limit for infinite scrolling and then forces you to use a pagination. I'd rather provide other ways of dealing with large result sets, like filtering results that have already been added etc.
Signed-off-by: Michael Mayer <firstname.lastname@example.org>
yes, i don't think the limits should be raised as this already slows down my reasonably-spec'd computer by loading lots of pictures. i think the issue is that from a user perspective, the library is "infinite scroll" until it isn't. I thought i would be able to just keep scrolling back in time through my entire library, but i only get a fraction of the way through before i can't go any further and have to choose a different method of browsing.
this is in contrast to google photos, where my entire library is shown, it handles infinite scrolling, and there's even a timeline along the left so that i can quick-scroll to a certain date-range. if i do this scrolling too quickly, it takes a moment for the images to cache but otherwise it's a seamless user experience.
i cannot speak to code complexity regarding this, but from a UX standpoint i would say that the current behavior did not match my expectation based on the general functionality of the site, and therefore this is bad UX (this small use case, not the entire site). a site should not use infinite scroll if it cannot scroll infinitely.
EDIT: also, I've tried using the unsorted flag but a) there isn't a search field in many of the views (calendar, folders, etc) and b) applying it manually to the url with
Jumping to a point in a timeline is different. Time effectively is a search filter then, like you can limit results with our filters. Just a different way to visualize it. Many users asked for this, so it's definitely on the list. I personally prefer a real search form and typically don't use it.
Would a timeline also work in a situation where you have lots of photos taken in a very short time, like a wedding? Jumping to a different year is much different from what your initial use case was (selecting wedding photos probably taken on the same date).
Note that Google Search is a prominent example for what you describe as bad user experience. They use a so called "top k" index where you can only actually see the first k results even though there supposedly are millions of results 😉
You're right, we don't provide a regular search form in albums or moments as the search filter might conflict - in various unforeseen ways - with the scope of the album or moment, like when you open "May 2020" in the calendar and then request results from 2019. Technically, albums and moments (incl calendar and folders) are nothing else than static search filters. So you can filter / find the same results using our regular search if that makes sense.
You can find a list of all filters on https://docs.photoprism.org/user-guide/organize/search/
I agree that those docs need a little more work and better descriptions of what each filter does.
Edit: You especially might want to try
those additional search filters are great, thank you. i didn't seem to find them in my first pass of the documentation.
when i used google photos as an example, i wasn't referring to google search... google search is paginated, hence the famous Goooooooooogle at the bottom. Pagination is a bad UX for a photo album, i agree, and is the primary reason i'm looking for an alternative to Piwigo (which uses pagination) and have happily found Photoprism (which uses infinite scroll).
But google photos (photos.google.com) is an infinite scroll of your entire photo collection which loads on-demand, similar to Photoprism. The timeline along the side is a separate feature but loads in the same interface as the infinite scroll.
If i'm browsing my collection in google photos, I am never told "you've looked at too many photos, we can't load any more, please search or use some other interface to find the thing you're looking for." This is the differentiator i wanted to call out.
if i'm looking through my photo collection for every picture i've taken of my dog over the last 10 years, i can't just scroll through my photo collection (the default landing page of photoprism) to find them and add them to an album because i'll be told there are too many pictures to load and my browser will crash. instead i have to find a different way of browsing my photo collection:
This flow is not intuitive because the photo library acts like i should be able to view them all (it's right in the name of the mechanism: infinite scroll, not arbitrarily limited scroll). this is at the heart of the matter: UX requires consistency and predictability by the user. if the user is presented with an interface that says "you can keep scrolling down, and we'll load more pictures as you need to see them" then it should continue to do this, instead of stopping at an arbitrary point and saying "wait, not that far down! use something else".
hopefully this clarifies my initial statement... i'm not suggesting a combination of pagination and infinite scrolling from a user-perspective, i'm suggesting consistent infinite scrolling behavior. using pagination on the backend to make that happen both forward and backward will have to be the only way to do that without requiring as much RAM as there are photos.
all this is to say: the view already loads the next 60 photos, with a maximum of 2,222. it should probably be limited to 500 to reflect the maximum number you can select, and once it met that limit you just continue loading the next 60 by clearing the first 60 photos out of browser cache, the whole situation would be much smoother and put less pressure on system resources.
Typically it is possible to jump to the last page where there is a pagination. Not only does Google skip results, you can't even jump to the last page. Users accept this because it is Google and they are used to it. That was my point.
Maybe we should call it dynamic scrolling instead of infinite, to dampen expectations ;)
This is what Flickr does when you dynamically scroll too far in the Photostream:
They also have a Camera Roll view with infinite scrolling, but it loads really slow.
All in all, I think we have a good enough solution for the start even though there is room to improve. But that requires more budget.
When you do a search in Google Photos, you see the results in a regular view, not the Timeline. They don't even have different result layouts (like List, Card or Mosaic View) to choose from, unless there are settings I haven't found so far?
To properly render a timeline, you need to know how many results you have and what dates they have. Applying a filter slows down performance significantly as you always need to operate on the complete result set. We intentionally don't do this in favor of performance and more metadata in search results, so that we can render our Card and List View (which saves me a lot of time as I don't need to open every picture to see camera, lens, codec, location etc).
When implementing a Timeline view without additional filters (like Google), we will choose an approach similar to Places where all results are loaded instantly, but with less metadata.
My point is: You can't have everything without any tradeoffs. For us, performance and good filters were more important than a Timeline view as part of our first release. Once there is budget, we can provide a Timeline view that is just as nice as what Google has to offer. If you think Google has the perfect product, there is also no reason to use PhotoPrism instead.
There's a lot of focus on timeline view in this issue, and it's making me regret having brought it up as a side-note because there are separate issues which you've already linked to.
Google doesn't have a perfect product because I am not in control of any of my data by using their service. I have been searching for a functional self-hosted replacement of their photo service for about three years now, migrating my photos constantly from Sigal to Piwigo and now to Photoprism, with countless trials of other products in between. Photoprism has been by far the best.
The only issue I've had with it is that it doesn't clear browser cache of thumbnails when infinite-scrolling in any of the views. I still stand by my recommendations that:
I can only hope that once this issue gets raised to it's eventual priority, this is a change that budget allows for. I will do what I can to help sustain the project.
I was going to also give more feedback regarding your specific implementation ideas, but didn't have the time so far and wasn't sure if you're interested after all I wrote already...
Even if this works, micro-managing the browser cache is often not a good idea:
I currently don't have time to upload 100k files to Google Photos for testing, so I don't want to make a statement how exactly they handle this - but I wouldn't be surprised if they only do lazy loading when you scroll to a position but don't remove anything that was already loaded. You typically don't want to do this as scrolling back and forth would cause a lot of traffic and bad UX by itself.
Also keep in mind:
Bottom line: Loading too many files is bad, but loading them repeatedly over a network without caching seems worse. What we can and should do is a) optimize our JS so that rendering gets faster and b) add additional views, like a Timeline, for users who like to browse their library as known from Google Photos and other photo apps (see #152 and #502).
I have verified in my google photos account that the interface reloads thumbnails that have already been loaded when i revisit them, because they have been purged from local memory. This is only with a significantly smaller subset of photos that happen to be in my account, probably only a thousand or so.
This sounds like something that is a reasonable thing to consider "best effort" to accommodate, but you also have a mobile application which handles caching differently. Users concerned with data usage would best leverage the mobile app to cache photos locally rather than load them over the internet. I don't think this is unreasonable, and most people conscious of their mobile data usage already do things like this regularly, choosing native caching applications over webapps. On top of that, if a user is concerned with their data usage, they probably should use your alternative suggestions to find the photos they're looking for rather than load every image in their photostream trying to look for it, and then doubling back over photos that they've already passed.
I will definitely investigate these settings to see if it improves my local browser performance, but thumbnail size would then have even less to do with the 2,222 image limit.
I recognize the difficulty in identifying a good baseline for performance related issues, and my recommendation would be to always start with a very limited constraint window, and allow for higher-performance options secondary. It's the reason that web development has a "mobile-first" design mentality for responsive display sizes, and tools like https://github.com/tylertreat/comcast exist. I'm not you, so I cannot make those decisions for you, but I am a technical consultant by trade so I'm automatically opinionated and want to tell other people how to do things 😄
First of all - GOOD JOB! I'm impressed!
@williamkray Suggest that problem is in showing a large number of photos.
I just discovered that project (at night) and immediately noticed, that it's hard to get pictures far far away.
It requires scrolling down, waiting to load, scrolling down, waiting,... It's time-consuming.
I know there is a calendar tab, we can limit dates in the search box.
So being able to scroll like in google photos will be desired.
I believe it can be solved by creating a virtual list.
Pagination is already implemented on the backend.
When we will have:
It will be possible to deliver google photo's like scrolling.
Knowing count, we will now how many rows we need to display.
Then we can load only pictures which are in view (with some margin).
In that way viewing thousands of pictures should be possible.
For example when we will move the scroll bar to the middle.
instead of every page to reach offset 10000.
A simple example of such a scroller with 200000+ elements! (JS/React)
Please check out: (description how virtual scrolling works)
It seems that you use VUE.
Currently, I don't know even a basis of VUE, nor Go :/
Using virtual lists can solve several issues.
API returns just array of items.
Use of "vue-virtual-scroll-list" (or other library) will still require some work like fetching image details on demand.
Note on Google photos timeline
Note, that even Google photos don't show a timeline on the side for example when you search for some term.
I main view (view of all photos) it shows a timeline where you can see "what date you can expect on given scroll position".
I'd love a timeline view also, but my most desired feature is smoother/better infinite scrolling. I found this article about google photos very helpful, particularly "4. Instantaneous Feel" : https://medium.com/google-design/google-photos-45b714dfbed1
All the lower quality preload isn't even necessary. Just preload 60 more photos when I've scrolled down 20 out of 60, instead of waiting until I'm at 60/60.
So now that JS and thumbnail API performance was improved by a lot, browsers limit the number of connections thus loading images delayed - sometimes up to 20 seconds after opening a page (or more). Solutions may be to use multiple sub-domains / hostnames or try HTTP2.
"content-visibility" enables the user agent to skip an element's rendering work, including layout and painting, until it is needed: - https://web.dev/content-visibility/ - https://developers.google.com/web/updates/2016/06/css-containment
While it makes sense for the file browser which shows up to 999 results at once, I'm not convinced it helps the other views which already use lazy loading. Feels shaky especially on mobile, e.g. because the top toolbar fades in and out even when just scrolling down.
Feels extremely shaky when scrolling. Top toolbar fades in and out all the time.