@JTannerWMF and @schoenbaechler
Just wanted to add a quick note here to say that search and sort features might not be possible here because there is no api which can serve-up that information. to do it within the app, we would have to make multiple api calls and store huge amounts of data at runtime, which is not advisable. Wanted to get this in before you made any design efforts on this 😅

Cc @MattCleinman

@Sharvaniharan Which API are we currently using for this? If you can let me know that API, I'll see how possible it might be for server teams to allow for filtering. Thanks!

Thanks for the infos @Sharvaniharan! Just FYI → designs for search/filtering have been done already a week ago, see T299234 or Figma👇

Seemingly feasible

1. Endpoint for counts for all types (capped at some large number)

Needs investigation for feasibility (is it performant enough?)

2. Revisions from multiple sources
3. Searching by comments text

Next steps: Luke working w/ Desiree on prioritizing this.

Hi @scblr and cc @JTannerWMF

By reading the ticket description, looks like the mock design does not align with the task user story.

In the mock design, the overflow menu ("Filter by") only has the filter function, and I don't see a way of changing the order of the list.

Do we need to add the function of changing the order of the list? Thanks!

@cooltey thanks for spotting this. I don’t think we need sort options for the revision history that’s why we are using the existing pattern (sort/filter icon) to provide filter functionality: please check Figma for the latest designs.

Hi @scblr
The APK is ready for review, but there's something that will need to be optimized a bit and I think we can do the design review synchronously.

@cooltey filtering works great so far!

01) The search bar / searching does not work in the latest APK though — I’m not sure if it should work at all though (per Sharvani’s comment in T299233#7658437)?! See video below for reference:

https://www.dropbox.com/s/ahooyr8xw1xgpfa/screen-20220316-175640.mp4?dl=0

02) The other thing I noticed is that the illustration for the empty state should also be used when applying filters directly 👇

Hi @scblr

02) The other thing I noticed is that the illustration for the empty state should also be used when applying filters directly 👇

This part is done. Please check the latest APK.

01) The search bar / searching does not work in the latest APK though — I’m not sure if it should work at all though (per Sharvani’s comment in T299233#7658437)?! See video below for reference:

This will be handled in a separate ticket (but it is working in progress now). I'll let you know when it is finished.

Thanks @cooltey

02) The other thing I noticed is that the illustration for the empty state should also be used when applying filters directly 👇

This part is done. Please check the latest APK.

It does not work reliably on my device yet, see this video:

https://www.dropbox.com/s/8o9324xucufxkph/screen-20220322-091842.mp4?dl=0

01) The search bar / searching does not work in the latest APK though — I’m not sure if it should work at all though (per Sharvani’s comment in T299233#7658437)?! See video below for reference:

This will be handled in a separate ticket (but it is working in progress now). I'll let you know when it is finished.

Okay!

Hi @scblr
After a discussion with engineers, the bots filter will not be able to be implemented due to the API restriction and also the server-side load balance consideration.
Please see the comment here: https://github.com/wikimedia/apps-android-wikipedia/pull/3181#pullrequestreview-917858713

In order to update that, I've updated the overflow to this: (and you can check the latest APK)

Please let me know if need to change the design, thanks!

It does not work reliably on my device yet, see this video:

Looks like this is an issue from the Paging library, I'll keep looking for solutions Now it is fixed.

@Johan re: displaying bots edits in revision history 👇

@Dbrant
This is a very costly and unnecessary API call. I believe we discussed that we will not be supporting filtering by Bot edits? This is not only because the API does not support it, but also because no one actually needs it.

I remember you mentioning that it’d be helpful to see and filter bot edits. Any comments from your end on it? Thanks!

I think my point – sorry if I wasn't clear enough – would be useful to filter out bot edits. I agree with @Dbrant that there are few situations where you need to focus on them specifically, but it would help to be able to hide them in order to focus on the human edits, as some less edited articles might have as many bot edits as human edits.

But it'd merely be helpful, not crucial.

Thanks @Johan 👍

In order to update that, I've updated the overflow to this: (and you can check the latest APK)

Please let me know if need to change the design, thanks!

Looks good to me, per our conversation on Slack, please use the following type definitions for the dropdown:

enabled state
label: primary_text_color
icon: textColorTertiary

disabled state
label: textColorTertiary
icon: textColorHint

And make the following updates re: checkmark

• Currently the interface does not indicate that 'Bot edits' are shown, since the checkmark is missing from it
• We need to add a checkmark in textColorHint (disabled icon state) to indicate that bot edits are shown in the list
• Behavior:
  • If ‘All edits’ is active, ‘Bot edits’ should have a checkmark in textColorHint
  • As soon as users start to interact with the dropdown, namely disabling ‘All edits’, or tap on ‘User/Anon edits’ → the checkmark from ‘Bot edits’ disappears. It reappears again, once the other 3 options are active too. (edited)

In T299233#7799658, @Johan wrote:

I think my point – sorry if I wasn't clear enough – would be useful to filter out bot edits. I agree with @Dbrant that there are few situations where you need to focus on them specifically, but it would help to be able to hide them in order to focus on the human edits, as some less edited articles might have as many bot edits as human edits.

But it'd merely be helpful, not crucial.

Unfortunately it doesn't look like we have an API that lets us filter out Bot edits.

I'll note that the root ticket connected to this one (https://phabricator.wikimedia.org/T302436) is a Foundational Technology Request to get an API that allows only one type of edits (bot, non-bot, etc.). It's unlikely that process will finish anytime soon, but we've gone through the proper channels to reqeust an API enhancement for this.

Hi @scblr,

Looks good to me, per our conversation on Slack, please use the following type definitions for the dropdown:

enabled state
label: primary_text_color
icon: textColorTertiary

disabled state
label: textColorTertiary
icon: textColorHint

And make the following updates re: checkmark

• Currently the interface does not indicate that 'Bot edits' are shown, since the checkmark is missing from it
• We need to add a checkmark in textColorHint (disabled icon state) to indicate that bot edits are shown in the list
• Behavior:
  • If ‘All edits’ is active, ‘Bot edits’ should have a checkmark in textColorHint
  • As soon as users start to interact with the dropdown, namely disabling ‘All edits’, or tap on ‘User/Anon edits’ → the checkmark from ‘Bot edits’ disappears. It reappears again, once the other 3 options are active too. (edited)

All done.

This is great @cooltey – a question re: loading behavior. When accessing 'Edit history' from the article, the behavior is currently as follows:

1. Search bar
2. Header
3. Contents

See this video:

https://www.dropbox.com/s/ggndgjtis4z3hli/screen-20220325-190950_.mp4?dl=0

Can we change it to:

1. Header
2. Search bar
3. Contents

It feels a bit strange, when the search bar is the first thing users see (on lower bandwidths for multiple seconds) without any of the “real” content of the page loaded yet.

Thanks!

Hi @scblr

This is great @cooltey – a question re: loading behavior. When accessing 'Edit history' from the article, the behavior is currently as follows:

Done!

The loading behavior feels great now @cooltey 👏

01) I noticed that the empty state uses the wrong copy & illustration. Sorry for not spotting it earlier. It should use this:

