Back button behaviour with no backstack

[opusforlife2]

Checklist

• I checked, but didn't find any duplicates of this issue in the repo.
• I have read the contribution guidelines given at https://github.com/TeamNewPipe/NewPipe/blob/HEAD/.github/CONTRIBUTING.md.
• This issue contains only one feature request. I will open one issue for every feature I want to request.

Describe the feature you want

The OS Back button should close Video Details instead of minimizing to the mini player if:

1. It is the last video in the backstack (or the only video the user opened).
2. The video is not open in the embedded player.

Is your feature request related to a problem? Please describe it

Coming from 0.19.8, a user would expect the Back button to close Video Details instead of minimizing it. This behaviour has naturally changed so that a video playing in the embedded player isn't accidentally stopped. But if the user has just opened Video Details, then there is nothing to preserve. So a Back button tap should close Video Details instead.

How will you/everyone benefit from this feature?

More familiar navigation with the Back button.

Problem

If you play in popup or background players, closing the Video Details (by swiping down and closing the mini player) currently closes them too. However, if you back out of the app, then open it again, you can see that the mini player is gone but playback continues. This implies that background/popup playback isn't tied to the mini player, so that behaviour could be changed.

[TheAssassin]

This issue is the result of a discussion on IRC. I mentioned that it makes no sense to create a mini player in case a video isn't playing. This behavior is unexpected and counterintuitive. Instead, the mini player should only be created when leaving a video details page while the video is playing. Example cases in which this would make sense:

• returning to search results from video details (-> mini player in search results)
• clicking a suggested video in the video details (-> mini player in new video details, stopped as soon as the new video is playing)

The latter would be a new addition, but I think it would be nice to have. Right now, the switch from video details page 1 to video details page 2 is quite broken; the old video keeps playing until the new details are loaded, if the latter fails you get a broken page with "Network error", the old video is still playing and the back button does not bring you to the old video but the search result.

Also, something that makes absolutely no sense to me is this swiping up and down. I would suggest to get rid of this stuff. It's anything but intuitive. I was told that since the video details swipe up when you open them, it should be "obvious" that you can also swipe down to "minimize", but the opposite is true. To me, a simple history of activities switches would be more intuitive.

It seems to me like the "activity history stack" (I hope you know what I mean) management has become too complex and fragile. I'd like to suggest to reduce its complexity again, make it less complicated and more robust again.

Oh, by the way, I think fixing the mini player creation while a video is not playing is going to fix some of the central points of the critics of the new release (who, by the way, have been very annoying as they started to abuse our comments system and have been yelling at us for no reason instead of seeking a constructive dialog...).

[avently]

I will not describe my feelings while I was reading this. You probably can imagine. I would like to set 21 dislikes if I could.

[opusforlife2]

:O

[opusforlife2]

@avently The mini player is useful for keeping the backstack and to browse, but if the stack size is zero and the video isn't playing, what's the harm in closing video details?

[avently]

@opusforlife2 do you know something about unexpected behavior? Or about unpredictable behavior? Or about complexity of logic of some elements and their behavior?

[opusforlife2]

I can certainly imagine it, looking at VideoDetailFragment.java.

[TheAssassin]

@avently please focus on the topic. If you can contribute sober arguments, that would be highly preferred. Most comments so far are basically off topic and of little relevance. (@opusforlife2, this also goes for your last comments.)

Regarding unexpected behavior: the entire point is that what is implemented now is considered unexpected/unpredictable behavior, and therefore leads to a bad UX. This "we swipe up to inform the user that they can swipe down" is not nearly as obvious as it seems. In fact, I'd just drop that.

We do not want to remove that mini player. There are such voices, but many they are being aggressive and spam our comments section etc.
Instead of following this abusive scheme, this issue tries to explain what may be problematic and suggests how it could be fixed.

[avently]

@TheAssassin
now every video you open makes the mini player to appear.
Every back press that happens without history makes the mini player collapsed.

So the behavior is completely expected. You always know that you will never lose current video if you press back once - the video will always be at the bottom in the mini player.

Your and topic's suggestions makes the opposite situation: whenever I press Back I should be aware of existing history (which is nearly impossible) and should be ok to lose current video I opened for a reason. This makes the situation harder to use without thinking and memorizing. This completely unexpected/unpredictable (choose your word).

[opusforlife2]

You always know that you will never lose current video if you press back once - the video will always be at the bottom in the mini player.

@avently And that's fine. The only addition here is that if the thumbnail is visible (player not opened, no notification) then the Back button should close the fragment. No video is playing, nothing is lost.

Every back press that happens without history makes the mini player collapsed.

whenever I press Back I should be aware of existing history (which is nearly impossible)

Those are contradictory statements. How does the mini player know when to collapse if it isn't checking the backstack?

[TheAssassin]

Likely a duplicate: #4597

It's not just us who dislike this behavior. I think there should also be an option to turn off the mini player entirely, but if the back button behavior is fixed, most people will be happy again.

[avently]

@TheAssassin

most people will be happy again

Most if the people are happy now and will not be happy if something changes with back button behavior.

Those who don't want to have a history exist can make a setting for such behavior
Those who don't like mini player can make the same thing (it's ok for Android TV but NOT ok for other devices since it's a main thing to control all players).

[TheAssassin]

As far as I can see, the feedback is very mixed. Even if you assume that the majority of the users is satisfied, there's a lot of critics of the mini player.

As far as I can tell, the criticism focuses on the back button behavior, something that can be fixed easily and that doesn't require disabling the entire feature.

Being able to disable the mini player entirely would, as far as I can see, not require a lot of work either. But this issue is about the back button behavior.

[Stypox]

Closing in favour of #4479 as there is more discussion there

[opusforlife2]

@Stypox Not the same issue. #4479 is about completely removing backstack navigation with the Back button. This one is only about a specific case which Assassin and I think will solve most people's issue with the new behaviour, without completely changing the functionality again. Sort of an 80:20 Pareto principle thing.

[Stypox]

Yes, but they are just two different solutions for the same problem, so they have to be discussed together, don't they?

[opusforlife2]

It becomes very confusing to propose and discuss multiple solutions to a problem in one issue. You have to trawl through lots of comments to get the gist, and it's worse for those trying to participate, who have to keep track of multiple discussion threads. Gitlab is much better in this respect, because it does have comment threads.

Since Github doesn't, I think it's better to have separate issues. This way, if one solution is favoured over another, then one issue can be closed, while the other stays open until a PR is sent.