New content indicator - ignore content I can't see

[Suzuki Stumpy]

More of an annoyance than an outright bug I guess.

 

If a private thread is updated in a sub-forum, then the 'unread content' indicator for that forum still shows there is unread content - even though the content isn't visible.  For example, check the screenshot below - there's no visible threads at all in the side-stories page, but it still indicates unread content.  Same goes for the game in the main game widget on the homepage - the game shows me that there's unread content for me, but when I go there, there's nothing there that's visible to me.

 

Anything that can be done about this, or is it one of those 'too difficult, learn to live with it' kinds of issues?

 

[Eric]

8 hours ago, Suzuki Stumpy said:

More of an annoyance than an outright bug I guess.

 

If a private thread is updated in a sub-forum, then the 'unread content' indicator for that forum still shows there is unread content - even though the content isn't visible.  For example, check the screenshot below - there's no visible threads at all in the side-stories page, but it still indicates unread content.  Same goes for the game in the main game widget on the homepage - the game shows me that there's unread content for me, but when I go there, there's nothing there that's visible to me.

 

Anything that can be done about this, or is it one of those 'too difficult, learn to live with it' kinds of issues?

 

I'm pretty sure it's solvable. Did the home page have the unread indicator set for that game, or did you only see it when you went inside the game?

[Vladim]

I can unprivate the thread, lol 🙂 There's no big secrets in it, just my subpar writing!

[Suzuki Stumpy]

3 hours ago, Eric said:

I'm pretty sure it's solvable. Did the home page have the unread indicator set for that game, or did you only see it when you went inside the game?

No, the homepage indicator also shows the game as unread, even though everything accessible to me is read.

 

1 hour ago, Vladim said:

I can unprivate the thread, lol 🙂 There's no big secrets in it, just my subpar writing!

😆😆😆 … still needs to be looked at though, otherwise someone else will only mention it later..

[Eric]

6 hours ago, Suzuki Stumpy said:

No, the homepage indicator also shows the game as unread, even though everything accessible to me is read.

That's good news, because the code behind the two indicators is different and knowing that one is working while the other isn't means I can try making the tab indicator code the same as the home page code and hopefully resolve the issue quickly.

[hakootoko]

The same thing happens on oMW. The solution is to click on 'Mark all as read' after reading all the threads you can see.

[Eric]

Added to the tracker!

[Eric]

This is going to end up taking a bit longer to work. At present it's no worse than OGMW, so I'm going to prioritize it lower on the list.

[Suzuki Stumpy]

No worries, it’s only an annoyance rather than an outright bug, so I’m cool with it as long as there’s awareness.

[TiffanyKorta]

I'm in a game right now where everyone is in private links, and whilst it's trivial it gets a little annoying to get notified that there are new posts for stuff you can't see! Is there a way to not get notifications for private threads that aren't yours?

[Eric]

Ah, the age-old request. As much as I'd like to say "yes, I can do this", here's why this is a "very difficult" problem to crack.

 

To determine whether a given container is unread, the server needs to know two things: (1) the last item you read, and (2) the last new item in the container. Item (1) is stored in a table that basically lists, for each container, the last time you read the end of the container. Item (2) is similarly kept in the table of containers, indicating when that container last had new content submitted. These two data points are thus easy to find given user A looking at container B, and computationally trivial to determine whether the Item (2) date is after the Item (1) date.

The solution to the request requires determining a hypothetical Item (3), the last new item in the container that is visible to the user. Instead of being available in a simple query, now we have to look up all new content since the date of Item (1) and determine whether that item is visible. Instead of being cached or indexed, this additional computation has to be done every time a user needs the unread indicator determined. In the case of nested content (topics within forums within games), the additional query and computational cost is multiplied by the number of items.

 

There are three approaches to solving this:

(a) Build a cache that keeps track of the last readable item in each container, for each user.

(b) Throw more computational power to reduce the latency of making the determination to something the user won't notice.

(c) Find a novel computer science-y way of solving this.

 

Unfortunately, (a) and (b) both have substantial cost implications for the site in storage or CPU, which leaves me with (c). If I was pursuing a graduate degree in CS and not a full-time software development manager... but alas, I'm probably not going to have the personal bandwidth to solve this in O(reasonable) time.

[Malkavian Grin]

I'm no CS major or anything, but I've done my fair share of programming and even some database management for web jobs.

Let's say you still do the calculations as they are currently done. You say they are quick and easy on the server. My suggestion then revolves around adding a third check after you do this that looks to see whether you have access or not (something it seems to already be doing) and if not, can't you just run another update that removes the notification? (Maybe to "hack" it, you make it functionally the same as the user clicking the "mark this forum as read" kind of thing?)

The issue is, I don't know the order of operations (nor the structure of the way the site is built--but PHP is pretty flexible with database table checking IMO) so I can't give you specific strategies to accomplish this, just conjecture (which is always helpful right? lmao).

You've probably already thought long and hard about this, so I apologize if this is less than useful.

[Eric]

Rodrigo and I bandied about some clever solutions while we were at MWM. Added to the feature request queue to track.