Notifications - more annoying than useful?

mtschirs

After using Vanilla for some time, I started getting annoyed by the red notification icon, always compelling me to click on it even though I already checked out the new message or read the new comment it wants to tell me about:

And it is not only me. About one third of the active users of this forum participating in this little survey have already given up, ignoring the red signal with an average number of 17 unread notifications. Another third is behind schedule in making the irritating icon go away and only the last third has a clean notification icon, probably the OCD folks among us.

Suggested improvement: When reading a new comment or message that created a user notification, said notification should become inactive instead of continuing to steal the user's attention with its red eye-catching popup.

Is that feasible / does that scale up?

peregrine

I know what you mean

Sounds like a great idea if it could be done without performance hits.

But I think you have seen a cross section of human behavior, the ones compelled to click it, the ones who ignore it, and the ones who switch from compelled to couldn't care less. I've seen that on forums as well.

peregrine

---

Bleistivt

Well, you'd have to check the activity table every time a user opens a topic, which can be quite expensive.

But I definitely agree that decreasing the count when a discussion that caused a notification was opened would be much better.

Records can easily be mapped using the RecordType and RecordID field. These are not indexed though.

mtschirs

First of all, the GDN_User table already keeps track of the number of notifications via non-indexed "CountNotification" column.

We could get rid of that column and put the information about the number of notifications as well as the related foreign record ID for each notification into e.g. the GDN_User.Attributes column.

Each time a record - such as a conversation or comment - is served, a look-up into $User->Attributes for the record ID would be pretty fast. It scales with the number of unread notifications which can be pruned e.g. by deleting notifications older than x days.

The only problem would be to define what a foreign "record" is. The current getRecord() function in the core library of Vanilla 2.2 is problematic and will probably be removed soon.

To summarize: seems pretty feasible to me and would have a real positive impact on the user experience. However, we would need feedback from the Vanilla repository maintainers whether it should go into the master branch or not.

vrijvlinder

Also I think there is a bug, where if the user was banned or deleted or the discussion was deleted, the notification remains... when you click the notification it just refreshes the page and does not remove the red flag... so one might have one unread that does not exist...and not a way to remove it.

Linc

It seems to me the issue is volume, not automated obsolescence, no? Automating notifications going away seems like a lot of work for a reversed goal. You want folks to click on Notifications first, so that act should zero it out, not a bunch of coding to lower it based on actions.

The core of it is that notifications count ever upward rather than letting related notifications "group" and not increment. If 20 people comment on my bookmarked discussion, that should be '1', not '20'. From my perspective, that's the heart of the problem.

vrijvlinder

Maybe a possible way to enhance the notification system, would be to place the user preferences at the editor level. Per comment or Post.
Have the option to get notified or not based on selecting "Notify me if ....." otherwise no email or notification.

mtschirs

@vrijvlinder schrieb:
Also I think there is a bug, where if the user was banned or deleted or the discussion was deleted, the notification remains... when you click the notification it just refreshes the page and does not remove the red flag... so one might have one unread that does not exist...and not a way to remove it.

I can confirm this flaw for the "new messages" counter. I am stuck with 2 new messages now I got from a spambot that was deleted before I read the messages.

Also, I think the red "new messages" counter / icon should disappear once it has been clicked; not stay there till all new (spam) messages have been clicked and read individually (that is how SMF handles it).

Linc

@mtschirs said:
Also, I think the red "new messages" counter / icon should disappear once it has been clicked; not stay there till all new (spam) messages have been clicked and read individually (that is how SMF handles it).

This is the current behavior of the notifications menu item. Extending that to the new messages item would be a welcome enhancement.