Page MenuHomePhabricator

Create Filters for Watchlist on iOS
Closed, ResolvedPublic

Description

Background
Watchlist on Web and Android includes standard filters that users use to customize their Watchlist view. We know this is a functionality important for Watchlist users and should add into the app.

Requirements

  • Filter functionality and state should have continuity with other platforms
  • Any functionality in the designs that is additional and not present on Web should be considered a nice to have in the interest of time
  • Should visually look like the layout of the Filter's screen for Notifications
  • The filter should include:
    • An option to Reset the filters to its original state
    • Which wikis are being shown in the Watchlist with affordances that indicate multiple options are selected. There should also be an affordance for users to update their app languages that takes them to Wikipedia Languages screen that is generally accessed in Settings.
    • Latest Revision with the options of: All, Latest Revision, Not the latest revision. User can only select one of these at a time. The affordance should be a reusable component to indicate this like a radio button
    • Watchlist activity: All, Unseen changes, Seen changes. User can only select one of these at a time. The affordance should be a reusable component to indicate this like a radio button.
    • Automated contributions: All, Bot, Human. User can only select one of these at a time. The affordance should be a reusable component to indicate this like a radio button.
    • Significance: All, Minor edits, Non-minor edits. User can only select one of these at a time. The affordance should be a reusable component to indicate this like a radio button.
    • User registration and experience: All, Unregistered, Registered. User can only select one of these at a time. The affordance should be a reusable component to indicate this like a radio button.
    • Type of change: Page edits, Page creations, Category changes, Wikidata edits, Logged actions. Users can select multiple at a time. Use a reusable affordance that indicates a user can select multiple at a time.
    • If a user filters away all items in their watchlist we should reuse the empty state designs for if someone does not have any items in the watchlist but update the copy to read: No Results, please remove your filters to see more.

Designs (Figma)

iOS Watchlist 01.png (1×786 px, 104 KB)
iOS Watchlist 02.png (1×750 px, 86 KB)
iOS Watchlist 29.png (3×750 px, 171 KB)

Reference
T326648

Event Timeline

JTannerWMF triaged this task as Medium priority.Jul 27 2023, 9:47 PM
JTannerWMF created this task.

@scblr can you update this design based on the new requirements. For example the check marks should probably radio buttons (consult @OTichonova if this is what is standard) the entry point also needs to be reconsidered with the Search being cut from scope. We may want to adopt the entry point behavior from notifications for the sake of consistency. In notifications you have different icons, its placed on the bottom and languages is separated from the other options. That way the engineers can reuse the language screen from notifications.

iOS Watchlist 29.png (3×786 px, 185 KB)

Added the mocks @JTannerWMF. The designs went through several rounds of feedback by @cmadeo and @OTichonova, so we’re good to go. Thanks!

Okay after looking through the feedback from @cmadeo and chatting with @Tsevener , please use toggles for multi select and check boxes for single select. We will keep the filter entry point and full page as you have it designed because it will cut down development time to have it as one page vs. having it separated in a toolbar like notificatons. @Tsevener will also update the notifications Wikipedia Projects screen to use toggles for multi select and maintain checkboxes for single select so we have parity with the iOS system.

cc: @OTichonova

Thanks, @JTannerWMF. I just talked to @OTichonova she’s going to update the Figma screen per your discussion with @Tsevener 👍

Reassigning to Olga, when you make the update please move this to doing

@Dbrant @cooltey Hi y'all, I'm working on watchlist filters for iOS and ran into some uncertainties about approach / how it works. Can y'all answer these questions about the Android implementation? They may help me pick a direction.

  1. Aside from Search (which iOS is not doing at this time), does Android perform any other local filtering on the data, or is the data simply the server response after calling it with the correct params?
  2. If the server response in step 1, does Android persist and display watchlist while offline? If so, how does that work with filters? I'm thinking of a situation where the most recent cached server response was a filtered watchlist, then the user resets filters while offline, the list will still reflect a filtered watchlist.
  3. Do you know how the "seen" and "unseen" filter affects the list? I didn't notice any difference while I played with it, but maybe I'm testing wrong. I just want to make sure I don't need to post some sort of "seen" call when a user views a diff.