Illustration:

Figma

Copy: Try removing X filters to see more edits

02) I noticed a change when tapping the link in the empty state when filtering. The link used to trigger the menu next to the filter icon (in the search bar), now it triggers one next to the link. I see where you coming from for it, but I think triggering it at its usual position (in the search bar) educates users on where to trigger it (which is good). Can you change it back to triggering the menu next to the filter icon?

The empty state

In T299233#7802100, @MattCleinman wrote:

I'll note that the root ticket connected to this one (https://phabricator.wikimedia.org/T302436) is a Foundational Technology Request to get an API that allows only one type of edits (bot, non-bot, etc.). It's unlikely that process will finish anytime soon, but we've gone through the proper channels to reqeust an API enhancement for this.

Thanks for that info, Matt! 👍

In T299233#7810203, @scblr wrote:

The loading behavior feels great now @cooltey 👏

---

01) I noticed that the empty state uses the wrong copy & illustration. Sorry for not spotting it earlier. It should use this:

Done!

02) I noticed a change when tapping the link in the empty state when filtering. The link used to trigger the menu next to the filter icon (in the search bar), now it triggers one next to the link. I see where you coming from for it, but I think triggering it at its usual position (in the search bar) educates users on where to trigger it (which is good). Can you change it back to triggering the menu next to the filter icon?

Yes, updated.

Thanks @cooltey – this all looks good to me now!

One more ask: could you talk to @Dbrant about the logic of the 'Filter by' dropdown? Dmitry and I were discussing yesterday if it might be more intuitive to use radio button (exclusive filtering) instead of checkbox logic. Dmitry’s able to explain it better.

Hi @scblr

Done. Not sure if you want to change the icon to radio-style or just want to keep the current style.

I like how you improved the smoothness 😎 👊

Styling with the checkmark can stay as is 👍

One last thing – I’ll attend UX writing office hours today and will ask about copy for a system tooltip that informs users that filtering by Bot edits is not possible, e.g. `Filter by Bot edits is not possible due to technical restrictions'.

Testing on 2.7.50400-alpha-2022-05-05

I moved this ticket to did not pass QA because of the following:

• I was unable to tap on "Bot edits" as a filter, even on articles that contained bot edits
• If the user selects a filter in revisions for an article and then navigates to another article's revision history, the selected filter is still active.
• I could not figure out how to sort by date or tag as listed in the ticket description

Hi @ABorbaWMF

I was unable to tap on "Bot edits" as a filter, even on articles that contained bot edits

This is expected. The intention is only to show how many bots edit in the overflow menu.

If the user selects a filter in revisions for an article and then navigates to another article's revision history, the selected filter is still active.

This is expected and the filter preference is shared. @scblr Please let me know if you need to remove the filter preference.

I could not figure out how to sort by date or tag as listed in the ticket description

I removed the misleading description in the ticket. We are not going to offer the sort function in the revision history list.

Agree with what @cooltey is saying in T299233#7915225.

And yeah, unfortunately, filtering by bot edits is not possible (per @Dbrant’s comment in T299233#7800916).

Thanks @ABorbaWMF for identifying it! 🧐

Looks good on 2.7.50401-r-2022-05-09