Responsive Side Toggle Menu Enhancements

1) Script Title:
Responsive Side Toggle Menu

2) Script URL (on DD):
http://www.dynamicdrive.com/dynamici...togglemenu.htm

3) Describe problem:
One issue and two suggestions...

Issue: It would be nice to be able to adjust the placement of the top of the menu (vertically). My site included a top fixed navbar. When I implemented the Side Toggle Menu the first <li> entry was hidden behind the navbar. I worked around the issue by including a <br> before the first <li>.

Suggestion 1: Include a parameter (if possible) that would allow for all secondary level <ul>'s to close when another <ul> is opened. This capability is included in the Glossy Accordion Menu.

Suggestion 2: Include a parameter (if possible) that would allow for a hover image for the down arrow. The design of my site uses red lettering (and a red arrow) but the hover is dark brown background with white lettering. The red arrow with the dark brown background is not the best.

One final word... Great menu option and VERY EASY to implement.

jdadwilson

p.s. DreamWeaver did indicate a lot of potential errors from missing semi-colons in the js script.

It should be possible to change the vertical position of the menu by adding "margin-top:2em;" (or some other appropriate value) to the ".sidetogglemenu{" section of the CSS file.

Dreamweaver is just being pedantic. Semicolons are optional in JavaScript but, if the code is going to be minified, it can break if the semicolons are missing. As a lifelong C, C++ & C# programmer I've always used them and never had a problem with JavaScript or PHP.

In order to position the top of the menu beneath the bottom of the fixed navbar, you have to give the navbar an ID, say 'fixed_navbar'. Then you would do, at the end of the body section:

Code:

---

<script>
function navbar()
{
document.getElementById('togglemenu1').style.marginTop=document.getElementById('fixed_navbar').clientHeight+0+'px';
document.getElementById('togglemenu1').style.maxHeight=document.body.clientHeight-parseInt(document.getElementById('togglemenu1').style.marginTop)+'px';
}
navbar()
</script>

---

If there are other elements that you want to push the menu down, you have to take their clientHeight into account too. As an exercise, see what happens if you replace 0 above with a greater number, say 50

Anyone from DD have a response to my suggestions?

jdadwilson

Quote:

---

Issue: It would be nice to be able to adjust the placement of the top of the menu (vertically).

---

You should be able do it with CSS - Try;

Code:

---

#togglemenu1 { top:5em !important }

---

Quote:

---

Suggestion 1: Include a parameter (if possible) that would allow for all secondary level <ul>'s to close when another <ul> is opened. This capability is included in the Glossy Accordion Menu.

---

From a UX standpoint, on small screen devices this isn't usually a desirable behaviour. Imagine opening a large sub-menu and scrolling to the bottom, only to close it and have the menu contract; pulling the screen up with it and landing you in the middle of the page. It could be rather disorientating. That might be the reason for DDadmin's setup - although maybe it could be added as a desktop feature? Although for consistency across devices, one easily learnt and recognisable behaviour is usually best. DDadmin can hopefully provide his thoughts on that when he has time.

Quote:

---

Suggestion 2: Include a parameter (if possible) that would allow for a hover image for the down arrow.

---

How about doing something with CSS? You could put a background colour on the arrow, and extend it a little way with a border. Something like this;

Code:

---

.sidetogglemenu a img.downarrow { background:#fff; border:3px solid #fff; border-radius:50% }

---

You could change the colour on hover;

Code:

---

.sidetogglemenu a:hover img.downarrow { background:yellow; border:3px solid yellow }

---

Or you could use an image with a contrasting background colour to begin with.

Quote:

---

Originally Posted by Beverleyh

You should be able do it with CSS - Try;

Code:

---

#togglemenu1 { top:5em !important }

---

---

But giving a fixed top position to the menu will cause its bottom to be out of sight (below the view port). Even if you would fix that for a given (vertical) window size, the issue might reappear with smaller horizontal window sizes, for instance, when the text of the nav bar is long. So I would prefer the javascript solution given above.
Maybe a css solution using table and table-cell could do it, I haven't tried that one.

Quote:

---

But giving a fixed top position to the menu will cause its bottom to be out of sight

---

Yes, on long menus/short viewports, but it doesn't really hinder usage because the scrollbar kicks in, so its still accessible. No fix needed, unless I'm missing something.

Quote:

---

Originally Posted by Beverleyh

You should be able do it with CSS - Try;

Code:

---

#togglemenu1 { top:5em !important }

---

---

This does not work. I set the margin-top to the desired height and it works fine. Probably not the best solution, but it works.

Quote:

---

Originally Posted by Beverleyh

From a UX standpoint, on small screen devices this isn't usually a desirable behaviour. Imagine opening a large sub-menu and scrolling to the bottom, only to close it and have the menu contract; pulling the screen up with it and landing you in the middle of the page. It could be rather disorientating. That might be the reason for DDadmin's setup - although maybe it could be added as a desktop feature? Although for consistency across devices, one easily learnt and recognisable behaviour is usually best. DDadmin can hopefully provide his thoughts on that when he has time.

---

Not sure I totally understand your reply. I probably was not clear on the issue. Reference my test site menu (http://www.txfannin.org/new-site/index.php Note in the OTHER LINKS menu there are three sub-menu areas. Selecting the first displays the sub-menu items. Selecting the second does likewise. BUT the first sub-menu remains displayed. The desire is to have any open sub-menus close when any sub-menu is opened. This feature is implemented in the DD Glossy Accordion Menu

Quote:

---

Originally Posted by Beverleyh

How about doing something with CSS? You could put a background colour on the arrow, and extend it a little way with a border. Something like this;

Code:

---

.sidetogglemenu a img.downarrow { background:#fff; border:3px solid #fff; border-radius:50% }

---

You could change the colour on hover;

Code:

---

.sidetogglemenu a:hover img.downarrow { background:yellow; border:3px solid yellow }

---

Or you could use an image with a contrasting background colour to begin with.

---

The first option works... But, what would really be desirable would be to have four options.
1. Normal state with a down arrow.
2. Normal state hover with a different color down arrow.
3. Selected state with an up arrow.
4. Selected state hover with a different color up arrow.

Given that the downarrow is implemented in the .js (and my limited knowledge of js) it is difficult to accomplish the desired effect.

Thanks for your assistance.
jdadwilson

Code:

---

#togglemenu1 { top:5em !important }

---

Quote:

---

Originally Posted by jdadwilson

This does not work.

---

I've just tested and can confirm the that DOES work for the demo as it comes from the DD page.

Quote:

---

Originally Posted by jdadwilson

Not sure I totally understand your reply. I probably was not clear on the issue. Reference my test site menu (http://www.txfannin.org/new-site/index.php Note in the OTHER LINKS menu there are three sub-menu areas. Selecting the first displays the sub-menu items. Selecting the second does likewise. BUT the first sub-menu remains displayed. The desire is to have any open sub-menus close when any sub-menu is opened. This feature is implemented in the DD Glossy Accordion Menu

---

Yes I understand what you mean but I maintain that it generally isn't a desirable behaviour *now* for usability reasons. The Glossy Accordion menu is a much older script - originally created in 2008 and last updated in 2012, before responsive design became mainstream, and before mobile usability became an issue. On a large screen, the menu is a small part of the whole interface, so having sub-menus automatically contract isn't (wasn't) so much of a concern because you can keep your bearings within the context of the whole experience. Mobile on the other hand, changes the context of the menu - it becomes the only thing to occupy the screen, so menus with many items and many sub-menu items can easily disorientate a user. If the user had opened a long sub-menu and scrolled to the bottom of their screen to see lower items, only to have it close/contract automatically, outside of their control, when they tried to expand another menu item, they would lose their place as what they were previously looking at escaped away from them, back up the page and out of site, leaving them looking at whatever the menu was previously obscuring. Cue lost bearings. Cue confusion. Cue frustration.

I can't speak for DDadmin though so he might interject some alternative wisdom the next time he's passing.

Quote:

---

Originally Posted by Beverleyh

Yes, on long menus/short viewports, but it doesn't really hinder usage because the scrollbar kicks in, so its still accessible. No fix needed, unless I'm missing something.

---

Beverleyh, you're right, except that a vertical scrollbar without visible 'endpoint' doesn't look good. Also, 5em may be right for certain windows and bad for narrower ones (because the fixed navbar may take more vertical space there).

5em was just a random value given as an example. It could be modified, or used within media queries, for each use case.

No problem about the scrollbar endpoint - that can be fixed with CSS too;

Code:

---

#togglemenu1 { top:5em !important; bottom:0; height:auto }

---

Quote:

---

Originally Posted by Beverleyh

5em was just a random value given as an example. It could be modified, or used within media queries, for each use case.

---

I know, but it's a fixed value. Now when the navbar (containing large text) displays in smaller windows, it'll take more and more vertical space, and may end up being partially hidden by the menu or partially hiding the menu. Resolving this issue with the help of media queries would force us to use too much breakpoints.

Quote:

---

Originally Posted by Beverleyh

No problem about the scrollbar endpoint - that can be fixed with CSS too;

Code:

---

#togglemenu1 { top:5em !important; bottom:0; height:auto }

---

---

You're right.

Quote:

---

Resolving this issue with the help of media queries would force us to use too much breakpoints.

---

Such is responsive design. Setting media query breakpoint (tweakpoints) when the content *breaks* the layout is recommended practice, so we can just set one when needed. Of course in UXD one would then address the suitability of a heavy populated navbar on mobile - at which point we question and reevaluate the suitability of the navbar (use a different content delivery pattern perhaps) or just show priority navigation, moving secondary navigation elsewhere.

Beverleyh, I would think that the choice between using css or javascript is a question of coding technique, not a question of user satisfaction.

Choice of JS or CSS to solve a problem isn't what I was addressing - I raised UXD in reply to your given scenario molendijk;

Quote:

---

Originally Posted by molendijk

Now when the navbar (containing large text) displays in smaller windows, it'll take more and more vertical space, and may end up being partially hidden by the menu or partially hiding the menu.

---

Quote:

---

Originally Posted by Beverleyh

in UXD one would then address the suitability of a heavy populated navbar on mobile - at which point we question and reevaluate the suitability of the navbar (use a different content delivery pattern perhaps) or just show priority navigation, moving secondary navigation elsewhere.

---

I hope that clears up any confusion.

Wow, I surely didn't expect such a simple (for me anyway) issue to cause such a discussion. You are way over my head.

But... forget for a minute the smaller viewports. Note the home page for my test site http://www.txfannin.org/new-site/ as viewed on a large viewport. Selecting the MORE LINKS option in the top navbar displays my "Side Toggle Menu" which contain all the links to the areas of the site. Note also that three menu items have sub-menus as indicated by the down arrows. Selecting the first menu item with sub-menus displays the sub-menu items as desired. Next, select the second menu item with sub-menus. It too displays the sub-menus (first sub-menu items are still displayed). WAIT... what happened to the third menu item with sub-menus. It is off the screen (unless you have a very tall monitor)!

It just seems to me (at least in this instance) that if a user is navigating through a site and they select a sub-menu area and decide to then look in another sub-menu area the first area should collapse when the second is selected. If there are five areas and they are all open it would make for a confusing experience (just my thought).

Again, thanks for your great products and greater support.
jdadwilson

On my machine, the third menu is not visible even if no sub-menu is open.
There's probably something on your page that prevents the menu from producing a vertical scrollbar.
Replace

Code:

---

<div id="togglemenu1" class="sidetogglemenu">

---

with

Code:

---

<div id="togglemenu1" class="sidetogglemenu" onClick="expandlength = ' '">

---

If that doesn't help try

Code:

---

<div id="togglemenu1" class="sidetogglemenu" onClick="expandlength = ' '" style="position: absolute; overflow: auto; ">

---

Quote:

---

It just seems to me (at least in this instance) that if a user is navigating through a site and they select a sub-menu area and decide to then look in another sub-menu area the first area should collapse when the second is selected

---

This is the behaviour that we should ideally avoid because it takes control away from the user. Manual contraction (the kind your menu currently has) is generally considered more user-friendly because the user stays in control - they can choose when and how they want to navigate - maybe comparing menu items from different sub-menus in order to decide on the most suitable destination.

I can't comment on your non-scrolling issue that molendijk has identified as I'm stuck on iPhone for now, put you could try to investigate at your side with the developer toolbar - great for troubleshooting - F12 in most common browsers. You would select the side menu container and check to see what styles are being applied/overridden and then you can hopefully counteract them directly.

The first option does not work. The second option works but has a BAD side effect. A vertical scroll bar is added which allows the page to be scrolled to see the entire menu as desired, BUT when the page is opened a second time a horizontal scroll bar is added thus allowing the scrolling to the right to see the 'hidden' menu.

jdadwilson

Then try

Code:

---

<div id="togglemenu1" class="sidetogglemenu" onClick="expandlength = ' '" style="position: absolute; overflow-x: hidden; overflow-y: auto; ">

---

Quote:

---

Originally Posted by Beverleyh

I hope that clears up any confusion.

---

I'm afraid I explained myself not well enough. So here's a link to a demo-page which might provide a better explanation/demonstration of what I'm trying to say.

Ah, I see what you mean. When I used an example top offset of 5em earlier, and you replied;

Quote:

---

I know, but it's a fixed value. Now when the navbar (containing large text) displays in smaller windows, it'll take more and more vertical space, and may end up being partially hidden by the menu or partially hiding the menu. Resolving this issue with the help of media queries would force us to use too much breakpoints.

---

I can see now where the confusion came from - but allow me to explain - too many breakpoints wouldn't necessarily be required if you employ other responsive CSS techniques.

I'll reiterate that 5em was just an example, but the unit of measure needn't be a fixed one - a relative value like vw or % could be used instead to make it work better with a fluidly sized header (like in your demo).

From your demo;

Quote:

---

how could css alone allow us to always position the top position for the toggle button and the menu at the required vertical distance relative to the header image, which will vertically shrink or expand depending on the size of the window and whose height is not specified (view source)!?

---

The 'padding-bottom' method would be a good one to use when the header height needs to be fluidly scalable. I wrote about it before, here http://www.dynamicdrive.com/forums/e...-Retina-Images and http://www.dynamicdrive.com/forums/e...ponsive-Design

I looked at your JS demo and recreated the scalable top offset with pure CSS http://fofwebdesign.co.uk/template/_.../ddsidetoggle/ and only one media query to cap the fluidity at a max-width. It's pretty robust.

The only notable modification I made to the menu markup was to use an inner div and transfer the styles to it (background-color, right border, shadow, etc.)

And I like the 'push content' option so decided to keep that in.

Quote:

---

This is the behaviour that we should ideally avoid because it takes control away from the user. Manual contraction (the kind your menu currently has) is generally considered more user-friendly because the user stays in control - they can choose when and how they want to navigate - maybe comparing menu items from different sub-menus in order to decide on the most suitable destination.

---

Does not this logic totally contradict most of the menus presented on this site. All of the horizontal drop-down type menus only display one sub-menu (drop-down) at a time. 'Manual contraction' is certainly not an option with them. Even a goodly number of the vertical menus that have either a click or roll-over option to display a sub-menu don't have a manual contraction -- move to another menu item and the previous sub-menu goes away.

jdadwilson

I will clarify - I wasn't referring to horizontal dropdown menus. I was referring to the behaviour of modern vertical accordion menus (that are designed with responsive considerations) because that's the type you are using. Old scripts on DD many exhibit different behaviour because navigation patterns have changed in the last few years since touch and mobile became mainstream.

Quote:

---

Originally Posted by Beverleyh

Ah, I see what you mean. [...] I looked at your JS demo and recreated the scalable top offset with pure CSS.

---

Hi Beverleyh, that's pretty impressive indeed.
Two questions though:
1. When you slowly decrease or increase the window width whilst the menu is open, the top of the menu may get out of place. But I don't think this will pose a problem when the page is used the 'normal' way.
2. The first div in the body section of my page has:

Code:

---

<div id="fixed_header" style="position: fixed; left:20px; top: 0; right: 20px; text-align: center; background: #dedede; z-index:1; ">

---

We can make the header image smaller by increasing the values for left and right, for instance: left: 100px; right: 100px. When we do that, the top position of the menu button, the menu itself and the text on the page will automatically adjust to the new situation.
I wonder what will happen on your demo page when we change the size of your header image. If we replace

Code:

---

.header img { display:block; margin:auto; max-width:100%; height:auto; width:auto\9 /* IE8 */ }

---

with something like

Code:

---

.header img { display:block; margin:auto; max-width:80%; height:auto; width:auto\9 /* IE8 */ }

---

your header image will shrink. Will the top position of the menu button, the menu itself and the text on the page automatically adjust to the new situation? My guess is 'no', since 350 / 1260 x 100 will not work properly any more. Am I right?

Btw, your page will look even nicer on iPad when you put

Code:

---

html,body{height: 100%; overflow: auto; margin: 0; -webkit-overflow-scrolling: touch;}

---

That will keep the header image completely stable when the page is scrolled (see my demo page).

Quote:

---

1. When you slowly decrease or increase the window width whilst the menu is open, the top of the menu may get out of place. But I don't think this will pose a problem when the page is used the 'normal' way.

---

No I don't think it will either. It's probably an issue with your screen needing to refresh and the JS needing to recalculate. It's unfortunate that the menu keeps closing during resize but hopefully you can fix it.

2nd point - Different use cases require different CSS. If you're familiar with responsive design techniques you'll recognise max-width:100%; height:auto; as basis responsive image CSS, so changing the max-width to anything other than 100% wouldn't be appropriate. To alter the size of the header/image in my demo, you would change the padding-bottom value instead. That's calculated by taking the width and dividing it by the height then multiply by 100. If you were working with a different sized image, you'd recalculate the new image proportions and transfer that to the CSS (in whichever places reference the image width or height) and this particular demo will just *work*.

Alternatively, if your asking about resizing the image within the banner (in effect creating a grey border round the edge of the image) I imagine you'd put a padding on the header div (the image container) and increase the padding-bottom offset to account for the change. Box-sizing may be required. I don't know - I haven't tried it.

3rd point - I don't think that's needed. It fixes the Safari browser toolbar to the top of the screen and stops the screen going full-size on scroll. If you want to restrict screen height by doing that, go for it, but it wouldn't personally be my goal.

Quote:

---

That will keep the header image completely stable when the page is scrolled (see my demo page).

---

Sadly the header is nothing near stable in your example in Chrome, Opera Dolphin and Mercury. It isn't fixed during scroll and disappears off the top or bottom of the screen (depending on scroll direction). When scroll stops, it recalculates and snaps back to place.

I don't know about Opera Dolphin and Mercury, but my header is stable with Asus Tablet DU9542 and iPad Air (and on desktop, of course).
As for my 3rd point, it solved certain ios resizing issues I had on iPad, see this.

Feedback from Android - the JS demo constantly refreshes to give the effect of a persistent judder with the side menu flashing in to view every second or so. The top offset never gets chance to calculate so does not work. However, the CSS offset method works fine.

Having observed the behaviour of both demos on multiple/various devices and browsers, I feel that the CSS offset offers a more stable result and smoother, more consistent, visual effect in responsive environments. It's interesting to see both approaches though and I'm sure that users of the menu will find this thread useful in the future.

I'm closing the thread now to avoid it straying further from the original purpose of the thread. The OPs suggestions are on record and can be considered by DDadmin during future script modifications or rewrites.