Navbar: A composition-based version of Header
What is the use case for the component you're requesting? To easily create site navigation menus that are consistent and responsive.
Landscape analysis Some examples...
- Material UI - https://mui.com/material-ui/react-app-bar/
- Carbon - https://carbondesignsystem.com/components/UI-shell-header/usage/
- Bootstrap - https://react-bootstrap.github.io/components/navbar/
It is a common need to have list navigation on sites. There is a lot of need for a component that easily builds site navigation that contains tabs that function as text, links or drop-downs. It is also important, and necessary, that these components respond appropriately on different devices. Specifically, collapsing the menu into a hamburger menu is most desirable.
Features that I think would be needed/nice to have...
- The ability to have drop-downs for tabs
- The ability to have links for tabs
- The ability for tabs to have icons
- The ability to choose how the collapsed menu is shown... Full page view - https://www.si.com/ (view on mobile and interact with hamburger menu button in top left) Side nav view - https://www.google.com/ (view on mobile and interact with hamburger menu button in top left) Expand - https://mui.com/ (view on mobile and interact with hamburger menu button in top right)
- A prop for controlling the collapsed state of the menu (defer all control to user, no automatic state changes)
- A prop for prominent style (extra padding)
- A prop for sticky header
- A prop for navigation alignment
- Slot for beginning of navabar
- Slot for end of navbar
Examples of how this component could be used to create more consistent experiences...
JSTOR

About Site

Support Site

Additional considerations I think it would be important to consider how this component would be used in tandem with the header component. Maybe this component serves as a suplement to the header component, in which case there wouldn't be as much of a need for feature suggestions 5-9. Those features would most likely be desired on the header component instead. However, maybe this component would be intended to be the header itself in which case those features are necessary and we may need to think of others that may be necessary for a header component. As of right now, the PharosHeader component is strictly a slot machine that is specific to JSTOR and JSTOR only.
I believe this component will help develop more consistency across current and future Ithaka sites and applications.
A few thoughts to inform some further direction here:
- One big reason for the current inconsistency is that the latter two examples above are using things that aren't Pharos to accomplish their entire site header situation
- The extra padding called out as a "prominent" style may only be a function of inconsistency or implementation limitation rather than intentional design choice in each instance
- Ditto for the alignment
- I'm wary of introducing slots until we have demonstrated use cases for filling those slots with specialized content
- Ditto for stickiness
@shoupeva-ithaka might you elaborate about the items regarding dropdowns, and if/how they aren't covered by the existing DropdownMenuNav component?
The features weren't necessarily ones that aren't present in a current Pharos component, but rather ones i would desire to have if a new navbar component were to be created. So yes, the DropdownMenuNav does offer that functionality already and would most likely be used inside of a navbar component (or at least inherited from, i.e. PharosSidenavButton vs PharosButton). Maybe I am wrong, but I feel like there could be benefit from having a component that can build out navigation from a passed prop and respond to mobile devices.