Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Improve picture viewer opening animation UX #19163

Open
HarHarLinks opened this issue Sep 24, 2021 · 4 comments
Open

Improve picture viewer opening animation UX #19163

HarHarLinks opened this issue Sep 24, 2021 · 4 comments
Labels
A-Media O-Uncommon Most users are unlikely to come across this or unexpected workflow S-Tolerable Low/no impact on users T-Enhancement

Comments

@HarHarLinks
Copy link

Your use case

What would you like to do?

Continuaton of an issue raised in #18186.

The first time clicking on an image with this, the transition does not work properly: noticeably the screen first darkens, only then the transformation happens. This is also on current nightly and presumably stable, probably due to the full size loading only when clicked on. On subsequent tries, the darkening and transformation happen simultaneously, resulting in what feels like a much snappier UX.

element-pictureviewer-delay.mp4

Demonstrated in the video is pretty much the optimal case of non-cached full resolution. The delay described above is minimal due to a limited file size of 1MB or so and the origin homeserver presumably being quite beefy. There are instances for me where images load slow enough that I am able to click them while only the blurhashed image is shown and the full resolution may take dozens of seconds to load, although that is the extreme case.

Why would you like to do it?

This is certainly a common case since 1. why would you commonly open the full size repeatedly and 2. while some hs may be faster than mine, it will never be instant.

How would you like to achieve it?

To solve this, I propose to use the thumbnail as a placeholder and replace it by the full size when that has (async) downloaded. Same could be applied to blurhash if not even the thumbnail has loaded (or if there isn't any). Perhaps combined with this, a loading indicator is needed so the blown-up thumbnail is not mistaken for full quality.

Have you considered any alternatives?

when clicking the image, don't do anything except show a loading indicator on the thumbnail in the timeline while the full resolution is fetched. once it is downloaded, perform the animation and open in viewer.

I don't like this alternative as much, as it takes away control: I might scroll around and suddenly a minute later the image viewer pops up.

Additional context

original issue: #18186
issue about closing animation: #19134

@SimonBrandner
Copy link
Contributor

Hmm, I am rarely able to repro :(

@SimonBrandner SimonBrandner added A-Media O-Uncommon Most users are unlikely to come across this or unexpected workflow S-Tolerable Low/no impact on users labels Sep 24, 2021
@SimonBrandner
Copy link
Contributor

Does this always happen to you? What HS are you using?

@SimonBrandner SimonBrandner added the X-Needs-Info This issue is blocked awaiting information from the reporter label Sep 24, 2021
@HarHarLinks
Copy link
Author

HarHarLinks commented Sep 24, 2021

Yes, happens almost always, including URL preview images. Using my own slightly underpowered homeserver.
Usually the delay is about so long that the effective animation is dim first, enlarge second, i.e. sequential instead of parallel just as seen above. Not necessarily bad UX, just seems like an overly slow animation. It is only when opening the same (now cached) image a second time, that it feels much faster suddenly.

@SimonBrandner SimonBrandner removed the X-Needs-Info This issue is blocked awaiting information from the reporter label Oct 3, 2021
@HarHarLinks
Copy link
Author

Also when opening a space's image on the space explore page, and the image's full resolution is higher than the element window has space, the current animation is from 1:1 resolution to fit screen. In this case there should be no zoom animation imo.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-Media O-Uncommon Most users are unlikely to come across this or unexpected workflow S-Tolerable Low/no impact on users T-Enhancement
Projects
None yet
Development

No branches or pull requests

2 participants