Navigation in Hylo; web and mobile

[thomasgwatson]

Basic Nav/URL structure

Hylo Navigation url structure largely maps a 'RESTful' hierarchy, to a visual hierarchy, that runs left to right for both url and screen. This url structure has been with us for a long time but now the design/interface is making a clearer distinction that maps to the url structure.

For example, take this image:

/ basically maps to the global navigation on the left (See the PURPLE areas). The items in the global nav allow the user to navigate to different 'contexts'. These contexts include things like specific groups, the users personal context (my) and the public context.

So we get the next part of the url: /:context/:optionalContextIdentifier, and the corresponding reflection of that in what we call the "context menu". Focus on the ORANGE areas. Depending on the context, this menu changes.

Take the next image as an image

With a different context, we get a different menu (in ORANGE).

Then we get to the GREEN areas, what we commonly refer to as the 'view'.

We now arrive at /:context/:optionalContextIdentifier/:view/ and then, beyond that, many views will allow yet another depth. Take this next image

Here we still see we are in the 'projects' view, of a specific group but now we have another layer with the BLUE areas highlighted. We often refer to these with specific optionalMatches, for either a user, group or post. These could be considered sub-views or we have often called them 'detail' views, like PostDetails.

Beyond this basic structure, there are a few urls add-ons that cover creation/editting etc, and smaller url hierarchies.

Mobile

Mobile navigation doesn't use urls; We use React-navigation, and it uses nested objects to map different stacks of screens. The developer and user experience of this navigation behavior is different, even though we have the links mapping of all sorts of URLs to their respective nested screens in the mobile app.

Mobile also has different space constraints; of course we aren't going to fit global nav, context and views on the one mobile screen!

Previously, we have had a left-to-right hierarchy of UI pieces, roughly being: the drawer (that covers most of global nav needs) => the group menu (that covered what the context menu now covers) => view screens, which intermingled views and detail (sub) views. Since there were several layers of this nesting, we also provided a bottom nav, a tab bar menu, that allowed a limited number of key views like notifications, messages, user profile, etc, to be accessed at anytime.

DISCUSSION: Moving forward with Mobile, as of Jan 2025

We have decided to condense the two initial layers together; global nav and context menu. These will both now live in the Drawer. The result of this is that the 'Group Navigation" is now redundant, and should be remove. This combining and screen removal has some not-straight-forward impacts on the nesting style of navigation structure that the mobile app users.

So navigation wise:

All of these things (see image) are in the same 'stack', the HomeNavigator stack. So if you navigate to one of them, and another view from this set is already in the stack, it will be there when the top view is dismissed (when the user triggers a 'go back' action)

Previously, the Group Navigation was always rendered at the bottom of its stack; it was the initial view, and so it was always the last thing in the stack. So we always knew when to choose between 'going back' and opening the drawer. The Group Navigation was the back-stop.

Now we are removing Group Navigation; So we have no straight-forward backstop. As another layer of complication, there is no single screen that can be the backstop, without offering a poor user-experience; Each group now could have a different view (And thus screen) be its default

From here there are several inter-linked possibilities

Courses of action

1. Look at all screens in this HomeNavigator stack; determine all of the true views, aka non-detail views. Whenever one of those is the current screen, and the 'go back' action is triggered, open the drawer. Otherwise, its a detail view and if there is a screen on the stack ("below" the current screen), navigate to that. This sounds a bit clunky but I think it will give us the right outcome

2. Create some sort of defaultScreen, that has the sore job of just opening the correct default view of the group or context that has been opened. I don't think this quite works in react-navigation mobile nav world; basically, I want to be able to use url history commands like replace and redirect, that we get from React-Router. But these don't really exist, as far as I understand, in the mobile space. So, I don't think this option works

3. Separate views and detail views into different STACKS
   Maybe this is a more 'react-navigation' way of separating out the nesting? Then views and detail views are separated out in the nesting, and thus its a clearer distinction. However, this goes against the general advice of "try not to go crazy with your nav structure and have lots of nesting".

4. Reset our nesting structure altogether
   Maybe there are some benefits from a fresh start?

5. Lean more heavily on ModalScreens
   Some screens are available only as ModalScreens. Some screens (like PostDetail, a detail view) exist both as modalScreens and as screen deep in the stack hierarchy. ModalScreens are handled differently than normal screens (going off this https://reactnavigation.org/docs/modal ), and it might be simpler to push (for example) all of our detail views to be modal screens only (we are pushing in this direction somewhat with web navigation as well).

and then, another possible curveball on top of all of this: Our current navigation structure, with all its various stacks, might be a performance drag for lower-end machines: react-navigation/react-navigation#11290
Not sure how to assess this in the context of our app; I need to better understand React-Navigation

Mobile navigation nesting as of 12-JAN-2025

So for the main nested structure, starting at https://github.com/Hylozoic/hylo/blob/dev/apps/mobile/src/navigation/AuthRootNavigator.js

We have two navigator stacks: CreateGroupTabsNavigator and DrawerNavigator and all of our ModalScreens grouped below them.

I'll skip a detailed look at CreateGroupTabsNavigator, it just deals with that specific workflow.

DrawerNavigator, on the other hand, takes us DEEPER....

https://github.com/Hylozoic/hylo/blob/dev/apps/mobile/src/navigation/DrawerNavigator.js

So, it covers the setup for the Drawer, which then wraps all of its spice into the DrawerMenu, and then nests a single screen, the TabsNavigator.

I'll skip the DrawerMenu; its got a LOT of UI in a single screen but nothing nested under it.

So we end up at the TabsNavigator ( https://github.com/Hylozoic/hylo/blob/dev/apps/mobile/src/navigation/TabsNavigator.js )

This renders the bottom navigation tabs, which will now appear in ANY screen nested below this navigator. There are several navigator stacks here, with the primary one being the HomeNavigator

The HomeNavigator takes to our views and detail views. https://github.com/Hylozoic/hylo/blob/dev/apps/mobile/src/navigation/HomeNavigator.js