What should "Hide read posts" do?
What should "Hide read posts" do?
Edit
Thank you so much to those who responded. I think all of the answers here has given me the gist of why people want this feature: to see new content, but in a temporary sort of way (almost like a "new content" button). I think with this direction I should be good from here. If anyone has any specifics they'd like to see for this feature feel free to post it. I will read it all before I implement this feature tonight after work (in ~6 hours).
Original
This is concerning the action in the FAB overflow menu "Hide read". I thought about this feature more yesterday and I ended up with ever more questions.
This button is an action which is what I think it making it so weird for me. It's not a setting. So one would think tapping it would make some change each time, and that change is different each time it's tapped (ie. it's not idempotent).
Here is what I'm thinking. When a user taps "Hide read", all posts that the user has read in that session and in the community they are currently looking at are added to some "hidden list". This list will contain any posts hidden in this way and only this way (well i might add a hide post action on each post later).
This means that if you read a post yesterday, came back to the app today and then tapped "hide read", that post will not be hidden even though you've read it.
Only posts that you have read in your current session for the current community you are on will be hidden.
There is an edge case here where a post you've read yesterday appears in the feed today, in the community you are browsing. In this case, if "Hide read" is tapped, that post will be hidden.
Is this what users would expect "hide read" to do? For people who used this feature in other app, is this what it did in that app?
You're viewing a single thread.
I expect it to hide everything I've opened at least once on the current list (and next pages) and then forget I pressed that button the moment I go to a different community/sorting/any feed switch. That's how Relay conditioned me to use it
If I were to design the feature I'd make it a toggle instead of a press once button that persisted until I closed the app. Maybe you can add a setting for if you want the app to remember the toggle state permanently, but I'd probably want to see everything again when I re-open the app
I do not like the idea of the list of "opened" posts being reset when you reopen the app (is that what you mean by new session?). If I read a thread in the afternoon, open the app in the evening and then click hide, I expect it to hide the thread I read in the afternoon.
This unfortunately just gave me even more questions.
On the surface this sounds literally the same as the server's version of "show read posts" but client side. This has some issues such as when would posts actually be hidden? If you read a post and the went back to the post list screen. Will that post just instantly disappear? If mark post as read on scroll is enabled, it would be pretty jarring of an experience if you scrolled down and all your posts just vanished.
This also raises some concerns performance wise as well. A client side hide read feature would require the client to request substantially more posts. Eg. you've read up to page 10 of "All". Now if you refreshed "All", the app will need to refetch up to 11 pages because it's very possible you've already read the first 10 because Lemmy posts don't change that often. I could just implement this and see what happens though, maybe it won't be so bad.
Thinking about it more, my concerns with when a post will be hidden is probably why a lot of apps have it act like an "action" and not like a toggle. One crazy idea would be to combine the two somehow. Eg. have the "Hide read" button act as both an action and a toggle somehow. One idea is to have the row in the menu have maybe a long press to disable feature. This would be extremely hidden though.
Probably not a good idea to hide things behind a long press. You could give the option to change the action between permahide and singlehide in the settings if you want to have both
The current button on the FAB is on point of a good direction and the read post should be hidden temporally just when you press it, that's how Relay, Sync and Boost for Reddit worked.
If you close Summit or refresh the feed the read posts should re-appear dimmed, until you hide them again.
Wait so it disables even on refresh?! I mean that makes implementing the feature a lot easier for me. I'll give it a stab tonight. This should be easy to implement.
Yeah, read post re appaering but dimmed (as you must read them) is like many apps handled this when you refresh the feed :)
I did a quick implementation and a demo of the feature. Can you please verify that this looks good? https://www.youtube.com/watch?v=fBGmkHP9abg Thank you so much!
I think it looks pretty great!
The performance concerns make sense, that might be why Relay has it as an action only for already loaded posts. If you're unsure of how to start I think just copying Relay's behaviour would be good enough there - no performance issues, and not difficult to understand
I personally don't use/want hide on scroll, only hide on open/click (so I don't read the same post twice). So for me posts vanishing as you scroll past them wouldn't happen
This brings me to a feature request that Relay is missing - a toggle to hide/collapse text of comments that were made before x time. Relay let's you quickly navigate between comments that were made in the last x timespan, but not hide the rest alongside it. If I only wanna see subcomments from the last 3 hours then I need to order by "chat - new" and that collapses trees into single comments which is weird
I updated the post to give some information for which direction I'm going to take the feature. My current idea is to just make it be a "new content" button. You press it and you will only see new content (new content as in things you didn't read) from the time you've pressed it. Force refreshing the page will disable it and show you old content again. This kind of deals with the performance issue by adding friction to the action. Eg. you need to physically press a button to hide read posts. This at least means users probably won't press it every second like software would.
I did a quick implementation and a demo of the feature. Can you please verify that this looks good? https://www.youtube.com/watch?v=fBGmkHP9abg Thank you so much!