We’ve removed the option to disable the fixed top bar

Question

We’ve removed the option to disable the fixed top bar. We didn’t change the default. We’ve only removed the ability to change the default.

According to SEDE, we’ve got ~13k users with the fixed top bar disabled. To put this into context, 730k people have opted into either system or dark theme.

There are lots of smaller features that aren’t frequently used, but they don’t routinely introduce bugs in the way that this one has. Since this preference has caused more bugs than we’d like to admit, I’ve made the decision on behalf of front-end at Stack Overflow to kill it.

If you see anything that seems funky as a result of us unshipping this, please add an answer here and include your browser, version and OS.

Update

Apologies for the delay. Managing a post on Meta can be a full time job on its own. Meta can be a difficult platform to have a dialog on. The irony is not lost on me.

I understand your frustration with removing this preference, but this will not be reversed. The fixed header provides the user valuable context and navigation. This can mean things like switching between Teams, joining a network site, joining a collective, signing up or logging into the site, receiving notifications, checking a review queue, getting help, navigating to your settings... These are important actions for our users. We want them to persist regardless of page position, whether visiting a page outright, or being deeplinked to an answer or a comment. We think the 50px required to provide this context is acceptable, even on small screens.

Fixed headers are an established pattern across the web and apps. You’ll find fixed headers on Reddit, Quora, Nextdoor, CNN, Vice, Craigslist, LinkedIn, Gmail, Jira, Facebook, Pinterest, Walmart, PayPal, TikTok, and YouTube—to name a few. There are two popular and notable exceptions, Amazon, and some pages of GitHub. I’m sure each of these companies have varying reasons for adopting this pattern.

In the original post, I was too focused on what the feature was costing our development team.

In Oded’s original post, he called out:

We are taking on a bit of debt by maintaining two versions of something that exists everywhere

He was right. The costs of tech and design debt are real, but so are the benefits of greater user context.

Answer 1

Ugh.

I'm sorry, but that's my response. I'm one of the people who had it disabled for a very clear reason: I have a relatively small screen and the topbar takes up too much space, leaving me able to see less content at a time and feeling squashed in.

SE does a very bad job in general of informing people that they can change some of the settings. Perhaps instead of just removing them, you find a way to let people know that the options exist in the first place?

Answer 2

To add another voice: Ugh.

There are lots of smaller features that aren’t very popular, but they don’t routinely introduce bugs in the way that this one has. Since this preference has caused more bugs than we’d like to admit, I’ve made the decision on behalf of front-end at Stack Overflow to kill it.

Now this may be anecdotal evidence, but I haven't seen any bugs caused by the topbar settings. Others who frequent Meta have said the same (here's one of them).

The last sentence here also comes across as though this is one person's decision, not in consultation with others (let alone the communities that are actually affected...). If that's the case, I'm concerned: one person having the ability to unilaterally change something that 13,000 people are using seems... excessive?

Was there any other analysis or testing done around this beyond that simple 13k figure shown here? Was there any analysis of how active those 13k are on average, compared to how active those non-13k are? Their reputation scores or other contributions? Was there any analysis of how that number changes if the default setting is non-sticky? Were any A-B tests run? Were there attempts to make that setting more easily accessible or well-known?

This is yet another change made without consulting anyone who may be affected by it. It appears to have been done unilaterally, and with insufficient data or research backing up the rationale for doing so. Please undo this change and go back to the drawing board.

Answer 3

And another voice: ugh.

I appreciate that it seems like SE has a pulse, but can we please stop doing the "one step forward, two steps back" routine?

Merits of the removal aside, we've been over this several times: low usage numbers alone are not a justification of removing a feature.

Neither does it help that the announcement is, once again, a statement of fact rather than an invitation to discussion and that it is coming right after a somewhat promising attempt to make things more open with the last announcement. It starts to feel like Groundhog Day.

On another note, was this really that buggy to warrant a complete removal? Here is a small compilation of bug reports I've been able to uncover so far:

Year	Report	Status	Setting state
2021	How to pin topbar? The preference does not seem to be working	no response	sticky on
2021	Body scrolls above the company header	confirmed bug, fixed	sticky off
2019	Not able to see the newsletter confirmation message box fully when the top bar stickiness is enabled	no response	sticky on
2018	Top of answer covered by sticky top bar after clicking direct link	confirmed bug, fixed	sticky on
2018	Make "Create Team" banner respect sticky setting	temporary issue, not even worth fixing	sticky on
2017	New Top Nav should not overlay review-bar	confirmed bug, fixed	sticky on
2017	Sticky top bar obscures full screen code snippets	not fixed, has a workaround	sticky on
2017	The "welcome back" message is covered by the new sticky nav bar	confirmed bug, fixed	sticky on
2017	Buggy behavior with sticky menu + notifications	confirmed bug, fixed	sticky on

