Mark All as Read Behavior

[vincode-io]

The Issue

I don't think the Mark All as Read function should mark items that I have begun to read and then marked as unread to read when used. My reasoning is that because I have explicitly told NetNewsWire that I want that article marked as unread, NetNewsWire shouldn't automatically mark it as read when the Mark All as Read function is used.

My Reasoning

The main reason that I will mark an article as unread is that I don't have the time or energy to read an article that I may have opened which marked it as unread. I could star the article, but that isn't what I use starred status for.

To me starred is for articles that I want more permanence in how long it is saved. For example, I have Supporting async/await as a module owner starred because I think I might need it to migrate some of the RS project code to async/await. That might not happen soon and I want to be able to reference this article at anytime in the future.

That is different from an article that I want to read soon, but don't mind losing if I never get to it. I guess I could use a Read Later service, but I don't. I figure that we have Mark as Unread for a reason and that reason is because I want to see it in the Timeline the next time I pull that Timeline up.

Because I use Mark as Unread (for what it intended, I believe) I have to be very careful when using Mark All as Read, Mark Above as Read, or Mark Below as Read. I have to keep it in my head that as long as I am in a Timeline that I have done a Mark as Unread, that I shouldn't use the bulk marking functions.

I didn't even know I was doing this until we were working on the design for Mark Read on Scroll, but I have been thinking about the behavior of Mark All as Read ever since.

The Consequences

I realize that there is a lot of inertia to changing the behavior of Mark All as Read. Rightfully so. It has literally worked the same way for decades. Will making this change shock or upset NetNewsWire users though?

If this change were made, I believe we will have positive user feedback, not negative when users first encounter it. When users first see that Mark All as Read left something in the Timeline as unread, they will most likely check the Timeline and recognize the article that they had marked as unread. Personally, I would be relieved that Mark All as Read hadn't undone my Mark as Unread command and that the article still appeared in my Timeline.

[brentsimmons]

Over the years I’ve heard from many people that they use mark-unread this way — it’s how they maintain their to-read list.

One of the planned features for NetNewsWire 5.0 that didn’t make it was to have a To Read folder, much like the Starred folder, where you put articles that you want to read. The idea is that it would be short-term storage, not permanent like Starred.

This way you could do triage by going through all your unread articles, maybe reading some of them, sending some to the To Read folder, and otherwise being happy to use Mark All as Read or whatever.

There are some challenges with this feature. The first ones I can think of: What do we do about syncing? Do we save articles in that folder after the originating feed has been deleted?

[vincode-io]

I'm really not trying to build a to-read list. If I did, I would implement some kind of Read Later service integration.

If I mark a Daring Fireball article as unread, it is right there in my Daring Fireball feed next time I feel like catching up on Daring Fireball articles. I don't want to have to check a special folder and the Daring Fireball feed both.

Using a Read Later type of workflow is friction that I feel is unnecessary for what I am trying to do, which is use the unread status for its intended purpose. I simply want to indicate that I haven't read the article. The unread status serves the same purpose as it does in Mail and Messages. It works fine as it is and there isn't any need to build something special.

The point I am trying to make is that if I directly mark an item as unread, why I want to mark it as read through an indirect action on that article using Mark All as Read? It just doesn't seem like that is something that any user would want to do.

To put it another way, what use case are we trying to preserve where a user would mark an article as unread and then want to mark it as read using Mark All as Read?

[brentsimmons]

Gotcha. I have a few questions:

• How would you mark one of these articles as read? Would it still be automatic on selection? What if you did a select-all on the timeline and did Mark as Read? Or would you have to explicitly do a Mark as Read on just that article?
• We have a boolean state for read/unread. This would mean either that becomes read/unread/marked-unread, or we add a second boolean like userDidMarkAsUnread — we need to be able to differentiate between just unread and marked-unread. I imagine we could sync this via iCloud. How would we sync this with other systems?
• Is there any prior art for this? Are there other apps that work this way?
• Is there some way that we might indicate these marked-unread articles in the UI, so that the state is visible? What would that look like?
• Would it be reasonable to expect a new smart feed with just these, so that people can find them easily and handle them (by reading or marking as read)?
• Would this feature need a preference? On by default or off?

[vincode-io]

How would you mark one of these articles as read? Would it still be automatic on selection? What if you did a select-all on the timeline and did Mark as Read? Or would you have to explicitly do a Mark as Read on just that article?

An article that has been marked as unread would work the same as any other article that is unread as far as marking it read except for indirect actions like Mark All as Read. I would consider explicitly doing a multiple select , including select-all, and then a Mark as Read to be a direct action that would mark the article as read.

We have a boolean state for read/unread. This would mean either that becomes read/unread/marked-unread, or we add a second boolean like userDidMarkAsUnread — we need to be able to differentiate between just unread and marked-unread. I imagine we could sync this via iCloud. How would we sync this with other systems?

There would still only be the boolean read/unread.

Being explicitly marked as unread is only relevant until the current timeline gets changed. It isn't a persistent state. If for example I marked a Daring Fireball article as unread while in All Unread and then switched to the Daring Fireball feed and then did a Mark All as Read, the article should be marked as read.

Basically there would be a Set<Article> that an article gets added to in TimelineViewController when a Mark as Unread is done on it. That Set<Article> is used to exclude articles from the bulk Mark functions. The Set<Article> is cleared at the same time that when the feed is switched for the Timeline.

Is there any prior art for this? Are there other apps that work this way?

I can't find any, unless you consider Mark on Scroll to be in the same class as Mark All as Read, Mark Above as Read, Mark Below as Read. All 4 of those are indirect actions on the read state of the article. I am very much extrapolating what I learned while working on Mark on Scroll to the other Mark as Read bulk functions.

Is there some way that we might indicate these marked-unread articles in the UI, so that the state is visible? What would that look like?

I hadn't thought about having some kind of visual distinction for a manually mark as unread article while it is protected from the Mark as Read bulk functions. It makes a lot of sense. I would like to change our current unread indicator on Timeline articles to be a SF Symbol to match other places that we denote read (empty circle) vs. unread (sphere in a circle) anyway. Then this symbol could denote the slightly different from unread, but temporary state.

There also some circles with slashes through them that might work too. If you didn't want to change the article indicator on the Timeline, then circle.slash.fill might work well.

Would it be reasonable to expect a new smart feed with just these, so that people can find them easily and handle them (by reading or marking as read)?

Since the deliberate mark as unread state isn't persistent, a smart feed wouldn't work.

Would this feature need a preference? On by default or off?

I wouldn't add a preference unless someone has case for why they would mark an article as unread and then want to mark it as read in a bulk Mark as Read function immediately after that. Maybe there is a case for that, but I can't imagine it.

I really think that this is just how the bulk Mark as Read functions should work. They shouldn't mark something as read that I had just moments before marked as unread. Why would anyone want that to happen?

[vincode-io]

Here is what I would like to do with the Timeline unread indicator.

[vincode-io]

One thing to keep in mind if we were to change the indicator style, is that users will probably expect the one that looks like the unread/read control to work like it. So that would have to be a button instead of an image. We'd also have to expand the hit target on iOS because the image is too small to be hit accurately using touch.

[stevenlis]

@vincode-io I think it could also be a good idea to add a toggle for automatically mark read. If I click an article to scan it to decide if I need to read it later more carefully, then I wanna manually to check read/unread. Right now, the app mark an article as read the second you click on something.

[vincode-io]

@StevenLi-DS i have seen that as a configuration option in some RSS readers. The ones I saw had a configurable time period. I recommend you open a new issue so that we don't lose track of your request.

[brentsimmons]

Reopening because this needs additional verification.