▲ 589 points
back
245 comments
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.
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.
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
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.
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.
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.
Apollo was the best iOS app ever made. RIP.
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.
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.
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.
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.
> 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.
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.
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.
> 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).
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”.
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.
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
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.
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.
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.
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
Back can mean multiple things? That's a good thing? Sheesh. The Android back button as been broken for years.
> There are no patterns
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.
A navigation that I'd love to see on Android is swiping right to go forward
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.
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.
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.
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.
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...
> 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
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.
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...
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.
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.
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."
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.
I always turn the button navigation on for Android phones on setup. Only gestures are terrible navigation.
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.
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.
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.
I love the design of that page. Very clean and informative. Very visual. Well done!
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).
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.
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).