[Website] Nav bar design

[carynaudenried]

Design needs

• New look and feel for navigation UI; include existing logo
• Include placement for log in/register button
• Anchor navigation to top of page

[carynaudenried]

@burlexpo Moving this convo to Github.... I'd like to get your feedback on this nav design before I get further.

The issue I'm running into with the existing logo is that it doesn't translate well to small spaces like the nav. The circle makes it hard to scale down to a short space, and the smaller letters become unreadable.

I'm proposing we create a "small space" version of the circle logo for use in the nav, so that you always have a logo present on the page. Here's a mockup of what that could look like. I did my best to match the fonts, but even better if you can get the names of the fonts or the original creation file for that logo so I can use the exact match. What do you think about this approach?

[carynaudenried]

@burlexpo following up here as I catch up! What do you think of the design proposal I posted above using an alternate version of the circle logo for the nav bar?

[burlexpo]

@carynaudenried Thanks for following up! I;m fine with the alternative version of the logo. I wouldn't even worry about the fonts; since the original had to be sort of mashed to get it into the circle, I think yours is close enough. I do have a small, rectangular version I used for the pens.

[carynaudenried]

@burlexpo great, thanks!

Here's what I'm thinking for the full styling of the nav, then. These are ready to be worked on (tagging in @bethlakshmi to take a look )I'm also attaching exports of the smaller logo I recreated - I think it's good to keep the fonts somewhat similar to the original circle logo.

Let me know if anything doesn't make sense. Here's a link to the Figma if that's easier to inspect the details: https://www.figma.com/file/Pk1Of5sOwOdrjftUqiegaL/BurlExpo-Site?type=design&node-id=409-131&mode=design&t=2PI84jeuqY7AKQEV-4

Logo exports (1x and 2x - do we still use 1x assets anymore?)

[burlexpo]

Visually, I like the fonts, organization, and layout a lot. Is this the color scheme you're leaning towards? It seems a little muted for "burlesque", but I don't see colors that well.

The content of the menus, on the other hand, is kind of chaos. They grew sort of organically. I would love your help @carynaudenried creating some organization that made sense

[carynaudenried]

@burlexpo Yes, colors and fonts wise this is what I'm thinking for the nav bar only. My thoughts are that we don't want to go too bold with this so that the actual colors and designs of the pages stand out. Nav bar should generally be a bit more readable and not stand out too much, IMO, if you have cartoony elements that you want to stand out on the pages (which I'm excited to work on next!)

As for the content of the menus -- yes, I would love to work on them, I agree there's some confusing elements that we could simplify. But I purposefully didn't address that here yet, so we could focus on the look/feel first. I can open a new ticket just to focus on the information architecture so that Betty can take on the design updates while we do that.

[bethlakshmi]

comments:

• I am not sure I can get the hamburger to X conversion given the tool I use (Bootstrap) for this... I can fool with it, just not sure.
• also not sure if I can move the carots from side arrow to down arrow when the menu gets expanded. Should be easier than the hamburger to X, just not sure yet.
• So far, can do the rest. I'll start on it soon, I think most of it is not code changes - maybe only the font is a code change.

I'll probably be a bit slow - I'm finishing up a merge users function that is dragging on (but nearly done) and having a whole lot of family life right now

[bethlakshmi]

Are we good on colors? I'm going to start on setting up a complete copy on the test site:

https://burlesque-expo-stage.us.aldryn.io/main/

Where I already have the code to change up the layout. So I'm going to get anal retentive now on height, color, font etc.

[bethlakshmi]

@carynaudenried and @burlexpo - OK, I just did the top level of menus. The settings in figma are partially transparent, and on top of the red curtain background the difference between hover and not-hover seems a little subtle to me.

What do we think?

https://burlesque-expo-stage.us.aldryn.io/themes/style_edit/1

[burlexpo]

@bethlakshmi not sure what you mean by "top level". In the attached is it "Events" "I Want To..." "Conference" etc? Because if so there is no perceptible difference (to me) on hover vs non-hover. The menu items seem clearly indicated on hover, though (see bleow)

[bethlakshmi]

Yes, that is what I mean. The stuff in the black bar at the top.

There is, believe it or not, a slight distinction in the hover. It is very, very slight. If you logout (to get rid of the django cms menu) and then scroll around so that the light color page part is underneath the menu, then the hover difference is a lot clearer.

The way the design calls for it - the menu bar background color, and the hover background color are both slightly transparent. So on the red background, there's a lot less distinction between these two colors than on a light background. And the design in Figma is using a medium gray background, because we haven't picked background color yet.

... so all that is the long way round to:

• do we want a distinct hover color?
• if we do - do we change the menu/hover color or the background color?

FYI - there's more work to do on the LOGIN button - I got it close, but there's more cleanup on hover text color (currently a sickly green color) and probably other aspects there. That was where I stopped for the moment. It used to be a button, so de-button-ifying was a process.

[bethlakshmi]

OK! I think I have it all! Also went through the detailed specs on the right of the figma and I put a few comments in there on where I couldn't get it to work exactly to spec.

@carynaudenried and @burlexpo - can you go over it closely? There's a lot of little fiddly details to these menus. Stuff particularly to look at:

• spacing both for desktop and mobile - expanding and contracting your browser width will show the variations
• hover/focus - when the mouse is over something (hover) or when it was just clicked (focus)
• active - a menu item that is actively shown on screen - changes the look of the menu
• logged in/logged out - the login panel only shows up if you are logged out

Also - I kept the editor up to date with stuff I added so - https://burlesque-expo-stage.us.aldryn.io/themes/style_edit/1 - will show demos of the various menu items in the "Menus" section. I did not do any of the login stuff there - it's in the "Everything Else" section (no pretty demo yet).

I'll work on the active bug (that activity only shows up 1 level deep, not recursively) but the only real blocker to publishing now is a second/third set of eyes.

[burlexpo]

I tested things both logged in and logged out

Thoughts/notes:

• Hovering over the Menu header ("Events", "Conference" etc) is a very subtle change to my eyes.
• Hovering over the menu header doesn't reveal the menu. I have to click on it.
• Menu headers are decorated to show whcih section I'm in
• When i click the active menu header to see the dropdown menu items, the page I am on is highlighted.
• The highlight color for the page I'm on seems to be the same as the hover color.
• Clicking the logo doesn't seem to do anything. Is it supposed to?
• Clicking the header image does take me to the Home page
• The three buttons seem to work fine
• Shrinking the screen converts from "menu" to "hamburger" just fine
• Login panel works as expected

[bethlakshmi]

Agree on:

• Hovering over the Menu header ("Events", "Conference" etc) is a very subtle change to my eyes. - yeah, I'm not sure how to tweak this - could do either a lighter background color so the difference is clearer, or we could do a header with different transparency.
  For comparison - here's the header on the curtains, dark red background:

and here it is on the light panel color:

.... way clearer.

• The highlight color for the page I'm on seems to be the same as the hover color. Yep. That's my bad. Just fixed it. I think I've got it aligned with the design, but check me on this:

  • menu at normal = 65% transparent gray.
  • menu that's active (current page is in this menu) = same (65% transparent) and underlined.
  • menu that you hover over (but did not click) = darker (85% transparent), and NOT underlined
  • menu that you clicked and opened = darker (85% transparent, just like hover) AND underlined That last one was creativity on my part, perhaps. It came about because when in mobile view, the active menu header blends into it's subitems quite a bit but with the underline, it's clear it's the header above the other stuff.

• Clicking the logo doesn't seem to do anything. Is it supposed to? the spec doesn't say anything - but it could. A common thing would be take the user back to the home page?

Other thoughts:

• Hovering over the menu header doesn't reveal the menu. I have to click on it.

Yes, that's how it works now, and that's what bootstrap gives us. I actually really dislike hover menu opening - this article includes my reasons and more. For me, the big one is that I'm really bad at hover menus - they always leave me swearing. But the fact that mobile devices don't have mice so don't have hover is the killer reason, IMO.

• buttons - FYI, also - I was able to create this:

by sizing my window to be smaller but not so small that it flipped into mobile view with the hamburger. I'm not sure there's much I can do about this - but it's a thing to be aware of. Basically - too many menu items + too many buttons = weird scrunchy buttons. Also (second image, see green arrow) - it means that any time a menu item is getting the darker background color, the sizing of the menu item box, is smaller than the now taller header - because of the stacked up buttons.

I'm definitely open to how to smooth this a bit... should I put some spacing between the buttons top & bottom? I could try to make the height of the menu items auto-resize to always be 100% of the menu height...? or we could make sure that this is a rarity. BTW - the magic number is 992 pixels. This is what bootstrap uses as the cutover between a desktop style menu vs. the hamburger menu. So that's the place to test when we're deciding what the menus should be.

[burlexpo]

Hover Header color instead of changing the opacity of the background, could we change the color of the font? From something like white (unhovered) to yellow (hovered)? @carynaudenried what do you think?

Logo Click yes, have it take you back to the main page

[bethlakshmi]

logo click is done.

I have a new theme ready on the main site called "2023 Menu on Top" which I'll cut over to when we are ready to install the new menu. It will need some manual changes at the same time, since I changed some CSS classes around, but I think I've minimized it enough to make it easy to replicate what we have on test on the live site pretty fast (less than an hour)

Now just waiting the color change question.

[bethlakshmi]

Researched the "active" bug - I thought it couldn't do multi-level depth on what page is currently active. That's not true, it works fine.

What doesn't work is any case where I'm using GET attributes as a selector. For example

This works fine: https://burlesque-expo-stage.us.aldryn.io/scheduling/view_list/Special/

This doesn't: https://burlesque-expo-stage.us.aldryn.io/calendar/General?day=05-05-2023

I don't have a way to fix this - the decision on what an ancestor is gets done in Django CMS. But I could change how we map URLs to avoid using GET requests. For example, the not-working URL for a calendar, could instead use the syntax:

https://burlesque-expo-stage.us.aldryn.io/calendar/General/**__**

And the active logic would work just fine.

Do we think this matters? if so, I'll do it under a separate ticket.

[bethlakshmi]

Here's another one on the "does this matter?" - mostly @burlexpo - cause it will be his pain in the ass.

The new design uses Montserrat in place of Vast Shadow. But there's no automatic way to port all the places where our context references Vast Shadow. So, as a result - headers like "Code of Conduct" on the main page look sort of sad.

I can do any of the following: 1 - pull out Vast Shadow completely (currently what staging shows), and leave it to Scratch to update all headers as he sees fit. Montserrat is available in the CK Editor, the way Vast Shadow used to be, he just has to manually update it all. 2 - leave the Vast Shadow font in the list of links we reference in our base html - that will mean that any CMS text properly displays with the Vast Shadow font, but that no new text can be made with it, because I have pulled it as an option from our editor. 3 - leave Vast shadow in the editor, too, so that we can continue to use it.

I lean towards 2 with a later ticket to pull it completely after we've reviewed and updated the text... thoughts?

[burlexpo]

What I would love instead of "Vast Shadow" being some sort of separate thing, is just to be able to set the styles for H1-H6 and if I want one of them to use a specific font in every instance, to have access to those fonts.

[burlexpo]

Active bug it should be consistent. If we're showing people what page they are currently on, we should do it all the time or none of the time.

[bethlakshmi]

Active bug - #505 - OK, working on it. Looks pretty contained.

On the setting of fonts in the editor in Django CMS - I think we need to talk, because I believe that's how it works right now. Because "Vast Shadow" was set as an explicit font, we have problems. I can set a font on the h1-h16 styles and then when you use those styles, that'll be what you get. But what font do you want on what style? Do you want all of them to just use Montserrat?

[burlexpo]

This may be a @carynaudenried question, but I'm pretty sure I don't want all of them to be Montserrat; it's a pretty boring font. I'm thinking "Creepster", "Limelight", or "Poiret One", for the header fonts, depending on which vibe we're going for

There doesn't seem to be a Google font that is close to Budmo Jiggler or Shining Night

[carynaudenried]

Looking over everything now! Sorry for the delay, this has been an incredibly busy month.

Re: fonts -- we don't have to use Monserrat for the header styles -- I was thinking that'd be good for nav and smaller text since it's very readable. I'm open to any font, particularly "Limelight" since it's a bit more versatile and has both caps and lowercase. https://fonts.google.com/specimen/Limelight?query=limelight

[carynaudenried]

First off, Betty, this looks great!

Weighing in on the comments above:

- Hovering over the Menu header ("Events", "Conference" etc) is a very subtle change to my eyes. Yep, this will look much more subtle over a dark background like we have now. I like a somewhat subtle hover state but since we'll probably have a dark background for the site going forward, I'm good to go with Scratch's suggestion of a yellow color for the text instead of the darker opacity background on hover. Something like this? Or maybe we could keep the darker background and also add the yellow color for a bit more focus (color is #FDD76A)

Hovering over the menu header doesn't reveal the menu. I have to click on it. Agreed with Betty on this one, hover menus aren't a great UX pattern as they can be difficult to navigate, esp with our flyouts in the menus. They're also less accessible for visually impaired.

Clicking on the Logo Yep, that should go to the home page -- sorry for not calling that out.

The highlight color for the page I'm on seems to be the same as the hover color. Yep. That's my bad. Just fixed it. I think I've got it aligned with the design, but check me on this:

menu at normal = 65% transparent gray. menu that's active (current page is in this menu) = same (65% transparent) and underlined. menu that you hover over (but did not click) = darker (85% transparent), and NOT underlined menu that you clicked and opened = darker (85% transparent, just like hover) AND underlined That last one was creativity on my part, perhaps. It came about because when in mobile view, the active menu header blends into it's subitems quite a bit but with the underline, it's clear it's the header above the other stuff.**

I see what you solved there -- on mobile it does seem helpful to have more focus on the menu you clicked and opened. I'm good to go with keeping the underline there as well as the dark background/yellow color text we're using for the new hover state for when you've clicked and opened a nav menu.

Buttons at 992 pixels Yeah, for now we can hope this is mostly a rarity -- My thoughts on how to handle this is we have two options:

• Remove the buttons when your browser is between 992 pixels and however wide it is when it cuts over to mobile view
• Add a bit of padding to the buttons top and bottom so they look more spaced out when they do this (maybe 5px)

I'd say maybe let's go for the second option, and we can think about hiding them later if it feels like they're getting in the way. Tablets are still used but probably not as much as laptop sizes or mobile these days.

---

Other comments

Super nitpicky, but I noticed a couple things on the Login menu:

• The font weight is pretty light on the text entry, is it possible to change to Montserrat Regular?
• It looks like the letter-spacing is applied on a couple of the pieces of text in here where it shouldn't -- the "Forgot password?" and "New here? Join Us" links.

[bethlakshmi]

• hover color - love it, done!
• homepage on logo click - done!
• Buttons at 992 pixels - I like that answer... done! definitely option 2 is better looking:

I used margin of 4 px top/bottom, only because that's the easy way with bootstrap, and it seemed close enough. Let me kow @carynaudenried if that's not good enough.

@burlexpo - Fyi, this introduces a bit of fussiness if you ever want to change the buttons. I did them with Django CMS, because that's how you built these buttons in the first place. To make them look nice, I added an attribute for "class" with a value of "m-1" - which is bootstrap-ese for adding the smallest possible margin to the button. If you want to add buttons, I suggest copying one that's there, not DYI-ing it, cause this attribute value is really hidden... -- it's nested at the bottom of the options:

Other comments - fixed fonts on login menu.

Any others?

[bethlakshmi]

I think the only question I still have is about Vast Shadow and whether to keep including it? or to include any other jazzy fonts for use in page text?

[carynaudenried]

@bethlakshmi nice! the 4px looks good, I think option 2 is fine as well.

I'm looking at the staging site and am not seeing any changes to the login menu, is this where I should be looking? https://burlesque-expo-stage.us.aldryn.io/main/

Re: Vast Shadow -- I think if we introduce Limelight as our display font, and Montserrat as our text font, that's enough (and if we want to do something fancier with image headers for certain areas, we're not limited to those two), so my vote is to remove Vast Shadow. However if it's easier to keep it in for the older content, that's fine, but I could see how removing it might make things load faster. Kind of a judgement call for you both.

[bethlakshmi]

Cool if Scratch likes Limelight as the fancy header and Montserrat for text

• I'm willing to manually port all the old Vast Shadow from our CMS text in the interest of removing it and avoiding the ambiguity.

Do you want me to move ALL text to Montserrat? - as in make it the default for anything in the context as well - it's not a big deal, but I hadn't done it yet. And at that point, it would also make sense to make sure I have all the font weights included. I think I only did a few of them, since the Navbar didn't need many.

And - oops! The font weight & spacing changes to the login menu needed a code change, and that got caught in the cross fire of code change vs. deployment syncing - should be good to check now, just double checked myself! Sorry about that.

-Betty

On Mon, Sep 11, 2023 at 12:15 PM carynaudenried @.***> wrote:

@bethlakshmi https://github.com/bethlakshmi nice! the 4px looks good, I think option 2 is fine as well.

I'm looking at the staging site and am not seeing any changes to the login menu, is this where I should be looking? https://burlesque-expo-stage.us.aldryn.io/main/

Re: Vast Shadow -- I think if we introduce Limelight as our display font, and Montserrat as our text font, that's enough (and if we want to do something fancier with image headers for certain areas, we're not limited to those two), so my vote is to remove Vast Shadow. However if it's easier to keep it in for the older content, that's fine, but I could see how removing it might make things load faster. Kind of a judgement call for you both.

— Reply to this email directly, view it on GitHub https://github.com/bethlakshmi/gbe-divio-djangocms-python2.7/issues/492#issuecomment-1714196243, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABCVB43XJ2S3CWRD7ZCR6LTXZ42JRANCNFSM6AAAAAAZ4SC3CY . You are receiving this because you were mentioned.Message ID: @.*** com>

[burlexpo]

@bethlakshmi Let's add in Limelight and if I need to go through and replace "Vast Shadow" by hand, I will.

I think I'd like to go with something like

H1, H2, H3: Limelight in varying sizes (I'll leave the specific sizes up to @carynaudenried) H4, H5, H6: Bebas Neue (https://fonts.google.com/specimen/Bebas+Neue?classification=Display&stroke=Sans+Serif)
Body: Monserrat

[bethlakshmi]

OK, just put up the update:

• headers are set with these font styles
• got the CK Editor used in Django CMS to include these fonts, so that:
  • if you pick a header - you just get the headers with the right fonts
  • you can also set this font as a tag inside anything, with any font size
• found a few other places were I had just replaced Vast Shadow with Montserrat, where it makes more sense to use Limelight or Bebas Neue - so fixed CSS in those places.
• set up Tiny MCE (what we use when editing text inside of GBE code - like the event descriptions) - so that our Admin editing also includes all 3 new fonts. If you just use headers - you'll get the right text (Limelight or Bebas Neue) but the font selection lets you pull it in when you don't want to use the headers that way.

I think that's everything?

If we wanted to do more with the text in the main area of the page, I suggest we do another ticket.

[carynaudenried]

Sounds good. I think we can close this one out! (Or whatever is best on Github, I'm not sure how you want to manage these threads!)

[burlexpo]

Yup -- we mark the issue as closed. We can always re-open it if necessary ;-)