For v1 of the ReadingList, we want items to be automatically marked as read when they are opened. Note that for v1, we aren't yet surfacing the read/unread state anywhere. Items are either in the ReadingList, or not. So marking an item as "read" here is really deleting it. Potential improvement for this would be to only delete the item after the page has been the current tab for X seconds. ie, we don't automatically mark an item as read if it's opened in a background tab and never looked at.

I guess there's the question of under what conditions this applies: * Only when opening an item using ReadingList UI * Regardless of how that page was added (ie, including via typing in the URL bar) I'm thinking it should always happen, regardless of how the page is opened. Especially given the button we have in the URLbar, and future plans to integrate with urlbar autocomplete. Michael: thoughts?

Marco: FYI. Another for v1.

(In reply to Blair McBride [:Unfocused] (I don't read bugmail - needinfo? me!) from comment #2) > Marco: FYI. Another for v1. Thanks Blair. Added to campaign priority list.

(In reply to Blair McBride [:Unfocused] (I don't read bugmail - needinfo? me!) from comment #1) > I guess there's the question of under what conditions this applies: > * Only when opening an item using ReadingList UI > * Regardless of how that page was added (ie, including via typing in the URL > bar) > > I'm thinking it should always happen, regardless of how the page is opened. > Especially given the button we have in the URLbar, and future plans to > integrate with urlbar autocomplete. • I agree with you Blair, read is read, regardless of how the content was accessed. > > Michael: thoughts?

So - what will actually happen here, from a user's perspective? Anything? Comment 1 implies that an article will be deleted upon being marked "read," and that we're going to so mark it automatically? We shouldn't delete articles automatically.

I interpreted the "delete" not as a removal of an article from the Reading List, but as a Removal of the "Unread" status. We should let users control their Reading List.

*sigh* Think this is the result of mis-communication, and differences between what the ReadingList is eventually wanted to be and what we're actually shipping as v1. (In reply to Michael Maslaney [:mmaslaney] (mmaslaney@mozilla.com) from comment #6) > I interpreted the "delete" not as a removal of an article from the Reading > List, but as a Removal of the "Unread" status. For v1, marking something as read means removing it from the list. We don't have UI that displays "read" items - they just disappear. So what we can do is one of: * Mark items as read automatically, where the item is just deleted. * Mark items as read automatically, not truly delete them, but make them *look* deleted. ie, don't show in any UI until v2. This means we store data that people will believe has been deleted (until they suddenly re-appear in v2). * Mark items as read automatically, but that has no visible change. ie, all UI shows "unread" and "read" items exactly the same, with no way to tell them apart. In v2, the "read" items suddenly appear to all change from "unread" to "read". * Mark items as read automatically, introduce a proper read/unread state in v1, and miss the already tight shipping deadline by a month. * Don't mark items as read automatically until v2. People must manually remove items from their list when they've read them.

Mass change of ReadingList bugs, moving to their own component. Filter bugspam on the following quote: “Reading is to the mind what exercise is to the body.” ― Joseph Addison

Let's move forward with this option: * Don't mark items as read automatically until v2. People must manually remove items from their list when they've read them.

(In reply to Michael Maslaney [:mmaslaney] (mmaslaney@mozilla.com) from comment #9) > Let's move forward with this option: > > * Don't mark items as read automatically until v2. People must manually > remove items from their list when they've read them. Given our time constraints this feels like the best option to me, it will give people 6 weeks to create a large reading list that we can later release fixes to help them auto-manage.

WFM!

Deprioritized during backlog review. Removed from IT 39.2 priority backlog and not part of the initial Q2 campaign release.