Well this @mention is a bit more complicated than what one might think. For example: If someone creates a post, without any @mention, then edits it, and adds a @mention — then, do you detect this, when looking at the edits, and send a @mention notification now? And what if s/he edits the post again, and removes the @mention, then, do you remove the notification? Cancel the email if it hasn't been sent yet? And if the email has been sent, and the user clicks the link, and views the post — but the @mentioned user sees no @mention because it was removed, then ... this is not good UX. Should you do something about this? Explain that the @mention got removed? Or just leave the user slightly confused?
Also, do you really want to send an email for a @mention immediately? What if the user who writes the post, keeps editing it, after having saved it? Should you wait for a minute or two, until s/he seems to be done editing it? And then generate the @mention email? Or directly, even if then an early out-of-date version of the post will be included in the email.
What if the @mentioned user is in do-not-disturb mode, then you need to schedule the notification for later.
And what if the @mentioned user is already online and sees the post with the @mention in, diriectly? Then maybe you needn't generate any notification at all. But how do you determine what s/he is reading currently?
There's a lot to think about (more than what I mentioned above) that one might not think about, ... before one starts implementing everything. — And this is just for @mentions. ... Kind of goes on like this, with every small seemingly simple feature you want to add.
It's a forum. Read the thread and don't have any such concept as a "mention". If you get quoted, you'll see it as you go through the pages. If you're really lazy just namesearch your handle (which may or may not change, may or may not be unique, etc) but basically participate don't just cherrypick.
Right, but you would just be one of the rare users that turns the system off. Which is fine, but don't let it blind you to what the typical user wants.
"Just use the /search feature to find replies" isn't something I can say with a straight face to the sort of users I have. I would just leak them to competing forums that have good UX. It's no ideal for someone to be unaware that a thoughtful reply was made to a post they invested in.
If they were so invested they'd be reading the thread for people who are communicating about the topic. For people who are referring to comments or quoting other posts or didn't specifically @mention to drag a person back to look STRAIGHT AWAY lest they lose engagement.
@mentions on forums are good UX in the way that twitter @mentions are good UX - they drive clicks and opens - not engagement. They don't push good content, good conversations, good experiences. They allow people to sandbox discussions, to talk across each other. To skip volumes of content to just get their little piece.
Having the feature degrades the forum community imo, irrespective of who does and does not use it.
I'm a guy who likes old school forums though, so, you know, my opinion is probably not worth that much ;)
Seems you've had a bad experience with mentions. Maybe people have been using them in the wrong way, where you've seen them.
At work, we were using Slack, and @mentioned each other "all the time", and I'm fairly positive we would have abandoned Slack if people couldn't mention each other. Mentions are like going to the other person, and saying, "Hi, look there, you knowledeg & help is needed over here a short while". And then the other person takes a look, replies with help or status update for example.
Our mentions were related to none of driving clicks or opens or engagemenet — instead, it was about getting work done, directly rather than ... some day later when the person happened to maybe see the relevant comments.
Can someone @mention (and thus notify) everyone on the forum in one post? Of course not, just take the first 6 unique mentions.
But what if they edit their post and @mention 6 different people? Easy, edits don't trigger notifications. Well, what if someone forgot to mention someone or typo'd someone's name and they just want to make that edit. Seems pretty lame that they can't fix their mentions.
So if you want to allow the latter but not the former, you need to start tracking historical mentions per post in the database. Which you needed anyway so that someone can't @mention, delete the @mention, and then @mention again to trigger dupe notifications.
And what does the notification actually look like if someone edits a one-week-old post to add a @mention? It's kinda confusing for a user to see "Foo mentioned you in post #123", click the link, and see that the post is a week old. They report it as a forum bug. So maybe you now have some logic that sends a notification with "Foo edited post #123 to mention you." Yet another if-statement.
We both could go on and on.
And this is how every feature goes. They are hard problems without a best solution, only trade-offs.
At least if you're building a generalized forum like phpbb, you're solving a problem that will compound across thousands of users deploying your forum software. Meanwhile my forum was completely bespoke for my community and I couldn't shake the feeling that I was wasting my time.
So then it was tempting to wonder if I should work on generalizing my forum so others could use it. Well, now you're even in the bigger hell of generalizing software in a pond with dozens of formidable competitors in a world where you're pretty certain that traditional forums are slowly dying. Good luck with that.
What if the @mention user decides to change his/her display name, now you need to parse @mention into a unique id and save that in the database with comment body and then translate it back when you serve it to the currently chosen @mention name...
Of course it's social media. The username and avatar is one's social identity on a forum. I think you have a very narrow experience with forums if you find it surprising that someone wants to change their username if you accept that they would also want to change their avatar.
A good example of "the devil's in the details" is the decision chart of how Slack decides whether to send a notification for a particular message.
I mean, how complicated could it be, if the user is in the channel and he doesn't have notifications turned off, then send it, it's just a simple nested if statement, right?
But, it turns out that when you map out all of the decision points, it's quite a bit more complicated.
If you count the situations that lead to "No" you'll realize that all the "No" cases can be easily checked for, and if you're not in a "No" case then you're in a "Yes" case.
Can probably be implemented in a regular function with about 30 lines of code?
You're glossing over the fact that in order to have all of those complicated notification rules that users expect, you have to allow the user to set all of those complicated notification settings. You have to give them the ability to subscribe to threads, set notification preferences for a variety of items (channels, username mentions, keyword mentions, @here mentions, etc), set DND and exceptions, etc.
> If you count the situations that lead to "No" you'll realize that all the "No" cases can be easily checked for,
I think you might be under-counting the "No" cases.
I counted at least 30 (and then stopped, with plenty still to go) so I don't think you'll get it in 30 lines of code unless you have some very long lines with rather impenetrable logic.
Counting paths from the first node to the "NO" node rather than just counting total edges leading to the "NO" node.
Many of the conditions you mentioned are themselves determined based on various other conditions, and/or only triggered if certain paths (but not others) are followed.
> You can check these conditions sequentially and if any of them match, return false.
Not so.
For example, you could have the 'notification preference for device set to "never"', but there are paths through the flow diagram that evaluate to "YES" without ever going through the path that checks for the global device notification preferences.
Therefore if you are just sequentially checking each of the conditions you mentioned, then you'd be returning false (because that one statement matched) instead of true (because the flow should never go down that path).
No matter. I transcribed that list in a matter of 5 minutes with no knowledge about the application (I haven't used slack in a long time). I'm not going to get it right in 5 minutes. It will obviously take time.
But, this is not the kind of thing that justifies, for example, having 20 engineers to work on this one problem for three weeks.
It's still a simple thing for one person to handle in a couple of days.
I don't get why people use feature lists as an excuse for why things take a long time and require many many engineers.
I guess it is complicated compared to all the features mentioned before: complicated is not the right term, but extending users sessions with notification/messaging support is probably more code than the rest of the forum combined (in every language).
Suddenly there are a lot of things (on top of user sessions, which most web languages/environments have plug and play solutions for) hitting your database and effecting your caching strategies.
A modern forum system is a culmination of all these features and many more.
And each feature always seems trivial on the surface. That you pick on this feature as an easy one makes me chuckle and shake my head slowly as I recall the hubris of my past self.
I once made the mistake of thinking that building a forum would be easy, so I can relate.
Really? _that_ is complicated?
Serious question, do you find it complicated because you're still a beginner, or is there something I'm missing?
What language(s) did you use?