I’m building a mega nav dropdown with IX2 and I’ve got 2 issues:
Click / Tap interaction means the user needs to click the same element again to close, rather than just off the element anywhere on the page. Which will be confusing…
Hover over works but closes immediately after moving the cursor into the child element (mega nav) underneath it.
Hi @quarshcreative, not sure I understand issue no. 1, but regarding issue no. 2, I think you need to remove the ‘Hide Mega menu’ from the ‘Nav Link Hover’ and set it to the ‘Mega Nav’ click and mouse hover interactions. Hope this helps…
Yeah the hover trigger doesn’t have an ‘Active’ state available in WF as of now. There’s a way to work-around the hover but it’s lengthy. I recommend using a click trigger to hold the hidden menu. I know hover is much cooler, yet on tablet & mobile you’ll want click triggers anyway, so … ehh it’s better to use click triggers throughout.
Kind of a catch-22 huh? Tablet & mobile is so important, I’d stick with click triggers that keep users within the viewport. Try not to use an interaction that makes them scroll - down - then back up - then click to close again. Simple full page overlay, or slide in/out interaction. It takes more planning and organization with layering but I think it’s easier for users to enjoy you’re creativity.
Hey @garymichael1313, I’d prefer to opt for the click trigger but it requires the user to click again on the nav link to hide it, rather than clicking off anywhere on the screen, which is kinda the expected user experience… ya know?
I’m wondering if a hover state for this would work if I nested the Dropdown Mega Nav element within the Nav Link and offset it? I’m planning on using an entirely different menu on tablet and mobile.
Create a div and position it’s z-index so that it’s above the content and below the menu. It will need a position of fixed or absolute (depending on your site) so that it will overlay on top of the page content. Set a click interaction for the new div and choose the animation that closes the menu.
The first click that reveals the menu needs to also reveal this new div. The menu close interaction needs to also hide this new div.
Once setup, first click will reveal the menu as expected. Then the menu can be closed the same way it opened or by clicking off the menu.
Another benefit of this new div is the ability to use it to tint the page content to further draw focus to the menu.
Yep, sure I understand what you’re saying. But remember, what I was alluding to earlier.
The user doesn’t think like we do. They want concise, quick, easy access to the desired link. If you make the menu semi-transparent, it will be subtle enough to reduce design conflict; and it will provide navigation clarity. If you make them click > scroll > click back > and repeat, I would be concerned about the bounce rate.
But, man I certainly feel ya. This is a tough one to decide on. Take this approach.
Will the majority of users visit on desktop, tablet or mobile?
What is the estimated average visit time of each user?
Will there be a customer form to capture user data?
Is the ecommerce aspect the foundation to the site/project?
Will the project managers or a sales team interact with the site users at any point?
Is the menu going to be fairly consistent, or will it be updated often?
I say this because, with these questions the “Menu” should be consistent on each page - even product details pages. You know what I mean? It’s nice when it has consistent colors, location and functionality.
Just throwing out ideas to add. Depending on the interaction with the project owners, users may actually be on their own when visiting. If it’s never going to be “customer-facing”, you may use that as a guide.
Customers will not know the difference on what you and I are discussing. The only thing they’ll know is - they can or cannot find their way.
A dropdown nav may be the final answer! (It’s universal and clear)
That’s exactly what I needed Matt, thanks so much!
The only bug I have now is, if I use the background tinted div as the close trigger, the nav link needs to be clicked twice to reset the interaction for the Mega Nav to show again. Thoughts on why?
Setting the Hide Mega Nav interaction as both the firstandsecond click doesn’t seem to work… perhaps just on the second click? Not sure
Oh… hmm. Check your “Initial State”. If its present inside both interaction sides (1st & 2nd), remove it. Add the initial state as a separate “On Page Load”. Add all the initial states there.
I’m out running around and on my phone I can’t access read onlh sites. But I’ll check if you hit me later.
One small detail. Because you have the hide mega nav interaction on both the nav link and the bkgd tint, when you close the menu by clicking the bkgd it causes the 2nd click on the nav link to do nothing. If a visitor is trying to reopen the menu it will require two clicks on the nav link if the bkgd has been used to close it.
To fix this:
keep the z-index for the bkgd higher than the nav link
remove the 2nd click trigger from the nav link
duplicate the nav link
style the new nav link as the “selected” state style
add a click interaction to the new nav link to remove the mega nav
in the reveal show nav interaction add steps to hide the initial nav link and reveal the new link
in the hide nav interaction add steps to reveal initial nav link and hide the new link
This will avoid the issue overlapping or conflicting interactions by keeping the triggers for the show/hide interactions separate. The hide/show steps for the nav links should be seamless and invisible to the visitor.
Hope that helps. Let me know if you have any further questions.
