-100

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.

48
  • 30
    I bet if the default was not sticky, the stats would be reversed.
    – Kevin B
    Aug 25 at 18:51
  • 42
    Another "we are doing x" rather than "we are planning to do x; opinions?" post :/ Aug 25 at 18:56
  • 16
    Can you please provide an example of a bug that this caused? We haven't seen a single bug as a result of this setting. Aug 25 at 18:57
  • 43
    Usually when something is buggy, you fix the bug. Not remove the feature. This is the second one that's removed (counting the calendar here too.) Does it really matter that only a few people used it? People like to customize their experience. It's a sign of thoughtfulness to the users that they have options. On second thought.. there seemed to be a lot of bugs with the Collectives™ ;) Aug 25 at 19:01
  • 25
    I’m sorry but “it had a lot of bugs” is a terrible excuse to remove a feature. Maybe it had a lot of bugs because y’all did a poor job of letting people know it was an option, so few people were using it, which led to it not being well tested. If it was buggy and poorly designed, it shouldn’t have been rolled out and left live for so long. It’s really bad to take away features that are working fine for the people using them, especially when the excuse is “we did them incompetently”.
    – ColleenV
    Aug 25 at 19:02
  • 15
    If anything, the header being sticky is far more likely to cause bugs than it not being sticky.
    – Kevin B
    Aug 25 at 19:10
  • 14
    Relevant.
    – Adám
    Aug 25 at 19:19
  • 23
    Yet another change that nobody asked for, community feedback will be completely ignored, and the change will be implemented despite its extremely unpopular.
    – Ramhound
    Aug 26 at 2:07
  • 20
    It's a real pity you don't learn from mistakes. And worse, you never even realize that making one sided changes with big effect is a mistake. "It's hard to maintain and not widely used" IS NOT REASON TO REMOVE FEATURES. Nothing to say except that I'm annoyed and sad. Thumbs down, again. (And I'm sure now you will just keep doing it) Aug 26 at 8:55
  • 16
    This is a slap in the face of mobile users. As per the previously requested feedback, the biggest problem by far with the responsive design to be usable on mobile devices is its low information density, i.e., wasting of space. Instead of trying to fix this, you just made it worse, on a whim. Congratulations. Aug 26 at 10:19
  • 16
    I was really hopeful that things would start to change for better, when you asked for feedback before making changes. But now, with this attitude of removing stuff without asking (again), it seems that you didn't learn anything from this. I'm sad that you're doing it again, and now I've completely lost any hope that things will improve. The company will keep doing whatever they want, ignoring community's feedback, and that's it (I'd love to be proven wrong, but it seems that unfortunately I'm right)
    – hkotsubo
    Aug 26 at 13:10
  • 16
    Shall we assume the radio silence on both removed features, no "featured" status on both posts (when the "review queues" one is featured right now), and lack of communication about whether there even are any plans means that SE is no longer inclined to go the direction of restoring ties with their community as a whole and power users in particular? Welcome back to 2019, everyone, I suppose - hope no one of us are disappointed too much. Please, just tell us what to expect - if this is going to continue, we can all go our merry ways - Codidact's been gathering folks for about a year now. Aug 26 at 16:37
  • 19
    So if a very tiny percentage of your users have a certain disability would you then remove an accessibility feature because it wasn't serving enough disabled users? (If this seems like an apples-to-oranges comparison to you, I challenge you to think of feature configurability itself as an accessibility feature.) Aug 27 at 4:01
  • 16
    we’ve got ~13k users with the fixed top bar disabled. Now 13,000 users are angry the top bar has to be sticky. Aug 27 at 5:45
  • 15
    On the bright side, at least this post probably won't get many more than 13,000 downvotes ;) Aug 27 at 16:24

17 Answers 17

80

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?

