Wikimedia Apps/Team/iOS/Watchlist/rsk

Background
As the Wikipedia community continues to grow and evolve, listening and responding to our users' needs and requests is crucial. One such proposal that has resonated with many users is implementing the Watchlist feature within our Wikipedia apps. The Android app added the Watchlist feature in 2021 and improved it in 2022. This year we will bring Watchlist to iOS. This feature enables users to maintain a list of articles they're interested in, making it easy to stay updated on their changes and edits.

Objective
Our primary objective is to enable our users to track changes to articles by saving them to their watchlist. They will also have access to undo, thank, and rollback actions.

Hypothesis
We believe that we will increase the number of edits from experienced app editors from Northern and Western Europe. We also believe we will increase edits from experienced editors that are infrequent app editors in the US and Canada making the share of edits from this region more comparable with pageviews and installs. We believe that users will be able to mitigate vandalism faster on Wikipedia faster by having access to the Watchlist feature on their mobile device.

Testing our hypothesis
We will test our hypothesis by monitoring opt-in data in for the iOS app in the following target growth regions:


 * Northern and western Europe
 * North America

Northern and western Europe was selected due to the proportionate number of edits compared to installs. We believe we can enable editors in this region to edit more by enhancing their watchlist experience and making it easier for them to track and monitor articles of interest. The US & Canada was selected based on data that shows disproportionately low edits compared to high pageviews and active installs. We believe we can increase the number of editors to be more proportionate to the number of active installs.

Key performance indicators

 * Increase in edits from experienced editors in Northern and Western Europe
 * 10% increase in edit activity from US and Canada
 * 10% higher completion rate with undo and revert than web
 * 60% of users that engage with watchlist feature report it helping them mitigate vandalism faster and overall satisfaction with feature

Additionally, when we will conduct usability testing, we will look for a diverse group of users to ensure the functionality is used by people from a wide variety of groups. In addition to primary languages spoken in this region, we will be hoping to include testers that speak Spanish, Chinese & Punjabi.

We are also hoping to diversify the age groups, visual abilities, handedness and genders.

Why native implementation matters
The Watchlist feature being native is important for several reasons:


 * 1) Mobile-first experience - Native integration allows users to remain in the app for contributions and access their watchlist offline, ensuring a seamless experience.
 * 2)  Accessibility - A native implementation ensures that the feature adheres to the user's font/theme settings, supports offline access, and is compatible with screen readers.
 * 3)  Personalization and customization - Users can personalize their watchlist experience through theming and other customization options.
 * 4) Innovation -  A native watchlist feature supports multilingual feeds, allowing users to follow articles in multiple languages.
 * 5)  Safety -  Native implementation helps mitigate vandalism by providing tools to monitor and report suspicious activity.
 * 6) Continuity - Users can benefit from features like filters, watchlist expiry, and a count of articles being watched, ensuring consistency across platforms

We also introduced a new feature flag in the client app for the watchlist feature. This provides a safeguard for rollback without affecting other work. Flag checks are in place at key points including the watchlist, diff view, and article view entries (T336200)

We also designed the watch action flow in article view. The designs are as below:

iOS watchlist page created on MediaWiki.

We are currently iterating on early stage designs. We are discussing and describing tasks.

Early Stage Designs!
We have some early stage designs for the iOS Watchlist feature as well as some interesting updates relating to work around navigation.

Main Page

So how will the main page of watchlist look like? We have two variations.

Design 1: Top Navigation


 * The first variation of the watchlist page has the filter at the top right of the app.
 * This design has pro of being quite similar to the Android version hence a very similar experience for cross platform users on mobile.
 * Please note that in the first iteration of the iOS watchlist we will not have the search and filter functionalities and they are slated for the next version.



Design 2: Bottom navigation
 * The second design of the watchlist page has the filter icon at the bottom of the screen along with an icon to see other Wikipedia projects such as Wikidata.
 * This design also has the pro of bringing the filter icon closer to users.



Empty States

 * An "empty state" is a user interface (UI) design concept that occurs when there is no data or content to display in a particular section or screen of the app. This can happen for several reasons, such as when a user first launches the app, clears all data, or encounters an error that prevents data from loading.
 * We have designed the empty states for the Watchlist. There are two scenarios for the Watchlist. The first entails a scenario where the user has not logged in to the app while the second entails a scenario where users do not already have a Watchlist.

Design 1: User is not logged in


 * When the user is not logged in, they get a call to action button to log in or to sign up.

Design 2: User is logged in but does not have a Watchlist


 * When the user does not have any articles, we provide a call to action to explore articles that they would be interested in watching.



Diff View
A "diff view" in Wikipedia refers to a specific comparison view that shows the differences between two versions of a Wikipedia article. When editors make changes to an article, Wikipedia keeps a record of each version in its edit history. The diff view allows users to see the specific additions, deletions, or modifications made between any two versions.

We have two variants of the diff view with the main difference being how comparison looks like:

Design 1: Side by Side Comparison

Here the comparison is side by side. the pro is that comparison is very easy.

The con is that there is only so much text that you can add before the view gets crowded.

Design 2: Stacked Comparison

Here the comparison is stacked. The major pro is that more text can be added without looking too crowded.

Various Actions within the Watchlist

We have also designed other actions such as sharing, clicking the username on the diff view, what selecting the overflow button does, rolling back edits, undoing edits and sending thanks.