Add preference to hide announcements/reload-to-update notifications

[binki]

The notifications that show up on top of documentation in the upper right hand corner appear quite often and are annoying to dismiss. Could there be a preference to either fully silence these or could they be hidden behind a button with a little “new notifications circle” (e.g., like how GitHub shows you that you have unread notifications)? Or perhaps they could just always be hidden behind a clickable notification button and there is no need for a preference.

In my use case, I come to devdocs occasionally but not constantly. So whenever I come, I am trying to read documentation because I can navigate to what I want to read about very quickly but the page is mostly covered by the notifications. I find it annoying to have to keep dismissing them.

Regarding the ~“reload to see new version!” notification, I have no reason to reload immediately because a reload will naturally happen sometime in the future when I close the tab and then open a new tab at an unknown time in the future to find other docs. So I think this notification should also be hideable.

[Thibaut]

Hey

There are two types of notification: changelog (announcements), and updates.

Changelog notifications are pretty infrequent (you can see all of them here) and tell you about new features or significant changes in the app, which I think is important. With those I'd rather err on the side of being annoying than risk people not knowing that new documentations/features were added (which would happen if we were to use a notification circle like GitHub). You should never see those notifications more than once, though; if you do, it's likely that something is resetting or blocking cookies in your browser.

Update notifications happen a bit more frequently — once every week or two. There's a notification asking you to reload, and then a changelog of how your installed documentations were updated (or if new major versions are available). You make a good point that showing a notification asking to reload, right after loading the app, is not a great user experience. For now I don't think a setting is warranted (you're the first to complain about this), but I'll change it to only show the notification if the tab is left open for 5-10min (needed for the many users that leave DevDocs open in one tab for long periods of time), which should greatly cut down the number of those notifications that you see, if you constantly open/close DevDocs in different tabs. Note that all those notifications are easily dismissable, by just clicking on them.

Thanks for the feedback.

[binki]

Just an example of this happening (as I’ve been touching JavaScript more lately, have hit this the past few days ;-)):

[binki]

Note that all those notifications are easily dismissable, by just clicking on them.

Sorry to make more noise, but I rarely have my hand on the mouse when using devdocs.io. Its interface—except for notification dismissal—is quite keyboard friendly. Is there a way from the keyboard to dismiss these notifications?

I might see if I can do some :hover ridiculousness on them with Stylus.

[jmerle]

At the moment the only way to dismiss notifications using the keyboard is to get the close button focused with tab, after which you can hit enter to close the notification. We might be able to make these notifications more easily accessible with tab by giving it a positive tabindex (which means the notification moves to the front of the tab order), but I am not yet sure if that's a favorable approach due to possible accessibility issues.

[twome]

I use DevDocs religiously (thank you for all the labour time you've saved!), and this is my only major gripe with it.

For app functionality updates:

I think adding a small notification indicator / dot / ! / + icon to the corner of the vertical-ellipsis menu button would be enough to indicate something's changed (especially for frequent users like me that would definitely notice a new tiny splash of colour). This would be much like how Chrome and Firefox indicate program updates with a small indicator in the corner of their main hamburger menu buttons (when opened, they then highlight a new menu option that either restarts the browser or opens a changelog - either option makes sense to wait for user confirmation).

For documentation content updates:

It would be great if the notification (or automatic refresh) could happen only if the content of the current page has changed (that might require a more complex system for diffing documentation than already exists, though). As a user, without some knowledge of what changed (or whether it even includes the current page), the decision to update the page or not is meaningless compared to the UI impact of the notification. Personally, I'd be 100% fine in all circumstances with the app just automatically refreshing the page (as long as the incoming new content has already been cached), rather than blocking the content to ask confirmation. The existing multiple-versioning system for docs is more than enough granularity for people who need a specific non-latest version.

[mk-fg]

I think @twome's notification icon proposal is great, and would like to also suggest that it should include hiding any errors in that icon (prehaps coloring it red or changing to an exclaimation mark if they occur, to signal importance).

This is because currently using devdocs.io in offline mode (loading it via proxy and disabling proxy afterwards) creates an error notification on every single page (as site is blocked country-wide here due to cloudflare), and that is very disruptive.

If reporting errors is more important than that, maybe at least adding default-off option to hide them would be a good idea, so that those who already know about errors can find an option to use app regardless, without requiring third-party blocking tools or patches.

(anyone looking for current workaround - add devdocs.io## ._notif to "My Filters" in uBlock)

[j-f1]

What kind of error are you getting @mk-fg? (please open a new issue so we can figure out how to get DevDocs working error-free)

[mk-fg]

Did open #1151, after a bit more testing, found that error seem to be due to disabled/blocked canvas reads in browser (fingerprinting protection).
Seem to be unrelated to this issue in general, and maybe not really a thing worth addressing on its own, but "I know about errors, pls leave me be" option suggested above can be a workaround for such cases.

[davidgilbertson]

Perhaps a simple change that would please many users is moving it to the bottom right. Moving to the bottom right would keep the benefits of informing the user without the downsides of annoying the user.

Side note: I use devdocs every day and love it, excellent work!

[jmacdonald]

First off, just want to state that I really enjoy and make use of DevDocs, so thanks for all of the work involved in creating and maintaining that.

I'd like to add my voice to the others: I find the "DevDocs has been updated" notifications quite distracting. I avoid using the mouse as much as possible, and so I'll reload the page the minute I see it, but then I'm often greeted with another notification, letting me know documentation sets that have been updated. So I'll reload again to dismiss that. 😅 Usually at that point, any context I might have entered, like a documentation set filter, will be gone, and so I have to retype that.

It's certainly not a deal breaker, but it sure is an annoyance. I would be happy with any alternative that doesn't overlay itself on top of the content, and ideally, something minimal, like the icon proposed earlier in the thread that I can ignore until I'm not actively searching for documentation.

[plastikat]

Okay, I have been patient about this issue for years–despite being very annoyed–but now that I have come across this ticket (when I was about to create my own), I guess I'll chip my few cents in.

Now, I really wonder if that's such a big deal for the project developers just to add a preference (disabled by default and with a “Only enable when you understand the consequences” hint), so a user can simply and completely opt out of all notifications on their own consent–and do it without all this “traditional” assessment of how many users are affected (and also not wasting time on coining a suitable alternative notifications design)? It would probably be (have been) the same amount of work that adding the 5-10min delay has taken. And even if there aren't too many of us affected, we're still not a single person–so why keeping us suffer for years? Is such reluctance really warranted? I mean, it would not (have) cut down the project developers rations, right?

To be honest, it strikes me each and every time I see this kind of tickets lingering around for years (seven–in case with this particular ticket) just because the users' rationale is not aligned with the developers' own 🤦 Luckily, in this particular case we have some workarounds (thanks for the uBlock snippet, @mk-fg), but oftentimes this is not the case.