Bottom tabs and main menu

[gnprice]

This is our new design for the overall navigation of the app. It replaces the current placeholder home page. In this design:

1. There is a bottom tab bar (aka "navigation bar", in Material 3 terms). It has 6 buttons: Inbox, Combined feed, Mentions, Direct messages, Channels, Menu.

   • All of those buttons except Menu go to screens we already have implemented. Menu is described below.
   • The navigation bar appears only on the screens that it leads directly to. In particular it does not appear on message lists.
   • Changes vs. RN legacy app: Search and Starred move from the top bar into the menu. There's no top tab bar; instead there's an app bar with the current page's title ("Inbox, "Channels", etc.).
   • For detailed design of the navigation bar, see Figma: here, and further details here. Screenshot:
     

2. The screen with the bottom tab bar is the root of the navigation stack; there's no navigating "back" or "up" from there. For how the user reaches the choose-account page (which we currently put at the root of the navigation stack), see below and 4.

   • We will add a button on the loading screen for the home page. When clicked, it brings the user to the choose-account page. This is necessary in case loading the account data takes a long time. This button should only appear after a few seconds of loading.
   • As a follow-up, we need to support logging out an account without UI interacting with the choose-account page UI. This means that the account can be logged out at any navigation level, which is not possible as of now (until we implement Handle invalid API key on register-queue #737 to invalidate API keys). A current side-effect of logging out is that the routes relying on the PerAccountStore of the account will be removed from the navigator stack. We need to ensure that the user ends up on choose-account page when that happens.

3. The menu is a modal bottom sheet. It has the same options as the navigation bar (except Menu itself), plus "Starred messages".

   • In the future the menu will gain more options as we implement them:
     • Settings: Store some client settings #97
     • Notifications screen: Set basic server-side notification settings #661
     • "My profile"
     • Search (but that's a post-launch feature): msglist: Offer search narrows #252
     • and doubtless others.
   • For now the menu will also have a "Switch account" option at the bottom, which just leads to the choose-account page.
     • As a follow-up, we'll put the current organization's name and icon at the top of the menu, paired with an "Organizations" option that does the job of "Switch account": Show current organization's name and icon atop main menu #1037
     • As a further, post-launch follow-up, we'll replace the choose-account page with a new modal menu: Account-switcher modal #1038
   • As a follow-up, we will add the markers for menu buttons: Show counts in main menu and nav bar #1088. They are omitted for now.
   • For detailed design of the menu, see Figma: here, and further details here.
     • For this issue, leave out menu options that are in the design in Figma but aren't mentioned above, or are left as follow-ups.
     • Screenshot:
       

Rationale

This design balances two things we want:

1. It's low-risk in terms of UX, staying fairly close to what the legacy app has. We don't want to get slowed down by having to iterate a bunch.
2. Where possible consistent with point 1, it borrows straight from more-ambitious designs we've discussed. This means it won't require scrapping a bunch of work later on as we add more features, or if we implement something more fully like those more-ambitious designs.

Related links

• Discussion in chat thread.
• Previous issue, which this one supersedes: Overall app navigation for beta #311
• Previous issue in zulip-mobile: UI redesign: main navigation menu zulip-mobile#5513

[gnprice]

This is a complex issue, so we'll want someone on the Zulip core team to handle it.

[gnprice]

A previous draft PR implemented the navigation bar (roughly point 1 from the description above):

• Add bottom bar for navigation, tabs for inbox #578

So that may be a helpful starting point.

[PIG208]

Just to clarify, because we have a button for the @-mentions page, I believe that the bottom tabs should be at least available for a MessageListPage of MentionsNarrow, where a compose box is not available.

Also questions:

• In landscape mode, what would the bottom tabs look like? Do we start centering them at a certain width, or do we stretch them to fit the width of the screen?
• This is a follow-up to 2 from the issue description. Do we want to switch between pages without navigation change? In this case, we might want to refactor InboxPage, SubscriptioinListPage, etc. so that they share the same scaffold, and the body functions like a multiplexer depending on the selected page.

[gnprice]

Just to clarify, because we have a button for the @-mentions page, I believe that the bottom tabs should be at least available for a MessageListPage of MentionsNarrow, where a compose box is not available.

Hmm, yeah, that part will be a bit awkward — either having that one anomalous message list with bottom tabs, or having that one anomalous tab that leads to a page without the bottom tabs.

I think both kinds of anomaly are things I've seen repeatedly in other published apps. Let's start with whichever one seems easier to implement.

(And then potentially this makes a reason to relegate @-mentions to the menu, instead of also being in the bottom tab bar.)

[gnprice]

• In landscape mode, what would the bottom tabs look like? Do we start centering them at a certain width, or do we stretch them to fit the width of the screen?

Answered in chat the other day (after the comment above): https://chat.zulip.org/#narrow/channel/243-mobile-team/topic/UI.20redesign.3A.20root.20level.20nav/near/1982007

• This is a follow-up to 2 from the issue description. Do we want to switch between pages without navigation change? In this case, we might want to refactor InboxPage, SubscriptioinListPage, etc. so that they share the same scaffold, and the body functions like a multiplexer depending on the selected page.

I'm not sure offhand what the right way is to organize the code, or to handle the navigation APIs to manage this.

Looking at the NavigationBar doc, that API seems to clearly want something much like you said: one page, a stateful widget, which provides the Scaffold and its NavigationBar.

Given that, I think the approach I'd try first (because it's my best guess for the right way) is:

• Those page widgets get refactored to be page bodies instead. This should be a small change: basically just return the thing that would have been passed to Scaffold.body, instead of returning the Scaffold itself.
  • Probably can have an NFC prep commit that splits page from body: e.g. make an InboxBody that's what the later steps will need, and a new InboxPage that wraps that. A later step will drop InboxPage.
• This is probably a reason to favor having @-mentions as its own page (so it's an anomalous tab, instead of an anomalous message list). That'd be a messier refactor for that one, because it's just a particular case of MessageListPage.

Probably a chat thread would be a good place for further discussion. I'll more reliably see it sooner and reply, and it's a more interactive medium.