You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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
The content you are editing has changed. Please copy your edits and refresh the page.
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.
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.
Description
Acceptance criteria
UX acceptance criteria
UI acceptance criteria
Navigating to this screen
There are several entry points to see a media full screen.
From the gallery
From the timeline
Same behavior:
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:
Notes
Size estimate
M
Dependencies
Out of scope
Open questions
Questions
Subtasks
Android
iOS
Rust
Other
The text was updated successfully, but these errors were encountered: