TeamNewPipe
Channel view: Tab Bar Unresponsive to Up/Down Swipes
Checklist
(fullfilled)
- [X] I am able to reproduce the bug with the latest version given here: CLICK THIS LINK.
- [X] I made sure that there are no existing issues - open or closed - which I could contribute my information to.
- [X] I have read the FAQ and my problem isn't listed.
- [X] I have taken the time to fill in all the required details. I understand that the bug report will be dismissed otherwise.
- [X] This issue contains only one bug.
- [X] I have read and understood the contribution guidelines.
Affected version
0.27.2 (also present in previous versions)
Steps to reproduce the bug
- On a small to medium size phone screen, open any channel in landscape mode
- Swipe up/down at various places and see what happens.
Expected behavior
The entire sliding screen contents (i. e. everything except notification bar and navigation bar, if any) should respond to swipes and slide up/down accordingly.
Actual behavior
If you happen to start the vertical swipe at the tab bar, the expected vertical sliding of screen contents does not happen.
Screenshots/Screen recordings
Screen recording of swipes performed at various places:
Screen recording of swipes performed at various places.
The grey overlays indicate areas that are unresponsive to vertical swipes. Whilst the top one is there for good reason (it doesn't slide up/down), there should be no such unresponsive spot in the middle of the lower part (which entirely does slide up/down):
Logs
No response
Affected Android/Custom ROM version
Android 9 to 11 (no other versions tested)
Affected device model
diverse
Additional information
Since the red header at its full size uses a large portion of landscape screen estate, it often needs to be collapsed or re-expanded. The tab bar at the lower fringe of the header tends to feel like a natural "handle" for doing so.
It's a shame that's exactly the part that does not respond to vertical swipes at all, which easily leads to a high failure rate in swipe attempts. These swipes only get successful if repeated elsewhere.
The user should not need to pay attention to such peculiarities.
Other apps have such tab bars too. Does swiping on them work for scrolling, or is this unique to Newpipe?
I can't remember having encountered any such tab bar inside a swipe-collapsible header (or drawer) in the 200+ other apps I'm familiar with.
Could you give an example of an app that I could check?
It doesn't have to be exactly like Newpipe's setup. Just having a tab bar and being swipe-able there would do. I don't think tab bars would be swipe-able in any other app. It would make it too easy to swipe when the user intends to switch tabs.
The vast majority of tab bars I have in mind is either
- stationary, or
- only collapsible/expansible by means unrelated to the sliding animation (like in browsers going full screen). I guess that's to keep things simple, because if a tab bar slides in accord with a vertical swipe close by, that swipe is naturally perceived as "moving the tab bar", and it becomes disturbing if it fails to react.
Other than NewPipe, I've yet to find an exeption to this rule.
However, there's a related challenge in messengers if you want vertical swipes to scroll the messages list while also using horizontal swipes to answer (or forward/delete/younameit) the touched message.
In various widespread implementations, that challenge is accepted by reacting to both, vertical or horizontal swipes, each for its distinct meaning.
In various widespread implementations, that challenge is accepted by reacting to both, vertical or horizontal swipes, each for its distinct meaning.
That is indeed the case. Personally, I would still prefer the current implementation:
- There's plenty of valid space that accepts the swipe gesture.
- There's zero chance of accidentally swiping vertically when intending to switch or swipe between tabs.
- And learning not to swipe from the tab bar is a comparatively tiny effort in terms of getting used to the app.
we could make the tab bar respond to vertical swipes if it detects that it can't be scrolled horizontally. this makes the tab bar simple to scroll without making it unresponsive if all of it can be seen at once
Good point. Browser scrolling on mobile also works like that. If you're zoomed into the page slightly and stuck to one edge, the browser automatically interprets your swipe gesture to be along its axis, while if you're in the middle, you have to be much more precise with your gestures.
i meant it more like "if all tabs are visible on‑screen at once, the app knows for sure that the user won't try to scroll them horizontally" but this is also a good way
Thank you both for your comments.
@opusforlife2
learning not to swipe from the tab bar is a comparatively tiny effort
That statement may sound trivial to many, but its applicability varies across abilities and learning types. Some people have a hard time adapting to such peculiarities, or maintaining the unusual attention or accuracy effort continuously required to compensate, both of which may lead to a needlessly frustrating UX.
@sosasees
i meant it more like "if all tabs are visible on‑screen at once, the app knows for sure that the user won't try to scroll them horizontally" but this is also a good way
Whilst that conditional solution would constitute an improvement over the current situation in a number of cases, I don't think we need to focus on safeguards here all that much, for the following reasons:
-
The two worst possible outcomes of any tab bar swipe - i. e. switching to another tab or toggling header expansion status unintentionally - are fully reversible and in fact, so far from "dangerous" it makes no sense to subjugate everything else to absolutely avoiding them.
-
You'd have to be off the desired direction by no less than 45° to end up triggering the other.
-
The fact that swipe input directions can freely coexist is also demonstrated in this very app already, namely by the tab body (i. e. comments/related/description). The tab body accepts both, horizontal swipes (to switch tab) and vertical swipes (to collapse/expand header(*)), just fine.
Re 3.: Couldn't the tab bar basically use the same logic?
(*) Note:
On lengthy landscape screens, the tab body doesn't really attract vertical swipes, as the fully expanded header reduces it to a thin line that is furthermore populated with possibly interfering icons. This makes the lower end of the header - and most prominently, the tab bar - even more appealing as the natural entry point to pull it up.Edit:
Cleaned up a bit.