Modern iOS Navigation Patterns
frankrausch.com
frankrausch.com
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.
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.
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.
(https://minesafetydisclosures.com/blog/2018/6/18/costco, though it's from 5 years ago so things might have changed)
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.
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.
I barely use the app except for the card and an occasional lookup for something not available in store.
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.
Looking forward to the EU's sideloading rules coming in though, so I never have to deal with this.
-
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.
* 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.
That's actually the reason I'm about to delete my account, the good contributors somehow left.
Honestly, I don’t think I could deliberately come up with a worse design.
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
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
Happy to listen to any feedback or feature requests you may have.
There probably is a magic gesture which I don't know about.
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.
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.
I wasn't even aware it was supposed to be a button
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.
If it's a card webview, just swipe it down from the top edge.
> Switching between the two is very jarring.
I think that's the crux of the problem. Someone who's used to one style and has built muscle memory and some kind of hierarchy and ontology of the interaction with the system will have trouble with a different paradigm. That doesn't necessarily mean there's something wrong with either - they're just different, and some people will prefer one over the other.
Switching between GNOME and KDE, or vice-versa, has a similar effect.
Would be consistent.
> It appears every time [long list of qualifications]
Is inconsistent.
OTOH if the current app was opened manually by the user, it won't be there.
It just feels so “out of space” and tacked on.
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.
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.
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.
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 < Back_to_previous_app is too small. It was clearly shoved into the OS long after the overall design was set. I feel it's correct that it doesn't take over the regular swipe-right-to-go-back navigation. Doing this better would have forced a significant redesign of the fundamental UI paradigms, IMO. That could have been very interesting.
I have not tried Android's event history thing. Whenever anyone hands me an Android to show me something, as soon as I hold it I manage to activate some "home" or "back" or "change app" feature that takes me away from the thing the other person was trying to show me. I've no idea what control I'm accidentally tapping, just by holding the device, but it's pretty consistent. So I'm not yet convinced of Android's improvements over iOS.
UI has no 'correct' approach, the only thing that matters is if people can happily use it.
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.
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.
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.
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.
Safari is bottom left.
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).
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.
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.
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.
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.
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.
- 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
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.
iOS UINavigationController and the SwiftUI equivalent support it by default and it takes effort (or a crappy hybrid implementation) to stop it from working.
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.
> 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).
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.
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)
Can you achieve this in Android Firefox when you don't have the UI back button enabled (because gestures are the default)?
Try starting the gesture and holding it down before completing it.
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).
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).
* 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.
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.
iOS has many faults, but not being able to go back is not one of them.
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”.
Could they also introduce some kind of page action menu? Maybe.
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.
Seems consistent to me?
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
Thoughtfully designed apps tend to set up clear expectations and deliver on them. Thoughtless or malicious apps can be confusing or intentionally mislead.
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.
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.
> the buggy text selection (editing URLs is a chore, holding the spacebar to move the cursor is broken when you move too far...)
I'm right there with you on these.
> positioning the unreliable sometimes-available back button at the top left has made me drop my phone at least once.
As a person with small hands, I hear you. I miss the days of the original iPhone which was probably >90% usable with a single hand.
Even the discontinued iPhone Mini was too large - which I suspect has been most of the reason of its "failure". Comparing with larger phones, the smaller screen is a downside, and it came without the upside of actually being a single-hand device so it's more or less lose-lose.
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.
I think apple gave up a lot of decent design interactions with ios 7. Baby with the bathwater.
is that text or a control? The auto-hiding menus that take away important controls, and require non-muscle-memory actions to resurrect.
I wish the lost certainty could all the themed back on.
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.
>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.
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.
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.
I'm not sure how you'd swipe out of this screen.
I've found it overall simpler and better than both iOS and Android.
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.
So when he speaks about iOS design and UX, I'm inclined to listen.
-----
* https://web.archive.org/web/20211223231349/https://v-for-wik...
Wish you could disable that, so common horizontal scrolling in web pages that don't fit activates the Back function
> 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.
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...
"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."
And, maybe for 2043 when our n-3 OS target will let us support them in our app.
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..
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.
You can swipe between apps using the black bar at the bottom.
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
>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).
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?
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.
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.
(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.)
Labels the buttons with what they DO.
"Don't delete", or "Keep", or "Save", and "Delete", would be appropriate button labels.
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.
> [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.
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.
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...
Then we go to something like Apple Notes where even the slightest bit of data is auto-saved without asking.
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).
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.
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".
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.
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.
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.
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.”
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.
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.
> 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?
Also, there is nothing wrong with a long list.
And I'm not here for hyperbole.
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.
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).
This can be of interest for a few reasons, but particularly because such investigations might reveal “true” design philosophies over espoused philosophies.
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