Introducing the unified new view for the topic list

Hmm I was a little hasty here, there isn’t quite consensus on this yet internally…will just give it some time to breathe first.

2 likes

I prefer having the single New (NN count) number on DiscourseHub. I think it’s a better option for most users. It’s simpler and it matches what we show on the community’s main menu. The Topics/Replies distinction is secondary, and users who really need it can filter by TOpics/Replies once they’re in the New list in the site.

1 like

I can understand the argument for simplicity. For me, there’s a difference between a new topic that might interest me and new posts in a topic where I’ve already decided it interests me. That’s why I’d like to be able to see right in the app’s overview what priority the new content has for me, without having to visit the forum and log in first. For me, the strength of DiscourseHub is precisely that I have an overview of all the forums I use without having to visit them individually. That’s what I’m missing right now for Meta. If I need to visit Meta and log in anyway to get the information, I don’t need to check DiscourseHub

2 likes

Yeah, I think we are going for simplicity for now. Remember that in Hub we show other numbers for notification counts. It’s helpful to have that simplicity and match what core does.

2 likes

Bit of a late one on this topic, but we rebuilt after unified new view went stable and a member flagged that topics he’s tracking stopped appearing at the bottom of topic pages. He’d been using that list to hop from whatever he’d just caught up on to the next thing.

@martin you dug into new_and_unread_results up in #20 for the All-tab ordering, this is the other caller of it, list_suggested_for. Before, that path did:

unread_results(…, :high)          # first, takes as many of the slots as it can fill
new_results(…)                    # only whatever's left over
random_suggested(…)

and now it’s a single new_and_unread_results(…) at normal priority. Both paths run through suggested_ordering, so same-category-first applies either way, the difference is that unread tracked topics used to get every slot they could fill before a single new topic was considered, and now they’re in one pool with them. Net effect: an unread topic you’re tracking in another category now ranks below a brand-new topic in whatever category you happen to be reading.

Quiet site, you’d never see it. Ours is busy with people following long-running threads across several categories, so the 5 default suggested_topics slots fill with new topics and the tracked stuff falls off the end.

Can’t tell whether that was deliberate. The announcement doesn’t mention suggested topics. Happy to dig up more if it’s useful.


&tldr: Suggested topics at the bottom of a topic unread lost its priority

1 like

I’ve also noticed the counts being wrong, including the unread count/link disappearing entirely when there’s actually one unread topic left.

Ah not intentional, just never got back around to fixing it after Sam confirmed in Introducing the unified new view for the topic list - #21 by sam that it was fine to. I’ll have to do a fix to make sure the unread results still take priority.

Can’t say I’ve noticed this, but there have been other issues we’ve observed over time with unread counts going out of sync. Would need a proper repro to look into this.

It gets out of sync pretty much all the time for me.

  1. Go to a topic that you’re watching with unread posts (e.g. via the unread topics page or a notification)
  2. Go to the bottom of the page
  3. Number is wrong, likely because it hasn’t accounted for the fact that you’ve read the current topic

Like it literally just happened as I navigated to this topic (my only unread one) via the notification from your reply.


I don’t have repro steps for the opposite where the count is too low or disappears prematurely, but I’ll let you know if I find one.

1 like

Ah I don’t often see this since it’s hidden in Horizon, I’ve got to keep Meta on Foundation so I see it more regularly:

vs Foundation for this topic:

As an aside, @chapoi do you know if this is intentional for Horizon?

Anyway, will see if I can reproduce now that I know the case.

1 like

Yes I see, the count is updated in the topic tracking state service but this component doesn’t update, not sure why:

1 like