✨ Update the main site navigation

[JoshBeveridge]

✨ Summary

Visit the Figma file • Contact @substrae with design questions

As a part of the UI consolidation work and the incoming user dashboards, we're giving the navigation some much-needed love. This includes the addition of new tools, sub-menus, and an updated mobile menu experience.

---

🕵️ Details

[!TIP] Layout guidance for all states and variants are included within their respective details element. If you have any questions about how to orient or space a particular element, or there is something missing, give @substrae a shout.

Variants

The links included in the nav and sub-menus depend on the "active role" (see #11034). If the user's role's map to multiple navigation roles, then an extra sub-menu appears on the left of the nav menu, with a label that reflects the current active role, and links to dashboards of all the roles the user has access to. (Note that, thanks to #11034, simply linking to a dashboard should update the active role on the new page.)

The links which appear in the Account submenu also depend on active role.

Colors

Desktop colors

The desktop version of the menu should trigger on the l-tablet media query. Because the header remains dark in light mode, the styles for the desktop layout are persistent across both modes. The only exception to this rule is the fly-out for sub-menus, which is detailed below.

• Background: base:all(black.9)
• Links: base:all(white)
• Active/hovered item: base:all(secondary.lighter)
• Divider: base:all(white.5)
• Sub-menu background: base(foreground)
• Sub-menu border: base:all(1px solid background.darker)
• Sub-menu link: base(black)
• Sub-menu active/hovered item: base(secondary.darker) base:dark(secondary.lightest)
• Notification bell: base:all(white)
• Notification dot: base(tertiary)

Mobile colors

The mobile version of the menu is fully color responsive to the user's chosen mode, with the colors specified as follows:

• Trigger backgrounds: base:all(gray.darkest)
• Trigger labels/icons: base:all(white)
• Trigger notification dot: base(tertiary)
-
• Page overlay: base:all(black.light.85)
-
• Background: base(foreground)
• Links: base(black)
• Active/hovered item: base(secondary.darker) base:dark(secondary.lightest)
• Divider: base:all(background.darker)

Hover states

Hover states should use the secondary.lighter color and persist across light and dark modes.

The only exception to that rule is within sub-menus where the background does in fact change, meaning the light mode hover should use secondary.darker and swap to secondary.lightest in dark mode.

Focus states

Focus states for the desktop menu should also translate to the mobile menu, and remain the same in both light and dark modes. Note that the focus states for the first and final element in the row exceed the space available in the container; this is intentional to ensure visual alignment while not focused and enough padding for each element while focused. Reach out if you have any questions.

Desktop experience

Logged out

The following options are presented when the user is completely logged out of the platform:

• Home - Takes the user to the root homepage
• Find a job - Takes the user to the browse jobs page
-
• Sign in - Takes the user to the sign in info page
• SIgn up - Takes the user to the registration info page

Logged in, applicant, no other roles

The following options are presented when acting as an applicant who has no access to other roles:

• Home - Takes the user to the root homepage
• Dashboard - Takes the user to the applicant-role version of the dashboard
• Find a job - Takes the user to the browse jobs page
-
• Your account - Triggers the applicant-variant of the account sub-menu
-
• Notification bell - Opens the notifications pane

Logged in, applicant, other roles

The following options are presented when acting as an applicant who can also switch to one or more roles:

• Applicant - Triggers the role sub-menu
• Home - Takes the user to the root homepage
• Dashboard - Takes the user to the applicant-role version of the dashboard
• Find a job - Takes the user to the browse jobs page
• Your account - Triggers the applicant-variant of the account sub-menu
• Notification bell - Opens the notifications pane

Logged in, manager

The following options are presented when acting as a manager:

• Manager - Triggers the role sub-menu
-
• Home - Takes the user to the root homepage
• Dashboard - Takes the user to the manager-role version of the dashboard
• Find talent - Takes the user to the talent search
-
• Your account - Triggers the manager-variant of the account sub-menu
-
• Notification bell - Opens the notifications pane

Logged in, community

The following options are presented when acting as a community:

• Community - Triggers the role sub-menu
-
• Home - Takes the user to the root homepage
• Dashboard - Takes the user to the community-role version of the dashboard
• Recruitment - Takes the user to the community processes table
• Find talent - Takes the user to the community-specific search table of all qualified users
-
• Your account - Triggers the community-variant of the account sub-menu
-
• Notification bell - Opens the notifications pane

Logged in, system admin

The following options are presented when acting as a system admin:

• Admin - Triggers the role sub-menu
-
• Home - Takes the user to the root homepage
• Dashboard - Takes the user to the admin-role version of the dashboard
• View users - Takes the user to the platform-wide users table
• Manage processes - Takes the user to a table of all processes on the platform
• System settings - Triggers the system settings sub-menu
-
• Your account - Triggers the community-variant of the account sub-menu
-
• Notification bell - Opens the notifications pane

Desktop, when scrolling

This is new behaviour, but now that the platform has so many tools and views, I'm proposing that we enable position: sticky behaviour on the nav element only so that users can maintain their sense of location and context. This will need to be paired with top: 0px so that the nav sticks to the very top of the viewport when the user scrolls past its initial location.

Mobile experience

[!CAUTION] The mobile menu is going to require some thorough manual accessibility testing to ensure that it functions as expected. In practice, it should act in a similar way to a <dialog> element, where, when open, the user's focus is looped within the menu and focus can't be transferred to the main page's elements unless the menu is closed (using the trigger or the ESC key).

Closed, logged out

By default, the menu is closed and the trigger to open it is pinned to the bottom-right of the screen; this is a departure from our current approach which is to just stack all the menu links at the top of the page, which takes up an enormous amount of vertical space, preventing the page's content from being obvious at first glance.

Open, logged out

When the menu is opened, an overlay is applied to the background, the ability to scroll the main page becomes locked, and the trigger's label and icon should change to x Close.

Closed, logged in

When logged in, the menu trigger is accompanied by a notification button. This button should trigger the notification pane, as described in the "Notifications, open" requirements in this list.

Notifications, open

When the notifications trigger is activated, the icon should swap to an x icon. The notifications pane should then open in the same fashion as the menu.

Should the notification pane exceed the available vertical space, it should begin at the top of the viewport and fill the screen below the trigger buttons. The pane should be scrollable and end at the positioning outlined below. This behaviour is the same for when the menu pane itself exceeds the available height, as outlined below in the "Open, larger than screen" requirements below.

Open, logged in, applicant, no other roles

When logged in, the "Sign up" and "Sign in" buttons are replaced with a details version of the appropriate account menu. The collapsed and expanded versions are pictured below. Please refer to the previous requirements for spacing.

Open, logged in, applicant, other roles

When the user has more than one role available to them, the role switcher sub-menu (as a details element) is added above the main menu, below the theme and language toggles. This image shows the collapsed and expanded states for that sub-menu, as well as its placement.

Open, logged in, manager

When switching roles, the menu changes as described in the desktop requirements, but with the mobile layout. The image below shows the manager version, with the account sub-menu collapsed/expanded.

Open, logged in, community

When switching roles, the menu changes as described in the desktop requirements, but with the mobile layout. The image below shows the community version, with the account sub-menu collapsed/expanded.

Open, logged in, system admin

When switching roles, the menu changes as described in the desktop requirements, but with the mobile layout. The image below shows the admin version, with the account sub-menu collapsed/expanded, as well as a version with the system settings sub-menu expanded.

Open, larger than screen

Should the menu be opened on a device that doesn't have enough vertical room to contain the menu, it should open in such a way that the top of the menu starts at the top of the screen, and the menu runs behind the triggers. The menu should then be able to be scrolled vertically to the point where the bottom of the card reaches its natural position as shown below.

Sub-components

[!NOTE] The sub-menus described below are specific the desktop layout of the menu - the mobile version should handle sub-menus as simple <details> elements.

Role sub-menu

This sub-menu only appears for users who have access to more than the applicant role on their account. Choosing an option from the role menu should take the user to that respective role's dashboard assuming they have the correct permissions.

The role sub-menu is unique in that it's label changes to match the current selection. This is helpful because it allows the user to see, regardless of their location on the site, which role they're currently acting as.

System settings sub-menu

This sub-menu is specific to the system admin role and allows for easy navigation to the CRUD interfaces for individual data models. Each item in the sub-menu should take the user to that item's respective index table, from where they can manage that particular data model.

Account sub-menu, applicant

The following options are presented when acting as an applicant:

• Applicant profile - Takes the user to the screen that allows them to edit their applicant-specific profile information
• Career timeline - Takes the user to their career timeline
• Skill library - Takes the user to their skill library page
• Account settings - Takes the user to their universal account settings
• Sign out - Logs the user out of their current session

Account sub-menu, manager

The following options are presented when acting as a manager:

• Manager profile - Takes the user to the screen that allows them to edit their manager-specific profile information (note that this doesn't exist yet)
• Account settings - Takes the user to their universal account settings
• Sign out - Logs the user out of their current session

Account sub-menu. community

The following options are presented when acting as a community:

• Account settings - Takes the user to their universal account settings
• Sign out - Logs the user out of their current session

Account sub-menu, system admin

The following options are presented when acting as a system admin:

• Account settings - Takes the user to their universal account settings
• Sign out - Logs the user out of their current session

---

Acceptance Criteria

### ✅ Requirements
- [ ] Update initial colors and spacing
- [ ] Add the sticky functionality
- [ ] Create and implement the role toggle sub-menu
- [ ] role submenu only appears if user is logged in and has roles mapping to multiple nav roles
- [ ] Apply the new menu to existing community pages
- [ ] Update the guest menu items
- [ ] Create and implement the new account sub-menu
- [ ] Update the applicant menu items
- [ ] Create and add the manager version and menu items with temporary links
- [ ] Create and add the community version and menu items
- [ ] Create and add the admin version and menu items
- [ ] Create and implement the admin-specific system settings sub-menu
- [ ] Overhaul the mobile experience
- [ ] Perform a manual accessibility check to ensure navigating the menu and sub-menus is coherent and keyboard-friendly
- [ ] Apply the new menu to existing guest pages
- [ ] Apply the new menu to existing applicant pages
- [ ] role submenu contains links to dashboards of nav roles user has access to
- [ ] Apply the new menu to existing admin pages
- [ ] Remove the Admin Layout story

🛑 Blockers

### Blocked by
- [ ] https://github.com/GCTC-NTGC/gc-digital-talent/issues/11031
- [ ] https://github.com/GCTC-NTGC/gc-digital-talent/issues/11034

[tristan-orourke]

For the nav items available to Community roles:

• For the labels on the nav links, I suggest using the same wording our users are used to on the current admin site, to make the transition easier. That would mean using "Processes" instead of "Recruitment", and "Candidate search" instead of "Find talent".
• "Find talent" would be especially confusing, since that also appears on the Manager menu (and the current site) but leads somewhere different.
• I'm guessing this was originally designed for a post-self-referral world, but for now Community roles also need a nav link to view "Talent requests"
• They also need a way to get to the Communities page, analagous to the Teams page which is live on the current site. This is where Community Admins will be able to assign other users to their community.

[tristan-orourke]

For the nav items available to Admin roles:

• as of latest conversations with Lauren, the Platform Admin is intended to be able to act in a kind of oversight role. That means they need to be able to view pretty much everything happening on the platform, even if they can't edit stuff. For now, I think that just means they also need any links we decide to add to Community (like Talent requests).
• Skill Families and Announcements should be added to System settings

[tristan-orourke]

Lastly... there's a new quasi-role I'm not sure how to handle. I mean, technically its a Role like any other - the Process Operator role. But from a user's perspective, its more like a user has been granted full view+edit permissions on a single Process. If a user has Applicant + Process Operator roles, what nav should they see? How should they get to their processes?

[JoshBeveridge]

Okay, finally getting around to your comments:

• I changed Recruitment back to Processes
• I changed Find talent to Candidates (I omitted ... search as I feel it's not necessary)
• I've temporarily added Requests to the community menu
• For managing the community itself, I'm actually going to add this to the dashboard rather than the menu
• I've temporarily added Requests to the System admin menu
• I've added Skill families to the System settings sub-menu
• I've added Announcements to the System settings sub-menu
• Based on our previous discussions, our initial implementation of sharing is going to enable a restricted version of the role's nav and dashboard that provides access to the data and tools specific to the shared permission; this allows us to leverage the UI we're building rather than building anything dedicated for sharing, which we can look at doing later.

A couple other small changes:

• I've standardized a bit of the language down to single words for consistency
• System settings is now alphabetical

~Still going through and updating the 24 billion screenshots though 😂~

[github-actions[bot]]

Status: Error :warning:

Issues blocking this PR:

• NaN :warning: Issue/PR not found

• NaN :warning: Issue/PR not found

  ---

  This comment was automatically written by the Blocking Issues bot, and this PR will be monitored for further progress.