UX: Use virtual scrolling instead of initite scrolling in large collections

deekerman commented

2026-02-20 00:17:01 -05:00

Owner

Originally created by @dominikholler on GitHub (Nov 14, 2022).

A clear and concise description of what the problem is and why it is important to solve it.

Currently, it is required to scroll down to the bottom for multiple times, if an album, a library or a similar collection contains many photos.
If the draggable scrolling handle is moved to the bottom, the view scrolls down only the next 20(?) photos, instead of the last photos.
In large collections, it takes a very long time to scroll down this way.

It would be great, if a click on the scrollbar would scroll directly to the place in the collection.
It would be great, if the draggable scrolling handle would be moved to the bottom, the view would be scrolled instantly to the bottom.

For a user with more than 100k photos, there should be a way to scroll quickly to the end of a collection.

Originally created by @dominikholler on GitHub (Nov 14, 2022). A clear and concise description of what the problem is and why it is important to solve it. Currently, it is required to scroll down to the bottom for multiple times, if an album, a library or a similar collection contains many photos. If the draggable scrolling handle is moved to the bottom, the view scrolls down only the next 20(?) photos, instead of the last photos. In large collections, it takes a very long time to scroll down this way. It would be great, if a click on the scrollbar would scroll directly to the place in the collection. It would be great, if the draggable scrolling handle would be moved to the bottom, the view would be scrolled instantly to the bottom. For a user with more than 100k photos, there should be a way to scroll quickly to the end of a collection.

deekerman

2026-02-20 00:17:01 -05:00

closed this issue
added the
idea

duplicate
labels

deekerman commented

2026-02-20 00:17:02 -05:00

Author

Owner

@lastzero commented on GitHub (Nov 14, 2022):

Any reason you don't simply change the sort order, for example from newest to oldest first?

@lastzero commented on GitHub (Nov 14, 2022): Any reason you don't simply change the sort order, for example from newest to oldest first?

deekerman commented

2026-02-20 00:17:03 -05:00

Author

Owner

@dominikholler commented on GitHub (Nov 15, 2022):

Any reason you don't simply change the sort order, for example from newest to oldest first?

This works for users who are aware that the search bar can be expanded, and if the user is sure that he wants to use exactly the other end of the collection.

It would be more intuitive if the scrollbar would behave like intuitively expected, because the scrollbar is already visible in the default view, does not require additional understanding the search/sort bar, and would also work to see photos which are not exactly at an end of a search.

@dominikholler commented on GitHub (Nov 15, 2022): > Any reason you don't simply change the sort order, for example from newest to oldest first? This works for users who are aware that the search bar can be expanded, and if the user is sure that he wants to use exactly the other end of the collection. It would be more intuitive if the scrollbar would behave like intuitively expected, because the scrollbar is already visible in the default view, does not require additional understanding the search/sort bar, and would also work to see photos which are not exactly at an end of a search.

deekerman commented

2026-02-20 00:17:03 -05:00

Author

Owner

@lastzero commented on GitHub (Nov 15, 2022):

Yeah, but it's also a much higher effort and the initial loading would most likely be slower...

If we had no sorting and only one view, as with the competitor whose name I don't want to mention, then that's a special case, since the view can't be changed anyway and you can just cache the results and output them from memory without requiring database queries that might cause a delay in the user interface.

Also, with our current team size, it doesn't seem advisable to offer the most complex solution on the market while users are waiting for many other features, e.g. for sharing with other users or batch editing.

@lastzero commented on GitHub (Nov 15, 2022): Yeah, but it's also a much higher effort and the initial loading would most likely be slower... If we had no sorting and only one view, as with the competitor whose name I don't want to mention, then that's a special case, since the view can't be changed anyway and you can just cache the results and output them from memory without requiring database queries that might cause a delay in the user interface. Also, with our current team size, it doesn't seem advisable to offer the most complex solution on the market while users are waiting for many other features, e.g. for sharing with other users or batch editing.

deekerman commented

2026-02-20 00:17:04 -05:00

Author

Owner

@lastzero commented on GitHub (Nov 15, 2022):

If you're okay with limited search and sorting in exchange for being able to scroll down quickly, then your issue might be a duplicate of that:

#152

@lastzero commented on GitHub (Nov 15, 2022): If you're okay with limited search and sorting in exchange for being able to scroll down quickly, then your issue might be a duplicate of that: - #152

deekerman commented

2026-02-20 00:17:04 -05:00

Author

Owner

@dominikholler commented on GitHub (Nov 15, 2022):