10
  • Informing more people about it wouldn't solve whatever.. "headache" it existing is causing
    – Kevin B
    Aug 25 at 18:54
  • 7
    I didn't know it was an option.
    – Chindraba
    Aug 25 at 18:59
  • 2
    This is what my entire screen looks like at 100% zoom, by the way: i.stack.imgur.com/hcGPp.png
    – Mithical
    Aug 25 at 19:06
  • 1
    Wow @Mithical, that really is a tiny screen. I think it's only about a quarter of mine. Which has its own downside's though: i.stack.imgur.com/8bNgK.png
    – Luuklag
    Aug 25 at 19:23
  • @Luuklag It's easier to fix your problem though. There's a user script for it at Bring back the layout! Aug 25 at 19:25
  • @Unconsidered in theory yes, but company policy won't let me install scripts.
    – Luuklag
    Aug 25 at 19:28
  • @Luuklag Install it as a bookmarklet (Assuming you're allowed to have bookmarks). I just did.. it works fine. Aug 25 at 19:34
  • 23
    I've recently been working on a laptop at work and for the first time in my life I disabled the always displayed taskbar in Windows and the difference a couple tens of pixels make to the user experience isn't funny. The last post I saw from SE was to improve the user experience on smaller devices, but this is the antithesis of that.
    – Peilonrayz
    Aug 25 at 19:54
  • 4
    I also had an unsticky top bar. But I just noticed on my phone that if you zoom in slightly, you can make the top bar scroll up and out of sight (it comes back when you scroll down). At least that's what happens in my Samsung browser.
    – PM 2Ring
    Aug 26 at 9:03
  • 5
    @PM2Ring That's bizarre. If I zoom in even slightlier, I can scroll up a part of the top bar, but its lower part remains sticky. The whole thing sounds like a bug. Aug 26 at 9:36
65

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.

1
  • 17
    They don’t have to care about “the vocal minority” now that they have been purchased. Who cares whether a fraction of a percentage of users bitch on Meta about features being removed? That’s not what employee performance is going to be measured against. It’s not like removing last seen or top bar stickiness is going to make a significant number of people stop using the network. I’m not surprised, just sad. Users who don’t contribute in ways easily converted into money have little leverage, and the value of a “promoter” is underestimated until everyone wonders why the numbers are down.
    – ColleenV
    Aug 25 at 19:56
55

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)

3
  • It's worth noting that these are just the bugs that have made it into production.
    – Aaron Shekey StaffMod
    Aug 26 at 16:40
  • 18
    @AaronShekey of course, one can't find bug reports for what never made it production. Still, this is not an excuse for removing a feature people explicitly opted in and much less of an excuse to remove it without consulting the community that is the backbone of the network. I was hopeful that employing a team that works on an open-source codebase is a sign that SE is moving past the times of disregarding the needs of their dedicated users - I am very disappointed to say that now I think I was mistaken. Aug 26 at 16:56
  • 12
    @AaronShekey Bugs that make it into production are of more concern than those that don’t because they are apparently the type that whatever testing you’re doing has a hard time identifying. The stickiness seems like far more of an issue than the fact it can be disabled because those are the bugs y’all didn’t catch. If you’ve caught and fixed a bunch of bugs, the feature should be more robust by now and it’s long history of bugs a testament to how bulletproof it is now.
    – ColleenV
    Aug 26 at 18:27
37

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.

4
  • 6
    I volunteer as tribute.
    – Catija StaffMod
    Aug 25 at 23:24
  • 2
    Ah thank you. Good to see my memory isn't that full of holes 😁
    – Journeyman Geek Mod
    Aug 25 at 23:28
  • 16
    Yes, the change was that the top bar never was sticky until the SO top bar was redesigned and we created a user preference that allowed people to choose between the two - but only on SO - the rest of the network still only hid the top bar as you scrolled. I thought the sticky option was really great and asked for it to be made an option network-wide. I'm not sure why sticky was the default. Someone in another answer guessed that it was about marketing and making products more visible... I don't know. I didn't work here at the time.
    – Catija StaffMod
    Aug 26 at 0:55
  • 6
    This is why trying to justify a decision to your users with spurious excuses is a bad tactic. The excuse “not many people use it” makes us wonder why we’re not important enough to matter, and the excuse “other products do it” makes us want to point out all the differences between other products and this one. I’m sad that SE chose this path. They could have been announced they were making the top bar responsive instead of just taking away a feature and it probably would have been well received. A well-designed responsive top bar is better than having to choose sticky or not sticky.
    – ColleenV
    Aug 31 at 13:27
34

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.

Edit: 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.

31

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.

