If users sign up primarily to "Read", what appears as part of this MVP? We may want to plan for a pilot release that doesn't have any reading suggestions, but ideally we also have a plan for a very simple "Reading Suggestions" list that could be based on interests and highlighted mainpage articles.

How do the apps pull in main page content? There might be APIs we can use to build a very simple first-pass 'reader' view that basically just copies some stuff from the main page?

For read use case, we can direct the users to other places such as reading list or back to the article they were reading until we have refined and tested the design for new home page that will support various user types.

If the user selects "a bit of both" that is they are here to both read and edit @AAlhazwani-WMF shared that the current plan is to simply take them to newcomer home page which is fine however I wonder if we are able to add a link out to "saved" feature from there as well for these users? I believe such a link or call out could also be useful for people who say they are here for edit as well.

There might be APIs we can use to build a very simple first-pass 'reader' view that basically just copies some stuff from the main page?

That's what I was envisioning, these APIs exist already and my hope is that we can use a similar layout of "cards" as we use for Review Changes and Suggested Edits.
But also open to what Sneha suggests!

I wonder if we could consider a mini cross-team sprinthackular where a dev from each team + designers spend a week exploring this space? (Later in Q1 or early Q2?) @HFan-WMF

@KStoller-WMF Amin and I have been talking about the home page and the best ways to support various user types. I think for us it's still a bit early to conclude that working on bringing elements from the current Wikipedia home page into the new personalized home page is the right first step for improving reader engagement. Readers interact with Wikipedia through multiple touch points - the article experience, Reading Lists (saved pages), and this potential new personalized home page. We are trying to consider the overall reader journey, test some concepts and then decide which touchpoint is best suited to address the specific reader problems we're trying to solve first. Which is why I suggested directing readers to existing places for now until things are more clear to us. However I shall also continue working with Amin to refine what this home page could look like for readers in the near future.

Thanks, Sneha! That makes sense.

My hope is that we can include one reader focused module on the Home view for the pilot release (~November 2026), even if it evolves significantly over time.

I'm happy to defer to you and the Reader Experience team on what makes the most sense. At the same time, I'd encourage us to consider shipping something lightweight using the APIs that already power the mobile apps, rather than waiting until we've designed the ideal experience. That would let us start learning from real user behavior and engagement data, then iterate based on learnings.

ah makes sense if we want to do this as a learning exercise. We could probably consider this as an experiment for new reader accounts? @HFan-WMF

Hsuanwei and I had a chat about this and we were wondering if you are going to build a granular interest picker as part of the new onboarding we could reuse that and provide reading suggestions (related reads) based on what they picked. That would allow us to test our personalized reading recommendation idea.

@Sneha - Yes, I believe the interest picker we're building for Suggested Edits could be repurposed for reader suggestions. It could be a good fit for new account holders, who haven't yet generated Reader Lists or other data we could otherwise draw on. I think of this as two complementary signal types: the picker gives us declared interests, while over time we can layer in inferred interests from behavioral signals (for example: recent edits informing editing suggestions, Reading Lists informing reading suggestions). Declared interests stay valuable even then, both as a fallback and as something users can see and control. For the initial iteration, though, I'd keep it simple and rely on declared interests alone. That guarantees at least one clear reader-centric feature is available from the Home view on day one.

I know experienced editors have told us their reading and editing interests don't always align, especially for those doing moderation work. But I expect that this is less true for newcomers. One of the most common paths into editing is reading an article and noticing something to improve, so for most new account holders, reading and editing interests start out closely linked. Divergence tends to develop later, as editors take on specialized workflows. Conveniently, that's also when the inferred signals arrive: recent edits and reading lists are activity-specific, so the two suggestion streams can drift apart as a user's interests do, without us needing separate pickers up front. Or at least that's my initial thinking, but very open to ideas from you and Hsuanwei!

Yeah I think we would want to rely on declared interest at first too as using inferred ones would probably require us to get user permission first. Also agree that in the beginning reading and editing interest would be the same. @AAlhazwani-WMF and I were talking about a possibility of eventually having a global set of interest form where you can pull which ones you want to use for what purpose.