Background
The Article Recommendations based on interest module is the first module users encounter in the For You feed. It surfaces articles personalized to the user's configured interests from onboarding. Each interest topic generates a batch of 4 article cards, presented as a horizontal stack.
Each card in the batch uses the article's top image as a full-bleed background. If no image is available, a gradient background fills the card. The reason label reads "Because you follow [Interest Topic]."
Every For You card shares the same persistent chrome: Wikipedia logo (top left), Community tab access, language switcher dropdown (showing user-configured languages + link to language settings; changing language refreshes the module content in the selected language without leaving the module), and notification bell. The bottom navigation bar is always visible.
The three-dot more menu on each card surfaces four options: Save, Share, Hide module, and Customize interests.
User Story
As a Wikipedia reader with configured interests, I want to see a set of article recommendations tailored to each of my interests, so that I can quickly discover articles relevant to topics I care about and swipe through multiple interests in one continuous flow.
Requirements
- For each of the user's configured interest topics, the module generates a horizontal stack of 4 article recommendation cards
- If the user has N interests, they have N versions of this module to swipe through everyday
- Cards within one interest batch are swiped through horizontally
- This module forms the first & last content modules within the feed
- Randomly select 3 of their interests to display first in the feed.
- The rest of their interests should come at the end of the feed. after "Continue reading"
- Rotate/randomize the order of interests to keep it fresh
- If the user has no interests configured, this module should not appear
- Once a user has been shown an article, it should not reappear in their feed for a meaningful period of time, even if it's highly ranked
- Suppression should only trigger when a card is actually swiped to / displayed on their screen not just loaded into the feed
- Articles should rotate daily to keep content fresh over the longterm
- Only suggest articles in the main namespace, and do not suggest disambiguation articles
Suggestions based on topics
- If a user followed a topic, show recommendations based on the Topic in general
- Match Android implementation for Search parameters within Topics
Suggestions based on articles
- Articles that the user themselves selected during onboarding should never appear in their feed
- Match Android implementation using MoreLike API
Design
Variant 1: balanced →
Variant 2: Image-focused →
Variant 3: Text-focused AND when no image is available →
Android tasks for reference: https://phabricator.wikimedia.org/T419630
Eng Notes
Once a user has been shown an article, it should not reappear in their feed for a meaningful period of time, even if it's highly ranked
Per Android, they are not doing anything fancy for this. "The query that fetches articles based on topics of interest orders the results randomly. The actual api query lets us specify gsrsort=random, which produces "random" results within a topic, and simultaneously reduces the risk or NSFW articles."
Toni Handoff Notes
Based on progress at PR https://github.com/wikimedia/wikipedia-ios/pull/5995
Noting things remaining todo:
Each card in the batch uses the article's top image as a full-bleed background. If no image is available, a gradient background fills the card. The reason label reads "Because you follow [Interest Topic]."
UI still needs to be fine-tuned, current UI is stub / generated. Double-check patterns (WMFFont, etc), layout, rotation, iPad, themes, etc. Optimize for Voice Over if needed.
Once a user has been shown an article, it should not reappear in their feed for a meaningful period of time, even if it's highly ranked
Suppression should only trigger when a card is actually swiped to / displayed on their screen not just loaded into the feed
Articles should rotate daily to keep content fresh over the longterm
We could improve on this, I don't think it currently fits these requirements at the moment. For now I am matching Android. See https://wikimedia.slack.com/archives/C0479L1QDND/p1782226208266929 for more details.