Added some designs and bullet points to the task’s description @JTannerWMF @Dbrant. Disclaimer: this is not a whole design concept, just a concept that might help implement this.

I'm not sure this really needs to be broken into subtasks, but it does need a lot of thinking, especially around switching between different language wikis.

Issue 1:
To begin, here is our current screen that shows the current user's contributions:

• In the above screen we coalesce all the contributions of the user from their selected language wikis, as well as from Wikidata and Commons. This is extremely clunky under the hood, and cannot be done the same way for another user's contributions. Therefore this new screen will need to show contributions to a single wiki at a time, and will need a way to switch languages. (This can probably be similar to how we switch languages in Talk pages.)
• Since we can only show contributions from one wiki at a time, we will need a way to select "Wikidata" and "Commons" as the wiki, since these are not "languages". For that matter, we should do this anyway for Talk pages, since users also have Talk pages on those wikis, but they're currently not accessible in the app.
• Since we can only show contributions from one wiki at a time, the filtering options of "Article descriptions" and "Image captions/tags" no longer make sense, since these occur specifically on Wikidata and Commons respectively. (with the single exception of English, where descriptions are part of the article)
• Are we planning for the new design to replace this current screen? My assumption (and preference) would be Yes, which means all of the above points wound need to be applied to the eigenuser's contributions.

Issue 2:

• The graph: While it's sort-of possible to get a time-series of article edits, the same is not possible for user contributions.
• The filters: It looks like these are intended to be namespaces (Article, Article talk, User, User talk, etc), but then "Article description" and "Image caption" are not namespaces, and would add much more complexity here. Can we stick to namespaces in this list of filters?

The barebones prototype for this feature is roughly as follows:

• Make a copy of our existing Article Edit History activity, and instead of using an API call to get the edits for an article, use an API call to get the edits for a user. The structure should be the same.
• Strip away any logic that doesn't apply, such as "comparing" two revisions, filtering by user/bot edits, graphing edit volume, etc.

apk: https://github.com/wikimedia/apps-android-wikipedia/actions/runs/2692789522

@Dbrant just wanted to take a look at this, but the apk is expired – could you update it again, please? thanks

@scblr Updated apk:
https://github.com/wikimedia/apps-android-wikipedia/actions/runs/2835690142

Great work @Dbrant – I like the decisions you made along the way (T310270#8006664: no graph, replacing the current user contributions screen, etc.).

I might look at the current implementation a bit more – but this is what I’ve seen so far:

1) Add a Contributions link to the main navigation (above Talk).

Reuse the user contributions icon:

2) Can we show multiple wikis (+ commons + wikidata) at once?

I’m asking this again because a) we are already doing this in the production implementation of user contributions:

{F35456219}

and b) this is exactly where the apps shine (make boundaries between projects disappear).

Design would be similar as in the Watchlist:

3) Make the blue profile label clickable:

Ideally, it triggers the menu we use in other places (obviously without user contributions)

4) Move X edits since 2017 closer to the above title

Implementation	vs	Design

5) Add existing icons here

• All edits
• Article
• Talk
• User
• User talk

6) I’m wondering if we should add an App edits filter to this, in case people want to track their edits made with Android? Thoughts?

updated APK: https://github.com/wikimedia/apps-android-wikipedia/actions/runs/2912411093

1) Add a Contributions link to the main navigation (above Talk).
Reuse the user contributions icon

👍

2) Can we show multiple wikis (+ commons + wikidata) at once?

Unfortunately this is no longer possible. When displaying the contributions of the current user of the app, we know which languages they've selected, and that's how we know which wikis to list. But when we generalize to showing any other user's contributions, we have no way of knowing which languages they're contributed to. Therefore we must show contributions from one wiki at a time, and offer a selection to switch wikis.

3) Make the blue profile label clickable:

👍

4) Move X edits since 2017 closer to the above title

👍

5) Add existing icons here

👍

6) I’m wondering if we should add an App edits filter to this, in case people want to track their edits made with Android? Thoughts?

Ideally we should add filtering by tags, where android-app-edit is one of the possible tags. But filtering by tags should probably be a feature for the next version, where it can be built into User Contributions and Article Edit History all at once.

Ok, that sounds mostly good @Dbrant

1) Can we change the type of treatment for these? font_group_3 in italics and color_group_11 feels appropriate

2) Label and text are too close together. Can we apply a spacing in between? I’d say it should be 12-16dp.

3) User and user talk are using the same Label in German (User = Benutzer | User talk = Benutzerdiskussionsseite). Are we using the right translate wiki variable here or is this related to issue #2?

4) String’s not translated yet – will it be/has it been added to translatewiki yet?

https://github.com/wikimedia/apps-android-wikipedia/actions/runs/2951695818

1) Can we change the type of treatment for these? font_group_3 in italics and color_group_11 feels appropriate

👍

2) Label and text are too close together. Can we apply a spacing in between? I’d say it should be 12-16dp.

👍

3) User and user talk are using the same Label in German (User = Benutzer | User talk = Benutzerdiskussionsseite). Are we using the right translate wiki variable here or is this related to issue #2?

👍

4) String’s not translated yet – will it be/has it been added to translatewiki yet?

