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

[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.

[adamgrzybowski]

Hey, @mountiny I posted an update here but I guess it will be better to communicate on this issue.

Currently, I am working on the POC

[mountiny]

Thanks for the promising update Adam

[adamgrzybowski]

👋 Hey guys!
I thought it may be worth briefly describing the POC I'm currently working on 🛠️

Currently, our root navigator is the one handling the split view. The first route is always the BottomTabNavigator containing all sidebar screens.

This may be problematic if we want to navigate to the bottom tab screen from a central pane screen on a narrow layout. We have to pop all other screens from the root navigator to uncover the first route.

The idea is to create many smaller split navigators that we can push on the root. There will be a split navigator for each of the tabs:

• ReportsNavigator
• SearchNavigator
• SettingsNavigator
• WorkspacesNavigator (It doesn't have to be a separate button than the one for settings)

Now we will be able to push one split navigator on another one and we don't have to pop anything

This and the conditionally rendered bottom tab should be a solution for our issue.

There will be other benefits from these changes 🪨 🤾 🐦‍⬛ 🐦‍⬛

• Root navigator won't have the split responsibilities anymore. This is great because sometimes resizing can change the root state key and this can break the history.

• Many split navigators grouped by tab and related functionality should be easier to understand and maintain than one big root navigator.

• Because of separation, we prevent a whole category of bugs: sidebar and central pane out of sync.

• The split navigator will only have a sidebar screen and central pane screens, it will be easier to implement for native platforms.

I know the last one may be especially important given how this issue is going.

Excited to work on this issue! Back to coding! 👨‍💻

cc: @mountiny @WojtekBoman

[mountiny]

🪨 🤾 🐦‍⬛ 🐦‍⬛

That sounds very promising! Thanks for the write up

[shawnborton]

What's the latest on this one? cc @JmillsExpensify

[adamgrzybowski]

Hello everyone! An update from me.

As mentioned earlier, the goal we want to achieve requires changes in navigation architecture.

I know that persistent bottom tabs don't sound like a big feature so it should be quick to implement but please keep in mind that these changes are much deeper and will make navigation simpler and more reliable. It should also fix at least a few of the old problems that would be unsolvable otherwise.

Thanks in advance for your patience 🙇 and back to the update:

In the POC I am working on I managed to replace BottomTabNavigator and central pane screens with many split navigators. Those are quite big changes but the app handled it pretty well.

Changes mentioned above require modifications in some places related to navigation

linkTo: This function has been a pain for quite a long time. I rewritten it to do 90% of its previous functionality with 4x less code. Simplicity should help us with keeping this part bug-free. Needs a bit more work but not much.

SearchPage: With the previous approach we had to have a separate search page for the bottom tab and central pane. It was tricky to handle and fast resizing could lead to bugs. Now we can do it with just one page. I would say it's 80% refactored.

Workspace switcher: Works more or less for the search page and the part for reports is still to be done.

getAdaptedSatet:
This is mainly cleaning the code that won't be necessary anymore. But there will be some adjustments.

goBack:
This function is a pain as well. Implementation of many SplitNavigators should finally allow us to refactor it.

Navigation.ts:
Similarly to the getAdaptedState, mainly cleaning and some adjustments.

FYI: I am going to be ooo for two next weeks. I will have some time on Monday though and I will pass my work to @WojtekBoman.

cc: @mountiny @shawnborton

[mountiny]

Amazing, thanks for the update @adamgrzybowski

[JmillsExpensify]

Agreed, thanks a ton for working on this one. Great update!

[mountiny]

@WojtekBoman @Kicu Any updates for this week even if Adam was out?

[Kicu]

None from me, right now I'm mostly working with Search and if there are search-related nav issues.

[WojtekBoman]

Hey @mountiny, I recently started working further on POC, last week I was involved in topics related to OldDot Rules migration. Now I'm focused on connecting the new navigation logic with storing the policyID.

[adamgrzybowski]

I am back from ooo and I will continue my work on this issue together with @WojtekBoman

[mountiny]

Not overdue

[adamgrzybowski]

Hi everyone 👋 An update from us.

Changes visible to the user 👁️

From visible changes, we implemented @shawnborton requirements regarding bottom tab behavior.

bottom_tab1.mp4

bottom_tab2.mp4

Besides we found two regressions that we also fixed.

Regression 1: Policy should be changed to all if the chat doesn't belong to it.

Before:

policy_before.mp4

After:

policy_after.mp4

Regression 2: Some really weird behavior of search when resizing.

Before:

search_before.mp4

After:

search_after.mp4

Changes under the hood 🫣

However, what changed the most was the navigation structure. We know that the current structure is prone to something I would call the butterfly effect. Small changes in one place can cause regressions in others. My guess is that's how the regressions above were introduced.

That's why we are working on simplifying and bulletproofing navigation.

Here you can see an example of the old linkTo file that grew over time and was the root of many bugs.

And here's the new one.

We believe this approach can help us catch bugs that have not yet been reported and fit well with ongoing efforts focused on quality.

Testing

There are still things we need to adjust, but we think it's a good time to start testing the new navigators. We are removing a lot of complex code so we are expecting some regressions that we need to catch and fix.

Strategy

We talked about testing strategy and we want to utilize two ideas.

The first one
As in previous iterations, navigate around the app to see if the app feels right. We can already start this one.

The second one
Prepare more structured testing instructions.

We did notice that a lot of information about how navigation should work and what are the requirements is scattered somewhere over slack convos or in the closed issues.

We want to prepare a list of the testing steps covering all possible use cases for navigation separated into sections e.g. bottom tabs, go back.

This will be our list of requirements and testing steps at the same time. The idea is to extract them from already solved navigation issues.

Please let us know what you think about this approach and if you have an idea of what would be a good place to store the testing instructions for the navigation. We were thinking about the navigation documentation in the repo. Thanks!

cc: @mountiny @WojtekBoman

P.S. At some point we switched to a different branch so here's the new draft PR #49539

[dannymcclain]

That is so sick 🥹. This is coming along really well (at least from my perspective!)

Regression 1: Policy should be changed to all if the chat doesn't belong to it.

For this one, I think I was under the impression that if you filtered by a workspace, we'd only surface results that were in that workspace. Am I wrong about that? Can a smart person weigh in there? (If I'm wrong about that assumption then I think the fix for that makes total sense.)

[mountiny]

@dannymcclain i dont think so, at least not in the current state of the search we do not consider what workspace you have selected

So that would be a new feature afaik and the above mentioned expected behaviour is correct

@adamgrzybowski @WojtekBoman great job on this one, i think its looking great and having the navigation structure simplified is a welcomed bonus. Regarding the test steps, is that something you want to handle compose or you would like us to create? There are some testing steps already from the navigation refactor doc, they should be in the doc and we can base off them. Asking as it was not clear to me who is supposed to work on that 😂

[mountiny]

I will try to trigger a build on the PR and start testing