[HN Gopher] Modern iOS Navigation Patterns
___________________________________________________________________
Modern iOS Navigation Patterns
Author : felixbraun
Score : 570 points
Date : 2023-12-11 12:27 UTC (2 days ago)
(HTM) web link (frankrausch.com)
(TXT) w3m dump (frankrausch.com)
| pryelluw wrote:
| This is such a good resource for folks like me who struggle with
| the visual aspect of software. The diagrams and clear
| explanations are just excellent.
| wannacboatmovie wrote:
| Next, try addressing why they change all the time, and seemingly
| for no reason. It's infuriating.
|
| The latest inexplicable, surprise change happened when my Apple
| Watch updated overnight, I went to open control center the next
| morning to locate my phone which I had misplaced, and .... it
| wouldn't open. For 10 minutes I fiddled with this fucking thing,
| thinking I was going senile at one point, only to find out that
| Apple moved the control center trigger to the side (power)
| button, and swipe from below now does something completely
| different. No warning, no announcement, no nothing, and no way to
| revert to the old behavior which existed for years. Imagine
| walking into your car one morning and the operation of the pedals
| was suddenly reversed due to an automatic software update because
| some geekaroid at the car manufacturer thought it was a good
| idea.
|
| At this point I'm convinced they are making changes as a means to
| justify their existence. If I ran that company the project
| managers responsible for these breaking changes - and yes,
| unannounced UI changes are breaking changes - would all be fired.
| shutupnerd0000 wrote:
| Imagine buying a wearable computer with automatic remote
| updates and thinking it will behave like an analog watch.
| wannacboatmovie wrote:
| Actually, if one buys an appliance (which this is), I would
| expect and be fully okay with security updates only, and not
| for the basic means of operation/controls to change monthly.
| n8cpdx wrote:
| Overall I thought the watchOS changes were a huge upgrade to
| the visual design and power of the platform and its apps.
|
| But I still end up opening the wrong view (control center or
| app drawer) at least once a day. And it's been months! If the
| choice is so unintuitive a reasonably fanboyish user doesn't
| learn it after months, it's probably the wrong choice.
| wannacboatmovie wrote:
| And you just know it's configurable (just like the original
| iPad allowed you to change the behavior of the slide switch),
| but they simply chose not to.
| anamexis wrote:
| Interestingly, they did backtrack on removing the "swipe to
| change watch faces" functionality, and added back a
| configuration option for it today.
| wlesieutre wrote:
| Although I'm noticing that mine now brings up every watch
| face with the time set to 10:09 and then takes a moment
| to animate changing to the correct time. It looks really
| stupid with the solar face.
|
| And it doesn't do it just once when a face first loads,
| it does it _every_ time you switch faces.
|
| Hopefully a bug but I'm wondering if someone said "we
| made it so you can't switch watch faces quickly, now we
| can reclaim that RAM and save it for widgets that you
| didn't want."
| n8cpdx wrote:
| I've also noticed issues with the time on the watch face
| being out of date. I've also seen the date be wrong.
|
| It's a pretty serious flaw that doesn't get talked about
| enough. Been around for months at least, I got burned in
| September and ~May of this year.
| spike021 wrote:
| I hate how they changed complication buttons in the last major
| update. It used to be if I raised my Watch I could immediately
| tap my timer complication and it'd open my timer app. Now it's
| like the screen is constantly partially transparent and tapping
| the complication doesn't do anything unless the watch is at
| exactly the right angle. So confusing.
| saagarjha wrote:
| Isn't that how the always-on display has worked since
| forever?
| spike021 wrote:
| Nah. I have a Series 6. It works distinctly differently
| ever since I upgraded to WatchOS 10 (I think that's the
| latest major version that released when the latest iOS
| major release came out).
| xpe wrote:
| > Next, try addressing why they change all the time, and
| seemingly for no reason. It's infuriating.
|
| No, the "Modern iOS Navigation Patterns" (the title of this
| article) don't change all the time. Not even close.
|
| What you are talking about has to do with _buttons_ on watchOS.
|
| I strive to leave a wide wide berth for what people consider
| on-topic, but to me, this comment is an unrelated rant that
| will empirically crowd out discussion around the topic at hand:
| iOS navigation patterns. I'm here on this thread to learn about
| how to make better iOS apps.
| xpe wrote:
| And then ...
|
| > At this point I'm convinced they are making changes as a
| means to justify their existence.
|
| I really hope this is humor and that you aren't convinced of
| this; that would a faulty generalization. There are plausible
| other interpretations.
|
| > If I ran that company the project managers responsible for
| these breaking changes - and yes, unannounced UI changes are
| breaking changes - would all be fired.
|
| 1. Apple regularly breaks expectations. What is a breaking
| change to some is often the expectation at Apple.
|
| 2. I challenge your assumption that this decision was a
| mistake. I would expect the pros and cons were calculated.
|
| 3. How do you know the decision didn't get approved by higher
| up the chain?
|
| 4. Even if it was a mistake, I challenge your claim that the
| appropriate response is to fire the managers. I would point you
| to a vast literature on effective modern management. My
| remaining points elaborate on this...
|
| 5. I disagree with what appears to be angry, impulsive decision
| to fire them.
|
| 6. These are people. I'm not seeing any indication that you
| value them.
|
| 7. Emotions and empathy aside, it would be in your interest to
| build a healthy culture where risk-taking is encouraged and one
| mistake doesn't get you fired. Everyone makes mistakes. And we
| can learn from them. (Yes, dishonesty and negligence gets you
| fired. And poor performance gets you fired, but this is not
| evaluated on the basis of only one mistake.)
|
| 8. I disagree with what appears to be a "I have everything I
| need to know about this" attitude. At the very least gather
| more information before you fire people. If you disagreed with
| the pro/con assessment, look into how that decision was made.
| What process(es) could be improved?
| saagarjha wrote:
| You've created a very long list over what looks to be
| hyperbole until 'wannacboatmovie actually _does_ end up in a
| position at Apple where they handle staffing.
| xpe wrote:
| I consider you lucky if you think the attitude about 'just
| fire the people that made mistakes' is hyperbole. It a
| common attitude, so when ^^ says it, I believe that is what
| they mean.
|
| Also, there is nothing wrong with a long list.
|
| And I'm not here for hyperbole.
| saagarjha wrote:
| It's a common attitude _on the internet_ , where people
| will also argue for people to be executed or thrown in
| jail for trivial slights because it makes their annoyance
| more visceral. Nobody in their right mind will actually
| end up doing that when push comes to shove. It can be
| appropriate to tell people to calm their rhetoric when
| they do this but I don't see "ok actually 1. there might
| be a reason and 2. maybe they made a mistake and 3.
| people who make mistakes should be allowed to learn and
| 4. ..." being very useful.
| xpe wrote:
| Many people "in their right minds" _will_ fire someone
| simply because of one visible mistake. I criticized the
| comment because it endorsed such behavior.
|
| If you want to research the fraction of people that
| would, please let me know what you find. Do you think the
| uncertainty in that fraction would change my decision to
| respond to the words on the page? When someone tells you
| what they think, it isn't crazy to believe them.
| lacrimacida wrote:
| I hate these updates that change things around and break muscle
| memory. And most likely by coincidence it happens at the most
| unappropriate times.
| n8cpdx wrote:
| I'm not sure if this is related enough or not, but here goes:
|
| On Mac and now iPadOS (https://useyourloaf.com/blog/ipad-
| customizable-toolbars/), the built-in toolbar control supports a
| high degree of customization. You can try this in Finder, among
| many other native apps.
|
| Powerful built-in widgets are an underappreciated aspect of the
| Mac desktop, and something I worry about with SwiftUI taking
| over. They're also a huge win for iOS, but less so because it is
| so common for apps to want to put their own spin on the design.
|
| Anyway, am I crazy, or did iOS apps used to support customizing
| tab bars out of the box? While clearly different from toolbars,
| supporting editing the order (and which are actually displayed)
| of tabs felt like the spiritual equivalent of built-in toolbar
| customization. And I haven't seen it in years.
|
| According to doc it is still there, but does anyone know of apps
| still using this pattern?
| https://developer.apple.com/documentation/uikit/uitabbarcont...
|
| Anyway, tab bars are cool also because that is what is used by
| Apple TV in most apps I've used, and the consistent experience is
| wonderful.
| spike021 wrote:
| Yep back in the early days it was very common to be able to mix
| around tabs and take out out in the ones you wanted. Back when
| FB was still decent in the... iOS7? says it let you do this
| with chat, feed, notifications, groups, etc. as an example.
| saagarjha wrote:
| iTunes Store?
| jwells89 wrote:
| On Mac I wish more apps used the standard toolbar. The
| customizability is nice and rarely found in bespoke
| implementations.
| crooked-v wrote:
| Various Apple apps like Apple Store and Music use a tab bar at
| the bottom, but they're not customizable. Everything I can
| think of outside of Apple switched over to completely
| undiscoverable hamburger menus a long time ago.
| macintosh-hd wrote:
| I still miss the ability to rearrange the toolbar in iOS apps
| like the music app. I never use 2 of the tabs in Apple Music
| literally ever. I wish I could make it go directly to playlists
| and albums.
| jurip wrote:
| UITabBar has always been painfully limited in its
| customizability by the programmer and the customizability by
| the user aspect is something that few projects care about. By
| locking down its appearance so tightly, Apple pretty much
| ensured that everyone always replaces it with something else.
| superb_dev wrote:
| The customizable tool bars are still around in SwiftUI and very
| nice to work with!
| ben_w wrote:
| There's a few apps where I'd like to remove tab buttons as a
| user; but as a developer, _nobody_ has ever asked me to
| implement the feature; and based on my parents regularly
| accidentally removing things from the MacOS dock instead of
| opening them and needing my help to get it back, I suspect the
| ability causes a lot of customer support issues.
| happytoexplain wrote:
| This sets off my alarm bells big time:
|
| >High-Friction Modal
|
| >A decision is required to dismiss them: A decision whether to
| save state, whether to confirm (by tapping Done) or to destroy
| (by tapping Cancel) the data you've entered on a form.
|
| >Low-Friction Modal
|
| >They are easy to dismiss: "Low friction" means not having to
| think about how to get back.
|
| 'CANCEL' ON A PROMPT IS NEVER, EVER DESTRUCTIVE. This is a huge
| red flag for the author's understanding of UI conventions.
| "Cancel" must always be safe. "Cancel" is the low-friction no-
| thinking way to dismiss a prompt. It should dismiss the prompt,
| and _do nothing else_.
|
| Corollary to this is that you should avoid putting a "Cancel"
| button on a full-blown input interface that will throw away user
| data if dismissed (regardless of whether you have decided to
| embed said interface in a modal). If you do, you at least need a
| "are you sure" prompt _with a cancel button_ (hence why you avoid
| using the word 'cancel' redundantly on the original form).
| alain94040 wrote:
| Not 100% sure about cancel vs. stop.
|
| Say I'm creating a new calendar entry. I type a lot of
| information, then I get to save or cancel. Technically, cancel
| is safe because I'm not messing up my existing calendar. But
| all the typing I did (especially on mobile) would be lost. So
| is cancel really safe? But Stop wouldn't the right choice
| either...
|
| What do you suggest?
| happytoexplain wrote:
| > Technically, cancel is safe
|
| No, it's not safe in that scenario. "Destructive" means
| throwing away anything, even one word the user typed. Do not
| use the word "cancel" for that operation - use the word
| "Discard" or an X button, _with an are-you-sure prompt that
| has a cancel button that safely brings you back to the
| editing interface_.
|
| Edit: OK, maybe "one word" is an exaggeration. Certainly for
| the case of a form of input fields a no-prompt cancel button
| is inappropriate. However, if you have a simple OK/Cancel
| dialogue that contains a single one-line input field, it is
| usually acceptable to have a Cancel button that throws away
| your input without prompting.
| mcbits wrote:
| If I'm filling out a modal form and "Cancel" doesn't result
| in a clean form after I open it again, it should probably
| say something like "Hide" or "Finish later" instead.
| lawgimenez wrote:
| Give the user an option to save it as a draft. Fantastical
| does this, not sure about Apple's own calendar.
| systoll wrote:
| Both apps show a 'cancel' button on the 'add event' popup,
| as per this post.
|
| They both then show a 'discard/keep editing' prompt, but
| only fantastical has the extra option of a draft.
|
| But in addition to that -- fantastical's popup isn't even
| modal. You can push the sheet down to see and interact with
| the main calendar.
|
| Unfortunately, fantastical doesn't show the 'drag handle'
| that Mail and other apps use to show this functionality, so
| it's not particularly discoverable.
| lawgimenez wrote:
| My understanding is that if the navigation bar style
| starts with large then it should have the drag indicator.
| LeoPanthera wrote:
| Label your buttons "Save" and "Discard".
| JonathonW wrote:
| "Save", "Discard" (or "Don't save"), and "Cancel", where
| "Cancel" does not dismiss the editor.
|
| (This is the three-button close prompt that's been the
| standard in desktop operating systems since at least the
| Windows 3.1 era, but I guess we have to rediscover these
| things when the same problems come up on mobile.)
| happytoexplain wrote:
| That pattern makes more sense when you are A. Editing a
| document, as opposed to filling out an ephemeral form;
| and B. The document does not auto-save. This pattern is
| more likely on desktop, which is where you're getting the
| correlation from. It's unnecessarily complicated when
| filling out something that appears in a modal like the
| article is referring to, e.g. a calendar event.
| _moof wrote:
| That's not a cancel.
| LeoPanthera wrote:
| "Cancel" should never be on an "Are you sure" prompt.
|
| Labels the buttons with what they DO.
|
| "Don't delete", or "Keep", or "Save", and "Delete", would be
| appropriate button labels.
| happytoexplain wrote:
| Sorry, I disagree. I've seen the pattern you're describing.
| Yes, it is perfectly acceptable (usually preferable, even) to
| replace "OK" or "Yes" with an explicit verb. But please do
| not do the same for the cancel button. It creates an
| unnecessary cognitive prompt. Always give the user a no-
| thinking safe way of dismissing a confirmation prompt - we
| have trained users for decades that "Cancel" is that escape
| hatch.
|
| As another commenter pointed out, I agree with the HIG here:
| https://developer.apple.com/design/human-interface-
| guideline...
|
| > Always use "Cancel" to title a button that cancels the
| alert's action.
| kccqzy wrote:
| > Are you sure you want to cancel your flight?
|
| > [Cancel] [Cancel]
|
| I totally agree that it is preferable to replace "OK" or
| "Yes" with an explicit verb. The same thing should be done
| to the usual "Cancel" button. If you are already thinking
| of an explicit verb to replace "OK" with, just add "Don't"
| to the other one.
| happytoexplain wrote:
| And as always, the unstated first rule of UI is: Also use
| common sense :)
|
| E.g. in this case, the first option should be "Cancel
| Flight" or "Yes", and the second option should be "Do Not
| Cancel" or "No", though I'm sure there are other
| reasonably explicit options.
|
| Edit: We each made essentially the same suggestion as an
| edit to our posts at the same time. The only difference
| is that I consider this an exceptional case. I still
| contend that "Do Not XXX" requires more thinking than
| "Cancel" when there isn't an obvious semantic conflict.
| You say "if you are already thinking of an explicit
| verb...", but I am not concerned with saving myself
| cognitive effort - I am concerned with the user.
|
| Edit: Also, note that this is all tangential. The only
| point I was interested in writing about at the top of the
| thread is that, when you do see a "Cancel" button, it
| should never be destructive.
| isodev wrote:
| You're correct, the linked article contradicts the Human
| Interface Guide from Apple.
|
| From the official docs [0]:
|
| > Always use "Cancel" to title a button that cancels the
| alert's action ...
|
| > "A specific button title like "Erase," "Convert," "Clear," or
| "Delete" helps people understand the action they're taking."
|
| In fact, I think the entire topic is much better explained
| (with considerations for each platform) in the docs.
|
| [0] https://developer.apple.com/design/human-interface-
| guideline...
|
| More on navigation:
|
| https://developer.apple.com/design/human-interface-guideline...
|
| https://developer.apple.com/videos/play/wwdc2022/10001
| threatofrain wrote:
| In the example of Apple Calendar, creation is arguably the
| "dangerous" event even if it's not destructive, so one might
| argue that what Apple is currently doing on Apple Calendar
| (cancel destroys the event) is compliant with the spirit of
| their HIG. I'd use the same argument of creation-is-dangerous
| for the alarm app, which also has a non-scary cancel button
| that destroys the input.
|
| Then we go to something like Apple Notes where even the
| slightest bit of data is auto-saved without asking.
| isodev wrote:
| I don't follow. Apple Calendar shows a sheet to create a
| new event. The sheet has a primary action (Add) and a
| discard action (Cancel). If you hit Cancel after adding
| some data, you get an action sheet "Are you sure you want
| to discard this new event?" with the options to "Discard
| Changes" and "Keep editing"
|
| The primary and secondary actions on a sheet are not the
| same (different modality and context) as the options on a
| modal action sheet (where we usually have to confirm or
| discard).
| threatofrain wrote:
| Oops, you're right, I just didn't change any data.
| However, on Apple Calendar for MacOS, using [?]-n and
| dismissing the prompt will destroy your data. The same is
| true for alarms on iOS.
| saagarjha wrote:
| This is not true. Cancel is often destructive, we just have a
| bar over which it will ask you if you really meant to throw
| away your current work. Like, I just went to type a new message
| in iMessage and if I hit "Cancel" it gets rid of what I typed.
| That's because it's not worth the mental overhead of saving two
| lines of text that is the typical amount of unsaved content
| that a typical message contains. On the flip side, Mail will
| ask you if you want to save a draft if you exit.
| happytoexplain wrote:
| I disagree that this is evidence that it is "often"
| destructive - however, this is mostly a semantic
| disagreement. As you have pointed out, "destructive" is
| subjective. I mention in another comment that I would
| consider throwing away the contents of "a single one-line
| input contained in a prompt" to be non-destructive. It's not
| a large leap to the contents of a single instant message,
| whether or not I agree that it qualifies. E.g. if iMessage
| would throw away a large amount of text un-prompted, I would
| disagree with iMessage's UX.
|
| I'm not sure you really disagree with the core of what I'm
| saying, which is that "Cancel" is the universal easy way to
| _safely dismiss a modal prompt_ , and also, _regardless of
| what word you put on the button_ , if it would throw away a
| (subjective) threshold of data, _you should prompt the user_.
| saagarjha wrote:
| I went into this discussion with the suspicion that despite
| your ALL CAPS exhortation your opinion was not actually all
| that disagreeable or controversial.
| happytoexplain wrote:
| Yeah, I would characterize it as a genuine all-caps
| exhortation only under the qualification that I am
| defining the word "prompt" as a simple prompt, not e.g. a
| message-composing UI (but the author is talking about
| modals in general, so I was not being precise enough
| about my disagreement with the author in my first
| comment).
| xpe wrote:
| > A decision is required to dismiss them: A decision whether to
| save state, whether to confirm (by tapping Done) or to destroy
| (by tapping Cancel) the data you've entered on a form.
|
| Here are my questions so I can fully understand what you mean:
|
| 1A. Does it makes sense to have a button to (destroy/prevent)
| ("in-flight"/tentative) changes?
|
| 1B. if so, what do you think a button doing that should be
| named?
|
| 2A. You also think there should be a button to make the modal
| go away but keeping all inputed data just as it is?
|
| 2B. What should that button be called?
|
| I'm wondering if you might answer: 1A: Yes. 1B: "Discard". 2A.
| Yes. 2B. "Dismiss".
| xpe wrote:
| In the case of a e.g. "New Widget" modal popup, I'm quite
| comfortable with a "cancel" button that means e.g. "this will
| discard whatever you typed / stopping the creation of a new
| widget". That kind of cancel button certainly results in lost
| information, and in some sense it is "destructive". But isn't
| "destructive" of data that we expect to persist. I typically
| use the word in the latter sense.
|
| Hopefully people have a decent shared understanding of the term
| "destructive" or this is going to be very confusing for all
| involved. Is there a clear shared understanding? I don't run UX
| testing.
| fingerlocks wrote:
| I believe the author used "destructive" because that's the name
| used by UIKit to style a cancel button with the system
| defaults.
| robertoandred wrote:
| Not to beat a dead horse, but the use of these patterns is one of
| the many reasons Apollo was so much better than Reddit's official
| app. Consistent navigation, consistent gestures, consistent
| behaviors.
|
| And it's not like these concepts are hard, you just have to care
| enough to follow them. It's really disheartening to see how many
| apps don't.
| jwells89 wrote:
| That's the difference between an app that optimizes for being a
| good app and an app that optimizes for engagement and selling
| you things.
|
| It's similar to how supermarkets periodically shuffle around
| their shelving. Consistency in navigation, gestures, and
| behaviors allow the user to get what they want and get back out
| too efficiently.
| pacificmint wrote:
| Case in Point: I really like Costco, but if I ever cancel my
| membership then it is because of how they seem to reshuffle
| significant parts of the store every few weeks.
|
| I don't know if they think I will buy more if I run around
| for fifteen minutes looking for something, but man it's
| annoying.
|
| They probably think of it as 'increasing engagement'. To me
| it's just wasting my time.
| rtpg wrote:
| That might be for other reasons, because according to a
| study I've seen, Costco basically runs their stores "at
| cost" and wants to just make money off of the memberships
|
| (https://minesafetydisclosures.com/blog/2018/6/18/costco,
| though it's from 5 years ago so things might have changed)
| TeMPOraL wrote:
| > _They probably think of it as 'increasing engagement'. To
| me it's just wasting my time._
|
| Here you've stated the fundamental truth about the so-
| called _attention economy_. The core tenet of it, is that
| _money is made on friction_. Attention is a finite resource
| everyone prefers to conserve for their own needs, therefore
| it needs to be stolen, so it can be redirected to ads,
| upsells, and other form of behavior manipulation.
|
| That's why supermarkets are reshuffling stores so
| frequently. That's why so many websites are full of dark
| patterns and general annoyances. That's why ergonomics all
| but disappeared from software. Their inefficiency - wasting
| your limited lifespan in countless tiny ways - is how they
| make money.
| kortilla wrote:
| > That's why supermarkets are reshuffling stores so
| frequently.
|
| Normal supermarkets in the US very rarely do this.
|
| Walmart, Safeway, Whole Foods, HEB and all others I
| frequently shopped beyond Costco explicitly had very
| stable layouts.
|
| It was literally a topic of news in my neighborhood when
| one of them rearranged for a remodel.
| ThatMedicIsASpy wrote:
| I don't see that happening at all in Germany unless they
| completely redo the whole store layout. I always know where
| the stuff I want is (if I had purchased it before). The only
| consistent pattern we have is expensive stuff is on eye
| height and the cheaper option is on the bottom.
| mattl wrote:
| It's an absolute shame that Steve Huffman ruined Reddit by way
| of the destruction of Apollo. I quit Reddit a few years earlier
| but this was the nail in the coffin.
| TobyTheDog123 wrote:
| Apollo is one of the few reasons I shell out the $100/year
| for an Apple Developer Account.
|
| If someone is even mildly technical I'd recommend going the
| Sideloadly route for getting Apollo, ad-free/background-play
| YouTube, ad-free/backgroun-play Twitch, and ad-free Spotify.
| davkan wrote:
| You can use altstore to sideload those for free, or at
| least i know you can for uyou+.
| Gareth321 wrote:
| I believe there are two large caveats with Altstore. 1)
| It requires the use of a local "server" to phone home on
| a weekly basis. That means setting up and running another
| computer in the home, then configuring a regular check-
| in. Remote check-in (such as while traveling) sounds even
| more complicated. 2) There is a limit of three apps.
| extraduder_ire wrote:
| There is (was?) a sideloadable app called "reprovision"
| that did the re-signing on your device without needing to
| do a reinstall every time. Was useful for keeping a
| jailbreak app on an ipad 6. Worked great as long as I
| didn't turn the device off for over a week.
|
| Looking forward to the EU's sideloading rules coming in
| though, so I never have to deal with this.
| mattl wrote:
| That's good to know. spez really dropped a bollock on this.
| spiderice wrote:
| Fuck u/spez
| hmcdona1 wrote:
| The recent overhaul of Narwhal for version 2 reworked the
| entire app to operate pretty close to what Apollo was at
| its core. It's extremely customizable as well. Their new
| subscription plan for covering the API costs is pretty fair
| and would be cheaper than what you are doing here.
| TobyTheDog123 wrote:
| I'm glad there's a spiritual successor to Apollo, but
| it's not entirely about comparing one cost to one cost.
|
| -
|
| Spotify: $10.99/mo ($132/yr)
|
| YouTube: $13.99/mo ($168/yr)
|
| Twitch: $11.99/mo ($144/yr)
|
| Narwhal: $6/mo ($72/yr)
|
| -
|
| You'd be right, the $72/yr for Narwhal is less than the
| $100/yr developer certificate, but with all of the other
| sideloading opportunities it's no contest w.r.t cost.
| ec109685 wrote:
| Why not pay for Spotify and YouTube Premium?
| Gareth321 wrote:
| I can't speak for them but my YouTube experience is in
| the toilet as of late. I've been a Premium subscriber for
| years now and they just keep making the apps worse. I
| can't even turn off shorts anymore. Despite paying for an
| "ad free experience," they serve me this shit:
|
| * In-feed ads. These include ads for content prominence
| (preferential placement for creators), articles with
| link-out, ads for Google products and services like
| purchasing movies and shows in their store, and ads for
| Google product features.
|
| * Modal ads in videos which they facilitate. That is,
| pop-up ads in content.
|
| * Ads for merchandise under the content.
|
| * Ads for paid subscription to channels.
|
| * In-content ads in the form of creator sponsorships.
| These are becoming egregious.
|
| At this point my experience is infinitely better with
| another front end which bundles SponsorBlock. Why am I
| paying for a FAR worse experience on their app? Their
| family subscription is not cheap where I live.
| TobyTheDog123 wrote:
| Why would I?
| joemi wrote:
| I've noticed no change to the subreddits I'm active in.
| Obviously there was change when everyone was making a fuss,
| but now that that's died down, it seems like it never
| happened.
| jangxx wrote:
| Interesting that you say that, in my subjective experience
| the overall quality of submissions and discussions has
| dropped significantly. I don't have any data about this of
| course, but the site just doesn't really capture my
| attention anymore the way it once did, and it's mostly down
| to the comments just not being an interesting read anymore
| (for me).
| ThatMedicIsASpy wrote:
| Some folks use a phone for everything. I just can't stand
| it and have never touched reddit on a phone. But I hate
| everything web and phone related. It's just too small for
| me.
| realusername wrote:
| I've noticed some very big changes on my side, especially
| in terms of quality.
|
| That's actually the reason I'm about to delete my account,
| the good contributors somehow left.
| kaba0 wrote:
| I mean, if I would have to write curl scrips to access reddit,
| it would still be a better experience than the official reddit
| app, it's not a high bar.
|
| Honestly, I don't think I could deliberately come up with a
| worse design.
| BlindEyeHalo wrote:
| OpenRed is basically this. It is a reddit app that parses the
| html instead of using the api so the dev can keep it free. It
| is a bit buggy but I use this over the official app because
| you don't get ads or random posts from subs you don't
| subscribe to.
| Biganon wrote:
| I've never seen an app as confusing as the official reddit app,
| and I consider myself of normal intelligence
|
| I moderate a 30K-member subreddit so I need to be able to use
| reddit from my phone, but... it's impossible. Everything
| requires so many actions, I never know where I currently am,
| it's pure garbage
| mitemte wrote:
| I'm in the same boat. The UX on Reddit is in the same
| ballpark as AliExpress' app.
|
| Since Apollo was shut down, I've completely stopped using any
| Reddit app on my phone. Sink It[1] makes the mobile site
| tolerable, for cases when I end up on a Reddit thread off the
| back of a search engine query.
|
| 1. https://apps.apple.com/app/sink-it-for-reddit/id6449873635
| gorbypark wrote:
| Yeah, AliExpress' app navigation is on an entire other
| level. I sometimes get so deep in screens with no way to
| get back to the Home Screen that either spend a minute
| hitting the back button like 50 times, or just kill the app
| and start it again.
| ajoseps wrote:
| thank you for posting that link to Sink It, I never knew
| about it but it's a great option to improve reddit after
| Apollo went away. I also like how you can just auto-
| redirect to old reddit if you want
| ssiddharth wrote:
| I made this actually. Such a pleasant surprise to see it
| mentioned randomly on HN. :)
|
| Happy to listen to any feedback or feature requests you may
| have.
| drewmol wrote:
| Have you tried old.reddit.com?
| gog wrote:
| Moderation via the old interface is problematic, especially
| if you have custom mod tools and actions set up.
| faraggi wrote:
| ...and old.reddit is not mobile responsive.
| Galaxeblaffer wrote:
| ever tried Snapchat ?
| whalesalad wrote:
| Apollo was the best iOS app ever made. RIP.
| deanc wrote:
| For the nostalgic folks amongst us with a bit of a hacker
| spirit, you can apparently side-load Apollo and patch it to use
| your own reddit api key.
| layer8 wrote:
| This will hopefully become easier with EU-imposed official
| side-loading.
| qaz_plm wrote:
| For mobile browsing of Reddit, I found Sink It, iOS Safari
| extension, to help clean up the current mobile web version so
| I'm not struggling with old.reddit which isn't mobile
| responsive.
|
| https://gosinkit.com
| leokennis wrote:
| The official Reddit app is one of the few where I regularly
| "get lost" and it takes too much mental energy to go back to
| the main view...and I just force quit and reopen it.
| aeyes wrote:
| Even on Apollo you can get confused because you can open an
| infinite amount of layers (subreddits, user profiles, posts) on
| top of each other. After a few of them it gets very cumbersome
| to get back to the front page because you have to swipe / press
| back until you get there.
|
| There probably is a magic gesture which I don't know about.
| rTX5CMRXIfFG wrote:
| The entire article can be summarized into one word: trees.
|
| Anyway, this is the sort of information that you must absolutely
| consume from a direct source, i.e. Apple documentation and Human
| Interface Guidelines, because they change a lot and secondary
| sources can be outdated or flat out wrong at any given point in
| time. Additionally, your mental model of the UI must correspond
| with Apple's implementations of its UI frameworks (if this is
| targeted at designers, well the problem of design that is
| detached from engineering is a separate and long discussion,
| though very real and so widespread as to be the norm).
| wodenokoto wrote:
| My impression of this article is that it is not an
| interpretation of apples guide lines (ie a secondary source)
| but a write up of observations (ie a primary source)
|
| This can be of interest for a few reasons, but particularly
| because such investigations might reveal "true" design
| philosophies over espoused philosophies.
| rTX5CMRXIfFG wrote:
| What do you mean by true versus espoused? iOS's modals, tab
| bars, navigation bars, and everything mentioned in the
| article are exactly the objects or value types that you deal
| with when you go to the code level and actually use the APIs.
| eviks wrote:
| The official docs can also be wrong and outdated, so there is
| no difference here. Besides they can also be poorly written, so
| there is nothing absolute here
| rTX5CMRXIfFG wrote:
| Outdated, yes. Poorly written, sometimes. But how can you
| call documentation wrong without seeing the source code? And
| if the direct source is wrong, how could the secondary source
| then be right? Sounds to me like developer or designer
| arrogance is at play here, when they should be questioning
| the correctness of their own understanding.
| eviks wrote:
| > But how can you call documentation wrong without seeing
| the source code?
|
| Very easy - by observing reality, and how it matches to
| what's documented
|
| > And if the direct source is wrong, how could the
| secondary source then be right?
|
| In exactly the same easy way - by observing and documenting
| reality. For the same reason this is a second primary
| source, not a secondary one
|
| > Sounds to me like developer or designer arrogance is at
| play here, when they should be questioning the correctness
| of their own understanding.
|
| Good albeit slightly misdirected advice, we have a great
| case of misunderstanding pretty trivial things that lead to
| trivial questions and faulty personality assessment
| wodenokoto wrote:
| The Home Screen actually uses the pyramid pattern and not the hub
| and spoke.
|
| You can swipe between apps using the black bar at the bottom.
| b0b10101 wrote:
| except that the stack you're swiping between is not represented
| in the layout of the icons - it's on how recently you've used
| the app.
|
| ie: if i have photos, calender and safari all on the same row
| of the home screen, and i open photos, go back to the home
| screen and then open safari, if i swiped left to right (to go
| backwards) on the bar at the bottom i'd go directly back to
| photos, not to calender
| Dig1t wrote:
| This site itself is really nice to read and easy to understand. I
| wish Apple's docs looked as nice and were as easy to read as
| this.
| Groxx wrote:
| On the first entry:
|
| > _Drill-down navigation is stateless_
|
| I've been encountering this a lot lately, but: this seems the
| opposite to me, it's _deeply_ stateful as screen N depends on
| what you did before, and you can go back to it. It literally
| keeps track of some internal state in order to be useful at all,
| i.e. the list contents depend on state N-1, because if it didn 't
| it would be awful.
|
| A stateless UI would be, like, a one-step modal. It exists or it
| doesn't. Particularly strongly "stateless" if it's transient and
| you have no way to "resume" it.
|
| I've been in and around quite a few discussions using the term
| "stateful" to mean WILDLY different things through the years, and
| in a giant burst lately, and it has largely led me to conclude
| that almost nobody agrees with anyone else what it means and few
| are aware of this.
|
| What does "stateful UI" mean to you all? I find the variation
| _fascinating_.
| bruce343434 wrote:
| To me, stateful UI means that the front end is using variables
| to manage its behaviour.
| Groxx wrote:
| This would mean it's strictly an implementation detail then?
| Since any state can be turned into configuration /
| construction / just make infinite views, each one customized
| to show one state.
| asoneth wrote:
| Implementation differences are certainly a part, but people
| do interpret them differently.
|
| For example, I'm working on an application that is
| transitioning some of our stateful navigation to be more
| stateless to hopefully address some end-user confusion. We
| have an overlapping hierarchy where many objects have
| multiple parents, and the same object would display
| different breadcrumbs depending on which path someone took
| to the object. This made people confused about whether they
| were looking at the same object.
| asoneth wrote:
| I agree the use of "stateful UI" is ambiguous in general, but
| with respect to navigation I typically hear hierarchies
| referred to as stateless and activity stacks as stateful.
|
| With a hierarchy like iOS every child is supposed to have
| exactly one parent so you only need to know the current page to
| know what the "back" button will do -- it will go up one level
| in the hierarchy to the page's parent regardless of how you
| arrived at the page.
|
| With an activity stack like Android, it is not sufficient to
| know the current page, you must know how you got to that page
| because the "back" button refers to going back in the history.
|
| Many websites support both -- the browser's back button is
| stateful and navigates your personal history, whereas on-page
| navigation like breadcrumbs are often stateless and do not
| depend on the particular path you took to get to the page.
| There are exceptions of course, many search interfaces are
| stateful in that drilling into an item and going back using the
| in-page navigation will return you to the prior query rather
| than the page's parent.
| jurip wrote:
| One inexact wording here I noticed: "Swiping right from the left
| edge of the screen does the same as pressing the Back button." If
| you're implementing that yourself, it's important it's not a
| swipe gesture, it's an edge pan gesture. It has to be an
| interactive, cancellable pan that follows your finger, or it just
| feels wrong.
| insomagent wrote:
| I think the X/Twitter iOS app and the reddit app are guilty of
| this. I find myself way too often typing something out, then
| barely touching the edge of my phone, and my entire comment is
| gone.
| anileated wrote:
| Pro tip: Twitter works as PWA.
| hbn wrote:
| On Twitter you can't swipe out of the tweet compose screen.
| You have to explicitly click the "Cancel" button in the top
| left, and if you have anything written it'll pop a dialogue
| to either delete the contents, save as a draft, or cancel (go
| back to composing)
|
| I'm not sure how you'd swipe out of this screen.
| fractallyte wrote:
| Sailfish OS does this properly and consistently - in all apps.
|
| https://sailfishos.org/
|
| I've found it overall simpler and better than both iOS and
| Android.
| jurip wrote:
| I'm sure Sailfish, too, allows you to prevent the gesture if
| you want. On iOS if you use the standard navigation
| controller, you get it automatically. If you're swimming
| against the tide and want to do something unusual, you have
| to implement it yourself, but it's easy enough with a readily
| available gesture recognizer.
| mrweasel wrote:
| Swiping right from left to go back is a horrible horrible way
| of implementing a "back button" and you should never do it,
| always have an actual back. Why? Because left handed people
| exists. It's a not a natural of comfortable movement when done
| with your left thumb. You also can reverse the direction for
| left handed people, because if you normally read left to right,
| then swiping right seems like it should take you forward, not
| back.
|
| Generally I'm not a fan of swiping to navigate. On iOS it's
| really bad, because swiping from the bottom up, you bring up
| some menu, which actually contain a bunch of important stuff,
| which you can never find when you need it, but which you will
| trigger constantly when scrolling a web page.
|
| Perhaps more generally: iOS have devolved into a horribly
| complicated OS that is an absolute nightmare to navigate and I
| feel like Apple should start to take UI/UX serious again.
| Mostly the issue to me seems to be the expectation that the
| phone should handle a whole hosts of tasks for which it is ill
| suited.
| tanjtanjtanj wrote:
| I exclusively use my phone with my left hand and I have no
| issue with the swipe to go back gesture in iOS.
| tavavex wrote:
| I like the presentation, it's understandable and well-structured.
|
| From what I can see, Apple's guidelines look really similar to
| what Google suggests for Android apps - the only really big
| difference is visual presentation.
| rplnt wrote:
| When I see "iOS Navigation Patterns" I cringe. There are no
| patterns and it's one of the worst things (there are many) when
| comparing to Android. Going back on Android is easy, and back can
| mean multiple things. On iOS that I've been using over a year I
| just blindly try one of the two back "patterns", then look for
| buttons in an unreachable places. And even that sometimes doesn't
| work.
|
| Don't let developers use patterns, fix it on OS level. Developers
| don't want you to leave parts of their app - try doing back
| action on Instagram reels for example.
| rezonant wrote:
| The activity stack experience in Android is probably my
| favorite part of the system design. It produces a deep
| consistency that makes navigation effortless.
|
| I really wish this had been built in to iOS in the same way.
|
| The activity stack works across applications, which means a
| back gesture always brings you back to the screen before it,
| even when several applications work together on a task.
| wiradikusuma wrote:
| Don't iOS apps have that small black back icon on the top
| left that sometimes appears when you open another app?
| malermeister wrote:
| _sometimes_ is the problem. It 's not consistent.
| emsy wrote:
| That's just not true.
| immanentize wrote:
| I had to Google it and I think I've seen this thing in
| the status bar sometimes on iOS but it's definitely not
| consistent.
|
| I wasn't even aware it was supposed to be a button
| K2L8M11N2 wrote:
| It appears every time you get into an app by clicking a
| notification while you're in another app, and it's 100%
| consistent in that context.
| bshacklett wrote:
| The fact that you had to explain how it works indicates
| that a bit more consistency might be beneficial.
| room500 wrote:
| It is consistent when the apps are consistent.
|
| But it will not appear if the app opens the webpage as
| its own View (instead of opening Safari). In that case,
| there is no button and the user has to hunt for how to go
| back. And the user has no way of knowing whether an app
| will open Safari or will open the webpage itself.
|
| iOS requires users to build muscle memory in learning how
| to use each app. Android requires users to maintain a
| back stack in their head to remember what came before.
| Switching between the two is very jarring.
| rezonant wrote:
| To be fair, captive browsers are also a plague on Android
| apps. I despise them and especially so if there's no way
| to turn them off in a particular app.
| malermeister wrote:
| > It appears every time
|
| Would be consistent.
|
| > It appears every time [long list of qualifications]
|
| Is inconsistent.
| QkPrsMizkYvt wrote:
| It is consistent!
| cout wrote:
| I don't remember ever seeing (or noticing) anything like
| that on ios. Do you have a screenshot?
| jrockway wrote:
| This is for things like clicking ads in the New York
| Times. Safari will open, and then at the top left of the
| screen there will be a "< NY Times" indicator. It's below
| the clock and above the aA icon in the URL bar.
| Terretta wrote:
| Not just Safari. Most any two apps that support passing
| things from one app to the next (e.g. via Share Sheet, or
| a deep link, or etc.), the next app has a back to first
| app.
| HumblyTossed wrote:
| That itty bitty teeny weeny thing? Yeah, it's occasionally
| there.
| isoprophlex wrote:
| Swipe up from the bottom middle edge of the screen to bring
| that up on ios? Or do you mean something else?
| rezonant wrote:
| Not that, it's about how you navigate through screens in
| the same app and in multiple apps. Since the back gesture
| and back stack is universal and all apps are presenting
| activities added to the back stack, you can seamlessly move
| between apps using "intents" which are abstracted messages
| that multiple apps understand, and even tunnel through an
| arbitrary number of apps, and back up through each of their
| screens as if they were all in the same application.
|
| An example of an intent is "can anyone open this PDF file"
| or "the user wants to pick a file, can any app do that and
| let me know what they picked?"-- those file pickers could
| also be from your network browser app, or Dropbox, etc.
|
| And since activities are serializable (well, technically
| the intents that led to those activities being started),
| Android can do this without requiring the apps deep in the
| app stack to be running. It can freeze those apps to
| reserve resources and restart them at the specific activity
| when the user returns, if necessary.
|
| iOS does have limited inter-app linking (it's the tiny
| little back arrow and the previous app name that you'll
| sometimes see at the very top of the screen), but since
| back gestures aren't universal, the only reliable way to
| activate that feature is to tap it, since the app may not
| even understand back gestures, let alone do the extra work
| of relinquishing control when their own local back stack is
| empty.
| whalesalad wrote:
| Not true at all. Read Apple's HIG it's all spelled out there.
| Some apps deviate from this but that isn't the fault of iOS.
| Instagram on android is just as bad.
| runnerup wrote:
| > Some apps deviate from this but that isn't the fault of
| iOS.
|
| Then I suppose it's the fault of the App Store reviewers. The
| point is that Android handles the activity stack on the OS
| level and has much stronger control over what a back button
| does.
| the_gipsy wrote:
| Go to Clock, Sleep|Wake up (yes that's really the label!),
| click Change, scroll down a bit, click "Edit sleep schedule
| in health". It opens another app in hyperlink style, which
| the article recommends against.
|
| A lot of apps deviate constantly from the "blessed" patterns.
| The result is that as a user new to an app (or update), you
| have to click and gesture around to see what happens, and
| probably miss a lot of UI features because of that.
| the_other wrote:
| > Go to Clock, Sleep|Wake up (yes that's really the
| label!), click Change, scroll down a bit, click "Edit sleep
| schedule in health". It opens another app in hyperlink
| style, which the article recommends against.
|
| Most of the alternatives would be worse for either
| usability or maintenance, or both:
|
| - don't track sleep in the Health app
|
| - track sleep, don't provide alarms/notifications for the
| sleep/wake along with the schedule in the health app
|
| - put almost all the UI for Health's sleep/wake in the
| Clock app instead
|
| - provide almost identical UI in both the clock and health
| apps
|
| I'm sure there are better implementations of the current UI
| tho'. E.G still link to the 2nd app, but have it _after_
| the normal alarm clock in the vertical/reading order, and
| use better wording to explain the function and behaviour.
|
| I wonder if they're trying to avoid having Clock ask for
| permission to read the HealthKit data, which presumably
| they would have to do in most other possible
| implementations.
| the_gipsy wrote:
| It's the right thing to do, but it shows how broken
| "hyperlinking" is on iOS: after clicking the button, you
| get the health app on some specific screen. That screen
| has a "< Settings" button on the top left, which will
| obviously take you somewhere unrelated now. Assuming that
| we somehow recovered from clicking that, in the OS status
| bar there is a minuscule and ephemeral "< Clock" label,
| which _does_ take you back to the clock app, but
| disappears as soon as the user switches applications or
| to the home screen. However, the screen that took me
| there in the first place was some kind of "modal" which
| closed itself when the clock app went into background, so
| that's also broken.
| JusticeJuice wrote:
| But here's the key question - were you able to edit your
| sleep schedule? Do you think other people have been able to
| edit their sleep schedules?
|
| UI has no 'correct' approach, the only thing that matters
| is if people can happily use it.
| JusticeJuice wrote:
| There's this phenomenon where people only notice an interface
| if they don't like it. There's heaps of well documented and
| well used patterns in lots of apps in iOS, I think when rplnt
| says "There's no patterns" he's happily ignoring everything
| that works.
| tacker2000 wrote:
| Also, why is the back button on iOS all over the place?!
|
| Sometimes it's on the top left, sometime bottom left, sometimes
| bottom right, and im sure some apps even place it somewhere
| else.
|
| On Android there is a dedicated OS back button that is always
| in reach, when using the phone with one hand.
|
| This is the far superior way of doing this.
| mort96 wrote:
| The convention is that it's in the top left and that the
| "swipe rightward from the left edge of the screen" gesture
| also goes back. Most apps work like this, and it's not
| actually a problem in my experience. I can't actually
| remember seeing an app which puts the back button in the
| bottom right...
|
| With apps which follow the convention, I don't miss a
| hardware back button (or, as is more common in Android these
| days, a software back button in an OS-provided bar at the
| bottom of the screen). Swiping from the left edge of the
| screen feels pretty good. But Android's approach is probably
| better at providing a decent UX with terrible apps.
| RomanAlexander wrote:
| Gesture navigation is the standard in android these days.
| The OS-provided bar isn't even default on budget oppo or
| Xiaomi devices.
| realusername wrote:
| It's indeed very rare to have this large navigation bar
| on Android nowadays, I suspect the latest Android doesn't
| even support it.
| hpaavola wrote:
| Android (14) still supports it, it's in Settings > System
| > Navigation mode (on Pixel devices, different
| manufacturers might put it in other menus). I still use
| it and will keep using it.
| gvurrdon wrote:
| Same here; I found the swiping very difficult. I have
| also had a small number of people ask me how to switch to
| buttons.
| realusername wrote:
| Interesting, I had no idea they kept it! That's going to
| make my life much easier when testing if my apps work
| with it
| mort96 wrote:
| Ah, I see. I haven't used Android in a while.
|
| Then I don't really see what differentiates iOS and
| Android at all, other than that iOS still usually has the
| button in the top left.
| nine_k wrote:
| In which apps is this the default? I can't think of a
| single one where a swipe were used to navigate "back" and
| "forth". Gestures are everywhere, but never in the
| capacity of the back button.
| goosedragons wrote:
| Do you use Android with gesture based navigation or with
| the old style 3 buttons? With gesture based navigation,
| swiping back is the same as the old back button in any
| app.
| wildrhythms wrote:
| What do you mean? Flagship Android phones haven't shipped
| with a physical back button in years. Gesture navigation
| has been the norm for quite a while. And it works when
| apps use that system for its navigation patterns, which
| in my experience is every app on Android, including 3rd
| party.
| jeroenhd wrote:
| If you enable gesture navigation, swiping from the side
| of the screen emits a virtual back button press. It's an
| OS level gesture (that apps can attempt to disable, but
| that can be overridden by the user). This doesn't require
| apps to implement anything it they implement normal back
| button behaviour already.
|
| Several brands have removed button navigation by default.
| I think you can still enable it in the settings, but the
| button bar at the bottom of the screen seems to be the
| exception these days.
| runeks wrote:
| > The convention is that it's in the top left [...]
|
| Safari is bottom left.
| pflenker wrote:
| In the logic of Apple's design patterns, the button on
| the bottom left doesn't take you back a view. It
| manipulates the browser view and asks it to go one step
| back. I'm not saying that this is really the best way to
| reason about it, but at least it's internally consistent.
| rezonant wrote:
| As sibling commentor pointed out, the default (and
| standard) way to go back is a back gesture, there is no
| button to press anymore. The OS teaches you how to do this
| with an overlay tutorial. My mom, who is 68, was able to
| figure this out without any help when she upgraded to a
| Pixel 4A several years ago.
|
| What is surprising to me is that using a Back button that's
| at the top of the phone would be acceptable to you. That's
| definitely the hardest part of the UI to reach one handed,
| and yet going back in an app is definitely something you
| should be able to do quickly without having to stretch your
| fingers to reach it. Perhaps you prefer smaller phones, but
| those are becoming pretty rare these days.
|
| > The convention is that it's in the top left and that the
| "swipe rightward from the left edge of the screen" gesture
| also goes back
|
| So what's fun about that is from an iOS developer
| perspective, this is not always free, and the back gesture
| itself only works within your own app unless you do
| additional work. This is probably why you mention
|
| > But Android's approach is probably better at providing a
| decent UX with terrible apps.
|
| As I could imagine the app's back navigation is a factor
| you must consider when the OS doesn't handle it. It's not a
| dimension that matters on Android- as all apps are going to
| play nice within the back gesture system automatically
| unless they block it intentionally, even if the app isn't
| particularly good. I cannot recall any app I've come across
| that actually blocks the back gesture (not even games,
| remote desktop, Steam Link).
| mort96 wrote:
| I don't think that a back button at the top of the screen
| is very usable. I think it kinda makes sense to have it
| there, but it's not something you should be using as the
| primary back input.
|
| I don't know what you mean by "the back gesture itself
| only works within your app". I assume there are cases in
| Android where one app took you to another app and you can
| do the back gesture to go back to the app you came from?
| Anyway, the iOS model is that the back gesture just
| navigates within the app, and there are other features
| for navigating between apps. I won't make an argument
| about which is better, but I don't think iOS's model is
| obviously much worse.
| alexdbird wrote:
| > What is surprising to me is that using a Back button
| that's at the top of the phone would be acceptable
|
| This is why iOS added the back gesture, over ten years
| ago now, when phones started getting taller.
|
| > from an iOS developer perspective, this is not always
| free
|
| As an iOS developer since years before that gesture was
| added, I must disagree. The gesture comes for free unless
| you break it. Apps without back gestures smell like bad
| orgs.
|
| If you build some custom navigation you won't magically
| get it, because it's interactive and you need to make
| your navigation interact, but people are generally
| discouraged from building custom navigation. If you do go
| down that route it involves an _astonishing_ amount of
| code to reproduce interactive pop.
|
| > and the back gesture itself only works within your own
| app unless you do additional work
|
| I'm afraid I also have no idea what you're trying to say
| here.
| cout wrote:
| I thought "swipe rightward from left edge" was usually
| "open the hidden menu" except in browsers.
| mort96 wrote:
| No, swiping right from the left edge is pretty much
| universally "go back". Trying it now, it's true in pretty
| much every app with a navigation model where "back" makes
| sense; Mail, Settings, Notes, Bitwarden, Messages, Ivory,
| Nextcloud, a bunch of banking apps, Files, Signal, Slack,
| etc etc. If an app has a navigation model where "back"
| makes sense but swiping rightward from the left edge
| doesn't go back, I get very surprised; it pretty much
| never happens. I think Google Maps is the only example I
| can think of at the moment (and Google is generally
| impressively bad at following iOS platform conventions in
| my experience).
|
| I guess Discord is an example of an app where swiping
| from the left opens a hidden menu, but that "opening the
| hidden menu" thing can be thought of navigating "back"
| from the channel view to the server/channel list view. In
| any case, it's not an example of a situation where there
| is a "navigate back" option on the screen but swiping
| from the left edge doesn't trigger it.
| tacker2000 wrote:
| Im trying the edge swipe thing now again on my iPhone and
| it's pretty finicky and i sometimes need 2-3 times to get
| it right.
|
| So, like in the past, I will dismiss these swipe gestures
| after a while and revert to hunting for the back button in
| the end.
|
| Also, lots of apps have their "Done" or "Close" buttons on
| top, which are equivalent to "back".
|
| Apple should really enforce some consistency here.
| mort96 wrote:
| Huh, I don't think I've had to retry the back gesture
| once, it's always just worked. Are you using a case which
| makes it hard to access the screen edge or something?
| alexdbird wrote:
| > their "Done" or "Close" buttons on top, which are
| equivalent to "back"
|
| Are they though? The former are for a modal, back is for
| a stack.
|
| Apple likes to have a strong model of where things came
| from. Animations, verbs and gestures follow from that. In
| my experience of Android, things just appear/disappear
| with often arbitrary animations, which add nothing, it's
| like a cargo cult says an animation must go here but it
| doesn't matter which one. I prefer iOS's consistency
| here.
| layer8 wrote:
| What's worse is that the same apps have the same buttons in
| different places depending on if you're on iPhone or iPad.
| While different form factors have different affordances, this
| is just bad for muscle memory.
| yakubin wrote:
| Action which I find much more useful than Back is Up. I'm
| always annoyed when someone hands me their Android to do
| something and I need to go through 10 screens hitting Back
| instead of Up. I almost never want Back. I want Up. This is
| also reflected in my use of Finder on Mac e.g. where I often
| hit Cmd+Up, but never Cmd+Left.
| dep_b wrote:
| It is fixed on the OS level, but some people claim hybrid apps
| are indistinguishable between native apps. Except every time:
|
| - Swipe LTR (on a LTR locale) does not go back
|
| - The back button's size is exactly as big as it looks, instead
| of extending quite a bit below it's visible box in the
| navigation bar
| rezonant wrote:
| > - Swipe LTR (on a LTR locale) does not go back
|
| Do you mean on iOS? Because on Android, both swipe from edge
| rightward and swipe from edge leftward both mean back when
| using the default gesture navigation settings, regardless of
| the RTL/LTR direction of the content or device locale. This
| is a side effect of the fact that Android _does not have a
| notion of forward_. I 'm not convinced they _should_ have
| done this, but eh.
| dep_b wrote:
| I wasn't sure, I guess books are read from the same side in
| every culture?
|
| iOS UINavigationController and the SwiftUI equivalent
| support it by default and it takes effort (or a crappy
| hybrid implementation) to stop it from working.
| gbil wrote:
| The worst case of all is when a submenu on the control panel is
| open, then it doesn't matter if I swipe from the bottom or try
| the back gesture, I need to click somewhere in the screen to
| leave this menu.... Inconsistency FTW
| Shrezzing wrote:
| Escaping an already-playing 30 second YouTube advert on their
| iOS app may be the most challenging UI experience in the modern
| era. I've landed on forcefully closing the app, and re-opening
| it as the only escape.
| hnlmorg wrote:
| I generally prefer iOS to Android but man you're so right.
| The number of times I've had to forcefully close an app (not
| just YouTube) because I cannot figure out how to go backwards
| in the UI stack.
| GuB-42 wrote:
| Android was, I think, even better in the early days.
|
| It had 4 hardware buttons: back, menu, home and search. They
| lost menu and search along the way. Sure, they weren't always
| needed, but they were common enough functions that could
| warrant dedicated buttons. Now, everything is different and you
| never know how to popup a menu (hamburger menu? where? or is it
| a swipe?), even though it is always the same functionally.
| rezonant wrote:
| Well, the menu and search were always context-dependent from
| what I remember (ie, on devices that used on-screen buttons
| as opposed to hardware buttons, they were only present when
| the app requested them to). This created a situation where
| the buttons were sort of weirdly sized and bolted onto the
| side of the standard three button layout. This wasn't ideal-
| and I don't recall an app that made particularly good use of
| them.
|
| > Now, everything is different and you never know how to
| popup a menu (hamburger menu? where? or is it a swipe?), even
| though it is always the same functionally.
|
| Well if it's a hamburger menu than you can see it, and drag
| out sidebars can be checked with a drag in the middle of the
| screen (but not from the left edge lest you activate the back
| gesture), so it's pretty quick to figure out.
|
| However I will nominate the Soundcloud app as _the single
| worst_ app design I have seen when it comes to menuing. It is
| absolutely atrocious, and actually uses none of the above
| options. I 'll leave it as an exercise to go try it out if
| anyone wants to laugh at bad app design (sorry if anyone who
| worked on it is reading this).
| pigcat wrote:
| Can you expand on the design sins of the Soundcloud app? I
| use it a lot and have never noticed anything particularly
| funky. I'm on iOS.
| rezonant wrote:
| I hope it's better on iOS.
|
| On Android, you have 5 tabs at the bottom: Home, Feed,
| Search, Library and Upgrade. Having Upgrade in the same
| place that nearly all other apps have a Profile/Settings
| tab constantly trips me up. I'm actually a Next Pro
| subscriber too, so it feels a bit shitty to devote so
| much of the experience to extracting more money from me.
|
| And... well let's look at some user tasks:
|
| Task 1: Go to the app's settings
|
| Settings is only found on one of these tabs! Which one
| would you guess?
|
| That's right! It's Library!
|
| Task 2: View your SoundCloud notifications
|
| Notifications is also only found on one of these tabs.
| Which one? That's right! It's Home.
|
| Task 3: Start casting
|
| Casting, perplexingly, is offered on the Home, Search,
| and Library tabs, but in different locations.
|
| --
|
| This is exacerbated because each tab remembers your drill
| down independently, because after you leave a tab on a
| particular drill down, and you return attempting to
| access one of the top options, they won't be there any
| more.
|
| That upper right corner is the second most likely place
| to have a profile/settings menu, and they technically do
| have it there, but it's split up bizarrely and completely
| inconsistent throughout the app :*-(
|
| I constantly have to retrain my brain to deal with these
| things, and it's really only a challenge in this app.
|
| There are some other smaller things that annoy me, like
| how the "Showing last 7 days" time range selector in
| Insights (for artists) opens a full screen picker, but if
| you use the Back button in the upper left or you use the
| back gesture, it skips back to the previous page instead
| of closing the full page selector.
|
| I'm sure there are more but honestly just these are
| enough to irritate me whenever I use it.
|
| All this said, there are a lot of cool parts of the app--
| the scrubbable waveform in the playback drawer is really
| slick, and though tapping on the large background to
| pause isn't the most discoverable, it's also very cool
| that they managed to have zero buttons on this view and
| for it still to be quite capable. It's also really
| responsive and not very error prone to open and close the
| drawer by gesture, even though swipe left/right are track
| skip gestures as well.
|
| And Soundcloud's "Playback History" is something I wish
| literally any other audio/video app would add. But I just
| lost how to access it while I was navigating around. It's
| in there somewhere.
| abirch wrote:
| A navigation that I'd love to see on Android is swiping right
| to go forward
| extraduder_ire wrote:
| That would be quite hard to do without a special case, since
| the default action of the back button is to pop the current
| activity off the stack and return you to the prior one. (I
| know too much about this from trying to add a button in an
| existing app to do the same thing)
|
| It's a shame it's not available though. It'd be useful for
| navigating tab history in firefox. (currently, hold down back
| button and select from menu)
| ragnese wrote:
| > It'd be useful for navigating tab history in firefox.
| (currently, hold down back button and select from menu)
|
| Can you achieve this in Android Firefox when you don't have
| the UI back button enabled (because gestures are the
| default)?
| jeroenhd wrote:
| Android's back button gesture isn't handled by the app, and
| Android currently doesn't have a global "forward" key. I
| don't think we'll see a forward swipe soon.
|
| I'm also not so sure about the ergonomics of thst approach,
| I'm sure left-handed people would get annoyed that either
| their back gesture is now harder to pull off, or their
| forward gesture is pointing backwards (and doesn't work on
| right-handed phones).
| runeks wrote:
| > Don't let developers use patterns, fix it on OS level.
|
| I think Apple hasn't done this because it's not practically
| possible.
|
| For example, if it's possible to change the content of a view
| (which it obviously should be), then it's possible to remove
| all content and and replace it with all new content. If
| triggered by some user action, this _effectively_ is "going to
| a new screen". But the OS-level gesture won't work since the
| developer in question didn't use your proposed OS API call
| "createNewView", but instead just replaced the content of the
| current view.
|
| However, Apple _could_ make use of this OS API mandatory in
| order to pass review. Although I still think there 's some
| subjectivity around what is "a new view" (that I can "go back"
| from) versus "an existing view with stuff changed" (that I
| can't "go back" from).
| nine_k wrote:
| It is very possible to do so that
|
| * There is a dedicated control for going back to a previous
| view / state, that control is always positioned by the OS in
| a predefined location, and cannot be removed or disabled.
|
| * The OS automatically does the right thing, that is,
| navigates to the previous view, unless the developer has
| jumped through hoops to override this behavior (e.g. to warn
| about unsaved data).
|
| Android does this, and it's very helpful and natural.
| nani8ot wrote:
| Gesture support on iOS feels natural because it's
| implemented by the application (?).
|
| On Android back gestures usually aren't 1:1 because they
| behave like a back button. Swipe and let go, then the back
| action is executed.
|
| Firefox on desktop Linux has better gestures than Android,
| namely swiping to the right goes back and swiping to the
| left goes forward. Firefox on Android doesn't, because the
| OS treats swiping in either direction as a back-button
| action.
| Aeolun wrote:
| iOS does this too. It doesn't mean I can't override it. And
| that's what many, many, many people do. Try using an app
| made in Unity on iOS or Android. It immediately feels
| janky.
|
| iOS has many faults, but not being able to go back is not
| one of them.
| ho_schi wrote:
| The _Share Menu_ is the worst. How a human being should figure
| that out?
|
| If offers: * Contacts * Applications
| * Vertically * Horizontally * Other items
| below. * But only after you've figured out, that it
| needs pulled up. * It is always placed in a different
| locations of an app and the icon has nothing to do with "Share"
| or "Copy/Paste".
|
| People grown up with smartphones can handle it, as usual you
| can adapt as long as you weren't older than 40/50 upon
| introduction. Most of modern stuff is horribly designed and
| often unreliable (Hello AppleTV. Can we speak today about
| changing a WiFi-Password? Why you don't reboot when I press the
| ON/OFF-Button? It is needed to workaround bugs).
| dgellow wrote:
| I have the perfect example. In safari iOS, "Share" is where
| the "Search in the page" feature is located! Just, why?!
| walteweiss wrote:
| Oh, thank you! Twelve years iPhone user here. Never knew
| it's there.
| lotsofpulp wrote:
| It is also in the URL/search bar, type whatever you want
| to find on the page instead of a website address and the
| bottom option will be "On this page".
| walteweiss wrote:
| I used this option just a couple of times when I
| desperately needed to find something on the page. Most of
| the time I'm not sure where that option is, so usually I
| just google it right before using.
| dgellow wrote:
| Oh wow, that's also pretty hidden, I never noticed it
| ho_schi wrote:
| Oh. I've always used the URL/search bar. Only your post
| made me aware that there is also a "Search" hidden in the
| share-menu.
| arrrg wrote:
| It's redundant placement. You can also just use the url box
| to search the page. Seems like a good pragmatic approach to
| me.
|
| Could they also introduce some kind of page action menu?
| Maybe.
| dgellow wrote:
| How do you search the page via the url box? I don't see
| the option
| alexdbird wrote:
| Type a search term, results from the page will appear
| below the $search_engine suggestions.
| pohuing wrote:
| You can see that it's draggable because there's a drag
| indicator at the top. That's what the small elongated oval is
| supposed to indicate.
| ho_schi wrote:
| Hm? I don't recognize/see a drag indicator. There is a tiny
| elongated black oval at bottom (like always).
| pohuing wrote:
| No you're right, I misremembered. It is android that has
| a drag indicator for bottom sheets
| Aaargh20318 wrote:
| > Going back on Android is easy, and back can mean multiple
| things.
|
| For me, this is one of the worst things about Android. There is
| zero consistency in what the 'back' button does. Even as a
| developer this is something I struggle with, what should the
| back button do in a specific case? Does it go back to the
| previous screen or does it go back one level in a drill-down
| navigation (which can sometimes, but not necessarily always, be
| the same thing).
|
| Sometimes it's up one level in the navigation structure,
| sometimes it's go to the previous screen. Sometimes it's close
| a dialog. Sometimes it's even close the application. Depending
| on the context it could any of these, and it can be unclear
| which one if multiple could apply. The only way to find out is
| press the back button and see what happens.
|
| I hate ambiguous user interface elements. When I click on
| something I'd like to know what action it will trigger.
| wildrhythms wrote:
| >Sometimes it's up one level in the navigation structure,
| sometimes it's go to the previous screen
|
| Seems consistent to me?
| markandrewj wrote:
| Small note, most people go back using the gesture navigation
| for Android now days. It's also consistent in going back a
| screen normally.
| eddd-ddde wrote:
| It's analogous to the browser navigation. It's entirely to
| the app to decide which screens and interactions are part of
| the navigation tree and which are not.
| maxsilver wrote:
| I'd argue this is a good thing. In Android UX guidelines, the
| "back" button's "promise" is not that you go back to a
| specific item, it's that you unwind your most recent action
| (notably, _not_ unwind state, it 's not an "undo" button,
| just that it unwinds the most recent _action_ ).
|
| Apps get to decide what metaphor makes sense for an "action"
| (maybe it's a page, a screen, a dialog, etc). But users can
| be confident that the "back" button always takes them
| "backwards", even if the metaphor various apps use may
| differ.
|
| Users can feel reasonably safe that the "back" button will
| take them "back" one 'step' or one 'action' worth, even if
| the app is using panels instead of pages, or modal dialogs
| instead of inline alerts
| shimon wrote:
| I think the Android approach is: the back button usually
| does what you want, unless what you want is consistency.
|
| Thoughtfully designed apps tend to set up clear
| expectations and deliver on them. Thoughtless or malicious
| apps can be confusing or intentionally mislead.
| moritzwarhier wrote:
| I disagree, and side with the sibling comments consensus:
| having switched from Android to iOS this summer, this was the
| largest friction for me - this and the bad onscreen keyboard,
| and the buggy text selection (editing URLs is a chore,
| holding the spacebar to move the cursor is broken when you
| move too far...)
|
| Also this has always bothered me before switching whenever I
| used a friend's iPhone for a moment.
|
| The trouble alread begins when some link in Safari opens a
| 3rd party app.
|
| Sounds weird, but Apple could really learn a lot about UX
| from Google regarding this "go back" interaction.
|
| It really was a joy how reliable it works even for inception-
| level nested app interactions.
|
| On iPhone, half of app switches (at least) require me to
| swipe up or go to the home screen.
|
| And positioning the unreliable sometimes-available back
| button at the top left has made me drop my phone at least
| once.
|
| For all that's to like about iOS, "navigation patterns" are
| not one of them for me.
| matchbok wrote:
| You can swipe left/right on the very bottom of the screen
| to switch "back" to apps. The back swipe gesture is for "in
| app" navigation and is much better than what Android has.
| The Android back button can do like a million things:
| dismiss keyboard, go back a page, switch apps, go home,
| etc. It's a mess.
| moritzwarhier wrote:
| Thanks, didn't use this before. I'm not a big fan of so
| many similar gestures though. I already sometimes
| accidentally switch tabs in Safari by swiping. Using this
| app-switch gesture from safari seems like a nightmare
| when first trying. And generally pretty fiddly. Maybe it
| needs getting used to.
|
| The swipe area is very small on the vertical axis and
| there's also some risk of hitting in-app buttons,
| especially if apps place buttons at the bottom --
| although I guess this is discouraged. It's especially
| annoying when using a phone cover. And I like mine -
| iPhone would be unusable for me without it because it's
| also much more fragile than all my previous budget
| Android phones.
|
| Will try getting used to it though.
|
| Re your "It's a mess" comment: I've never had a problem
| with the android back button, it always did exactly what
| I expected and it was easy to build an intuition for it.
|
| The context-dependand behavior always seemed very well
| thought-out to me, because I never ever had to think
| about it.
| pickingdinner wrote:
| And iOS is all that plus the ambiguity of the existence,
| location, and look of the button/action itself.
| layer8 wrote:
| One of my pet peeves is that there is no universal equivalent
| of a context menu. There's long press, there's the share button
| that is often used not just for sharing but for all kinds of
| context-menu-like functions, there are other buttons or
| hamburger/ellipsis menus, there's the swipe left/right on an
| item with additional actions appearing and sometimes a
| "More..." secondary menu, there's the text-edit "tap a
| selection and wait for a second or two for some options to
| appear", and so on. The respective menus that may or may not
| appear also differ in their looks.
|
| The lack of a uniform UI pattern for what is right-click on the
| desktop already surprised me way back in iPhone OS 3. Long
| press would have been the obvious choice, and you could have
| had a uniform context-menu function everywhere. Users would
| just learn "when in doubt, long-press for any and all
| additional actions" and wouldn't have to try different
| gestures, look into the share menu or other random menu
| buttons.
| Tarq0n wrote:
| The swipe sideways on an item is the worst, i once spent half
| an hour trying to delete a sleep record in the health app.
| layer8 wrote:
| Even if you know an action is under swipe, it is often
| difficult to avoid triggering the default swipe action and
| to drag just the right amount if you really want to select
| one of the non-default swipe actions, or conversely
| (especially on iPad) you may have to drag inconveniently
| far to trigger the default swipe action. It's just a bad UI
| pattern.
| matchbok wrote:
| Back can mean multiple things? That's a good thing? Sheesh. The
| Android back button as been broken for years.
| eviks wrote:
| > Swiping right from the left edge of the screen does the same as
| pressing the Back button.
|
| Wish you could disable that, so common horizontal scrolling in
| web pages that don't fit activates the Back function
| Unfrozen0688 wrote:
| I always turn the button navigation on for Android phones on
| setup. Only gestures are terrible navigation.
| MaxikCZ wrote:
| Depends on the gestures, I guess. I have all gestrues by
| swiping from right side and cant be happier (back, home, swap
| last used app, list of last used apps, splitscreen, power
| button). All the same swipe, forked by the swipe direction
| (upwards, sidways, downwards) and whether I hold the finger
| down after finishing gesture.
|
| Its amazing, and one of the main reasons I wont be switching to
| apple. Who thought that the back gesture should be swiping
| right from left edge? Why not left from right edge? Doesnt make
| any sense for right-handed people..
| jakey_bakey wrote:
| I'm dead excited for 2040 when SwiftUI can handle all of these
| patterns natively.
|
| And, maybe for 2043 when our n-3 OS target will let us support
| them in our app.
| geniium wrote:
| I love the design of that page. Very clean and informative. Very
| visual. Well done!
| hackernewds wrote:
| iOS does this reasonably well
|
| > A typical iOS application has a fixed architecture-often a
| hierarchical tree with multiple levels. This rigid struc- ture
| makes navigation options pre- dictable. Structural navigation
| pat- terns give users confidence about where they came from,
| where they are in the hierarchy, and how to navi- gate back to
| where they came from.
|
| whereas on Android, sometimes the 'Back' gesture lands you on the
| previous page and sometimes it completely closes the app. it's so
| inconsistent that I dropped 12 years of using Android and
| switched to iOS.
| haint_ wrote:
| It has been like that right from the start. It amazes me that
| you put up with it for a whooping 12 years before deciding
| you've had enough.
| iamflimflam1 wrote:
| When I first started developing for the iPhone (back when they
| first released the official SDKs) Apple were really hot on their
| Human Interface Guidelines and had really good documentation on
| what made a good UI along with standard patterns to follow.
|
| That seemed to completely vanish when they went with the "flat"
| design - mainly I think because none of it made sense anymore.
| They went from very clear:
|
| - make sure the user interaction is obvious
|
| to
|
| - this might be clickable, or it might be some text or maybe it's
| a long press...
| Charlie_32 wrote:
| Are there any good app examples of what Frank says here?
|
| "A step-by-step sequence should be contained in a modal overlay
| for presentation to emphasize that the Back button in this
| context serves a different purpose than in a hierarchical drill-
| down.
|
| The step-by-step process is usually completed with a Done or
| Close button, which also closes the containing modal.
|
| The sequence can have a variable number of steps and different
| paths depending on the options selected."
| leokennis wrote:
| Frank Rausch created the best Wikipedia app ever, "V for Wiki"*
|
| So when he speaks about iOS design and UX, I'm inclined to
| listen.
|
| -----
|
| * https://web.archive.org/web/20211223231349/https://v-for-wik...
| russelldjimmy wrote:
| On a side note, what ever happened to V For Wiki?! I used to
| use it every day and one day it just stopped working. Looked it
| up on the App Store and found that it was missing. I was
| heartbroken :(
| leokennis wrote:
| I believe development stopped at some point, but the app of
| course remained working frozen in time. But then earlier this
| year Wikipedia changed their API and the app stopped working
| definitively.
| jeffybefffy519 wrote:
| I recently moved from iphone se to a later iphone without a home
| button, the user experience is so much worse. I accidentally take
| screenshots all the time and find it slower to navigate back to
| the home screen.
| pcurve wrote:
| I agree. You also get 'trapped' on some screens because all of
| a sudden you've lost all navigation cues, even the swipe up
| bottom nav.
| hbn wrote:
| If you ever lose the bottom home bar it just means you're in
| a full-screen view where they want to prevent accidentally
| swiping to go home, like a full-screen video or a game. In
| those cases you just have to swipe up once to re-enable the
| home bar, and then again to actually go to the home screen.
| Aerbil313 wrote:
| Btw, does anybody know the proper way to quit home screen
| "Search" in iOS? Currently I swipe up to close the keyboard and
| then tap the empty space at the bottom of the search screen.
| Seemed like a bug the first time.
| hbn wrote:
| Are you talking about the Spotlight search you get when you
| swipe down on the home screen? Doing the typical home swipe up
| from the bottom should get you out of it. Same for the app
| library search.
___________________________________________________________________
(page generated 2023-12-13 23:01 UTC)