Yep, this is just because this is still a feature branch, and not yet merged.

Looks good so far @Dbrant, we’ll need to address the following before releasing:

Issue #1

Problem: Suggested editors can’t see their contributions, as Wikidata and Commons edits are not visible in the contribution history.

Solution: Include Commons and Wikidata contributions and use the filter interface from notifications to switch between projects. In contrast to notifications, only 1 project can be selected at a time.

Issue #2

Problem: Suggested edits contribution count is out of sync with the detail view

Solution: Enhance the string with the current project name to this: X edits since 2017 on %currentProjectName, so it e.g. reads: “15 edits since 2017 on German Wikipedia“. If that is hard to translate into more languages, use: X edits since 2017 (%currentProjectName)

https://github.com/wikimedia/apps-android-wikipedia/actions/runs/3007618951

In T310270#8212195, @scblr wrote:

Solution: Include Commons and Wikidata contributions and use the filter interface from notifications to switch between projects. In contrast to notifications, only 1 project can be selected at a time.

👍 Done, but note that this is a huge change that represents a brand new way of selecting a wiki. (There are no other places in the app that have this kind of interaction with Commons or Wikidata, so there may be some unexpected behavior that comes from this.)

Solution: Enhance the string with the current project name to this: X edits since 2017 on %currentProjectName, so it e.g. reads: “15 edits since 2017 on German Wikipedia“. If that is hard to translate into more languages, use: X edits since 2017 (%currentProjectName)

👍

Looks good @Dbrant

1) Can you update the Wikidata/Commons logos at the top right when a project’s been selected?

2) Question: Do we have the possibility to filter by multiple namespaces? (not just one)

I remember we can only show results from one project at a time – but what about more flexible namespace filtering? More flexible filter is e.g. used in notifications:

https://github.com/wikimedia/apps-android-wikipedia/actions/runs/3010416309

In T310270#8217412, @scblr wrote:

1) Can you update the Wikidata/Commons logos at the top right when a project’s been selected?

Done!

2) Question: Do we have the possibility to filter by multiple namespaces? (not just one)

Yes!

In T310270#8217412, @scblr wrote:

1) Can you update the Wikidata/Commons logos at the top right when a project’s been selected?

Done!

Perfect now!

2) Question: Do we have the possibility to filter by multiple namespaces? (not just one)

Yes!

Works well – but with one small tweak, so it works the same as in Notifications (consistency is important). Please apply its filter number indication and check mark logic: 'All edits' should enable/disable all other items in the dropdown.

And this state should basically set a check in front of 'All edits' as well:

Check out the implementation from Notifications for more details – here’s a screen recording:

https://www.dropbox.com/s/uwi4hedd3ebqdkn/screen-20220907-224902.mp4?dl=0

In T310270#8218992, @scblr wrote:

Works well – but with one small tweak, so it works the same as in Notifications (consistency is important). Please apply its filter number indication and check mark logic: 'All edits' should enable/disable all other items in the dropdown.

I'm not clear why this should work the same as in Notifications -- the filtering here is fundamentally different, and for different purposes and use cases. And the filter here is a dropdown menu, whereas in Notifications the filter is a separate screen; it's already not consistent.

The filtering in Notifications is exclusive: you're selecting the wikis to exclude from the list, and the "filter number" is the number of wikis that's excluded. Whereas in User Contributions we want to allow users to inspect edits to specific namespaces by including them in the list. It would be quite confusing to make the "filter number" reflect how many namespaces are excluded.

Another problem with this is if the user unselects "all" namespaces, so that no namespaces are selected -- there's no API that gives us a list of edits from "no" namespaces.

Ok, that is fine @Dbrant re: keep the current filter as opposed to exclusive filtering.

Question: are these two states the same?

State 1)	State 2)

If yes, the interface needs to represent that. Means: these two states need to become one:

If no, I suggest introducing an 'Other' filter item that contains all the other namespaces.

In T310270#8220264, @scblr wrote:

Question: are these two states the same?
If yes, the interface needs to represent that. Means: these two states need to become one:

It's basically yes; but then I have a counter-question:
The default state (showing all edits) would become this:

So then, how does a user select one specific namespace to view, with one tap? (which is what most users will want to do)

@Dbrant

So then, how does a user select one specific namespace to view, with one tap? (which is what most users will want to do)

1. How do you get to this assumption? (which is what most users will want to do)
2. I saw that you updated the previous behavior, as it’s now a radio rather than a checkbox selection (only one thing can be chosen at a time). I think that works better, as it’s no longer a mix between both concepts.

In T310270#8236190, @scblr wrote:

1. How do you get to this assumption? (which is what most users will want to do)

This is rooted in my experience with editing and patrolling Wikipedia, as well as the standard behavior on Desktop and Mobile web.

Sounds good to me, I’ll move it to the next column.

Looking good to me on 2.7.50421-beta-2022-10-03

0448

0448

NGN10,000,000.00

AMULUDUN 89.5 FM DJ &OLA AS ARM PRANG DATING FGN ATM FBN TAKEAWAY AMP EAT SECTION AMBER ODDS ECONOMICS YORUBA