88
is anyone else bothered by the lack of the 3 buttons at the bottom
(programming.dev)
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
this post was submitted on 13 Aug 2023
88 points (77.8% liked)
Android
17644 readers
92 users here now
The new home of /r/Android on Lemmy and the Fediverse!
Android news, reviews, tips, and discussions about rooting, tutorials, and apps.
🔗Universal Link: !android@lemdro.id
💡Content Philosophy:
Content which benefits the community (news, rumours, and discussions) is generally allowed and is valued over content which benefits only the individual (technical questions, help buying/selling, rants, self-promotion, etc.) which will be removed if it's in violation of the rules.
Support, technical, or app related questions belong in: !askandroid@lemdro.id
For fresh communities, lemmy apps, and instance updates: !lemdroid@lemdro.id
📰Our communities below
Rules
-
Stay on topic: All posts should be related to the Android OS or ecosystem.
-
No support questions, recommendation requests, rants, or bug reports: Posts must benefit the community rather than the individual. Please post to !askandroid@lemdro.id.
-
Describe images/videos, no memes: Please include a text description when sharing images or videos. Post memes to !androidmemes@lemdro.id.
-
No self-promotion spam: Active community members can post their apps if they answer any questions in the comments. Please do not post links to your own website, YouTube, blog content, or communities.
-
No reposts or rehosted content: Share only the original source of an article, unless it's not available in English or requires logging in (like Twitter). Avoid reposting the same topic from other sources.
-
No editorializing titles: You can add the author or website's name if helpful, but keep article titles unchanged.
-
No piracy or unverified APKs: Do not share links or direct people to pirated content or unverified APKs, which may contain malicious code.
-
No unauthorized polls, bots, or giveaways: Do not create polls, use bots, or organize giveaways without first contacting mods for approval.
-
No offensive or low-effort content: Don't post offensive or unhelpful content. Keep it civil and friendly!
-
No affiliate links: Posting affiliate links is not allowed.
Quick Links
Our Communities
- !askandroid@lemdro.id
- !androidmemes@lemdro.id
- !techkit@lemdro.id
- !google@lemdro.id
- !nothing@lemdro.id
- !googlepixel@lemdro.id
- !xiaomi@lemdro.id
- !sony@lemdro.id
- !samsung@lemdro.id
- !galaxywatch@lemdro.id
- !oneplus@lemdro.id
- !motorola@lemdro.id
- !meta@lemdro.id
- !apple@lemdro.id
- !microsoft@lemdro.id
- !chatgpt@lemdro.id
- !bing@lemdro.id
- !reddit@lemdro.id
Lemmy App List
Chat and More
founded 1 year ago
MODERATORS
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)
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
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.
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?
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.
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".
honestly i couldn't say with absolute certainty, but i don't think so?
i'm not entirely sure that i'm following this correctly, but assuming i am: it's the same number of gesture triggers
that's a fair criticism
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 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)
I'm not talking about the number of gesture triggers or their discoverability, but rather, their predictability. System Gestures are always on, no matter the screen, the area is defined despite being "invisible". The way it is on top of whatever app is currently on screen makes sense.
A swipe to change tab has the entire content as a "visible trigger", i.e. the gesture will work on any area that is visibly part of the content.
A swipe on cards/list-item (to reply, delete, etc...) has the card/list-item as the trigger area, it is visibly defined.
A swipe from the edge to open a side sheet has a trigger area that extends far beyond the confines of the Hamburger Icon. And if any of the other gestures are present, then the edge gesture conflicts with them. Even worse is, the gesture with no visible area is "on top" of the others that have a predictable area, despite the fact that they exist on the "same plane".
System gestures also don't have a visible area, but again, they work regardless of the current app, and are "on top" of apps. So despite the fact that they also conflict with the other gestures, because they are drawn on top, it doesn't feel as wrong as the side sheet edge gesture.
Like, with the edge gesture to open a drawer, you need to keep the app elements in mind as if there is some physical elevation inside the app. The edge gesture is on top of the tab gesture, and things like that.
With the system gesture, the elevation itself is between the app and the system. Almost like if the system gestures are a glass panel on top of the app. It is a predictable rule.
ah, i see. in that case i can't say i agree. i'd say that it's fairly predictable - i can't think of a single app with a drawer in which it didn't work, until they introduced gesture navigation and broke it.
with a back button, it's always in the same corner; with a back gesture what happens when the phone is rotated? (i genuinely don't know) does it stay on the side it was on, or does it move so it's now on the left? wouldn't that make it very hard to reach with one hand?
yes, but it doesn't extend beyond the confines of the drawer. in my head it's more like the drawer is always there, and you can trigger it with the hamburger, or "drag" it into view manually
not really - one is from the edge, one is not. it doesn't conflict any more than scrolling up conflicts with the new home gesture (and is far less often accidentally triggered)
that is reasonable. i can't say anything to refute that
i mean yeah, that's the very point of material design. the whole spec goes on and on about the information conveyed by implied depth
but even before that, drawers and menus usually had some type of drop shadow to imply depth (practical skeuomorphism at work^!^)
yeah, i subjectively don't like that. with nav buttons and a status bar, that's where the system was and that's how you interact with it. now it's an invisible layer over the whole screen that's not predictable at all; as a swipe right goes back, but a diagonal swipe does something else. that's two gestures on the same metaphorical "layer", one a system action and one an app action. weird.
I made it implicit, but forgot to say out loud: While system gestures makes the open-drawer-edge-gesture worse to the point of unusable, I think that looking back it wasn't that good to begin with. Which is why I think Material Design never officially supported it in the first place, way before gesture navigation was a thing.
The pill-thingy is anchored to the bottom of the screen, so basically it always point to the ground, the back gesture is on the side. It isn't uncomfortable because it matches the easiest point to reach, which is the side of the screen relative to the user, not the device. This very old image shows the most reachable areas of a screen:
https://miro.medium.com/v2/resize:fit:640/format:webp/1*9IDju9_qkRNyKpueLBhkgg.png
That is fair. However, the drawer isn't visibly always there.
It is a bit funny that the design system designed to resemble real life materials didn't really accept that metaphor. Besides, my point was that the gesture itself was implying physicality, you could move the content to swap between tabs, but the gesture was 1:1 with the content. With a drawer you weren't moving the drawer into view, you were reaching a glass handle that was glued to the drawer. Either that, or you were reaching into the realm beyond the screen to bring it on. That is something that I never quite liked for app gestures, because not only is it implied that things exist outside the screen(which is fine), but that you can somehow reach for them.
Erm, there is no diagonal swipes, at least officially from Google. You just swipe perpendicular to the edge of the screen. So from the bottom edge you swipe up, from the left edge you swipe right, right edge to the left
i mean, i'd say it's better than nothing. otherwise one has to reach all the way up to the top to press the hamburger menu
that doesn't seem hugely ergonomic - i can hardly reach the bottom middle of my phone, let alone the left edge
well yeah, it's this exactly. your finger starts from off-screen, where the drawer is currently hanging out, and drag it on-screen. almost exactly the same as the notification drawer, the control centre on ios, or that stupid "charms" thingy on win8
i thought that was how one opened nav drawers with gestures enabled? a diagonal swipe; or swipe, wait, then swipe a bit more (which i'm not even going to go into how awful that is). including in official google apps?
You don't need to reach the middle bottom of the screen, any area on the bottom can trigger the home/recents gesture.
The notification drawer has a bigger and more visible trigger area, tho.
I thought you were talking about system gestures, not nav drawer
okay actually that is good then. that's perfectly fine. ~~(although when compared to buttons, i still don't know how i'm supposed to reach the left edge to go back)~~
yeah fair point, but it's still the same paradigm of an item that gets dragged into the screen
i was sort of talking about interaction inconsistencies, but alright let me rephrase: a swipe right goes back, but a diagonal swipe does [presumably] nothing despite them being pretty semantically similar
Left or right edge, it's the same. If you are holding your phone with your right hand, your thumb is either holding the phone by the right edge, or is just hovering on top of it.
At least on LineageOS it can register a diagonal swipe as long as it sorta fits into a 45° angle, either downwards or upwards.
OH. alright, i didn't know that, that's much better
yeah alright, that seems pretty reasonable then. i think that does sound fairly consistent and predictable