I am sure there are more, but I urge the dear reader to spot the similarity between the reports (hint: look for the last column)

Answer 4

I use SE on mobile heavily. While my desktop is semi-ludicrously large, I kinda don't need/want the vertical real estate on my phone being used for something non-essential to what I am doing right now.

If memory serves (and I am doing this on my phone and haven't looked it up) non sticky as an option was community requested as it was the old default, and specifically was added in due to that.

On mobile Chrome and other mobile options, we can't userscript this back either.

I also suspect your small minority includes a lot of long time or engaged users... The stats you shared don't tell the whole story.

This change as a whole kinda negatively impacts my experience here and I would appreciate if it was reconsidered.

---

Fixed headers are an established pattern across the web and apps. You’ll find fixed headers on Reddit, Quora, Nextdoor, CNN, Vice, Craigslist, LinkedIn, Gmail, Jira, Facebook, Pinterest, Walmart, PayPal, TikTok, and YouTube

I took a quick look through a few - and many of them either have a different view for mobile, which is something y'all are trying to avoid, a fully featured mobile app (which you don't have any more). It isn't really an accurate comparison

Going to facebook on mobile will send you to m.facebook.com which has no fixed header for example. Gmail likewise either uses the app or a dedicated mobile view.

The fixed header provides the user valuable context and navigation. This can mean things like switching between Teams, joining a network site, joining a collective, signing up or logging into the site, receiving notifications, checking a review queue, getting help, navigating to your settings... These are important actions for our users.

Well, I can scroll up on most posts and go to the header. I don't need to do all these things while reading a post...

---

I took a quick look at the sites mentioned on my phone...

Youtube: Bar is slightly sticky and vanishes when you scroll down
TikTok: Transparent, unobtrusive
Paypal: non sticky top bar
Walmart: Sticky top bar
Pinterest: Disappearing bottom Bar
Facebook: non sticky top bar
Jira: No way for me to check
Gmail: Sticky Top Bar
Linkedin: Vanishing Top Bar as you scroll down
Craigslist: very 90s, simple page reminiscent of SE's mobile theme. Non sticky top bar
Vice: slightly collapsing sticky top bar
CNN: Sticky Top Bar
Nextdoor: Needs account, so I can't check. Sticky top bar on the login page
Quora: Sticky Top Bar
Reddit: Sticky top bar

5 sticky top bars, and I can't check two. 6 are non sticky, and one is a transparent sticky top bar that blends into the content.

Nearly all of them have dedicated mobile apps, and separate mobile themes... which I believe we'd like to avoid. I don't think its accurate to say that they all have sticky top bars. Its a nearly even mix on smaller screens.

Answer 5

What kind of bugs did having a fixed position topbar introduce? I understand if you don't want to admit exactly how many bugs this has caused, but maybe one or two examples might help folks understand the necessity of the change.

Pushing webpage content down by 50px typically does not cause many issues with page layout, so I'm curious what some of the issues are that you are facing here. As a regular wielder of HTML/CSS myself, it would help me be aware of a potential issue, as I use sticky/non-sticky header preferences in my webapps a fair amount.

From your comment reply to Sonic pointing out this SO bug report, it sounds like the issue at hand there was that your own team was not aware of the feature. That is not really a bug, so I'm guessing there are other issues.

Answer 6

I'm one of the users that had the top bar set to non-sticky. I think one part that might not be obvious is just how irritating the sticky behaviour can be. This is more of a sub-conscious thing, but especially the transition when first scrolling down always draws my attention, like some annoying animated ad. I'm not sure how this will change with time, but this is the kind of setting that is probably a much bigger deal to the people that have it enabled that people that don't use it would expect.

Removing features that are rarely used because they add complexity is something I tend to do myself, so I can't fault you for the general idea there. But I think you underestimate the importance of this feature by only looking at the number of users, I'd bet that a large part of those are very active SE users.

Answer 7

feature-request

Since the preference option has been removed, make the top bar non-sticky for everyone. This has been the case until 2018, and there was no reason to change the default when the option was introduced. The stickiness of the top bar is nothing but a waste of screen space for a useless gimmick, and it should not be forced on all users.

Answer 8

You’ll find fixed headers on Reddit, Quora, Nextdoor, CNN, Vice, Craigslist, LinkedIn, Gmail, Jira, Facebook, Pinterest, Walmart, PayPal, TikTok, and YouTube—to name a few. There are two popular and notable exceptions, Amazon, and some pages of GitHub.

There's another "notable exception" you didn't mention: Wikipedia.

Wikipedia does not have a sticky top bar. Your inbox and everything else stays at the top of the page while you scroll down, looking at the content... which is of course what you visit Wikipedia for. When you visit Wikipedia, it's for the content, whether you're consuming or editing that content.

So too here on Stack Exchange. Wikipedia has long been the project that most closely resembles Stack, because here too, our focus is on the content.
People visit Stack Exchange for questions and answers. Leave aside the power users who visit to review and for chat and everything else for the moment. Most people are here for the content, and the top bar... isn't content.

If I'm reading through a question or answer, the top bar is irrelevant. I don't care if I got an inbox notification or reputation change. What matters to me, right then and there, is the content, and I don't need bright shiny notifications distracting me.

Notifications and rep changes can wait until I'm done reading and hit the home button to bring me to the top, or scroll up.

Please remember that Stack Exchange isn't Reddit. It's not a meme-filled forum. It's not CNN - it's not a news site either. It's also not TikTok - Stack isn't a social media site. Or Amazon. Most people aren't doing their shopping through Stack.

So we don't need to take our cues from sites like Reddit or CNN or TikTok or Amazon. Stack should be taking cues from sites like Wikipedia, because Stack Exchange is a knowledge-sharing site, and should look like one.

Answer 9

Your goal with most of these design changes is to make the SE design fully responsive and to also replace the mobile theme entirely. This particular change does not do that and it adds another problem to the whole bunch of existing ones for this design on phone screens. The current design does not work well on phone-sized screens; it wastes too much space. A fixed top bar takes up a lot of space, so you're not solving an issue for the future here, but doubling down on a design decision that is going to be really problematic once you try to switch everyone to the main design for mobile.

You're not getting the right amount of pushback right now for the problems of the main design on mobile because almost nobody uses it. I'm quite sure that once you switch, people over there will be torches and pitchforks over the sticky top bar and other space-wasting design decisions. I mean, even the mobile browsers themselves don't make their top bar with URL and menu sticky. They pretty much hide their whole UI after the user scrolls.

At this point you might have to relent and disable stickiness for mobile devices. And then we're back at supporting two options, so you might as well reenable the preference. You already have the complexity then. Or just decide that the sticky bar doesn't provide more benefits than it costs and have a non-sticky top bar for everyone else.

As for the valuable context and navigation:

• switching between Teams

• joining a collective

These two are in the sticky side bar, not the top bar

• navigating to your settings

This is really not that important and not necessarily very often. It is also hidden behind two clicks, because you need to go via your profile.

• joining a network site

• signing up or logging into the site

These are for users that are not logged in, but I understand why you want them very visible

• receiving notifications

• checking a review queue

I look at notifications after I navigated to a page, not while I'm reading some posts (which is when I'm scrolled down and a non-sticky top bar would not be visible)

• getting help

This is a menu point that is probably not used that often. Of course help is important, but it's not the kind of stuff you try to access while you're reading posts and scrolling down.

The part I use most often is curiously not one of your examples, the site switcher menu. I usually navigate using this instead of bookmarks, so I use it quite heavily. And even then I prefer the non-sticky version of the top bar.

One aspect you didn't mention is that we already have another sticky element, the left sidebar. This is also a part of the design that was heavily criticized, and in the end SE never was able to fulfill the promise to actually use that wasted space there and add useful features to the left sidebar. Having two separate sticky navigation elements is really more of a symptom of the organic growth of the current design, and not a coherent design philosophy.

Answer 10

Comparison between numbers indicating usage of fixed top bar vs dark mode looks somewhat inaccurate, I would suggest to at least "normalise" these numbers by some sort of site activity - by amount of views or by days visited or by reputation of users etc.

To start with, dark mode was announced much wider - respective announcement had featured tag allowing it to get 30K+ views, and two dedicated articles at SE blog: here and here, a dedicated hat in the 2020 winter bash, along with posts at multiple resources outside of Stack Exchange: zdnet, lifehacker, turnoffthelights just to name a few.