Yeah, but it's also a much higher effort and the initial loading would most likely be slower...

I was hoping that the UI framework already would provide some virtual scrolling to implement lazy loading.

output them from memory without requiring database queries that might cause a delay in the user interface.

The improvements during spring, e.g. #2433, were really great in this regard. Since June, the loading times for new thumbnails feels acceptable to me.

Also, with our current team size, it doesn't seem advisable to offer the most complex solution on the market while users are waiting for many other features, e.g. for sharing with other users or batch editing.

Sure, no reason to rush. I hope that the project will get more traction and more contributor in the long run.

If you're okay with limited search and sorting in exchange for being able to scroll down quickly, then your issue might be a duplicate of that:

I am not sure how this will work, since I have no experience with competing software, but I will wait and try.

@dominikholler commented on GitHub (Nov 15, 2022): > Yeah, but it's also a much higher effort and the initial loading would most likely be slower... I was hoping that the UI framework already would provide some virtual scrolling to implement lazy loading. > output them from memory without requiring database queries that might cause a delay in the user interface. The improvements during spring, e.g. #2433, were really great in this regard. Since June, the loading times for new thumbnails feels acceptable to me. > Also, with our current team size, it doesn't seem advisable to offer the most complex solution on the market while users are waiting for many other features, e.g. for sharing with other users or batch editing. Sure, no reason to rush. I hope that the project will get more traction and more contributor in the long run. > If you're okay with limited search and sorting in exchange for being able to scroll down quickly, then your issue might be a duplicate of that: I am not sure how this will work, since I have no experience with competing software, but I will wait and try.

deekerman commented

2026-02-20 00:17:04 -05:00

Author

Owner

@lastzero commented on GitHub (Nov 15, 2022):

We already use virtual scrolling and scrolling is not slow, it's just that we don't have a timeline view yet and you can't scroll to the bottom with one click. See the existing (open and closed) issues for a full discussion history on this topic.

@lastzero commented on GitHub (Nov 15, 2022): We already use virtual scrolling and scrolling is not slow, it's just that we don't have a timeline view yet and you can't scroll to the bottom with one click. See the existing (open and closed) issues for a full discussion history on this topic.

deekerman commented

2026-02-20 00:17:05 -05:00

Author

Owner

@lastzero commented on GitHub (Nov 15, 2022):

Please let us know if the timeline view would be sufficient for you (so we can close this issue as a duplicate) or if you expect instant scrolling for any sort order, because that's the part where it can get really slow without in-memory caching. In the worst case, without a matching index, this forces the database to use temporary tables on disk (depending on the specific order, for example if you're not sorting by time but by something else like similarity).

@lastzero commented on GitHub (Nov 15, 2022): Please let us know if the timeline view would be sufficient for you (so we can close this issue as a duplicate) or if you expect instant scrolling for any sort order, because that's the part where it can get really slow without in-memory caching. In the worst case, without a matching index, this forces the database to use temporary tables on disk (depending on the specific order, for example if you're not sorting by time but by something else like similarity).

deekerman commented

2026-02-20 00:17:05 -05:00

Author

Owner

@dominikholler commented on GitHub (Nov 15, 2022):

Will the timeline view be the default view in albums shared via public link?

@dominikholler commented on GitHub (Nov 15, 2022): Will the timeline view be the default view in albums shared via public link?

deekerman commented

2026-02-20 00:17:06 -05:00

Author

Owner

@lastzero commented on GitHub (Nov 15, 2022):

We can't decide that until we can implement it and do UX testing.

@lastzero commented on GitHub (Nov 15, 2022): We can't decide that until we can implement it and do UX testing.

deekerman commented

2026-02-20 00:17:06 -05:00

Author

Owner

@lastzero commented on GitHub (Nov 15, 2022):

I assume that an album timeline is less valuable because most people will share events that take place at a specific time, such as a birthday or vacation photos. Also, the albums you share shouldn't be so large that it takes you a lot of time to go through them, since most people who get the link don't have time to do that unless they don't have a job or kids. I'm having a hard time seeing the use case for a timeline view in shared albums, but if it's useful and adds value (for a use case I don't see right now), we can certainly introduce it.

@lastzero commented on GitHub (Nov 15, 2022): I assume that an album timeline is less valuable because most people will share events that take place at a specific time, such as a birthday or vacation photos. Also, the albums you share shouldn't be so large that it takes you a lot of time to go through them, since most people who get the link don't have time to do that unless they don't have a job or kids. I'm having a hard time seeing the use case for a timeline view in shared albums, but if it's useful and adds value (for a use case I don't see right now), we can certainly introduce it.

