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: @adamgrzybowski

[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

[mountiny]

@WojtekBoman Thanks for the write up, I still think we want to explore this path more.

I believe its common to have the bottom tab on more pages in the app. It kinda felt like our solution is a bit custom before and what we are proposing here is more in line with standard usage of bottom tab navigator

[shawnborton]

Totally agree that we want to explore this further, especially given that we think we will want to reuse this pattern for Domains as well.

[Kicu]

@shawnborton @mountiny we will continue with the research to bring some more specific info. That is mostly done by @adamgrzybowski and @WojtekBoman but I'm sometimes helping a bit.

For now a question to get a bit more specifics:

• Do you guys see any more views at this point where you would like to see Bottom Tab? (asking because the issue started with Workspaces Page). Because I believe adding a bottom tab on every Page is not something we want? (chats? settings?)

The more requirements we know right now - the better the solution will be, and navigation in this app really is quite complex 😅 Every time we want to do some change we need to think about: mobile native apps, wide layout and how would that affect URL/route for browsers.

[shawnborton]

Right now I think we're really only imagining the Settings > Workspaces > Workspace Editor, as well as (soon to be) Settings > Domains > Domain Editor. That being said, I could totally see an argument where we might as well do this for all Settings pages to be consistent, but I don't know if that is really a requirement or not. cc @Expensify/design for any additional thoughts too.

[dannymcclain]

No additional thoughts from me, I agree with your summary!

[JmillsExpensify]

I don't think it's required for the other pages, like profile or security and such, but I do think we should do this for workspaces (and domains in the future). I don't think we need to do it in other places.

[mountiny]

@Kicu @adamgrzybowski Do you have any further questions to get you unblocked? Thanks!

[Kicu]

Hey, we synced with guys and discussed some more details.

First to re-iterate:
The main difficulty in our navigation is that we support both narrow and wide layouts and we expect the navigation to be consistent between the two. That means having a lot of code handling screens on narrow + bigger devices and transitioning from one to the other. In order to introduce the bottom bar in more screens we will have to modify said logic.

We would like to ask if it's possible for the UI/UX people to give us 2-3 examples of apps where navigation and bottom bar behaves consistently and similar to what we would like to have in Expensify in future?
(Some examples of desktop apps (wide layout) would also be nice, but these are harder to find.)
Looking at such apps would help us find any possible edge cases and understand different navigation flows better.

We have tried to search for desktop+mobile apps ourselves, but couldn't find any desktop apps that behave similar to ours. I have checked Spotify, Slack and Notion - not the deepest search but at least these are popular.

Some insights:

• popular mobile apps have bottom bar on some views but not on all of them, like you would expect...
• however desktop apps very often don't have bottom bar, even if their mobile versions has it
• mobile slack shows the bottom tab on different views on ios and android. For example slack chat on iphone will have the bottom bar and on android it will not - I find that interesting but dunno why it's like that;

To sum up, going back to this quote from @mountiny

[...] our solution is a bit custom before and what we are proposing here is more in line with standard usage of bottom tab navigator

I agree with this in regards to mobile apps, but when talking about mobile+wide layout things are not so clear cut 😉

Now for something less serious, here are some first experiments that @WojtekBoman did for the bottom bar 😅

rec-screen.mov

^ I know this is silly, but it shows exactly the kinds of edge cases that we are ironing out right now, to avoid issues later.

[adamgrzybowski]

I agree with this in regards to mobile apps, but when talking about mobile+wide layout things are not so clear cut 😉

Yes, this is an important point. I'd say we have a custom solution for the bottom tabs anyway. This does not depend on the number of screens that do or do not have a bottom tab bar.

What is custom and new though is that we want to introduce a conditional bottom tab depending on the screen size.

[dannymcclain]

Happy to try to look around a bit, but FWIW I think it's going to be pretty hard to find any other apps doing what we're doing. The way we try to maintain consistency across platforms is really not normal, so I suspect it will be difficult to find examples to draw inspiration from. But I'll try to take a look regardless!

[shawnborton]

Yeah, that's my general sentiment too. But to clarify, even if we don't find a perfect example, we can still make progress on this, right?

[mountiny]

Yeah, I agree. The fact our app is trying to maintain consistency pretty hard means that there are not many examples like this. This makes it a bit tricky to handle, I think what could help is if the design team created some interactive mockups with various flows to catch all the edge cases and establish the patterns we want in this updated form of navigation. Would that help to get a better understanding of what the expected output is?

[shawnborton]

Happy to make more mockups and flows if we think the original screenshots/video from the first comment above won't suffice. It's hard to think of any "edge cases" right now since we really only want to apply this to the Workspaces/Domains page.

[mountiny]

more great progress on the PR

[mountiny]

progressing

[mountiny]

Native stack about to be merged

[mountiny]

in progress

[melvin-bot]

This issue has not been updated in over 15 days. @Kicu, @mountiny, @WojtekBoman, @adamgrzybowski eroding to Monthly issue.

P.S. Is everyone reading this sure this is really a near-term priority? Be brave: if you disagree, go ahead and close it out. If someone disagrees, they'll reopen it, and if they don't: one less thing to do!

[mountiny]

PR is getting close, making this daily now

[melvin-bot]

@Kicu, @mountiny, @WojtekBoman, @adamgrzybowski Eep! 4 days overdue now. Issues have feelings too...

[adamgrzybowski]

Working on it. It's close

[mountiny]

All the bugs from the first QA round should be fixed, that did not include hybrid app as we did not have working ad hoc builds yet. I have now asked QA for another round including hybrid and hopefully that is the last one before we can merge this