Compared to that, topbar announcement has never been featured and managed to gain mere 3K views, likely from regular meta visitors (0.015% does ring a bell?) - so it has got much harder start from the very start.

Another thing to take into account - which is maybe even more important - is that dark more is much more in-your-face and because of that much much easier to spread by word of mouth.

I can easily imagine someone looking over the shoulder of their colleague / classmate asking "Hey what's that, your Stack Overflow is dark, how can I make it look like that in my browser?" Chances of topbar tweak spreading like that are practically nonexistent in comparison because it is just so much harder to notice.

---

Suming up, these several thousands users aware of topbar switch more likely represent most active and motivated part of site audience ("core group" if you wish). Indiscriminately comparing them to hundreds thousands random passers-by feels kind of... slippery.

I think it would be safer to base your estimates on some kind of "weighted" metrics that would somehow account for site activity of involved users.

_{(Note to address particular clarification in comments - this is not specifically about dark mode and initial example with IE users was concerning for the same reason: simply counting amount of users while ignoring possible differences in their site activity is not a reliable way to estimate impact of the changes.)}

Answer 11

I didn't notice that Ollie had already written a user script to make the top bar non-sticky, so I wrote my own. I like mine slightly more, since it just injects a couple of lines of CSS instead of installing any active event handlers:

// ==UserScript==
// @name        SE No Sticky Top Bar
// @namespace   https://github.com/vyznev/
// @description Disables the sticky top bar on Stack Exchange sites
// @author      Ilmari Karonen
// @version     0.3.0
// @copyright   2021-2022, Ilmari Karonen
// @downloadURL https://gist.github.com/vyznev/7c9a7ddc5c057d4c895864e460b4a88d/raw/se_no_sticky_topbar.user.js
// @homepageURL https://meta.stackexchange.com/a/368984
// @match       *://*.stackexchange.com/*
// @match       *://*.stackoverflow.com/*
// @match       *://*.superuser.com/*
// @match       *://*.serverfault.com/*
// @match       *://*.stackapps.com/*
// @match       *://*.mathoverflow.net/*
// @match       *://*.askubuntu.com/*
// @exclude     *://chat.*/*
// @exclude     *://blog.*/*
// @grant       none
// @run-at      document-start
// @noframes
// ==/UserScript==

var css = `
  html:not(.specificity-hack) { --top-bar-allocated-space: 0px; }
  body:not(.specificity-hack) { padding-top: 0px; }
  .s-topbar.ps-fixed:not(.specificity-hack) { position: static !important; }
`;

var style = document.createElement('style');
style.textContent = css;

var parent = (document.head || document.documentElement);
if (parent) parent.appendChild(style);
else {
  // work-around for https://github.com/greasemonkey/greasemonkey/issues/2996
  var obs = new MutationObserver(function () {
    var parent = (document.head || document.documentElement);
    if (parent) { obs.disconnect(); parent.appendChild(style); }
  });
  obs.observe(document, {childList: true});
}

If you have a user script extension such as Greasemonkey or Tampermonkey installed in your browser, clicking this link should prompt you to install the script.

---

Alternatively, if you're using a user style extension such as Stylus, you can just grab the three lines of CSS from the script and add them as a user style for SE sites:

html:not(.specificity-hack) { --top-bar-allocated-space: 0px; }
body:not(.specificity-hack) { padding-top: 0px; }
.s-topbar.ps-fixed:not(.specificity-hack) { position: static !important; }

You won't get automatic updates to the script this way, though, which I suppose may be seen as a good or a bad thing, depending on how much you're willing to trust me. (I don't actually use Stylus myself, so I'm not particular interested in maintaining a separate gist for it.)

---

Ps. The :not(.specificity-hack) trick may or may not be needed in a user style, but at least it shouldn't hurt anything. In the user script version it makes the behavior more reliable, since there's generally no guarantee whether the custom CSS will get injected before or after the site CSS.

Answer 12

This line is a disingenuous half-truth:

We didn’t change the default. We’ve only removed the ability to change the default.

The default was the non-sticky header that scrolled out of the way when you moved down the page. The whole reason to have the preference was BECAUSE it was the option to give us the default back.

About the only time I need the top bar is when I go to check a notification or visit my profile. I really prefer having the screen full of useful stuff, like questions, answers, code, images, etc... The site navigation hasn't been forgotten about. It should just step aside while it's not needed.