2
  • 7
    The original intent of the sticky header was to ensure new users who visit from google directly to an answer get a chance to see "Developer Jobs" in the header. It being annoying, or likely to draw your attention, is likely an intended feature.
    – Kevin B
    Aug 25 at 19:55
  • 3
    @KevinB Users from Google start at the top scroll position, so I don't think there's a conspiracy here. The sticky header is actually useful, you retain quick access to inbox, navigation and tools no matter what your scroll position is. I don't hate all sticky headers, but this one is annoying for some reason. I suspect it is the way the left sidebar stays sticky that leads to the weird transition when you start to scroll, but I'm not sure. Aug 25 at 19:58
27

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.

4
  • 7
    Not sure I like that. Let's make it an opti.. oh!.. Aug 26 at 9:16
  • 4
    I only noticed this after your comment above, but once SE removes the old mobile view as planned the sticky top bar really needs to be revisited anyway, it just takes too much space on mobile devices. Aug 26 at 10:45
  • 1
    @MadScientist The way things go here lately, I’m quite afraid that’s a naïve expectation. And anyway, since they are actively preparing for removal of the old mobile view, the time to fix it is now, given that they already meddle with the feature. Aug 26 at 11:00
  • 4
    I support this even though my top bar is sticky. I think it’s apparent from the compilation of bugs where the top bar was the culprit that the stickiness was the problem most often, so according to the “we unship features with too many bugs” logic the sticky bar should be unshipped, not just the option to disable it.
    – ColleenV
    Aug 26 at 18:19
18

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.

15

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.)

14
  • 5
    this looks like yet another case where "citizenship level" metrics would be useful
    – gnat
    Aug 27 at 17:33
  • 2
    If only we were given the voice that other minority groups among the community get
    – Kevin B
    Aug 27 at 18:33
  • 3
    Since I made the edit to compare to dark mode I figure I ought to respond. I broadly agree with your answer, but there just isn't a perfect comparison. Dark mode was a feature requested many times. The non-sticky topbar option was added to make other changes easier to accept. I definitely think A > B therefore remove B is simplistic. But an option used by a small percentage of users (even if they are very engaged users) is at greater risk of removal than an option used by a larger percentage. The bigger problem, in my mind, is how this change was communicated. :-( Aug 27 at 19:08
  • 2
    @JonEricson my concern applies the same to original comparison to IE, it is not specifically about dark mode: it does not look OK to measure things by indiscriminately counting users without weighting on their "citizenship level". Dark mode makes a good material to demonstrate the issue but frankly, IE example could probably do just as good - say I wouldn't be surprised if "appropriately weighted" stats for IE users turned out order(s) of magnitude lower than those for topbar
    – gnat
    Aug 27 at 20:06
  • 10
    @JonEricson I think the entire "number of users" argument is irrelevant. Features aren't unshipped just because not enough people are using them. There's some other reason that would cause someone to look at how the feature is being used and calculate the costs and benefits. The problem here is that the costs of keeping versus removing the "unsticky" top bar were never really assessed; it was just assumed that 13K users' need for that feature weren't important enough to offset whatever the real reason it was removed. The assumption that "sticky" should be the default seems untested as well.
    – ColleenV
    Aug 27 at 20:48
  • @ColleenV: I think there are legitimate reasons to avoid user preferences and number of people who have opted in is a fine way to decide whether an option is worth supporting. A stronger argument would be if there were some sort of reason long-time users don't like the sticky topbar other than they got used to it years ago. Ideally there would be a way to fix the problem people have with the sticky topbar and make the default the same for everyone. Aug 27 at 21:10
  • 5
    @JonEricson If it is really the option that is causing the problem, that's reasonable. Looking at the bugs that made it into production, allowing a "sticky" bar is what seems to have caused most of the problems. I am not a fan of making users tweak a hundred options to get a usable interface. That's just a way to cover up bad design. My problem is taking away something after leaving it in place for years. It's like trying to raise the price of something without adding any value to it because you set the wrong price point. It makes customers unhappy.
    – ColleenV
    Aug 27 at 21:18
  • 4
    It would be better to replace the option with something responsive so that on small screens, the top bar wouldn't interfere as much with the content. That, however, requires that you understand how people are using the feature and think about how to meet that need instead of just taking it away from them. The most galling thing about this decision is the utter lack of caring about user needs. There's seems to be no regret at all that the site was made less functional for more than ten thousand people.
    – ColleenV
    Aug 27 at 21:22
  • 3
    @JonEricson literally it being sticky is the problem I have with it. there's no changes that could occur with it that would change that. There's literally no reason I would ever need to see the header while I'm scrolling down the page. I view sticky headers as a similar annoyance to automatic newsletter modal popups. Yes, they can drive up engagement with the links in the header, just like modal popups drive up newsletter signups. That doesn't make it a good user experience.
    – Kevin B
    Aug 27 at 21:42
  • @KevinB: Right. The problem with the sticky header, in your opinion, is that it doesn't earn it's keep. It's all well and good for the site owner to want it, but what does it do for the users? (I have a slightly different viewpoint because I like seeing notices shortly after they occur, having access to the search bar at all times and the ability to switch sites without scrolling. Maybe there's no combination of functionality that will make the sticky topbar useful for you.) Aug 27 at 22:28
  • My opinion of it is also soured by past usage of the header, to be fair. (Possibly current to an extent?)
    – Kevin B
    Aug 27 at 22:42
  • 2
    @JonEricson "I like seeing notices shortly after they occur, having access to the search bar at all times and the ability to switch sites without scrolling." The problem is that the top bar is not really good at any of these things. Search engines are much better than the semi-broken internal search, for notifications there are better 3rd party programs which will notify about inbox messages regardless of whether I have the browser open or not and site switches are much easier with bookmarks than clicking thorough endless hamburger menus ... Aug 28 at 10:12
  • 5
    @gnat Dark mode was also part of the last winter bash to get a hat/mask - good opportunity for a lot of users to get to know the feature. Personally I set it to automatic for this event and then forgot about it because my system is in light mode anyway. Aug 28 at 10:58
  • 5
    Dark mode also had the huge banner as seen in this blog post. Aug 28 at 12:28
