Secondary logo option

[mwengren]

What should we add?

Conversations with the NMFS/CETACEAN group looking to deploy a new site under IOOS.us raised the requirement to potentially add logo/branding other than the IOOS/IOOS.us content that's in our standardized header.

Just wanted to capture that requirement here for tracking. No good suggestion on how to do that, other than to encourage sites where this is needed to embed a logo beneath the standardized IOOS.us header/menubar in a site-specific menubar (red area below):

We could also consider shrinking the top banner size and/or the blue IOOS.us menu bar vertical height to save some screen space at the same time - a large banner and two rows of bulky menu bars will eat up a lot of screen pretty quickly.

Ideally, we want to avoid sub-sites customizing the header configuration, even though this is possible, because it will prevent centralized bulk IOOS.us-wide header updates if individual sites are using their own.

Reference

No response

[nguyandy]

I like the idea of shrinking the top banner/blue bar!
Are you thinking of applying this across all instances? There's also the option to add a "compact" config option to the ioos header/

[mwengren]

@nguyandy Could we make 'compact' the default and instead have an 'expanded' option? If there's an example that shows what that looks like, please share, or if not just a screenshot would be great.

I don't think I've seen what that looks like (or remembered that existed). We'll need to document that somewhere if it isn't already so site implementers know of the different options available, whatever they end up being.

Is this something that can be set outside of the shared menu bar code as a CSS/display option, or would that mean a site would have it's own custom version of the menu to maintain if enabled?

[nguyandy]

@mwengren , at this time, there's no config option for a compact setting, but it's not a heavy lift to add.
ex: <ioos-header compact>

Because the header/footer components are built on the shadow dom, the parent site is unable to style these components - and these components are unable to style the parent website letting us avoid any type of styling conflicts. Like adding a "compact" option, we can definitely add a style config allowing parent sites to pass in CSS if this is something we want to do.

But in the meantime, I did push a compact version of the header up to https://hfradar.ioos.us/dev
This retains the menu text size, however shrinks down the padding/logos. We're looking at a reduction from 135px -> 100px with this change.

[mwengren]

@nguyandy I like the compact version! I'd vote for just making that the default.

I might need to chat sometime to understand how adding a style config would help or how it would work, exactly, but in any case, I think the compact view should allow enough space for CETACEAN or other sites to add a secondary menu bar w/logo if they want.

It might be a kind of noisy UI with two menu bars, but hopefully will meet the need if it's a requirement for anyone to do that.

If the style approach would allow a sub-site to inject something like a logo without modifying the shared header/footer components themselves, then I could see reason to pursue that.

[nguyandy]

@mwengren I updated the component to use the compact version. You should see this change reflected across all the new IOOS sites using the new header component.

RE: the style approach - this can really be any attribute really. We're able to pass in overrides+options, just a matter of figuring out what type of option we want to provide. Here's an example of passing in a custom menu config to the header component as a POC.