This task depends on T268709 which is listed as "nice-to-have" so I'm removing this from the current sprint.

@mewoph -- this is a user interface improvement that is Ready for Development, and is a good candidate for our interlude period right now.

Hi @MMiller_WMF @RHo, a few clarifications:

• What should happen to the navigation when the "No more suggestions" card is shown? Should the edit button be disabled since "Edit" doesn't apply here?

• [Perhaps this is for @nettrom_WMF] Instrumentation questions:
  • Should the edit button use the same se-task-click event (same as when the use clicks on the task card)?
  • Do we need an explicit event for when the user navigates through the feed via swiping? Perhaps this could also be deduced by the fact that a task card impression is recorded without a click prior to it.

In T268708#7215852, @mewoph wrote:

Hi @MMiller_WMF @RHo, a few clarifications:

• What should happen to the navigation when the "No more suggestions" card is shown? Should the edit button be disabled since "Edit" doesn't apply here?

Hi @mewoph - yes, the edit button should be disabled like so:

• [Perhaps this is for @nettrom_WMF] Instrumentation questions:
  • Should the edit button use the same se-task-click event (same as when the use clicks on the task card)?
  • Do we need an explicit event for when the user navigates through the feed via swiping? Perhaps this could also be deduced by the fact that a task card impression is recorded without a click prior to it.

Change 704634 had a related patch set uploaded (by MewOphaswongse; author: MewOphaswongse):

[mediawiki/extensions/GrowthExperiments@master] [WIP] Suggested Edits: Add mobile swiping gesture for task feed

https://gerrit.wikimedia.org/r/704634

@mewoph -- I think I can answer your instrumentation questions, but @nettrom_WMF and @RHo please correct me if you think differently.

• The edit button should use the same se-task-click event. I do not think we're going to be interested in reporting on which way the user entered the task.
• I do think we should have an explicit event for swiping. That's because this will be the first time a feature has a swipe interaction in the mobile web browser, and it will be valuable to multiple teams to know whether it is popular. If we add a new event, @nettrom_WMF will likely need to update reporting code.

@nettrom_WMF @RHo what do you think?

In T268708#7218618, @MMiller_WMF wrote:

@mewoph -- I think I can answer your instrumentation questions, but @nettrom_WMF and @RHo please correct me if you think differently.

• The edit button should use the same se-task-click event. I do not think we're going to be interested in reporting on which way the user entered the task.
• I do think we should have an explicit event for swiping. That's because this will be the first time a feature has a swipe interaction in the mobile web browser, and it will be valuable to multiple teams to know whether it is popular. If we add a new event, @nettrom_WMF will likely need to update reporting code.

@nettrom_WMF @RHo what do you think?

To the first point, I prefer we use a different se-task-event because it will be useful if we are able to glean user-behaviour information from this – i.e., are people are more likely to click edit when they see the explicit CTA or will they still go to the larger tap area directly on the article card?
And +1 to adding a new event for swiping.

@mewoph -- okay, hearing that @RHo wants to be able to distinguish those two actions, let's add a new event for the new button.

@MMiller_WMF @nettrom_WMF @RHo — to summarize the instrumentation changes for this task, these events will be added:

• se-task-navigation-swipe with action_data dir with "prev" or "next" values (same as se-task-navigation)

• se-edit-button-click with action_data newcomerTaskToken (same as se-task-click)

Change 705493 had a related patch set uploaded (by MewOphaswongse; author: MewOphaswongse):

[schemas/event/secondary@master] Suggested Edits: Update homepagemodule schema to support new mobile navigation

https://gerrit.wikimedia.org/r/705493

This looks good to me! Having it as a separate event should work great (the other option I'd suggest would be to use action_data to make it possible to distinguish them, but I don't think that's necessary, let's go with the current plan!)

Change 705493 merged by jenkins-bot:

[schemas/event/secondary@master] Suggested Edits: Update homepagemodule schema to support new mobile navigation

https://gerrit.wikimedia.org/r/705493

Change 704634 merged by jenkins-bot:

[mediawiki/extensions/GrowthExperiments@master] Suggested Edits: Add mobile swiping gesture for task feed

https://gerrit.wikimedia.org/r/704634

For @RHo review
(1)

* Remove the current footer that begins, "Other users have noted these articles need work..."

The Figma mockup for Desktop has the footer removed. The footer is present in current production (wmf.19 and wmf.18).

The screenshot below is for mobile - the footer is removed.

(2)

* Add a footer that contains a blue edit button in the middle with a white pencil icon. This button opens the article, just as tapping on its suggestion card will open it, too.

(3)

• The footer should be sticky, so that it's always at the bottom of the screen. Note for QA: let's make sure that these buttons are not so low on the screen that they trigger the Safari navigation bar to open on iOS.

The Safari navigation bar appears - the issue is reported as #2 in T289088.