Aside from Search (which iOS is not doing at this time), does Android perform any other local filtering on the data, or is the data simply the server response after calling it with the correct params?

We leverage the API to do all of the filtering, with parameters like wlshow=[bot|minor|anon|unread|...], wltype=[edit|new|log|...], and so on.

does Android persist and display watchlist while offline?

Nope, the watchlist is not available offline.

Do you know how the "seen" and "unseen" filter affects the list?

........Good question. The short answer is: I don't think it's working as intended in our implementation. 😬
The way it's supposed to work is: Revisions that are "unread" are pages that you literally haven't visited since the last revision occurred. The moment you visit that article, the watchlist entry for that article becomes "read". The problem is that we load the article using our Rest APIs, which doesn't register as a visit in the logic of the watchlist. So, if you only ever use the app, and never visit articles in a browser, then nothing will get marked as read, and this filter wouldn't have any use.
I'll do some following up on this.

Hi @JTannerWMF @Tsevener !

use toggles for multi select and check boxes for single select. We will keep the filter entry point and full page as you have it designed because it.

Updated in description and added to Figma.

This is also now a design component.

@Dbrant @cooltey Hi y'all, I'm working on watchlist filters for iOS and ran into some uncertainties about approach / how it works. Can y'all answer these questions about the Android implementation? They may help me pick a direction.

  1. Aside from Search (which iOS is not doing at this time), does Android perform any other local filtering on the data, or is the data simply the server response after calling it with the correct params?

Hi @Tsevener, I would like to add some detail about the implementation on Android.

The idea was:

  1. For wlallrev, only send 1 if you want to see all watchlist items, otherwise keep it null.
  2. For wlshow, send multiple values and combine them with |, but please make sure to avoid sending the positive and negative values at the same time. For example: avoiding sending unread|!unread
  3. For wltype, combine values with "|"

Please see GitHub for detail:
https://github.com/wikimedia/apps-android-wikipedia/blob/b928b783dcf9f298b5e5a07f23497d9ac9fad8e9/app/src/main/java/org/wikipedia/watchlist/WatchlistViewModel.kt#L103-L157

You can also visit here to see the findings:
https://phabricator.wikimedia.org/T326648#8542112

@Dbrant @cooltey sounds good, thanks for the details y'all!

@scblr There isn't a data state to look at yet, but the watchlist filters modal can be design reviewed now. It will be in TestFlight Experimental build #34. Thanks!

@scblr There isn't a data state to look at yet, but the watchlist filters modal can be design reviewed now. It will be in TestFlight Experimental build #34. Thanks!

Looks good already, @Tsevener

1) Add Done button here

IMG_9FCCDE5A0BAD-1 copy.jpeg (2×1 px, 222 KB)

2) Question: Is what’s written in this disclaimer the case for the Wikipedia section as well? If yes – we should add it below that section (only once)

IMG_9FCCDE5A0BAD-1 copy.jpeg (2×1 px, 253 KB)

@scblr

Add Done button here

Ah good catch, will do!

Question: Is what’s written in this disclaimer the case for the Wikipedia section as well? If yes – we should add it below that section (only once)

Actually, I think you pulled this footer from our Notifications Center which provides data a little differently. For watchlist we just use their app languages, plus Commons and Wikidata - it doesn't matter whether or not they actually have an "account" on that wiki on the backend. So I would actually recommend removing the footer text in the Wikimedia Projects section. Let me know what you think, thanks!

@Tsevener

Question: Is what’s written in this disclaimer the case for the Wikipedia section as well? If yes – we should add it below that section (only once)

Actually, I think you pulled this footer from our Notifications Center which provides data a little differently. For watchlist we just use their app languages, plus Commons and Wikidata - it doesn't matter whether or not they actually have an "account" on that wiki on the backend. So I would actually recommend removing the footer text in the Wikimedia Projects section. Let me know what you think, thanks!

Sounds good! I updated the designs and task description to match it.

1) Add Done button here

