So i just bought Asus rog phone 6d and im extremely bothered by the lack of the back ,home and whatewer is the 3 one called buttons on the news androids. Is this something you all got used to with time or does this still bother you( IT really fells much less intuitive compared to the old 3 buttons ,alghtough preferably i would love to have both since the back gesture seems kinda usefull )?
I prefer gestures. But if you like buttons just go to settings and turn them on.
I’m so used to gestures I can barely use a phone with button navigation. When I have to help my parents/grandparents with their smartphones I take longer just because they use buttons lol.
Also the 3 button navigation is not gone afaik. All OEMs I’ve used have it buried in the settings somewhere.
I think there’s a setting to bring back the buttons, if you want that.
Settings -> System -> Gestures -> System navigation
Just upgraded my phone and found this setting myself. Thank god you can change it back to the 3 buttons.
Definitely try gestures.
Being able to “go back” from a gentle swipe at any height is a blessing for the small hand. The rest of options are really, really intuitive.
Unless you have some mobility issues, you’ll never come back after a week.
You just made me try it out, it’s… Interesting. Hard to get used to, but I like the extra screen space.
i’ve no mobility issues, but i can’t stand that back gesture. it interferes with the ability to open drawers; and i can’t spam it quickly to get out of a “deep” page in an app
gestures do have pros (for instance, the ability to hold and scroll through recents) but the back gesture just seems straight up worse to me
it interferes with the ability to open drawers
It’s funny, but I tried looking around the old Material Design guidelines and I haven’t come across any mention of swiping to open a drawer. I know it was on Android Developers, but it appears that from the point of view of the design team, it wasn’t really “officially” recommended?
Regardless, Discord, IMO, offers a better implementation for side sheets, as the metaphor isn’t that you drag something from beyond the screen into view, you just drag the view itself to the side and that reveals the side sheet. And it works in the middle of the screen so it doesn’t interfere with the system gestures
It’s funny, but I tried looking around the old Material Design guidelines and I haven’t come across any mention of swiping to open a drawer. I know it was on Android Developers, but it appears that from the point of view of the design team, it wasn’t really “officially” recommended?
i found this: https://web.archive.org/web/20140110123608/developer.android.com/design/patterns/navigation-drawer.html (alternative link in case archive.org is down) - i presume they removed it from the old spec when they introduced the gesture navigation, so people don’t use it because it interferes with the gestures?wait never mind i misread this paragraph. i presume it wasn’t in the design spec as a) it’s an interaction behaviour, not a visual design behaviour, and b) it was also a thing in holo design (& older[?]), so they didn’t consider it part of the “material design spec”?
Regardless, Discord, IMO, offers a better implementation for side sheets, as the metaphor isn’t that you drag something from beyond the screen into view, you just drag the view itself to the side and that reveals the side sheet. And it works in the middle of the screen so it doesn’t interfere with the system gestures
it’s not a bad idea if you’re working around gestures, but it means you can’t have something where you swipe between tabs when not from the edge, and get the drawer when from the edge
or, for example, swiping to reply/forward in a messaging app, or upvote/downvote on a lemmy client
(also, subjectively, it’s kind of a bit ugly)
i presume it wasn’t in the design spec as a) it’s an interaction behaviour, not a visual design behaviour, and b) it was also a thing in holo design (& older[?]), so they didn’t consider it part of the “material design spec”?
Yesn’t. Material Design 1 and 2 guidelines have a bunch of sections regarding interaction, way more than M3 (although M3 guidelines aren’t “finished” yet), but they lack a section regarding that gesture in particular.
Like, M1 guidelines mention swiping on content to swap tabs, heck, you can even find the same on the current Material Design 3 guidelines
I think it was a conscious design decision from the Material Design team to not use that gesture in particular? Because it isn’t due to conflict with other components, in the tab guidelines they call attention to be careful when the content itself is swipeable.
it’s not a bad idea if you’re working around gestures, but it means you can’t have something where you swipe between tabs when not from the edge, and get the drawer when from the edge
or, for example, swiping to reply/forward in a messaging app, or upvote/downvote on a lemmy client
(also, subjectively, it’s kind of a bit ugly)
I mean, you already can’t have certain gestures with other gestures. Like you can’t (or shouldn’t) have swipe on a card to upvote at the same time you have swipe content to change tabs. I’d argue this restriction is better for the user because with discord’s implementation it is very clear what the trigger area is, because the entire view is the trigger area.
Yesn’t. Material Design 1 and 2 guidelines have a bunch of sections regarding interaction, way more than M3 (although M3 guidelines aren’t “finished” yet), but they lack a section regarding that gesture in particular.
Like, M1 guidelines mention swiping on content to swap tabs, heck, you can even find the same on the current Material Design 3 guidelines
fair enough. although in that specific example you could construe that as a warning of unforeseen conflicts, rather than a recommendation to implement swipe gestures. like, it doesn’t say “use swipe gestures for navigating between tabs”, it just mentions it as though it’s something the dev should already know (in the m1 guidelines, not m3 i guess)
I think it was a conscious design decision from the Material Design team to not use that gesture in particular? Because it isn’t due to conflict with other components, in the tab guidelines they call attention to be careful when the content itself is swipeable.
possibly? although i still maintain it’s likely that they saw it as part of holo, so there was no need to respecify it for md? the same that they don’t specify that you can scroll down to move the content field? especially as all of google’s own apps supported that gesture
I mean, you already can’t have certain gestures with other gestures. Like you can’t (or shouldn’t) have swipe on a card to upvote at the same time you have swipe content to change tabs.
yes; but my point is that it reduces the available actions for no discernible benefit. it’s not like they’ve added some spare buttons in the old place, like maybe bringing back the old universal menu button.
I’d argue this restriction is better for the user because with discord’s implementation it is very clear what the trigger area is, because the entire view is the trigger area.
maybe? i’m not sure about that though, as the hamburger button is on that side, and the drawer appears there; and i’d say “the edge from whence the drawer appears” is a lot clearer than “just any old fucking where”, but maybe that’s me
Alright, but wasn’t the tab gesture also available on the holo era?
yes; but my point is that it reduces the available actions for no discernible benefit. it’s not like they’ve added some spare buttons in the old place, like maybe bringing back the old universal menu button.
The benefit is less conflicting gesture triggers occupying the same area. A swipeable card/list-item has the entire card/list-card as the visible trigger. A Tab has the entire content as the trigger area. The Navigation Drawer gesture is an invisible area that can be placed on top of the visible triggers of other components.
maybe? i’m not sure about that though, as the hamburger button is on that side, and the drawer appears there; and i’d say “the edge from whence the drawer appears” is a lot clearer than “just any old fucking where”, but maybe that’s me
The issue is that the hamburger button is not the only button that can appear in that that place, a back button is common on that same area. The trigger area isn’t the width of a button, but the width of a very specific button, and worse, it extends far beyond the edges of the button and shares the same height as the screen.
I do see your point that “anywhere” isn’t an improvement, but I have to disagree, as that is fundamentally the same gesture to swap tabs, and you can predict the area trigger as being “just any old fucking where”.
Alright, but wasn’t the tab gesture also available on the holo era?
honestly i couldn’t say with absolute certainty, but i don’t think so?
The benefit is less conflicting gesture triggers occupying the same area. A swipeable card/list-item has the entire card/list-card as the visible trigger. A Tab has the entire content as the trigger area. The Navigation Drawer gesture is an invisible area that can be placed on top of the visible triggers of other components.
i’m not entirely sure that i’m following this correctly, but assuming i am: it’s the same number of gesture triggers
- old design
- swipe from edge: nav drawer
- swipe from anywhere: switch tabs (or whatever)
- tap back btn: navigate back
- your design
- swipe from edge: navigate back
- swipe from anywhere: nav drawer
- missing input: switch tabs (or whatever)
The issue is that the hamburger button is not the only button that can appear in that that place, a back button is common on that same area.
that’s a fair criticism
The trigger area isn’t the width of a button, but the width of a very specific button, and worse, it extends far beyond the edges of the button and shares the same height as the screen.
this i’m also not sure what you’re saying? it seems like a good thing to me - it takes up no space, and can be accessed from any height
I do see your point that “anywhere” isn’t an improvement, but I have to disagree, as that is fundamentally the same gesture to swap tabs, and you can predict the area trigger as being “just any old fucking where”.
i wasn’t strictly saying that, i was more refuting what i thought your point was: that “it’s not a discoverable gesture unless it’s tutorialised, because most people won’t randomly swipe in from the edge”; which i think in most instances is a very fair point, but in this specific instance i think it is discoverable because the drawer pulls in from the side. (source: i discovered it without a tutorial, or reading the md docs)
- old design
I used a phone without gestures the other day and had such a hard time with it, it was crazy how unintuitive the buttons felt in comparison to the gestures!
The simple fact is, neither is actually all that intuitive, they’re learned, but gestures definitely get to be very convenient and a much quicker form of navigation.
I would definitely not want to go back.
I remember it is especially intuitive when it goes full screen in landscape mode, like I think it needs one swipe and then choosing the needed button (it is better to swipe twice) or deal with the space occupied by the Android buttons on the right edge of your screen… iugh.
I jumped to the Android bandwagon later (2020) and as I came from iOS I never used them, but I tried them anyway… And they are not for me…
Fuck gestures! And people, can’t you understand other people like buttons instead of gestures? If you don’t have an answer to what OP asked, why bother to “give advice”?
