WWDC 22 Digital Design Lounge — Explore Design Navigation

Explore navigation design for iOS - WWDC22 - Videos - Apple Developer
Familiar navigation patterns can help people easily explore the information within your app — and save them from unnecessary confusion...
It struck me that tab bars and navigation bars are, at least in principle, identical to the original iPhone interaction paradigm. I’m wondering what the biggest difference you’ve seen in navigation is, since that first iPhone?

I love this question. I wish I had the time to answer more thoroughly. Here are some thoughts about tab bars and navigation bars: these components and interaction patterns clearly resonated with people. Maybe that was luck, maybe it’s a pattern that reflected our natural understanding of how things are organized and arranged already in the world around us. But they have evolved and modernized while staying true to what ‘just worked’ originally. As people’s comfort with apps grow, new patterns emerge to support new complexity such as sidebar being a solution specific to a new device and form factor.

Tab Bar

Should tab bar button items always automatically scroll to the top when the tab is already active?

If I’m understanding your question correctly, your tabs should maintain state. They should be scrolled to the top of view on first launch and when the screen scrolls, even if a person taps another tab, the previous one should maintain state.

I mean if the user scrolls down in the active tab view, and then taps that same tab (not a different one), should it be expected that the view jumps back to the top? Just wondering because I think I've seen this happen in some apps, but in other apps nothing happens.

Yes, tapping the currently selected button in a tab bar should scroll the content view to the top. Also, tapping the status bar. But this is really a power feature. Not sure how many people are aware of this functionality.

Tab Items

No Home Tabs! This isn't even a question, just a statement 😛
Can you please tell this to my Manager and Designers directly? Every time I have to fight not to have a Home tabs. Most of our Home tabs are just buttons that switch tabs, or show the content of the individual tabs twice 🤦🏽‍♂️

Tell them that Apple designers will be very disappointed to see a home tab in their UI ☹️ And point them to this video!

In reference to not creating a "home" tab, what are your thoughts on having "cards" that are overviews of content from a different tab? Would you consider that a duplicate?

Great question. This is highly dependent of the context and content of the app. Be cautious of cards that display unrelated or disparate types of information and make an interface feel like a dashboard. Dashboards are similar to Home tabs, as the information is not directly related and often overloaded. This makes it difficult to glance and takes longer to understand the relationships and how to take action.


We’ve seen some apps that have a wide array of Widgets that can be configured like a dashboard. It can be very powerful, especially on iPad. But these widgets would take you to the corresponding tab in the app.

The wonderful crusade against home tabs reminds me of the one you did for hamburger menus many years back. Are there other common app conventions that you see that you disagree with?

Thanks for remembering that session. It was YEARS ago.

We have a few, mostly they center on design conventions that come over from other platforms that could be adapted to match Apple platform conventions.

For example, drawing a back button as an arrow (with a tail) instead of a chevron ( < ).