deekerman commented

2026-02-20 00:17:07 -05:00

Author

Owner

@lastzero commented on GitHub (Nov 15, 2022):

We could just load the first 500 pictures when you open an album. This way you can scroll to the end if the album is not bigger. In fact, we already did that... might be 320 pictures... not sure if it was changed.

@lastzero commented on GitHub (Nov 15, 2022): We could just load the first 500 pictures when you open an album. This way you can scroll to the end if the album is not bigger. In fact, we already did that... might be 320 pictures... not sure if it was changed.

deekerman commented

2026-02-20 00:17:07 -05:00

Author

Owner

@dominikholler commented on GitHub (Nov 15, 2022):

I assume that an album timeline is less valuable because most people will share events that take place at a specific time, such as a birthday or vacation photos. Also, the albums you share shouldn't be so large that it takes you a lot of time to go through them, since most people who get the link don't have time to do that unless they don't have a job or kids. I'm having a hard time seeing the use case for a timeline view in shared albums, but if it's useful and adds value (for a use case I don't see right now), we can certainly introduce it.

In my scenario I use the same album to store all photos related to a family event, which happens every year.
I am aware that it is not the expected use, but I also have some albums per person or topic, which were initially created from exif keywords, because it is so easy to share photos via link this way.

We could just load the first 500 pictures when you open an album. This way you can scroll to the end if the album is not bigger. In fact, we already did that... might be 320 pictures... not sure if it was changed.

This might hide the issue, but would not address the real issue behind. This approach might also put stress on the client device.

@dominikholler commented on GitHub (Nov 15, 2022): > I assume that an album timeline is less valuable because most people will share events that take place at a specific time, such as a birthday or vacation photos. Also, the albums you share shouldn't be so large that it takes you a lot of time to go through them, since most people who get the link don't have time to do that unless they don't have a job or kids. I'm having a hard time seeing the use case for a timeline view in shared albums, but if it's useful and adds value (for a use case I don't see right now), we can certainly introduce it. In my scenario I use the same album to store all photos related to a family event, which happens every year. I am aware that it is not the expected use, but I also have some albums per person or topic, which were initially created from exif keywords, because it is so easy to share photos via link this way. > We could just load the first 500 pictures when you open an album. This way you can scroll to the end if the album is not bigger. In fact, we already did that... might be 320 pictures... not sure if it was changed. This might hide the issue, but would not address the real issue behind. This approach might also put stress on the client device.

deekerman commented

2026-02-20 00:17:07 -05:00

Author

Owner

@lastzero commented on GitHub (Nov 15, 2022):

Not really much stress since scrolling is virtual now. Check how many results are loaded in the maps view (places). Can be 50k, but only if it's not some problematic (slow) sort order or search filter without an index that could be used. See explanation above.

@lastzero commented on GitHub (Nov 15, 2022): Not really much stress since scrolling is virtual now. Check how many results are loaded in the maps view (places). Can be 50k, but only if it's not some problematic (slow) sort order or search filter without an index that could be used. See explanation above.

deekerman commented

2026-02-20 00:17:07 -05:00

Author

Owner

@lastzero commented on GitHub (Nov 15, 2022):

The bottom line is that you can't have all the results immediately and have complete freedom in sorting and searching. That would be the Holy Grail of computer science and we can't accept that as a "feature request". At the very least, you need to know how many matching pictures there are, so you know which scroll position should display which selection of pictures. This is more complicated in practice than you might think, since our API returns files, not photos. Depending on the order, they can be stacked differently. Files that are not in a stack are displayed as individual pictures, while stacked files are displayed as one picture.

@lastzero commented on GitHub (Nov 15, 2022): The bottom line is that you can't have all the results immediately and have complete freedom in sorting and searching. That would be the Holy Grail of computer science and we can't accept that as a "feature request". At the very least, you need to know how many matching pictures there are, so you know which scroll position should display which selection of pictures. This is more complicated in practice than you might think, since our API returns files, not photos. Depending on the order, they can be stacked differently. Files that are not in a stack are displayed as individual pictures, while stacked files are displayed as one picture.

deekerman commented

2026-02-20 00:17:07 -05:00

Author

Owner

@dominikholler commented on GitHub (Nov 15, 2022):

At the very least, you need to know how many matching pictures there are, so you know which scroll position should display which selection of pictures. This is more complicated in practice than you might think, since our API returns files, not photos. Depending on the order, they can be stacked differently. Files that are not in a stack are displayed as individual pictures, while stacked files are displayed as one picture.

