Horizontal-Swipe Title for Prev/Next

[GfEW]

Checklist

(fulfilled)

• I made sure that there are no existing issues - open or closed - which I could contribute my information to.
• I have read the FAQ and my problem isn't listed.
• I'm aware that this is a request for NewPipe itself and that requests for adding a new service need to be made at NewPipeExtractor.
• I have taken the time to fill in all the required details. I understand that the feature request will be dismissed otherwise.
• This issue contains only one feature request.
• I have read and understood the contribution guidelines.

Feature description

The single medium (audio or video) view consists of four parts(*):

1. the actual media player
2. the metadata and action area (title, channel, view count, add to playlist, share, etc.)
3. the tab body (comments, related, details) of the current tab
4. the tab bar with the three tab handles.

As of 0.27.2, horizontal swipes in the tab body (3.) already slide to the prev/next tab.

I'm suggesting to also allow horizontal swipes in the metadata and action area (2.), to slide to the previous/next medium wherever these terms make sense:

• if you opened the single medium view from history, previous/next are defined by history order
• if from a playlist, prev/next are defined by that playlist order
• if from a channel, prev/next are defined by that channel order (upload times)
• if from a search result, prev/next are defined by the order of search results
• etc.

Note that I'm not asking to tweak any of those existing orders but simply to use them as the base to determine which medium is "previous" or "next" to the current one.

Only if you opened the single medium view from "related" or via external link, there is no ordered media sequence but the current video alone, so swipes wouldn't switch to anywhere else. The same holds for the start/end of the sequence, e. g. there is no "next" item after the last in history.

Here's a mockup screencast to get you the idea:

Screenrecording20241001_225438.mp4

(Unlike in the mockup, the tab bar shouldn't move at all. If you e. g. are seeing the comments of video A, then swipe sidewise to video B, the comments tab simply remains selected, whilst its contents is updated so it now shows the comments of video B.)

Why do you want this feature?

Whether you like to quickly zap through a playlist or e. g. to find a specific scene in a lengthy search results list - switching to the previous/next medium is a very common need.

As of 0.27.2, it's unnecessarily difficult in NewPipe, as the UI only provides a devious

route ...

1. memorize the title of the current medium
2. press Back to leave the current medium view
3. be prepared that another single medium view might show up from backstack, and in that case, press Back again
4. in the media listing (be it history, search results, channel, playlist etc.) where you most recently tapped a medium to open it, spot the title you've memorized in step 1.
5. tap the medium before/after that, to open it.

By allowing horizontal swipes to switch to prev/next, this workflow can be massively improved and actually become a smooth experience.

Additional information

I think that, if horizontal swipes were also implemented in the actual media player area (1.), they should scan through the current medium (like they do in various standalone players); every other meaning would be confusing. Therefore, the suggested swipes to go prev/next are expressly limited to the metadata and action area (2.).

(*)

Please forgive the clumsy terms "single medium view", "metadata and action area" etc. - I don't know their official names. Hope you get what I mean by them, but otherwise, please do ask and I'm happy to clarify.

[opusforlife2]

and actually become a smooth experience.

This will likely never be the case. Your mockup shows everything preloaded. In reality, if you open one video page, and then swipe to the next one, you'll have to wait for several seconds (if your net is really good) for the page to load anyway.

It's only once you've loaded several such video pages that you can smoothly swipe back and forth between them.

[GfEW]

and actually become a smooth experience.

This will likely never be the case. Your mockup shows everything preloaded.

I've considered a more elaborate mockup to show realistic loading times, as well as video playback and pause. Due to time constraints, I hope this simple one suffices to illustrate the idea.

Just to be clear: By the term "smooth", I don't mean total absence of loading delays but smoothness in terms of overall interaction. Of course, transitions will still involve waiting moments in practice. But you'll get there with a swipe, as opposed to the devious route you currently have to take before even starting to load the video.

It's only once you've loaded several such video pages that you can smoothly swipe back and forth between them.

Actually, there are valid use cases of preloading two or three media e. g. in a local playlist, like when cross-comparing certain scenes, or checking back and forth between a reaction with the original, or between two different reactions to the same scenes.

However, the main point of the requested feature is to cut short the convoluted UI route currently imposed on everyone who frequently wants to see previous/next media, so they get accessible via simple swipes instead.

[opusforlife2]

At best, I suppose we could have the previous and next pages preload after the current page is finished loading. That will allow for at least a rudimentary swipe mechanism to exist.

[GfEW]

I'm getting aware this is actually two separate issues packed in one:

1. Swipe to go next/prev (main feature)
2. Preload neighbors to make swiping smoother (subordinate feature)

Whilst 2. is based on 1. being implemented, the opposite is not true - 1. is self-contained.

Even with no preloading whatsoever, swipe navigation already is the essential UI level improvement this feature request is all about.

Sorry if, by also discussing preloading here (the appeal of making interaction even quicker beyond swipes), I've blurred topics a bit. I guess I better move preloading to a separate, conditional feature request (dependent on this one) to clear up the confusion, and create a more realistic, less sidetrack-prone mockup indeed, but that takes time.

[opusforlife2]

No need to bother with that for now. If and when this gets taken up, the discussion about preloading will happen anyway.