15

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.

2
  • 3
    We want wikipedia to be the odd one out here. Can't copy-cat them ....
    – rene
    Aug 31 at 6:12
  • 2
    For each of these websites, I can name one other that offers the option to disable it, or doesn't have it. Case 1: Southwest Airlines. Case 2: Bing. Aug 31 at 7:38
14

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.2.1
// @copyright   2021, 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; }
  .top-bar:not(.specificity-hack) { position: static; }
`;

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; }
.top-bar:not(.specificity-hack) { position: static; }

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.

20
  • 1
    What's with the copyright line? It's CC-BY-SA now :) Aug 25 at 21:58
  • 2
    @Unconsidered: Copyright ≠ license. I'm still the author and copyright holder, whatever license I may choose to grant. (FWIW, my user profile includes a blanket CC0 dedication for any original content I post to SE, including this script.) Aug 25 at 22:19
  • 1
    As mentioned above by Unconsidered, simple .top-bar.js-top-bar{position: absolute;} works. Aug 26 at 8:13
  • 1
    I suppose that not much can be done for mobile browsers, where this change has the biggest impact. I guess it could be done using a bookmarklet, but it'd be a pain to have to click a bookmark every time you open a question page.
    – PM 2Ring
    Aug 26 at 9:08
  • @PM2Ring: Apparently it's possible to install Tampermonkey on Firefox Mobile (at least on the Android version) and run user scripts that way. It's just not particularly easy, since you can't (currently) install it via the official addons.mozilla.org collection. :/ Aug 26 at 10:14
  • 3
    @PM2Ring: For a bookmarklet, just javascript:(function(){document.querySelector('.top-bar').style.position='absolute'})() should be enough. It won't fix the extra whitespace in the left sidebar, though. (The reason my user script does it differently is that it tries to inject the custom style before the page has loaded to avoid any needless redraws and layout changes.) Aug 26 at 12:27
  • Ah, of course. :) Yep, that works.
    – PM 2Ring
    Aug 26 at 12:28
  • does this intermittently fail for anyone else? (document.head || document.documentElement) is often null?
    – Kevin B
    Aug 26 at 15:00
  • @KevinB: Are you using Greasemonkey? That seems to be a known issue. I do have a work-around, I just didn't realize it was still needed. :P Aug 26 at 16:31
  • I'm using tampermonkey. For now i've set it to run at document end, but that of course causes a FOUC. At least it works though. I'm running on a particularly slow environment, could be affecting how likely it is for me to have this issue
    – Kevin B
    Aug 26 at 16:32
  • 2
    @KevinB: Can you test this version and see if it works reliably for you? Aug 26 at 16:42
  • 1
    @IlmariKaronen Thanks, that does work reliably
    – Kevin B
    Aug 26 at 16:45
  • 2
    @OlegValter: If I wanted the code to run only after the DOM has been fully parsed, I'd just remove the @run-at document-start line. The mutation observer trick lets the code run as soon as the page starts loading and there is a documentElement into which I can inject CSS and/or JS code — which is usually true when the script runs at document-start, but not all user script extensions actually seem to guarantee that. Aug 26 at 17:23
  • 3
    @OlegValter: In this case, basically to minimize the risk of a FOUC, e.g. the top bar appearing briefly and then vanishing as the script runs, when following a link to an answer. There are other reasons to run user scripts early (e.g. some of my scripts modify the MathJax config, which must happen before MathJax itself loads), but for a simple CSS injector like this the main issue is avoiding FOUC. Aug 26 at 17:40
  • 2
    Upvoted: that CSS was exactly what I needed for Stylus :) Aug 27 at 16:29
10

UserStyle to fix (yet another) pointless change:

/* ==userstyle==
@name Stack Exchange
@namespace Steven Penny
@version 1.0.0
==/userstyle== */
@-moz-document
domain("stackexchange.com"),
domain("stackoverflow.com"),
domain("superuser.com") {
   .top-bar {
      position: absolute;
   }
}

https://github.com/openstyles/stylus

1
10

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.

2
  • 2
    “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?” — Please don’t. The browser’s own top bar already does this. This would double scroll-sensitive content, and be more confusing and frustrating. Sep 1 at 14:06
  • @SebastianSimon Like I said, I don't know if any of those suggestions are the "right" solution. They're just examples of how the choice doesn't have to be "always sticky" or "never sticky".
    – ColleenV
    Sep 1 at 14:09
9

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');
    }
});

4
  • 4
    Works also great with greasemonkey. Thanks a lot for the script and giving us back the choice to actual see the content we are here for on your screens! Aug 25 at 21:01
  • 2
    Actually, given the current content and headers it should work with Violentmonkey or, with a small adjustment to wrap it into a load event listener, directly from the console (or snippets) - so you can safely claim support for all major userscript managers. Aug 25 at 21:03
  • 3
    Here's my version. Aug 25 at 21:23
  • 1
    Y'all are welcome ;) @IlmariKaronen and others, please report any bugs that you see here. I've seen one already, so I'll fix that - I'm not the greatest scripter.
    – Ollie
    Aug 25 at 23:02
8

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...

1
5

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?

1
  • 12
    Yes, the sticky top bar is an example of a "vanity metric"
    – Mari-Lou A
    Aug 26 at 12:49
-1

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 ReasonsTM that the change will be implemented regardless, and you're just doing us the courtesy of letting us know.

5
  • 9
    Warning us a change is coming, when there's 0 chance any feedback we could provide would impact the result, isn't really all that useful. (the latter part of that is the problem)
    – Kevin B
    Aug 25 at 19:37
  • @KevinB as a for-profit company, they are going to make changes where there's 0 chance any feedback we could provide would impact the result. I'm advocating that they at least provide notice, as a better option than just shipping it.
    – LShaver
    Aug 25 at 19:41
  • I do understand and agree with that sentiment, however it doesn't change the response, ;) You (the royal you) can choose to run the site as standard business and treat the long-term users as no different than drive-by users, or you can choose to invite a joint effort between the business and your most active users.
    – Kevin B
    Aug 25 at 19:45
  • 9
    Unpopular decisions are not the same thing as removing features because you can’t be bothered to maintain them. If custom fonts don’t scale and they have to be standardized because otherwise the servers will crash once a week (I’m just making stuff up here) that’s something understandable. We did a bad job making it easy to account for the stickiness of the top bar during development, and we’d rather piss off 13K of our users than continue to maintain it is something else entirely.
    – ColleenV
    Aug 25 at 20:07
  • 6
    You’re right, but this has been requested since 2019: Please consider gathering Meta feedback before the “ship” stage. Aug 26 at 2:07

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .