Initial thoughts on the [EARLY 2025 PREP NEEDED?] tags:

Categorizing the user’s reading history categorized by topic, theme, category, or genre.

Yes, we need early tracking. There are server load concerns if we fetch topics upon page view. This is due to a lack of caching in the topics APIs (though there are still discussions to be had there). We may have more luck exploring categories, but we would have trouble determining useful categories to show the user. It would be worth asking Android how they are using categories. If they are able to fetch them upon page view without server load issues, then maybe we can too.

The article in your history that has the lowest pageviews (most niche or rare)

I think we could only fetch this data at the end of the year by looping through their history and fetching final page views per month like this. Likely server load issues here, so this may be a nonstarter.

We should visualize and tell the story of their knowledge journeys:

Need early tracking. If we stick with our tabs infrastructure, we could show them their largest tab with the most articles. I'm not sure if that will equate to a rabbit hole. For example, currently in the prototype, kicking off a new search from an article keeps the user in the same tab.

Alternatively we add local tracking to our WMFData page view database, and add a "source" page view relationship. This connection is then only set when the user visits an article via an article link. At the end of the year we should then be able to aggregate up their longest run of connected page views, and show it in a visual manner. Note, this is different our current source tracking for instrumentation purposes. That tracking is just a general "source" identifier (history, places, etc.). That tracking will not make more specific connections, like Dog led to Cat, etc.

Users get confused when editing stats do not cover the full year (edits viewed) and assume they are incorrect. We should strive to have all stats cover the full year.

Need early tracking, but it would be difficult.

• We could start persisting each edit they make in the app locally. Note that this will only work for that particular app install.
• Alternatively upon launch, we could fetch their user contributions API and persist those edits. I do not think that is a global API though, so we would have to limit it to their primary app language.
• Every launch, we only fetch the first page and persist whatever new edits haven't been persisted since last time.
• Every launch, we go through all of their persisted edits, and fetch daily page views for each page (for days that have not already been persisted) and persist those. Example call that persists "Cat" page views for first 20 days of Jan 2024.
• Risk of server load issues for these, but since it's only for logged-in users, maybe the numbers would be small enough.

Show articles read by geography

You can long-press any article in an app, and if there's an associated geography, it shows "View on map" as an option. So as long as whatever powers that (some persisted coordinates, probably) is persisted all year, we can do this in one go at the end of the year.

Show insights by language for Multilingual readers and editors

We persist the project language in History, so we can do this at the end of the year for pages read.
For editing, needs early tracking, but I don't think it would work very well.

For pages edited, there's a per-wiki edit count we could get, and a global edit count - https://phabricator.wikimedia.org/T376320#10202745. Those aren't limited by the year.
Getting all per-wiki counts via the API means making 300+ calls to get the user's edit count on each wiki, so that also won't work well.

Alternatively, we could start persisting the edit they made locally on that device. It would only be accurate on that particular app install. We are also already 3 months into the year, so it would be inaccurate. It's also easiest here if we can ignore edit reverts.

Here are some notes from my recent investigations:

Reading history by category, or mention a few categories they’ve read articles under

We have category data, but just note that the top categories could be very generic. Here are my top 10 category calculations from my device. I'm able to gather a count of the number of read articles that fall under each category:

"Living_people", count: 66
"American_film_actresses", count: 24
"American_male_film_actors", count: 21
"American_male_television_actors", count: 21
"21st-century_American_male_actors", count: 20
"20th-century_American_actresses", count: 20
"American_people_of_English_descent", count: 18
"21st-century_American_actresses", count: 17
"American_television_actresses", count: 17
"20th-century_American_male_actors", count: 16

(I did not realize I looked up so many actors...)

Anyways, the point is, "Living people" is very generic. Maybe we could provide a list of the top 10 categories to the user in the hopes that it touches on something more specific and interesting.

Show articles read by geography (You read X articles about Canada)

We have a list of read articles with latitude and longitude coordinates. The tricky part here is reverse geocoding into a user-readable region (like country, city, etc.). We can make a reverse geocoding request to Apple, but that will be rate limited and would not be recommended for dozens of requests per user. I recommend we first cluster the articles, pick an average lat/long value for each cluster and make a reverse geocoding request for the cluster with the most articles. Clustering could be tricky. MapKit can automatically cluster annotations, so the easiest lift here might be to actually display a map with all of the annotations, then have it automatically cluster for us (see example). Then hopefully we can look up the annotation cluster with the most annotations, and reverse geocode its coordinates. I'm not sure if the design can fit a map view but it could be the easiest option.

Alternatively, our Places code seems to have some custom clustering algorithm. That may be something we could reference instead if we can't fit a map view onto the slide.

The other requirements look doable without complications.

thanks for your work on this!

notes from my design review (i've split up into three buckets, affecting DYK, BYR, and both)

high level, affecting both DYK and BYR
1— upon opening a new tab, the user should be immediately dropped into the new tab screen in the focus state (i.e. with the keyboard up and the cursor blinking). right now, it seems like they enter a half-focus state where the Cancel button appears next to the search bar, as it does in the focus state, but those two aforementioned elements do not appear until you tap into the searchbar: see video here.
2— we should not be including recommendations for the Main Page. if their only viewed page is Main Page, we should hide recommendations. see above video for reference.
3— when someone opens a new tab, then taps Cancel, that should just close the focus state and they should stay on that new tab, rather than bumping them back to the tabs overview. see video here.
4— the title of the currently labeled “Tabs preferences” screen should read “Tab preferences.”
5— the check mark on the actively selected new tab theme looks to be a fainter weight than what’s in the design — can you ensure it’s styled as semibold 17px?
6— if a user taps on a link in the DYK or BYR and then taps back in the top left, the back button should function like it does elsewhere in the app and take them back to the previous screen, so in this case it should take them back to the new tab screen. right now, it’s taking them back to Search. see video here.
7— just now catching an error in the design, apologies — can you please update the placeholder content in the new tab card in the tabs overview from “any one” to “anyone"?
8— this might be outside the scope of this work, but i'm noticing that the image in the tab cards in the tab overview screen on iPad in portrait mode seems to be incorrect — it's square-ish rather than in a landscape rectangular configuration, as noted in the Tab designs Robin worked on. can we fix this? it's causing the descriptions to be cut off early, including the New tab description:

DYK
9— blue links should not be bolded:

BYR

11— on iPad, for recommendations, I have a search history and have visited one article but the app not recommending me anything:

Moving this back to Design Doing - this got a bit mixed up with Tabs V2.