Option to hide already seen posts

[multimeric]

Pitch

We add an option in the user settings which is "hide already seen posts". When this is enabled, a post is considered "seen" once it is scrolled offscreen (ie the user has scrolled past the post). Then, whenever that post would be shown later, e.g. if the user refreshes the page, if this option is enabled, that post is not displayed.

This "seen" information could be stored permanently in the Mastodon database. However, since this information is only important in the short term (ie for a few days, until the user's timeline has been replenished with new content), it could instead be stored on the user's client ie their browser, perhaps using the LocalStorage API. This would ensure that this new feature doesn't increase the load on Mastodon servers.

Determination of which posts have been "seen" would probably also require the use of JavaScript.

Motivation

Currently Mastodon shows posts on your timeline in chronological order. This is very transparent, but if you do not have a lot of fresh posts (perhaps because it is night time for most users of your network, or because you follow very few people), refreshing the page will give you content you have already seen. Users are therefore likely to be interested in keeping their timeline "fresh", and hiding viewed posts is a similarly transparent way to do this, which avoids the need for a post downweighting algorithm.

[multimeric]

I would happily look into implementing this, if one of the devs can approve the idea.

[Daboiboi12]

Love the idea man that really actually sounds good bro

[lirontocker]

I think there are some potentially significant UX issues here; for example, users may scroll past something and then want to return to it, and content "disappearing" is not a typical UX pattern and would thus represent a learning curve. If you're considering this, please test this with users before it is released, and consider a bridge for the learning curve, such as:

1. If this behavior is enabled by default, explain it to users during onboarding and tell them where they can turn it off (settings)
2. If this behavior is not enabled by default, include the option in settings.

[BhaaLseN]

How about an alternate design that remembers the last seen post (like #20956) and continuing the timeline from there? Or at least annotating the post/timeline in a way so I can find the location more easily?

On Twitter, my usual usage pattern used to be:

1. Open the main site (which brings up my timeline)
2. Scroll down until I get to (one of) the last post(s) I've seen on my last visit
3. Go upwards from there

And let me tell you, they didn't make that easy for me (even with their pseudo-chronological option being on.)
One of the Android apps I briefly used did that by default, but I'm mostly on Desktop and rarely went back.

With Mastodon on the other hand, being chronologically by default made this fairly easy; but the date on the post being the original date with no indication on when it was boosted (or otherwise became relevant for my own timeline) makes this more difficult than it has to be.

[rbairwell]

It might be worth highlighting that the API does support markers which can, as the name suggests, mark where you've got to in a timeline.

[multimeric]

How about an alternate design that remembers the last seen post and continuing the timeline from there? Or at least annotating the post/timeline in a way so I can find the location more easily?

The issue with that is that you miss out on the new content since you last visited. Under your scheme, when you start a new session you necessarily start browsing content that already existed in the past session, and if you press "home" to view new posts you eventually hit content you've already seen which brings us back to the original issue. By hiding posts you've already seen, you bypass this issue entirely.

[multimeric]

It might be worth highlighting that the API does support markers which can, as the name suggests, mark where you've got to in a timeline.

Hmm. I wonder if the Mastodon web client creates these already? If yes, they could be easily leveraged here, but if not I would be hesitant to add significant extra load on the server by automatically creating them for all users.

[BhaaLseN]

Hmm, i see a Bookmark button on posts (hidden away in the ... menu,) but I wonder if thats the same thing. But it would at least help my personal usecase if it was available on the web client.

[BhaaLseN]

The issue with that is that you miss out on the new content since you last visited. Under your scheme, when you start a new session you necessarily start browsing content that already existed in the past session, and if you press "home" to view new posts you eventually hit content you've already seen which brings us back to the original issue. By hiding posts you've already seen, you bypass this issue entirely.

Uh, that would be unfortunate if they appeared behind posts I've already seen. From practise tho, this doesn't seem to be the case (since even right now, I have direct posts with, lets say 8h and 12h timestamps mixed in with boosted posts that are >3d old.) Unless I'm misunderstanding something.

[MForster]

I think the markers that are supported by Mastodon could work for @BhaaLseN's reading style, but they would not work for mine.

• If I understand it correctly, @BhaaLseN strives to read his full timeline, always starting from the oldest unread status towards newer statuses, preferably until he has read all of them. Next time he starts at the position where he stopped last time.
• My reading style does not read the full timeline. I am interested more in the newest statuses first, because they may have more interesting discussion going on than older statuses where the discussion may already be cold, or where the information isn't new anymore. I would still like to see those older statuses, but if I don't make it, I'm ok with just having missed them.

The difference is that in my reading style sequences of read statuses alternate with sequences of unread statuses. I want to theoretically see all of them, starting with the newest unread statuses, and then jumping over sequences of read statuses.

AFAICT this can't be achieved with the markers supported by the API, because it's only a single marker per timeline, not multiple markers for multiple sequences of unread statuses.

[novoid]

Would this also address the issue that if I've seen a post already and some time later one of the accounts I'm following does boost this very same post, I'll have to see it yet another time in my home timeline?

[MForster]

Would this also address the issue that if I've seen a post already and some time later one of the accounts I'm following does boost this very same post, I'll have to see it yet another time in my home timeline?

Depends on the exact design, but I'd argue that this case should be covered.

[luqtas]

it feels that adding that would require some specimen of recent history... or people will bookmark a lot more and they may will require a more robust tool for navigating bookmarked posts (string search, categories/folders etc.)
¶
would a ‹seen› marker be useful or redundant?