With the new redesign I realized that each time a load a page I collapse the side bar on the left. Maybe it would be nice to allows users to choose if they prefer having the side bar open or closed by default. A possible rough answer would be to add a flag preference in the user profile. A better UX would be to have some sort of intelligent UI showing off to the user the n times he is collapsing the side bar to ask him if he wants to have the side bar collapsed by default. Actually the same king of behavior could be done for all collapsable element in the UI. This need further UX investigation, but currently I found very annoying to have to collapse the side bar all the time.

Good feedback, Jeremie. I wonder if making side bar state persist would work just as well. "The best interface is no interface." http://www.cooper.com/journal/2012/08/the-best-interface-is-no-interface

This would likely also tie into the discussion we had yesterday with Martell about adding support for the user configuring line spacing and margin size; some people like me like stuff more smooshed together to get more on screen while others like lots of whitespace.

I think that designing the feature to remember if you like the menus closed or open is different than designing Google-style Compact/Cozy layout settings. However, under the hood, saving the flag for the user's preference for both features may be done with the same system.

Do we want to persistently show/hide the left sidebar? We can make that happen now if we want.

I'd really like to get Holly's input on this. I like the philosophy of "Every UI preference you give to the user is a design decision you've punted onto them." I'd much rather have a few of us do some hard work to make a good design decision than to punt such a trivial mental task to millions of our users. :(

(In reply to Luke Crouch [:groovecoder] from comment #5) > I'd really like to get Holly's input on this. I like the philosophy of > "Every UI preference you give to the user is a design decision you've punted > onto them." > > I'd much rather have a few of us do some hard work to make a good design > decision than to punt such a trivial mental task to millions of our users. :( Exactly. Could not agree more strongly with this.

Yes, we are not letting users control their own spacing. That would be a horrible, horrible failure on our part.

This is an incredible mistake. I'm pretty angry about the opposition to this, given that failing to give me a way to fix the problems with the layout (from my perspective) reduces my productivity. Between the short lines of text being hard for my brain to process and the enormous wasted space (sorry, I know that style and design rules, as well as standard legibility rules say whitespace isn't wasted space, but to me it's a waste of my screen that I could have useful content on), I'm frustrated constantly by this, and my productivity takes a hit. I powerfully, strongly, ardently disagree with opposition to this idea. This is what makes reading on a screen better than paper: the ability to adjust the look of the content to match your personal preference. Denying users this ability means we might as well be shipping dead tree books to them instead. Being forced to waste time coming up with custom stylesheets just because we're going to be too lazy to make this possible makes me sad. (I get that I sound like a cranky ass here, but I'm really frustrated -- we're replacing a theme that for me, was easier to read with one that takes a step backward in readability (again, for me), so I was really hoping for some consideration in this area. I know I'm an outlier; I've conceded that in the past. But I think it's crazy to go off the deep end about how hard this is on our team to make it possible to adjust the left and right margins and the font size. I mean, come on, seriously? That doesn't make sense at all. Sigh. I'm sorry for going off a bit here, but seriously, every time we come up with a way to help with this serious problem, someone stomps on it, and I'm getting tired of it.

I'm personally okay with making the sidebar state persist, and I'm okay with discussing ideas to improve readability, but I'm not okay with skipping UX input and reaching straight for the dev hammer. We have professional UX contributors precisely because they study these issues from a holistic perspective. From the dev perspective, the problem with user preferences isn't small laziness. Preferences create an exponential number of UI states to maintain. Preferences create (2^num-of-binary-preferences)*(possible-values^num-of-preferences) states. In this case, preferences for: sidebar: 1,0 line-spacing: 10 values(?) left-margin: 10 values(?) right-margin: 10 values(?) add up to: 2,000 UI permutations. That's 2,000 new factors for bugs (e.g., word-wrapping bug 937634). So my primary development concern is preventing bug-swarms from users with different UI's expecting the dev team to keep them all aligned. Browser features like zooming in and out are aimed squarely at this problem, and beyond that yes - the dreaded custom stylesheets.

I'd like to focus on the original bug & comment by Jeremie & take the spacing/whitespace conversation elsewhere, because it is a larger issue and I think gets in the way of using this bug to do something smaller and meaningful with pout all the emotion. Let's use this bug to continue to discuss allowing users to choose if they prefer having the side bar open or closed by default. We can prioritize in the community bug triage meeting or get feedback through mdn-drivers.

I agree with Ali. We should limit the scope of this discussion. As for the feature being proposed, I agree that layout should not be customizable. This would lead us down the path of including everything but the kitchen sink, which can be dangerous. Luke offered an excellent overview of the engineering costs, and the user experience costs are just as great. We all know products that are overly complex for the few real use cases they need to support -- ahem, Bugzilla -- and they are usually not very pleasant to use. MDN is fundamentally simple: read, edit, translate, administer. Our user interface should reflect that. If the feature would be overlooked by most people (I am confident that it would, but we could run some numbers to be sure), making the interface more complex for the majority of users and increasing the cost of maintenance hardly seems justifiable. I hope not to understate that this feature really does matter to some people. But because those users are likely rare, another approach (like userContent.css) may be more appropriate.

I'm against a user preference for layout changes. I also browse MDN at a width that hides the sidebar by default.

MDN Web Docs' bug reporting has now moved to GitHub. From now on, please file content bugs at https://github.com/mdn/sprints/issues/ and platform bugs at https://github.com/mdn/kuma/issues/.