Reader: Inconsistent recent posts

[mmtr]

Context and steps to reproduce

See p1737706088502309-slack-C02FMH4G8

When switching between the "Full post" and "Scrolling feed" views, the list of recent posts is inconsistent.

Scrolling feed	Full post

It seems that they don't use use the same dates for getting the posts, and the "Full post" view is more restrictive.

Ideally, both should display the same posts.

Additionally, if there are not recents posts, it might be better to write something like "nothing posted in the last X days" with maybe a link to the reader for that site to see all posts.

Site owner impact

Fewer than 20% of the total website/platform users

Severity

Moderate

What other impact(s) does this issue have?

No response

If a workaround is available, please outline it here.

No response

Platform

No response

[mmtr]

@Automattic/loop maybe you can take a look at this?

[github-actions]

OpenAI suggested the following labels for this issue:

• [Feature Group] Reader: The issue is specifically about inconsistencies in post displays within the Reader feature.
• [Feature] Reader: This highlights the specific functionality related to how recent posts are displayed in the Reader.
• [Feature] User Interaction & Engagement: The inconsistency in post visibility affects user experience and engagement with recent content.

[davemart-in]

Yep. Thanks for writing this up.

@DustyReagan can you please grab this one?

Let's:

A) Make sure the date selection criteria is the same between the two views
B) Change the "Nothing posted yet" message to be "Nothing posted in the last X days"

[DustyReagan]

The "Full post" view uses the /read/streams/following endpoint and has a 60 day limit defined here:
fbhepr%2Skers%2Sjcpbz%2Sjc%2Qpbagrag%2Syvo%2Sfgernz%2Qohvyqre%2Qpbasvt%2SFgernzf%2SSbyybjvatFgernz.cuc%3Se%3Qs1pq9827%2323-og

The "Scrolling feed" view uses the /read/following endpoint and has no date limit, but it can take an optional after query parameter to limit the date range.

The most straightforward way to achieve parity is to add the after parameter to the "Scrolling feed" so that it also only shows posts that are less than 60 days old. But I'll highlight that this means that the "Scrolling feed" will only scroll to 60-day-old posts and then stop. That includes when you're viewing "All" posts. So, we'll probably want a message at the bottom of the "Scrolling feed" that says something like: “You’re all caught up! This feed shows posts from the past 60 days. Visit the individual sites to view older posts." Thoughts on this? cc @davemart-in

[davemart-in]

@DustyReagan Yeah, I think adding a note at the end of the feed makes sense for folks who may have just added one site with older content. For regular feed usage, I would never expect to see posts older than 60 days in my recent feed.

[DustyReagan]

Here is my proposed PR for "A) Make sure the date selection criteria is the same between the two views." Reader: Limit Recent "Scrolling feed" to posts newer than 60 days to match the "Full post" feed

I'll create another PR for "B) Change the "Nothing posted yet" message to be "Nothing posted in the last X days""

[DustyReagan]

Both PRs have been merged. ✅

[Addison-Stavlo]

this means that the "Scrolling feed" will only scroll to 60-day-old posts and then stop.

This feels weird for various reasons:

1. The recent feed stream is great for catching up. If hypothetical user goes hiking for 3 months while on a sabbatical, they should be able to come back and scroll down the recent stream reverse chronologically to catch up on whatever they missed. Hitting a wall that stops showing posts past a certain date is essentially telling the user "go find it yourself if you care that much". This seems like a regression / limitation in functionality of the recent stream.
2. We shouldn't put retroactive limitations on one stream, simply because there is another stream that has limitations and we want limitations to match. It seems like we are making one stream worse because the other isn't good enough?
3. Applying this limitation from the front-end instead of the backend disconnects the results more between web and mobile, ideally stream changes we will want to make on the backend so the apps have parity. @spsiddarthan recently moved a similar front-end change to the backend because of this concern p1737644861727019-slack-C03NLNTPZ2T
4. The scrolling feed is setup for infinite scrolling pagination, why apply a hard cut-off?

To me we could have simply just added a better "no results" message in the full post dataviews, and avoided imposing extra limitations on the scroll feed. Just communicate that the finite view only shows posts from the last 60 days, maybe give it a button to retrieve older at the bottom regardless, or a link to open the scroll feed instead if its empty. But the lack of parity between what shows up in infinite-scroll vs. finite-full-post is OK if expectations around that are set and clarified. But I don't think that restricting the infinite scroll feed to be... no longer infinite... is the right call here.

[DustyReagan]

This is great feedback, @Addison-Stavlo! Thank you! Personally, I’m okay with leaving the cutoff or reverting to infinite scroll.

If we revert the 60-day cutoff in the “Scrolling post” view, I agree that adding a clearer “no results” message in the “Full post” view would help explain why older posts don't show there. That could be enough to address the issue.

@davemart-in, do you have any strong feelings either way? Addison, if we go back to infinite scroll, would adding a “Show older posts” button (a “soft” cutoff) address your concerns?

[davemart-in]

I think Addie makes some valid points. I honestly don't feel overly strong one way or the other.