6

When loading a StackOverflow page, the user might notice that the Inbox icon shows unread messages. If the user clicks on it after the page has finished loading, they get a popup. If the page has not finished loading, it cancels the loading and navigates away to a whole different Inbox page (the same as the "go to full inbox" link in the popup).

This is annoying. If it's not possible for the popup to work before the page completely loads, then:

  • the icon should perhaps be disabled and grayed out; or
  • the icon should be absent, dynamically added after page load; or
  • take on a different appearance during loading which makes it clear that it's just a navigation link; or
  • something else: perhaps pop up some box which is empty except for indicating that the content is missing because the page has not loaded. That otherwise empty box can have the "go to full inbox" link at the bottom, like the real popup.
17
  • 2
    The option to go to the inbox needs to work on systems that do not have JavaScript enabled. None of your options allow for that.
    – Catija
    Commented Oct 31, 2023 at 21:01
  • Same behavior for all three top bar elements: inbox, reputation changes, and site switcher, so dupe of a past request to change that behavior. Technical suggestions can be added there as answers. Commented Oct 31, 2023 at 21:04
  • All of the icons in the topbar are implemented as <a> elements, so that clicking on them activates navigation when JavaScript is not available. It's done this way so they function with JavaScript disabled. The popup functionality for all of them doesn't work until SE's JavaScript is initialized in the page. How long that takes depends on your machine, browser, network connection, if the JavaScript has been cached, etc.
    – Makyen
    Commented Oct 31, 2023 at 21:05
  • 1
    This has been reported quite a few times already. Commented Oct 31, 2023 at 21:05
  • Interestingly, this post has a staff answer saying that this should only link to stackexchange.com if javascript is disabled. Maybe there was a regression since then. Commented Oct 31, 2023 at 21:06
  • @CaveJohnson If so, it regressed very shortly after being implemented.
    – Catija
    Commented Oct 31, 2023 at 21:07
  • @Catija the last paragraph of the linked duplicate says that the inbox button was working as expected (doing nothing until the script loaded) already and this question was from 2017. Commented Oct 31, 2023 at 21:10
  • 1
    @CaveJohnson It will link to stackexchange.com when the JavaScript that overrides the browser's default <a> element behavior isn't performing that override. That can happen if JavaScript is disabled or if the JavaScript that does that has not yet executed. How long it takes from the page being visible to when the JavaScript that installs that event handler executes depends on the various things I mentioned above. In other words, what the user describes isn't a regression. It would, of course, be possible for SE to make the JavaScript load and execute faster.
    – Makyen
    Commented Oct 31, 2023 at 21:10
  • @Makyen it's been a while since I did any frontend web development, but couldn't this be resolved using the noscript tag? developer.mozilla.org/en-US/docs/Web/HTML/Element/noscript Commented Oct 31, 2023 at 21:14
  • @CaveJohnson The second-to last is a close to exact dupe. The site should have found that duplicate while I edited the question based on similar terms being used.
    – Kaz
    Commented Oct 31, 2023 at 21:23
  • @ShadowWizardIsSadAndAngry I wonder if this question is a better dupe target as Kaz suggested. The one you used says that the inbox button was working fine. Commented Oct 31, 2023 at 21:24
  • @Catija That is false; the third option would work without Javascript. The item would appear in a form that makes it clear it is a navigate-away element, and since JS is disabled, it would stay that way permanently. Whereas with JS, it would be dynamically replaced with the popup. The main UX problem is that none of those icons change appearance while their behavior changes. If your eyes are on those elements, you don't necessarily see whether the page has finished loaded or not. The UX principle here: don't make UI elements randomly change their state/behavior without a change in appearance.
    – Kaz
    Commented Oct 31, 2023 at 21:28
  • 1
    So... you would recommend the site create two visual states that may just seem like random flickers to most users on a fast connection? So then there's dozens of reports complaining about why the top bar icons flicker on page load? I don't (personally) see that as a good UX change.
    – Catija
    Commented Oct 31, 2023 at 21:37
  • @Catija Here is an idea: while loading, the inbox icon could be shown without indicating any unread messages (no white number over red circle). On page load, it can flip to that representation if there are unread messages. Then you're not tricked into clicking on it.
    – Kaz
    Commented Oct 31, 2023 at 23:51
  • @Kaz but then the number disappears and reappears on page navigation... I'm not sure what loads at what point but it's not a simple thing to solve... but it seems like we solved it back in 2011 and then it broke again... I'm not sure whether it would work to go that route (only redirecting to another page if JS is disabled) but I'd be concerned about how people would navigate if the JS just failed to load rather than being disabled.
    – Catija
    Commented Nov 1, 2023 at 0:05

0

Browse other questions tagged .