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

[Story] Attachment viewer: navigation by swiping left and right #2698

Open
2 of 3 tasks
bmarty opened this issue Jan 20, 2025 · 3 comments
Open
2 of 3 tasks

[Story] Attachment viewer: navigation by swiping left and right #2698

bmarty opened this issue Jan 20, 2025 · 3 comments

Comments

@bmarty
Copy link
Member

bmarty commented Jan 20, 2025

Description

  • As a user
  • I want to be able to navigate to the previous and the next item when viewing a attachment full screen
  • So that I can quickly navigate to all the attachments without going back to the gallery or to the room timeline.

Acceptance criteria

UX acceptance criteria

  • When the media viewer is displayed, user can swipe left to see the previous media (may need to confirm the direction for RTL language)
  • When the media viewer is displayed, user can swipe right to see the next media (may need to confirm the direction for RTL language)
  • When a pagination is needed, a loader is displayed to indicate that more media are being loaded- When the media viewer is displaying the last media of the room (the most recent one), it's not possible to swipe right. We may want to display a special screen when a forward pagination request reach the end of the room (live)
  • When the media viewer is displaying the first media of the room (the older one), it's not possible to swipe left. We may want to display a special screen when a forward pagination request reach the end of the room (live)
  • When a video or an audio file is playing, swiping left or right pauses the playback. Limitation: playback state can be lost if the user swipe more, which means that if the user goes back to the previously playing media, the playback state will be reset.
  • The media viewer behavior does not change, and all the actions related to the media are correctly applied to the currently displayed media.

UI acceptance criteria

  • When the user is swiping, the top bar stays fix (i.e. does not swipe).
  • The top bar is showing the info of the currently displayed media

Navigating to this screen

There are several entry points to see a media full screen.

From the gallery

  • When an image or a video is clicked, it will be possible to swipe to see other images and videos of the room. Files, audio and voice messages will not be visible.
  • When a file, an audio file or a voice message is clicked, it will be possible to swipe to see other files, audio and voice messages of the room. Images and videos will not be visible

From the timeline

Same behavior:

  • When an image or a video is clicked, it will be possible to swipe to see other images and videos of the room. Files, audio and voice messages will not be visible.
  • When a file, an audio file or a voice message is clicked, it will be possible to swipe to see other files, audio and voice messages of the room. Images and videos will not be visible

Detached timeline

When user click on a permalink, the timeline will be focused on an EventId (i.e. not live). User can then open a media.
We will need an SDK update to be able to load a media timeline from a specific EventId.

Then the behavior of the media viewer regarding the swiping will stay the same.

Design request

We need some design for the following case:

  • The application is loading more media from the past (back pagination): a centered loader may be sufficient, do we need to display something in the top bar?
  • The application is loading more media in the future (forward pagination): a centered loader may be sufficient, do we need to display something in the top bar?
  • There is no more media to load from the past (beginning of the room). We may need to render something to replace a loading state.
  • There is no more media to load in the future (end of the room - aka live). We may need to render something to replace a loading state.

Notes

  • It's worth noting that when the event cache will be available, the performance will be better. But no event cache does not mean that we cannot work on this feature.

Size estimate

M

Dependencies

  • None

Out of scope

  • Nothing

Open questions

Questions

Preview Give feedback
No tasks being tracked yet.

Subtasks

Android

Preview Give feedback
  1. T-Task

iOS

Preview Give feedback
  1. T-Task
    pixlwave

Rust

Preview Give feedback

Other

Preview Give feedback
No tasks being tracked yet.
@americanrefugee
Copy link

Here are the requested designs for iOS and Android

  1. User tries to swipe left/right faster than the app can pre-fetch any available media > Show spinner in center and "Loading more..." in header
  2. No more media is found > Return to the first/last media item with a toast that says "No more media to show"

@bmarty
Copy link
Member Author

bmarty commented Jan 30, 2025

Question for the Rust team (@bnjbvr maybe?):
When we are on a focused timeline (after opening a permalink), and we click on a image, I have noticed that the timeline we create focused on this image for the media viewer is taking several seconds to return. Would it be possible to use the same timeline in this case? I've been told that this is what is done for the live timeline.
It looks like the already known event are fetched again from the server, which is not efficient.

@bnjbvr
Copy link
Member

bnjbvr commented Jan 30, 2025

@bmarty

A focused timeline does not use the event cache, by design. We may not have access to the target event in the cache, and as such, we might need to do a /context query to fetch it from the server. But then, inserting it back into the linearized timeline known to the cache is impossible, lacking a stable ordering of events. We didn't want to start storing disconnected components of the timeline, and try to use heuristics later to reconcile them with cached timeline chunks, as this is error-prone (especially because of the now unfortunately well-known multiple event orderings observed through /sync and other endpoints).

Getting a copy of a timeline with a different filter might be sufficient for what you're asking though, and seems more doable, so it's worth experimenting with.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants