Open elreydetoda opened 2 years ago
Maybe we can create another dropdown "Support" that combines the links "Sponsors", "Boost!" "Garage Sale" and "Membership". That would solve the issue of too many links.
Awesome idea @reclaimingmytime, although I do think we should keep Sponsors out of the support drop because that's listing all the people who sponsor JB.
If there was a "Sponsor Us" page with a form or something I could see that going under the Support list, but till then we should probably keep that one separate or have another category to group it under IMO.
Although it'd be good to get some feedback from @gerbrent (or just general JB people) on what he thinks about the idea too.
I really like that grouping though :grin:
grouping - helpful!
I'm hesitating on the top-level name "Support" Perhaps since I'm trained on other tech websites, where "Support" means tech support, not financial support. This hesitation alone, at least in my little tiny imperfect worldview, would have me hesitate to investigate that menu.
Anyone else feel this way?
That being said, the category is super helpful to simplify the UI.
As far as the Sponsors page goes - I'm indifferent either way. Sponsors are listed on every relevant episode page, and the Sponsors page here is intended to help listeners quickly find all the Sponsorship codes/links quickly for the whole network, so kinda fits in this category.
BUT!
I'm not sure this Sponsor grouping discussion actually solves the bug above. This ticket should probably focus on the solution to "Why isn't it hamburger-menuing?"
I'm not sure this Sponsor grouping discussion actually solves the bug above. This ticket should probably focus on the solution to "Why isn't it hamburger-menuing?"
I think the reason is Bulma's view-port settings. If it's like other CSS frameworks, it does not switch to the hamburger menu until it reaches a certain size. The navbar is just running off before it switches the to the more mobile view.
I can think of 2 possible routes with this.
it does not switch to the hamburger menu until it reaches a certain size
I'm a laymen, but doesn't this seem like a low-effort, minimum consideration method of accomplishing this feature? I would expect a far more intelligent way to solve the problem as a standard - which likely has challenges I'm not seeing - would be to compare the current page width to the menu width. if page-width < menu-width, then hamburgerize
.
I'm certainly missing something..... right?
alternatively, the menu being larger than the hard-coded size perhaps isn't a common situation.... room to improve here for sure.
To try and put it simply, the responsiveness of a website works around something called viewports. A viewport is a range of pixels between the breakpoints. Breakpoints are the hardcoded value that we use to generally say "Most phones are less than this size", "Most tablets are less than this size", etc.
Bulma has a very similar thing, hence why you can find the class has-text-centered-mobile
on a tag in the HTML. This basically says "if the size of the browser is smaller than the mobile breakpoint, center the text. Otherwise don't touch it"
I think the general consensus is that the hamburger menu is usually for mobile and tablet views. Because of this, the long JB navbar becomes longer than the screen, but we haven't hit the breakpoint yet, so no hamburger menu.
Hope this helps. ps. I am NOT a Front End Web Developer so PLEASE correct me if I got this wrong.
@gerbrent
I'm trained on other tech websites, where "Support" means tech support, not financial support
True, it might seem that way. Maybe "Support Us" is more appropriate?
Regarding the breakpoints of the hamburger menu: Setting a new breakpoint now would mean more work whenever we add or remove items. I believe the live page still needs to be added as a link the header, as an example. One route to go here would be to set the breakpoint width once the menu items are final.
As for the alternative options to display large menus on a desktop screen: Some pages just display few menu items for the desktop screen and display a sort of slide-out menu when clicking on "more", such as TWiT.
I've seen other pages create an overflow menu with a button to scroll over the extra menu items.
Alternatively, we can display the extra menu items below each other. Using the example from the starting post, the link "Community" would be displayed under "Shows" and the navigation bar would be one row taller.
Another option:
Always present the hamburger menu w a large subset of items. Not sure how easy that is technically.....
So, similar to your TWiT example above, the hamburger
behaves like a more...
So I actually have a half baked solution to this in a dead branch. It would resize the links into the hamburger menu as the page size shrunk. It worked nicely, but I abandoned it because it used JS and I heard we were trying to limit that on the site. I can always bring it back and implement it if that sounds like a better solution. It would make the site a lot more dynamic with sizing.
@Lord0fBytes I'm curious to see what you came up with. Can you mention the branch where you made the change?
Just checking in to see if there has been a decision on how to fix the navbar?
Ok so #266 fixes the main issue, by just increasing the breakpoint. In addition, the brand is always showing now.
I'm not closing this issue, since it might still need more enhancement as discussed with all the options above.
@gerbrent could these further enhancements potentially move to 2.0?
An issue that I saw in my PR #129 is that if your screen is probably about tablet size the menu isn't properly responsive. It's got too many items in it and overflows the page, so you can even seen the community dropdown. This is something we'll need to have a bigger discussion about, and if we want to collapse some of those menu options to make it smaller.