Wondering if this will always be free?  See why free is better.

Main Menu

Change alerts behaviour

Started by Arantor, May 28, 2022, 11:52:08 AM

Previous topic - Next topic


Going back to what @FrizzleFried  and I talked about previously, and the discussion that led to I think a rethink of the alerts dropdown would make sense.

Specifically: I don't think the actual act of *marking alerts read* is inherently a problem, neither is the changing of the number up top.

What *is* the problem, however, is nuking them from the list forcing you to go look them up in the  profile area. What it should do is fetch all alerts (say, everything unread + up to 2 days' worth of unread) and make the ones that are unread more visually prominent, and otherwise leave the behaviours about auto-marking alone.

This would match how people actually use notifications and be less confusing. I realised that my own use case over the last few years had this modified because we had other ways of tracking topics of interest and what you might observe as a 'todo list' so the list of topics of interest that needed a response/engagement was never in question, but coming back around to it I think this would actually solve the problem better than my quick hack.


Actually ... this is a fantastic idea!  Perhaps create a setting to allow the user to set the number of "days" of alerts to show at any given time?   New alerts come in bold/bright... read alerts revert to non-bold/light-gray, etc...

Awesome idea!


But do you still want to keep the alert dropdown?
"Greeting Death as an old friend, they departed this life as equals"


Yes... that drop-down is what we are referring to.


Yes, it's just changing what the dropdown shows. Instead of *only* showing unread, it should show recent alerts.


Ah, I understand now. Maybe, to avoid collapsing the interface with that dropdown, instead of limiting by days, limit by number of alerts. Say, always show the last 7 alerts.
"Greeting Death as an old friend, they departed this life as equals"


The alert dropdown is scrollable (has been for years). But even then, maybe (unread) + (last 2 days) + (no more than 30)?

Anyway I wouldn't worry too much about the exact details. I'd be inclined to get the broad strokes right and see how it feels for people.


Fine, seems reasonable to me
"Greeting Death as an old friend, they departed this life as equals"


Well if you're going  do that, for God's sake give all the top bar dropdowns a decent height. 120px is ludicrously small, even on the smallest phone.


Well it has a size of 87px when empty, 120px is, what, not even two alerts?

I never originally added the weird scrollbar JS to it when I set it up originally, and I'm sure I had it taller than 120px even with mobile in mind back then.


I was not accusing you, just stating my preference. :)
Is the weird js scrollbar used anywhere else? Because, if not, it's hardly worth a plug-in.


I can't even work out how big it's allowed to get because of that scrollbar code. I've even had a go at defenestrating it a couple of times over the years but it seems to break in other ways if I try :(

But it's that which constrains the size.


Yep, I tried playing with it myself. Convoluted and opaque BS. If it's only for one effing scrollbar I'd be inclined to just ditch the plug-in. You can style scrollbars on desktop these days anyway, and all mobile devices do inconspicuous scrollbars by default.


Oh yeah, if we're going to frig with the top bar drops I still reckon my "one anchor to rule them all" idea is the way to go. ;)

Haven't got around to doing markup and CSS for that yet, but it would be easy.


Quote from: Arantor on May 28, 2022, 04:35:12 PMI can't even work out how big it's allowed to get because of that scrollbar code. I've even had a go at defenestrating it a couple of times over the years but it seems to break in other ways if I try :(

But it's that which constrains the size.
Just looking around for something else, and found this:
Code (script.js) Select
if ($(this).hasClass('scrollable'))
skin: "default-skin",
hScroll: false,
updateOnWindowResize: true
So commenting that out and/or removing the .scrollable class from the markup should sort things out nicely. You'd get default system scrollbars on desktop, but IMO that's not a big deal. You would just set auto overflow and a reasonable max-height anyway (something like 70vh on mobile would make sense).

ETA: Had a look around, and the 3 kB scrollbar CSS + 23 kB scrollbar js is only ever used for the alerts and PM drop menus. I've killed it on my test site (index.css and template tweaks, + comment out in script.js) and it seems fine.


Further to the above, I'd add the following, though I realise some of this is going to be exotic to explain.

1. Alert grouping

Exactly what the mechanics are for this, or what they should be, is unclear to me right now but it feels like we should be able to group alerts together, e.g. if A, B and C all like a post since the last time I looked at my alerts, this feels like I should get a single alert (potentially even counted as only 1 alert) that says 'A, B and C liked your post'.

Now, the question remains whether this is done at the point the alert is *created* or at the point where it is *displayed*, and whether you group them together for the purposes of making the number correct. This is also influenced by how often the number must logically be recalculated for that to be the case; certainly every time you *receive* an alert the number of alerts you have unread is recalculated and then stored. It's also recalculated when you *read* an alert.

My gut reaction is to treat the *number* of alerts as the number of *grouped* alerts you have, namely that 'A liked your post', 'B liked your post' and 'C liked your post' are three alerts, but count and display them as a single alert grouping on display + counting.

The trick will be doing it efficiently enough without making another table of stuff (or making a new special alert type), because it's very easy to spend more time faffing around to pretty this up. I will note that XenForo doesn't group, NodeBB does (but it's slightly easier for NodeBB to do so given that it's not using MySQL)

2. Message bus

Now this is the really more controversial thing. So, every x seconds (and this shouldn't be user configurable, maybe admin configurable), we make a query home from the client to the server. This is known as a message bus and you use it for a heartbeat but also to ferry information around.

Specifically, you'd use it to phone home to get current alerts count, current PM count and stuff like that. If you're also in a topic at the time you could use it to fetch information about the topic you're in, like whether the topic has had new replies, or whether it had been locked.

You shove the details into localStorage for *each tab* including the last time any one tab phoned in, so that you only make one call home total regardless of number of open tabs, and you can refresh the state of each tab that way, assuming you want to.

There's also no reason you couldn't tag on draft saving onto the message bus as well to avoid more out of band trips being made.


IPB groups as well. The fan forum for the local amusement park uses IPB (has since before I became a member 17 years ago) and I got one that says "A, B, C and 1 other liked your post in <topic>". I believe it grouped them at the time I accessed the forum but I could be wrong.
Michael Eshom
Christian Metal Fans


I'd also like to have the option to sort alerts by subject to make it easier to delete a whole batch (I already have checkboxes displayed).

The reason for this is that a topic I was subscribed to had 25-30 responses between two login periods (ie, overnight) and I wanted to delete all the alerts for that particular topic so that I could easily see the other alerts that had arrived during the same period ...
Life doesn't have to be perfect to be wonderful ...

"Before you allow people access to your forum, especially in an administrative position, you must be aware that that person can seriously damage your forum. Therefore, you should only allow people that you trust, implicitly, to have such access." -Douglas


All good ideas.

Regarding the scrollbar JavaScript, I also hate it and I don't know why it is even there. (It was added before my time.) Ditching it would be highly desirable.

Regarding grouped alerts, I like it in theory, but the devil will be in the details. Our best bet would probably be to add an integer field in the extra info JSON that we store for like alerts, and then increment that number rather than generating multiple separate alerts. There would need to be some more logic as well, of course.

Regarding message bus, yes, I like this. Right now we have a number of separate AJAX requests that run independently for different purposes. It might be more efficient to route those into a single request and response transaction.
I promise you nothing.

Sesqu... Sesqui... what?
Sesquipedalian, the best word in the English language.