Open JoshBeveridge opened 1 month ago
For the nav items available to Community roles:
For the nav items available to Admin roles:
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?
Okay, finally getting around to your comments:
Recruitment
back to Processes
Find talent
to Candidates
(I omitted ... search
as I feel it's not necessary)Requests
to the community menuRequests
to the System admin menuSkill families
to the System settings
sub-menuAnnouncements
to the System settings
sub-menuA couple other small changes:
System settings
is now alphabetical~Still going through and updating the 24 billion screenshots though 😂~
This comment was automatically written by the Blocking Issues bot, and this PR will be monitored for further progress.
✨ 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
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.base:all(black.9)
base:all(white)
base:all(secondary.lighter)
base:all(white.5)
base(foreground)
base:all(1px solid background.darker)
base(black)
base(secondary.darker) base:dark(secondary.lightest)
base:all(white)
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:
base:all(gray.darkest)
base:all(white)
base(tertiary)
base:all(black.light.85)
base(foreground)
base(black)
base(secondary.darker) base:dark(secondary.lightest)
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 tosecondary.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:
Logged in, applicant, no other roles
The following options are presented when acting as an
applicant
who has no access to other roles:Logged in, applicant, other roles
The following options are presented when acting as an
applicant
who can also switch to one or more roles:Logged in, manager
The following options are presented when acting as a
manager
:Logged in, community
The following options are presented when acting as a
community
:Logged in, system admin
The following options are presented when acting as a
system admin
: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 withtop: 0px
so that the nav sticks to the very top of the viewport when the user scrolls past its initial location.Mobile experience
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
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
:Account sub-menu, manager
The following options are presented when acting as a
manager
:Account sub-menu. community
The following options are presented when acting as a
community
:Account sub-menu, system admin
The following options are presented when acting as a
system admin
:Acceptance Criteria
🛑 Blockers