IMG_9FCCDE5A0BAD-1 copy.jpeg (2×1 px, 222 KB)

@scblr Two design Qs here:

  • The "Done" button font in Figma is set in regular weight, but elsewhere in the app (notification filter, user talk page compose view) and iOS system apps (Mail) it's set in a heavier weight. Should we update this to the medium weight?
  • Should we also use the theme's "link" color for the done button text color? Again, see Mail on iOS's inbox filter view.

@cooltey @Dbrant I have a question about the Latest Revisions section. Are these the correct API parameters for this section? This is what I see when inspecting the Android traffic.

All: send wlallrev=1
Latest revision: (empty)
Not the latest revision: send send wlallrev=1

So "All" and "Not the latest revision" are effectively the same thing. Which options count toward the filter count? In my mind "Latest revision" adds 1 to the filter count, otherwise add zero to the filter count. Let me know if this is how the Android app works though. It feels pretty confusing so far on iOS.

Screenshot 2023-09-06 at 2.58.25 PM (344×662 px, 30 KB)

Screenshot 2023-09-06 at 2.58.43 PM (98×124 px, 6 KB)

Hi @Tsevener

So "All" and "Not the latest revision" are effectively the same thing. Which options count toward the filter count? In my mind "Latest revision" adds 1 to the filter count, otherwise add zero to the filter count. Let me know if this is how the Android app works though. It feels pretty confusing so far on iOS.

It should align the count with the filter screen if it has active enabled filters. In this case, the filter count should add 1 if the user selects "Not the latest revision" even if "All" and "Not the latest revision" are the same thing.

cc @scblr: not sure if you have any design thoughts on this.

@cooltey @scblr If "All" and "Not the latest revision" do the same thing (that is, tells the API to return all revisions, and does not count towards filter count), maybe we should remove one of these options? Otherwise it feels confusing with how the rest of the filter sections work (where All does not add to filter count, but one of the other options in the section does).

@cooltey @scblr If "All" and "Not the latest revision" do the same thing (that is, tells the API to return all revisions, and does not count towards filter count), maybe we should remove one of these options? Otherwise it feels confusing with how the rest of the filter sections work (where All does not add to filter count, but one of the other options in the section does).

Yeah, let’s remove one of the two options if they’re the same thing. I’m not sure if keeping All or Not the latest revision makes more sense, though. Maybe a hybrid, like All (Not the latest revision) would be most clear? Any advice on what’s least confusing from an experienced editor’s POV @Dbrant ? Thanks! 🤗

@Dmantena

  • The "Done" button font in Figma is set in regular weight, but elsewhere in the app (notification filter, user talk page compose view) and iOS system apps (Mail) it's set in a heavier weight. Should we update this to the medium weight?

Please reuse the existing style from the notification filter and user talk page compose view. Can you tell me which exact style is used there so I can update the Figma files? Thanks! (I suspect SF Pro Text Semibold 17)

  • Should we also use the theme's "link" color for the done button text color? Again, see Mail on iOS's inbox filter view.

Yes, good idea – I’ll update the designs on Figma.

Per today’s standup → We’re removing the "All" option (since it’s the same as "Not the latest revision") CC @JTannerWMF @cooltey

Created a task for Android as well: T345869

Can you tell me which exact style is used there so I can update the Figma files? Thanks! (I suspect SF Pro Text Semibold 17)

@scblr Yep, we're setting the font weight ourselves to .semibold, and the system is setting the font size to 17.

Screenshot 2023-09-11 at 1.00.17 PM (1×570 px, 257 KB)

Screenshot 2023-09-11 at 1.00.31 PM (1×570 px, 261 KB)

Screenshots of what I have so far. I adjusted the ordering so that the one that is less-filtered (Not the latest revision) appears that the top. Let me know if that's okay.

Dmantena added a subscriber: ABorbaWMF.

@ABorbaWMF Should be testable on TestFlight in main app target: Wikipedia 7.4.2 (Build 2654)

I am going to move this along but some things in the original requirements were left out:

  • An option to Reset the filters to its original state
  • An entry point to update their languages from the filter screen

@scblr if users complain about this it should prioritized in the future