(^ that's an android thing)

Tab bars that have a button in the center that performs an action rather than navigating to a location in the app.

"Home" is such a lazy name for the app's first tab! But the argument that's often given in its favour is that people understand it because that's how the first page is often referred to in web and app design and changing it would mean forcing people to change their already established habits.

Would Spotify / Twitter doing away with the home tab be a risky UI move that could lose them followers or a much needed navigation cleanse?

We can’t speak about what other companies should do, but I don’t consider risky moving to a more intuitive labeling convention, this way you ensure predictability and intention.

Specificity is always a good thing. If there’s a more descriptive word to use, it should be used.


And even web is starting to move away from the "home" concept. I have a feeling it will end up in the same category as having a floppy disk represent "save".

Wondering where "featured" tabs would fall—are they just home tabs with a different name or could they actually be considered useful?

Hard to say a blanket "yes or no" because it depends on the content inside the tab. We do "For You" tabs where the content inside changes dynamically based on what we think is relevant to the user. That could be considered a "featured" section but its use case is specific enough from navigation that it can be its own page.

Where it gets iffy is when you're just repeating the same content as in your navigation put on a page. That causes confusion with whether people should use the tab bar or Featured page to access information.


Recommended & feature articles could be highlighted under the Articles tab, instead of having a dedicated tab. I’d say, as said above, that it would be case by case and depending of the level of personalization the app offers.

In the "Explore navigation design for iOS" session there is an example of a "Profile" Tab which I've seen several apps using, but others like f.e. the Appstore uses Profile as button in the top-right side.

Does that depend on the importance of such a Profile screen ?

In other words, What makes something to be a "tab-worthy" ?

Great question. This is a judgement call based off of the importance of the profile. In many cases, the profile is not that important to the apps main functionality and it isn’t needed as a tab bar item.

When considering what should be a tab, think of your apps menu of options. When tabs are designed well, they tell a story at a glance about what your app can do and how people can use it. Profile tends to be less important in the scheme of things.

And just because you have tabs to use, doesn’t mean you have to use them all. Sometimes an app will feel more approachable if the tabbed navigation is simplified.


Agree. Also, if the user needs to access the Profile content regularly and you don’t want to place a profile button in the nav bar of every tab, a profile tab may be a better option.

How do you feel about a “more” . . .  button?

We're not fans of those either in the tab bar. They're very non-descriptive of the content that's inside and end up being a giant junk drawer in most IRL cases. Similar to the dreaded hamburger menu! Better to be purposeful about what the menu contains for navigation purposes and give it a specific  name and icon.

Tabs are great, easy to implement and to grasp for a user. The thing that mostly confused me in the past where designers misusing these concepts, e.g. by adding an action to a tab icon.

Totally, those are toolbars! Actions = toolbars. Navigation = tab bars.

Conventions

One that comes to mind that might've been mentioned in that session is avoiding the standard Apple platform icon for share sheet button.

Yep! That one gets my blood boiling. 🙂

Also, kabob menus (three vertical stacked dots) instead of an ellipses symbol.


For me I personally dislike icons without labels. Unless you think your icon is universally understandable across all cultures – because it usually isn't 😛

When do you recommend hiding the navigation bar when pushing a view? Ex: Apple News: When you open an article, the app pushes the article view and hides the main navigation.

It’s true that News doesn’t follow the typical convention we recommend for tabbed apps. I can’t really speak for the News team, but I believe the thinking was that people don’t generally switch between tabs frequently or want to persist state in each tab since the content changes all the time. People drill into articles, read, and then often leave.


You could consider temporarily hide the Navigation Bar for immersive experiences, just be sure to allow the reverse interaction and show it when swiping down or tapping the screen.


In that usage pattern, persisting the tab bar to allow for fast lateral navigation, or keeping it visible to help people stay oriented, is less of an imperative. This is pretty atypical for tabbed apps though.

I saw in Sarah M's session that there were Places cells with a ... button on their top right side. In what cases should we use such a button?

I believe you’re referring to the ellipses SF Symbol in the navigation bar? We would use this button for secondary actions that are related to the view, but perhaps not the primary actions someone would take.


"..." More menus are typically used to host a set of additional actions vs. navigation. You'll often see designs conflate the two.

I would love to hear the Design Teams thoughts on Kebab Menus and Floating Action Buttons! (I get a feeling they fall in the same boat as Hamburger Menus and Home Tab Bar Items 😄)

Most of these components are problematic for other reasons. For example, FABS tend to cover elements of an interface which can be difficult to read or interact with the content behind the action. They also tend to be duplicated across tabs and the redundancy, shows that the action lacks context.


And yes to all of the above, a lot of those paradigms you'll see on Android and it instantly makes people feel as if the design wasn't intended for an Apple platform.


Yes to above! I should add that FABs aren’t verboten on iOS but the action should be VERY important and VERY frequently used. Otherwise they get in the way. Things and Notes are two good examples of where a FAB makes sense. Problem is a lot of other apps use FABs for an action that isn’t all that common.

I saw in the session that there are list section headers that are bold and bigger than normal section headers. In which cases should we use these?

They’re a relative recent change to iOS (last year I think). It’s a matter of taste and judgement I think. But they’re particularly effective when the list is text only. It helps created needed differentiation (or grouping) between content items and category labels.

If the list items are visually distinctive, larger section headers might not be needed. But, personally, I think they’re an improvement in all situations.

I saw a tweet showing batch editing in the iOS 16 Photos app and apparently it uses a progress indicator at the bottom that reminds me of an Android-style snackbar/toast. Do you have any guidance on this UI element?

https://twitter.com/apollozac/status/1534903049373761537

We have progress indicators on iOS currently
https://developer.apple.com/design/human-interface-guidelines/components/status/progress-indicators.


We don't currently have published design guidance on that particular style of progress indicator (when it becomes more common the platform we'll consider).

Although from prior experience I can say that what that toasts are tricky to work with. The one you're seeing in iOS 16 is nice because it's using a deliberate "x" close button so people can dismiss the UI and it knows the process takes long enough that the toast won't magically disappear in 1 sec making it impossible to read or interact with.

So it's not disappearing automatically after the batch edit has completed? I need to try it myself, I guess…

It is disappearing automatically after the batch edit completes, but the reason it appears in the first place is that batch edits take time so it's appropriate for this context.

Another "heated" topic: where to put the X/close/cancel button - top left or top right? Are there really no guidelines about it? Confuses the hell out me (as a user and developer).

I totally understand how this could be confusing. You’re right, top right accessories are used for the main actions. But in the case of Modals there might be other resources more suitable - like buttons - to convey important actions. So Close takes the top right place.

I’d say that prioritization of the actions on screen are key here, once you have a clear understanding - you could decide what’s the best pattern to follow.

Styling

In the demo app shown, the Navigation Bar was hidden but the toolbar items was still showing. Is this new in iOS 16?! 😊

That’s a standard navigation bar with the background blur removed.


The image goes behind the navigation bar and it’s optional to remove its background, but for TAB BARS it’s not recommended.


Yes, the background translucency should not be changed or removed on the tab bar. On a navigation bar, it can be an aesthetic choice if it doesn’t hinder the user experience.

Recommendations

What are some books/resources that you would recommend every designer to read for design guidance, creative inspiration, best practices, etc (besides Apple's HIG, of course)?

For me:

Resources

I would love to have the design templates available for Affinity Photo and Designer. Is this something you are considering?

We are continually considering what apps to support for the ADR. 😉 Feedback Assistant would be a good next move.

Are there resources we can share with more web-minded colleagues? It can be difficult to explain that apps and websites should not have the same navigation design.

Absolutely! developer.apple.com/design

Also this video 🙂

I’m not sure we really speak explicitly to web designers per se, but this should be a helpful primer on Apple platform design patterns.


Also more specifically all the content inside "Navigation and search" in the HIG https://developer.apple.com/design/human-interface-guidelines/components/navigation-and-search/navigation-bars

As well as modality: https://developer.apple.com/design/human-interface-guidelines/patterns/modality

Show Comments