Also,

Fixed headers are an established pattern across the web and apps. You’ll find fixed headers on ...

Pointing to site designs on other major sites is a transparently misleading appeal to popularity. Will you update the site for infinite scrolling as well? Wait, don't answer that...

Answer 13

UserStyle to fix (yet another) pointless change:

/* ==userstyle==
@name Stack Exchange
@namespace Zombo
@version 1.0.0
==/userstyle== */
@-moz-document
domain("askubuntu.com"),
domain("stackexchange.com"),
domain("stackoverflow.com"),
domain("superuser.com") {
   .ps-fixed {
      position: absolute !important
   }
}

https://github.com/openstyles/stylus

Answer 14

Having a fixed top bar is not responsive. It is frustrating that y’all are deprecating all mobile support in favor of the responsive design (which I think is a sensible thing to do) then decide that small screen users must be stuck with large screen features. Honestly after thinking about it, I agree the user option is not the right way to handle it. The interface should just work without me have to diddle a bunch of preferences. It should work whether I’m viewing it on my phone or my 8k display.

There are many ways to accomplish the goal of making the things on the top bar easily available other than forcing it to display all the time. The first one that springs to mind was inspired be the “increase the zoom of your browser slightly and you can scroll the top bar off the screen” comment.

Why not allow the top bar to be scrolled off the screen on small screens when the user is moving down the page, but bring it back as soon the user moves some significant distance the opposite direction? A simple flick would make it visible again, even if you are 25 questions down a list of 50. Maybe new notifications make it visible and scrolling further down moves it off the page. It has to be possible to scroll the sticky bar off the screen, because I’m able to as I’m typing this in Safari, and if I pull down fast enough (or far enough, I’m not sure) it pops back (not just scrolls back onto view).

Alternatively, on small screens the top bar could have a widget that lets a user collapse the bar if it is in the way and tap it to expand it (vertically or horizontally, whichever is easiest).

I’m not saying that either of those suggestions is the answer. I do think that if all the eggs are going in the “responsive” basket, y’all should make it a really nice basket, even if it requires a lot of thinking about how to design it so that it can be maintained and evolved as user needs change.

Answer 15

Despite the fact that my screen is relatively big, so that I've never had much of a problem with this before, I've got a small beef: We need more options in our preferences. If a feature is buggy, fix the bugs, don't unship the feature and force those who use it to put up with the result. Scratch that - if the feature was properly buggy, it shouldn't have been shipped.

I've made a little Tampermonkey userscript for those who don't want it sticking around. Enjoy, and please report any bugs you might see in the comments below.

// ==UserScript==
// @name         Disable sticky SE topbar
// @namespace    http://tampermonkey.net/
// @version      0.2
// @description  Disable sticky topbar.
// @author       Ollie
// @match        *://*.askubuntu.com/*
// @match        *://*.mathoverflow.net/*
// @match        *://*.serverfault.com/*
// @match        *://*.stackapps.com/*
// @match        *://*.stackexchange.com/*
// @match        *://*.stackoverflow.com/*
// @match        *://*.superuser.com/*
// @grant        none
// ==/UserScript==

$(document).ready(function() {
     $('body').css({
           'padding-top': '0px'
        });
    if ($(this).scrollTop() >= 175) {
        $('.top-bar').css({
           'position': 'relative',
        });
    }
    else {
        $('.top-bar').css('position','static');
    }
});

Answer 16

Ugh.

Many users are already over-obsessed with their rep and badges. They do all kinds of silly things just to get rep and/or badges and complain imminently about the tiniest discrepancies in the displayed rep.

And now you are emphasizing these metrics even more by removing the option to have the top bar out of the way?

Answer 17

Disclaimer: I am not directly affected by this change.

I think generally users can understand that sometimes the company must make decisions that are unpopular with some minority of users, in order to reserve resources for other bugs and feature requests that affect more users. Though as others have noted, it would have been best to post this question, then make the change after a few days.

Is there a way that this workflow could be built in to your process? I only dabble in software development, but I imagine there is some internal process covering the necessary documenting, git-commiting, unit-testing, bug-hunting, and magic-wand-waving every time some change is made to the user interface. Could you add meta-posting and waiting a day or so to that process?

I believe users would even be understanding if there's two paths -- one where meta feedback is gathered and considered, and one where you've decided for Reasons^TM that the change will be implemented regardless, and you're just doing us the courtesy of letting us know.