Page MenuHomePhabricator

Variant C/D: mobile preview for suggested edits module with first suggested edit
Open, Needs TriagePublic

Description

T250440: Variant tests: C-mobile calls for the mobile preview of the suggested edits module to display the first suggested edit:

  • On the homepage, this variant employs an entirely new suggested edits preview, which shows an actual suggestion in miniature.
  • This is present even when the newcomer arrives for the first time, when the welcome drawer is open.
  • Header: "Suggested edits"
  • Miniature suggestion:
    • This is a mini-version of a suggested edit card from the actual module.
      • It should contains: the article title, title description, image, and task type.
      • It should not contain: a preview of the article content or a pageview count.
    • This should be the actual first suggestion that the user would be seeing in the suggested edits module if they were to navigate there at the time. That means...
      • ...any of the user's existing topic or difficulty filter settings should be applied in choosing the article shown.
      • ...when the user does navigate to the full module, they should see that same article as the first option.
  • Above the miniature suggestion should show the task counter and position in the queue, just as it would in the full suggested edits module, e.g. "1 of 135".
  • Button: "See all suggestions"
  • When the user taps anywhere on the module preview, whether the header, the miniature suggestion, or the call to action button, they should go to the full suggested edits module.

This also applies in variant D, once the suggested edits module has been initiated (pre-initiation it looks different, see T258022: Variant D: mobile preview for suggested edits module with call to action)

Mockup

Event Timeline

Catrope created this task.Wed, Jul 15, 6:51 AM
Restricted Application added a subscriber: Aklapper. · View Herald TranscriptWed, Jul 15, 6:51 AM
Catrope renamed this task from Variant C: mobile preview for suggested edits module with first suggested edit to Variant C/D: mobile preview for suggested edits module with first suggested edit.Wed, Jul 15, 6:54 AM
Catrope updated the task description. (Show Details)
Tgr added a comment.Fri, Jul 31, 2:59 PM

@RHo the task card version shown on the post-edit panel (which is what should be replicated here, design-wise) has no design for an error or zero results; it is simply not shown in those cases. Should we do the same here?

RHo added a comment.Fri, Jul 31, 3:30 PM

@RHo the task card version shown on the post-edit panel (which is what should be replicated here, design-wise) has no design for an error or zero results; it is simply not shown in those cases. Should we do the same here?

It's pretty important to show the suggested edits preview card with a suggested edit. In the case that there is an error or zero results, can we revert to showing what is currently in the variant A mobile SE preview?

Change 617834 had a related patch set uploaded (by Gergő Tisza; owner: Gergő Tisza):
[mediawiki/extensions/GrowthExperiments@master] [WIP] Add data for the top suggested edit card to the homepage

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

Tgr claimed this task.Mon, Aug 3, 5:04 PM

Change 617834 merged by jenkins-bot:
[mediawiki/extensions/GrowthExperiments@master] Add data for the top suggested edit card to the homepage

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

Tgr added a comment.Wed, Aug 5, 11:58 PM

I've played around with two approaches and I'm on the fence about which one to use. The context is that the server will insert task data for a single task into the homepage HTML. On the mobile homepage that will be used as the task preview, and then the full task list on the module view will be manipulated to start with that task, for consistency. (If someone uses the non-JS detail view, that will be inconsistent, but that's a fringe case.) On the desktop, the full task list will also be manipulated to start with the preloaded task - there is nothing to be consistent with in that case, but it should improve the performance significantly.

The question is, how to get the extra data? On the server, we only load the page title for the task, plus task-specific data like difficulty. The description (which comes from a different source on mobile and desktop), image and pageviews are all loaded on the client side as separate API requests. One option is to keep doing that - that will mean adding a skeleton phase to the task preview, much like the one we already have for the desktop card. It also means more promise juggling (the data for the preview card might be loading in parallel with the data for the other 199 cards).

The other option is to do all the lookups on the server side. That's a fair amount of code duplication (for the other 199 tasks the data is loaded just in time so it would still have to happen on the client, unless we create a new API), and unclear performance impact - it would replace some client requests with intra-datacenter requests, OTOH PHP is not good at parallelizing things. UX-wise, it would mean there is no loading / skeleton animation and the task is visible immediately when the rest of the homepage is, but the homepage takes a bit longer to appear.

I'm leaning towards the client-side approach; @RHo @Catrope if you have a preference otherwise, I'd like to hear about it.

RHo added a comment.Thu, Aug 6, 11:03 AM

I've played around with two approaches and I'm on the fence about which one to use. The context is that the server will insert task data for a single task into the homepage HTML. On the mobile homepage that will be used as the task preview, and then the full task list on the module view will be manipulated to start with that task, for consistency. (If someone uses the non-JS detail view, that will be inconsistent, but that's a fringe case.) On the desktop, the full task list will also be manipulated to start with the preloaded task - there is nothing to be consistent with in that case, but it should improve the performance significantly.

The question is, how to get the extra data? On the server, we only load the page title for the task, plus task-specific data like difficulty. The description (which comes from a different source on mobile and desktop), image and pageviews are all loaded on the client side as separate API requests. One option is to keep doing that - that will mean adding a skeleton phase to the task preview, much like the one we already have for the desktop card. It also means more promise juggling (the data for the preview card might be loading in parallel with the data for the other 199 cards).

The other option is to do all the lookups on the server side. That's a fair amount of code duplication (for the other 199 tasks the data is loaded just in time so it would still have to happen on the client, unless we create a new API), and unclear performance impact - it would replace some client requests with intra-datacenter requests, OTOH PHP is not good at parallelizing things. UX-wise, it would mean there is no loading / skeleton animation and the task is visible immediately when the rest of the homepage is, but the homepage takes a bit longer to appear.

I'm leaning towards the client-side approach; @RHo @Catrope if you have a preference otherwise, I'd like to hear about it.

Client-side sounds preferable to me as well. If I understand you correctly, does that mean the mobile preview card will require a loading state for the image thumbnail and description only? I think we can use the same loading animation (pulsing grey boxes) as the desktop card skeleton for those elements, as per T238231.

Tgr added a comment.Thu, Aug 6, 8:25 PM

If I understand you correctly, does that mean the mobile preview card will require a loading state for the image thumbnail and description only?

Those and the pageview count.