Might it be possible to have a new API call in the backend to estimate an upper limit depending on these parameters?

@dominikholler commented on GitHub (Nov 15, 2022): > At the very least, you need to know how many matching pictures there are, so you know which scroll position should display which selection of pictures. This is more complicated in practice than you might think, since our API returns files, not photos. Depending on the order, they can be stacked differently. Files that are not in a stack are displayed as individual pictures, while stacked files are displayed as one picture. Might it be possible to have a new API call in the backend to estimate an upper limit depending on these parameters?

deekerman commented

2026-02-20 00:17:08 -05:00

Author

Owner

@lastzero commented on GitHub (Nov 15, 2022):

No, that's not how it works.

@lastzero commented on GitHub (Nov 15, 2022): No, that's not how it works.

deekerman commented

2026-02-20 00:17:08 -05:00

Author

Owner

@lastzero commented on GitHub (Nov 15, 2022):

@heikomat Do you have anything to add?

@lastzero commented on GitHub (Nov 15, 2022): @heikomat Do you have anything to add?

deekerman commented

2026-02-20 00:17:09 -05:00

Author

Owner

@heikomat commented on GitHub (Nov 15, 2022):

@heikomat Do you have anything to add?

Will read through the comments and provide feedback when I'm back home (I'm currently at work).

@heikomat commented on GitHub (Nov 15, 2022): > @heikomat Do you have anything to add? Will read through the comments and provide feedback when I'm back home (I'm currently at work).

deekerman commented

2026-02-20 00:17:09 -05:00

Author

Owner

@heikomat commented on GitHub (Nov 15, 2022):

real virtual scrolling is possible, but difficult.

We'd need API endpoints to return all the results for a search. that would probably be to much data, so maybe we could just return the photo-ids of all results, no details.

If the view we want to virtual scroll in shows pictures only, and absolutely zero details, than that would be enough to have them displayed. if any details at all are used/shown, then we'd need an endpoint to fetch the details of multiple arbitrary photos. Whenever photos come into view, their id's could be used to request all of their details at once to display.

That is the backend part.

In the frontend we have other hurdles to overcome.
Real virtual scrolling is ONLY possible, if the size and position of every single virtual picture can be determined without rendering, or if the size and position of every picture is independent of the others. The easiest way to achieve that would be a view where the size of a picture+details is independent of the content (for example a long description must not wrap around)

In all of our current views (cards, list and mosaic) the position of the next element is dependent on the position and size of the previous element. The list and cards views additionally have text-ui-elements that can increase the parent-elements size, so their text MUST be rendered to know where each element is and what size they have.

The mosaic view is currently the only one where implementing a virtual scroll would be somewhat feasable, because no details are rendered. The other views would require some rewriting, so that the size of a single element is not affected by its content. I'd advise against implementing virtual scroll in a single search-view, because maintining different search views is easier when all of them work kinda the same

Because of that, and because you can already filter down elements in these views, i'd advice to create a completely new view for your use case, with all these info in mind - aka a timeline view.

That would have multiple benefits:

no breaking changes to existing functionality
filters could be ignored for a first version, making the backend changes much easier
When creating such a view, all the details mentioned above can be respected from the very beginning (especially the independent positioning and fixed sizes)

As always, the most important thing missing is someone with time to do that

@heikomat commented on GitHub (Nov 15, 2022): real virtual scrolling is possible, but difficult. We'd need API endpoints to return all the results for a search. that would probably be to much data, so maybe we could just return the photo-ids of all results, no details. If the view we want to virtual scroll in shows pictures only, and absolutely zero details, than that would be enough to have them displayed. if any details at all are used/shown, then we'd need an endpoint to fetch the details of multiple arbitrary photos. Whenever photos come into view, their id's could be used to request all of their details at once to display. That is the backend part. In the frontend we have other hurdles to overcome. Real virtual scrolling is ONLY possible, if the size and position of every single virtual picture can be determined without rendering, or if the size and position of every picture is independent of the others. The easiest way to achieve that would be a view where the size of a picture+details is independent of the content (for example a long description must not wrap around) In all of our current views (cards, list and mosaic) the position of the next element is dependent on the position and size of the previous element. The list and cards views additionally have text-ui-elements that can increase the parent-elements size, so their text MUST be rendered to know where each element is and what size they have. The mosaic view is currently the only one where implementing a virtual scroll would be somewhat feasable, because no details are rendered. The other views would require some rewriting, so that the size of a single element is not affected by its content. I'd advise against implementing virtual scroll in a single search-view, because maintining different search views is easier when all of them work kinda the same Because of that, and because you can already filter down elements in these views, i'd advice to create a completely new view for your use case, with all these info in mind - aka a timeline view. That would have multiple benefits: - no breaking changes to existing functionality - filters could be ignored for a first version, making the backend changes much easier - When creating such a view, all the details mentioned above can be respected from the very beginning (especially the independent positioning and fixed sizes) As always, the most important thing missing is someone with time to do that

deekerman commented

2026-02-20 00:17:09 -05:00

Author

Owner

@heikomat commented on GitHub (Nov 15, 2022):

also, i kinda glossed over the backend part with returning search data for ALL results.
That is doable, but not trivial for the reasons @lastzero mentioned (we'd need enough indices so that searches don't get to slow).
Having a new view without filters would of course help here

@heikomat commented on GitHub (Nov 15, 2022): also, i kinda glossed over the backend part with returning search data for ALL results. That is doable, but not trivial for the reasons @lastzero mentioned (we'd need enough indices so that searches don't get to slow). Having a new view without filters would of course help here

deekerman commented

2026-02-20 00:17:09 -05:00

Author

Owner

@lastzero commented on GitHub (Nov 15, 2022):

Thanks for your detailed feedback! Much appreciated. Clearly shows that is not something we can do in the near future and it won't easily work with the existing views. I'll close this as a duplicate of the timeline view then as it is planned anyway. Once it is done, we can move from there.

@lastzero commented on GitHub (Nov 15, 2022): Thanks for your detailed feedback! Much appreciated. Clearly shows that is not something we can do in the near future and it won't easily work with the existing views. I'll close this as a duplicate of the timeline view then as it is planned anyway. Once it is done, we can move from there.

deekerman commented

2026-02-20 00:17:10 -05:00

Author

Owner

@inthreedee commented on GitHub (Nov 15, 2022):

@lastzero: I assume that an album timeline is less valuable because most people will share events that take place at a specific time, such as a birthday or vacation photos. Also, the albums you share shouldn't be so large that it takes you a lot of time to go through them, since most people who get the link don't have time to do that unless they don't have a job or kids. I'm having a hard time seeing the use case for a timeline view in shared albums, but if it's useful and adds value (for a use case I don't see right now), we can certainly introduce it.

The use case for this would be something like travel albums. I regularly take long trips and share one album per trip/location with family. These albums can accumulate thousands of photos over the course of one trip. I sort them blog style, where the newest photos are added to the top as the trip progresses, but some family members check the album for updates less frequently. They would certainly appreciate a quick way to jump to the last date they know they checked for updates (ie, about three weeks ago).

I assume sharing albums in this way is quite common among travelers. Even at the end of a trip, I would appreciate timeline view for my own albums so I can quickly scroll to a specific date range in that album.

@inthreedee commented on GitHub (Nov 15, 2022): > @lastzero: I assume that an album timeline is less valuable because most people will share events that take place at a specific time, such as a birthday or vacation photos. Also, the albums you share shouldn't be so large that it takes you a lot of time to go through them, since most people who get the link don't have time to do that unless they don't have a job or kids. I'm having a hard time seeing the use case for a timeline view in shared albums, but if it's useful and adds value (for a use case I don't see right now), we can certainly introduce it. The use case for this would be something like travel albums. I regularly take long trips and share one album per trip/location with family. These albums can accumulate thousands of photos over the course of one trip. I sort them blog style, where the newest photos are added to the top as the trip progresses, but some family members check the album for updates less frequently. They would certainly appreciate a quick way to jump to the last date they know they checked for updates (ie, about three weeks ago). I assume sharing albums in this way is quite common among travelers. Even at the end of a trip, I would appreciate timeline view for my own albums so I can quickly scroll to a specific date range in that album.

deekerman commented

2026-02-20 00:17:10 -05:00

Author

Owner

@lastzero commented on GitHub (Nov 16, 2022):

They would certainly appreciate a quick way to jump to the last date they know they checked for updates (ie, about three weeks ago).

This makes sense and is totally doable, but requires a proper UI / UX, not an oversensitive scrollbar with a few rough dates, if any. We should do better than Google.

@lastzero commented on GitHub (Nov 16, 2022): > They would certainly appreciate a quick way to jump to the last date they know they checked for updates (ie, about three weeks ago). This makes sense and is totally doable, but requires a proper UI / UX, not an oversensitive scrollbar with a few rough dates, if any. We should do better than Google.

Rows
Columns

UX: Use virtual scrolling instead of initite scrolling in large collections #1612