We have a website/app that has a side menu that sticks to the left side of the screen (see mockup below)

100% zoom view

It is a responsive site, so when accessed on higher resolution screens (or if the user zooms out) I am not sure whether the side menu should always stick to the left hand side, like the mockup below (this is what Zendesk does)

No margins

Or if there should be a point in which we need to add in side margins to the left and right side of the screen, like the mockup below (this is what aCloud does)

wide margins

I guess it all boils down to whether people using massive screens (such as an iMac) like to physically move their eyes to the extreme left and right of the screen or want everything "infront" of them

  • 1
    It's not just about the stickiness of the menu, is it? Do you want the content width to increase indefinitely or is there a point at which it doesn't make sense any more? Aug 26, 2015 at 11:30
  • Yes correct, as a general rule if there was not a sidemenu then I would indeed just add in margins either side once the screen resolution is high enough. But in the case of a sticky left sidemenu, does this break the general rule?
    – Gueda
    Aug 26, 2015 at 12:33
  • As JonW notes below, Fitt's Law is a good reality check in this scenario. But you don't have to turn your sticky drawer into a distracting vertical ribbon to make it work. After a certain breakpoint, keep the nav elements themselves close to the content, but let the drawer stretch over the left edge to keep it one continuous region. Aug 26, 2015 at 16:08
  • One other thing to keep in mind: In my experience, people on giant screens (like 27" iMacs) rarely use full-screen browser windows. The fact of the matter is, there's just too much real estate on those things and it requires a whole new way of managing your windows. Aug 26, 2015 at 16:10

2 Answers 2


I would invoke the UX classic 'Fitts's Law' here. While not the perfect rule in situations like this, it is a good concept to consider. Basically - it'll take the user longer to get the cursor over to the menu, and longer to notice the page has been updated having selected an option the further the menu is from the main content (where they are likely currently looking). The longer it takes to get to an item, the greater the possibility of errors (clicking the wrong menu item, in this case). Plus means that it'll take them longer to see what option is currently selected in the menu too.

Generally, reducing the amount of time it takes a user to complete a task - even fractionally - is a good concept.

Not to mention the general annoyance of having to swipe the mouse over to one side of the screen and back again (if they have slow mouse speed they could be swiping, lifting, swiping, lifting... just to get over to the menu, and then the same in reverse).

  • "Generally, taking longer to do something that could be made faster is a good concept to go with." This sentence seems very ambiguous.
    – Celos
    Aug 26, 2015 at 12:56
  • @Celos Saving the user time is generally a good idea, but yes, it is ambiguous because it isn't always true. But for this situation I would say that it is. There is no benefit to the user for having to take longer to view and use the menu.
    – JonW
    Aug 26, 2015 at 13:06
  • but you could make that exact argument about the nav items on full width navigations (just like those in the example). There is also another alternative whereby the content is aligned further to the left also so that there is just more empty space to the right i.e. maybe the menu position isn't the problem here
    – Chris
    Aug 26, 2015 at 13:25
  • @JonW, I meant ambiguous from a purely grammatical perspective. It's easy to read it as ".. taking longer to do something is generally a good concept .."
    – Celos
    Aug 26, 2015 at 14:27
  • @Celos Ah yes, fair point. I've reworded that line to make a bit more sense!
    – JonW
    Aug 26, 2015 at 14:36

About the UX:

Keep it consistent. If a user is viewing the desktop version on a macbook it should be the same experience as on an iMac or larger display.

If you're on a larger display, look at this site for some inspiration about the navigation drawer. https://www.google.com/design/spec/material-design/introduction.html

Also, keep in mind, pinch to zoom may be beneficial on the table, but it may create an unexpected way on moving back to the navigation drawer if the user is still zoomed in.

When Developing:

Use a set pixel width for the sticky navigation bar or navigation drawer, and don't use percentages. This will appear the same width on every device.

And if you'd like to disable pinch to zoom:

<meta name="viewport" content="width=device-width, initial-scale=1.0, user-scalable=no">

Happy designing!

  • 4
    I'm afraid I would disagree with much of this. One of the benefits of responsive design is that you don't need to provide the same experience to users on different sized displays; you can cater the experience to the device being used. (Also, this is a UX Q&A site, not a development one, so no need to go into development advice here. Stick to the reasoning behind UX decisions, not providing implementation advice. Save that for StackOverflow)
    – JonW
    Aug 26, 2015 at 13:20
  • 1
    I would have to disagree with preventing zoom on mobile as a general rule.
    – Dave Haigh
    Aug 26, 2015 at 15:50
  • @DaveHaigh Why? What is the point other than to zoom on an image or text that was too small to properly read?
    – Mike Milla
    Aug 26, 2015 at 15:54
  • @JonW StackExchange allows code input in answers.
    – Mike Milla
    Aug 26, 2015 at 15:54
  • 2
    you cant predict why people might want to zoom. why go to the effort to prevent zooming when zooming is enabled by default. @JonW gives a good answer here on the matter. ux.stackexchange.com/questions/37511/…
    – Dave Haigh
    Aug 26, 2015 at 16:00

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.