The scope of the work here is for the functionality of coalescing all the lists into a single list - don't worry about matching the designs perfectly (sort functionality can be impacted and that is also okay for now)

Meeting notes: We've decided to keep this in sprint 2 but treat is a more a spike / exploratory work to answer open questions. We had some questions around how to display/sort content from multiple lists in this view, as well as how we'd do pagination, whether these should be items from all languages etc. It looks like we have an API end-point to get all list items from all lists (to be confirmed) but we need some clarity around the design and how we want the list items displayed and we're looking to create an implementation plan for this work this sprint.

No endpoint exists for getting a flat list of all entries across all lists for a single user. We'd have to add that.

We want to have 1 reading list so that casual users don’t have to maintain multiple reading lists.

For app users that have multiple lists, we decided to flatten the contents into a single list. I think we should reconsider this:

1. It could be confusing to users to have their organized lists disappear, they might think it’s a bug
2. This could be expensive for users with many lists/entries

My suggestion: Why not keep the experience as is for users with multiple lists, and for users with just the default list, show them that as flattened. We can check if the result of getList has size of 1 and if the list within it has default=true. In that case, don't show the reading lists, just show all the list items.

Is the reason why we can only show a single list on web because 1) we don't currently save the multiple lists server-side, only device-side? And 2) We don't have finalized designs for the multiple lists on web yet because we're in the exploratory/proving stage, and eventually after the first test, we'll move on to display multiple lists?

If 2 is the case, should we consider excluding users who have multiple lists already on App from the web A/B test? I agree with Loren that being able to see distinct lists on App but one mixed list on web might be confusing (and result in negative sentiment, if they were originally excited to be able to use their lists on both web and app). Could we still get the desired results for seeing retention effects if we only showed it to users who either only have the one default list, or no pre-existing list from App at all?

All the lists are stored on server-side, though the mobile apps also utilize device storage so that non-authenticated users can have reading lists. Then they synchronized the lists with the backend when a user is logged in.

That's an interesting point @HFan-WMF, of excluding users with multiple lists from the experiment. I'm curious what others think.

@LMora-WMF and I synced on this ticket today and based on our conversation and the comments above, I have summarized my thoughts below:

Option 1:
Continue with a single list for all users as planned, even for those who previously have reading lists. I don't think it is a big departure for app users because both iOS and Android have a view for "All ariticles" and default list where everything is saved. Its just that custom lists wont be visible at first. Also
we discussed adding some indication on the list page (especially for app users) to clarify that this is a temporary/beta feature and that functionality is currently limited - this bit can be covered in the ticket about layout/look and feel for this page.

Option 2:
Same as Option 1, but exclude users who have multiple reading lists for now (as @HFan-WMF suggested).
I am not sure about the feasibility of this. However even if it was feasible I think it could be good to have app users try this on Desktop as it would be nice to gather feedback or see desktop engagement from already engaged readers.

Option 3:
Offer different experiences for users with existing reading lists - showing folders if the users have custom lists vs. flat list for users without any saved content.
While this initially seems like a good way to reduce engineering effort and preserve the experience for app user it introduces several concerns:

• Mixed experiences (some accessing saved content from a flat list while others accessing via folders) may muddy usage signals.
• Would need some time to design the best way of showing custom lists on desktop.
• App users would see their lists but not be able to add to them via web. That could potentially add some confusion even if we try to explain - “you can see the lists but can’t add to them” or “that everything goes to default list on web, if you want to add to specific list go to apps"
• We would likely still need an "All" view as many users rely on quick access to their most recent saves. Having folders would add an extra click to access your recent saves.

Conclusion:


• Option 1 feels like the most straightforward and scalable path. If we continue to do further development on this feature (as we expect), then the extra effort won’t be wasted as will need an “All” view anyway.
• We can also try Option 2 if its feasible and does not add more effort than adding a flat list for app users. The only caveate is that we might be excluding some engaged users who have previously asked to use reading list on Desktop.

Thanks for summarizing all this @Sneha! I will move forward working on a POC for option 1.

afaik, I don't think we can divide the experiment based on if a user has multiple reading lists (or any)

I think Option1 is okay and show the default list. With option 1:

a) Show just the default list and not flatten multiple lists? with the note saying the feature is limited
b) Show all lists, flattened (requires backend API work or 2 api calls). Would need to deal with things like pagination.
c) Show all lists as different sections on the page with first X number of pages per list, then they can click into the list to view the complete list.

Think Option A would feasible and Option C can be possible, though adds more complexity

After reading through and thinking about this, I totally agree with Option 1. I think App users who already built multiple lists will be excited to get access to their saved articles on web, even if it initially shows up in one big list. If we're thoughtful in the copy to let them know that this is WIP that will evolve, I think it's much better to go with the straightforward approach to prove the usefulness of having this on web. Thanks for the great summary, Sneha, and the great discussions here, team!!

@aude is the "default list" and "all list" different? I would assume both would have everything the user saved so far.

I know the Android app and iOS app behaves a bit differently on the front end but I would think in the backend we would have an "all list" = everything saved so far.

@Sneha there is a default reading list. On the mobile apps, users can create additional lists but they always start out with one (default) reading list.

We can get "all lists" for a user (including contents) from the API in a 2 step process. Potentially we could add capability to the API to make this one API call instead of 2.

Regarding the performance implications of the two step process, 1). get all lists. 2.) get all items for each list, I agree that this should be addressed long-term because it will have performance implications, but for the initial launch, I think that's an acceptable approach.

Change #1178020 had a related patch set uploaded (by LorenMora; author: LorenMora):

[mediawiki/extensions/ReadingLists@master] [WIP] Add API and UI for querying all reading list entries

https://gerrit.wikimedia.org/r/1178020

Chunking this ticket into two. The first 2 requirements are now captured in: https://phabricator.wikimedia.org/T402244

Change #1178020 abandoned by LorenMora:

[mediawiki/extensions/ReadingLists@master] [WIP] Add API and UI for querying all reading list entries

Reason:

descoped

https://gerrit.wikimedia.org/r/1178020