[Due for payment 2025-03-17] Use persistent bottom tabs in Settings to improve Workspace Editor UX

[shawnborton]

We're currently displaying Workspace Settings in the equivalent of a full screen modal. This means you can't easily navigate between Inbox, Search, and Workspace Settings - each time you close the Workspace Editor, you need to navigate back to Settings > Workspaces > Launch the workspace editor.

Let's make it so that the bottom tab bar in Settings is persistent or sticky, in that even after you navigate one or two levels deeper, it remains:

CleanShot.2024-06-17.at.10.17.43.mp4

Other notes for completeness:

• We'll want to reshuffle the ordering of the LHN items for Settings so that Workspaces is higher up on the list and more discoverable (and always above the fold)
• We don't want to modify any of the existing native app back button behavior (this came up in Slack)
• If you are navigated a level or more deep within Settings, tapping on the Settings tab in the bottom tab bar should bring you back to the top level of Settings

Figma for this is here

cc @Expensify/design @mountiny

Issue Owner

Current Issue Owner: @CortneyOfstad

[mountiny]

Waiting for updates from SWM

[mountiny]

Asked for an update here

[mountiny]

Will follow up with the team

[mountiny]

Asked here https://expensify.slack.com/archives/C04878MDF34/p1720655134137259

[WojtekBoman]

Hi! Sorry this took a while, but there was a lot of navigation issues recently, and we needed some time to clean things up.
We investigated this topic together with Adam. Here are our thoughts:

The main change that we need to introduce is the possibility to display BottomTab conditionally on every page in the app, not only within the BottomTabNavigator (the way it's currently done). This approach requires some deeper changes to the current navigation architecture and may cause issues.

The first visible issue is connected with displaying bottom tab component in several navigators. Currently, it's rendered once in the BottomTabNavigator without any conditions, but to solve this issue we'd need to display it depending on the page and screen width (its position would no longer be fixed). It may cause small flickering of the bottom tab during transition between screens as the bottom tab contains the floating action button which has very complex logic.

Another problem is the inconsistency of the animations. Currently, when we navigate between screens with the bottom tab, we don't display any animation, and when we navigate from the bottom tab to the central pane, we have a slide animation. Now central pane screen can have a bottom tab, so sometimes when navigating to the CentralPane we would show an animation and other times not. This is presented in the video below.

So to sum up: as I mentioned earlier, the display of BottomTab on any screen in the app is related to the refactor of the navigation architecture. In the current structure we use BottomTabNavigator to display the bottom bar, now it would no longer be the responsibility of this navigator, so we will have to develop a new approach to handle display of the bottom tab.

What do you think about these considerations? Would you like us to continue working on this?

Screen.Recording.2024-07-09.at.16.48.22.mov