Page MenuHomePhabricator

Newcomer tasks: suggested edits module
Closed, ResolvedPublic

Assigned To
Authored By
MMiller_WMF
Sep 10 2019, 1:04 AM
Referenced Files
F30407463: Icon-levels.svg
Sep 20 2019, 4:35 PM
F30407416: image.png
Sep 20 2019, 4:35 PM
F30407462: Icon-hard.svg
Sep 20 2019, 4:35 PM
F30407464: Icon-easy.svg
Sep 20 2019, 4:35 PM
F30407461: Icon-medium.svg
Sep 20 2019, 4:35 PM
F30408366: image.png
Sep 20 2019, 4:23 PM
F30407015: image.png
Sep 20 2019, 9:29 AM

Description

This task is about adding the user's experience of the suggested edits module itself. This task may be too large, and we should make sub-tasks if necessary.

Note on platforms: all these specifications will need to apply to both desktop and mobile. During the time that explicit mockups for mobile are not available, engineers should use their judgment to build mobile versions. Those initial builds can be modified later as the mobile designs are finalized.

  • The module consists of these elements:
    • Difficulty filter
    • Topic filter (ticketed separately)
    • List of tasks
    • Task feed interface
    • Task explanation
    • Footer
  • Difficulty filter (T235042)
  • Topic filter
    • This module will also contain a topic filter, ticketed separately.
  • Other filters
    • No protected articles should be shown, at any level of protection.
    • No articles should be shown that are nominated for deletion. Specific templates for our target wikis are listed in this spreadsheet.
  • List of tasks
    • Recommendations are drawn from articles that are tagged with a maintenance template/category. This worksheet contains the listing. Here are some notes:
      • For each wiki, a certain set of specific templates/categories are specified, and they are assigned to a higher level task type, such as “Copy editing” or “Adding links”.
      • Some rows have a maintenance template and category, and some have just a template or just a category.
      • The list also contains an approximate count of how many articles should fall into each maintenance/category, which will hopefully be useful for checking to make sure the right maintenance/category is actually being used.
      • The following list is the mapping of task types to difficulty levels.
        • Links = Easy
        • Copy edit = Easy
        • Update = Medium
        • References = Medium
        • Expand = Hard
      • If an article has multiple maintenance categories/templates, it should only be counted once in the list showed to the user. The list from the bullet above should also be used to show the order of preference of how the article is counted. For instance:
        • If an article has both the "Links" and "Copy edit" templates, and the user has selected the "Links" and "Copy edit" checkboxes, the user should see the article in the list once, as a "Links" article. But if they have only selected the "Copy edit" checkboxes, the user should see the article in the list once, as a "Copy edit" article.
        • If an article has both the "Copy edit" and "Update" templates, and the user has selected the "Copy edit" and "Update" checkboxes, the user should see the article in the list once, as a "Copy edit" article. But if they have only selected the "Links" and "Update" checkboxes, the user should see the article in the list once, as an "Update" article.
    • Filtering by difficulty
      • The recommendations should be filtered to articles that have any of the maintenance templates/categories that correspond to the task types specified in the difficulty filter.
      • When presented to the user, the articles should be sorted randomly, to decrease how often different users sees the same articles.
  • Task feed interface (desktop mockup and mobile mockup)
    • The tasks are shown to the user one at a time as a card that includes:
      • Image from the article (or placeholder image)
      • Article title
      • Beginning of the text
      • Number of pageviews in past 60 days
    • Above the card is shown how many tasks there are with the current filter settings and which number task the user is looking at, e.g. "1 of 194 matching suggestions". We should cap this at 200. In other words, no filter configurations should yield more than 200 suggestions.
    • The user can click arrows to pass back and forth across the list. On the first card, the left arrow is grayed out and not clickable.
    • Note: the "X" in the upper right of the cards shown in the mockups is not required for the first version. It is ticketed separately in T232899.
    • When the user gets to the last card in the list, they can click the right arrow one more time, and then they see an area that says something like, “Change the filter settings to find more tasks.” along with a graphic. (T235043)
    • If the user's filter settings yield no tasks, they should see an area that says something like, "Change the filter settings to find more tasks." along with a graphic. (T235044)
    • When the user clicks a card, they go to the article from the card.
  • Task explanation (T235046)
  • Footer (T236050)

Below is a list of non-engineering items that need to be complete before this task is complete, but that do not block engineering:

  • Lay out the exact templates and categories from which we'll source tasks in Arabic, Czech, and Korean Wikipedias, along with their task type and the difficulty levels of each task type.
  • Add mobile designs.
  • Collect deletion templates
  • Finalize copy
  • Decide hierarchy of which task types to prefer if an article has more than one maintenance template/category.

Related Objects

StatusSubtypeAssignedTask
ResolvedMMiller_WMF
Resolvedkostajh
ResolvedTgr
Resolvedkostajh
Resolved mepps
ResolvedCatrope
Resolvedkostajh
Resolvedkostajh
Resolvedkostajh
DeclinedNone
Resolvedkostajh
ResolvedTgr
Invalidkostajh
Resolvedkostajh
ResolvedCatrope
Resolvedkostajh
Resolvedkostajh
ResolvedTgr
Resolvedkostajh
ResolvedCatrope
Resolvedkostajh
ResolvedEtonkovidova
OpenNone
Resolvedkostajh
ResolvedBUG REPORTTgr
Resolvedkostajh
Resolvedkostajh

Event Timeline

There are a very large number of changes, so older changes are hidden. Show Older Changes
MMiller_WMF updated the task description. (Show Details)
MMiller_WMF updated the task description. (Show Details)

image.png (636×1 px, 166 KB)

If I select one checkbox item from the "Easy" group and one from the "Medium" group, what should the label at the top right show?

image.png (636×1 px, 166 KB)

If I select one checkbox item from the "Easy" group and one from the "Medium" group, what should the label at the top right show?

hiya, I was thinking we could show an outline levels icon and comma-separate selected levels in the label (with truncation):

image.png (118×356 px, 5 KB)

Oh and here's the level icon SVGs assets btw:

I just tweaked a couple of specifications based on changes that @RHo made to the mockups following the desktop user tests.

@Tgr -- T232419: Newcomer tasks: suggested edits initiation and overlays and this task are about separate parts of the workflow. T232419 is about the part of the workflow when the user arrives on the homepage, clicks the call-to-action in the start module, and then overlays come up. After (and only after) the user gets through all the overlays, the module described in this task appears. (At the same moment, this also happens: T232420: Newcomer tasks: homepage changes based on initiation (desktop)).

Does that make sense?

No protected articles should be shown, at any level of protection.

We can get this article via the API when using search as a generator module, with prop=info and inprop=protection.

No articles should be shown that are nominated for deletion. Specific templates to be collected from ambassadors.

While not (yet) documented in https://www.mediawiki.org/wiki/Help:CirrusSearch it looks like you can do -hastemplate:{templatename} to exclude articles that have a certain template.


@MMiller_WMF Until I read this task closely, I was under the impression that we were using only templates for sourcing tasks. But this task says templates and categories. I think categories are also possible but I haven't done much to investigate it specifically. Can you confirm that you want both?

@kostajh -- thanks for reading closely. The reason I wrote "templates and categories" is because I have seen a couple cases in our target wikis where articles that need maintenance either have just a template or just a category, but not both. Looking at the list in the spreadsheet that we're using for this first version, it looks like every group we chose has a template, although two in Arabic don't have a corresponding category. So it looks using templates only will work for now, but I think it's possible that we may work with wikis that only use categories in the future. Therefore, if we want to build only with templates for now, I think that's fine, but we may need to come back to categories.

Does that make sense?

It does, thanks!

In Monday's standup @Catrope expressed he would work on the front end starting this week. He also stated he would break this tasks into subtasks, one for front end and one for back end. He will sync with @Tgr and @kostajh on this by Wednesday.

@MMiller_WMF @RHo if I remember right, for v1.0 we discussed showing a maximum of 20 items per task type (so: 20 copy edit tasks, 20 add links tasks, etc). Is that correct? If so, can you update the task description please?

Also, when do you think we'll have the deletion templates? It will be useful for T234426

@kostajh -- I am okay with limiting to a maximum of 20 items per task type, but I think we brainstormed that idea because we were worried about not having enough tasks or something. Does having a maximum help from an engineering perspective in any particular way? I imagine it could help with not giving all the newcomers the exact same lists of tasks, because we could choose a random set of 20.

Otherwise, I could also see us having the specification say that it should list all available tasks, even if it's like 20,000. But we would want them sorted randomly.

What do you think we should do?

I'll ask for deletion templates today.

Does having a maximum help from an engineering perspective in any particular way?

It means not having to deal with continuation (fetching recommendation results from the server in multiple parts). Continuation turns stateless requests into stateful ones, and that state has to be carried back and forth between the backend and frontend, which is somewhat cumbersome. Our backend is probably going to work by mashing together multiple info streams (like a separate search query for each task template), that makes continuation extra complicated.

Whether the limit is 20 or something significantly higher (say 500) is probably not going to make much difference, but having some limit does make things simpler.

Thanks, @Tgr. As @RHo and I are thinking this through, it actually sounds like an important decision for a few reasons. It sounds like the decision is whether we have to fetch all tasks before displaying any. Here are the three specifications I can think of that require fetching all tasks:

  • "A counter along the bottom [of the difficulty filter] that says how many articles fit the filter settings. This should update dynamically as the user alters the filters. When the topic overlay also exists, this number should include any topic filter settings."
  • "When presented to the user, the articles should be sorted randomly, to decrease how often different users sees the same articles." (and also so that they don't get results all from one maintenance template)
  • The thing that started this conversation: showing the actual number of available tasks.

So given this list, my questions to @Tgr and @kostajh are:

  • Is this the right list? Do these three things all have the same underlying requirement of fetching all the available tasks? Are there any others you can think of?
  • Given that we desire to do all three of these things, should we just accept that, and then display the full number of available tasks to the user (e.g. "1 of 21,789")?

Fetching all tasks and getting the number of all tasks are not necessarily related. This depends on how the suggestion engine gets implemented; currently we are relying on MediaWiki search which does return the total hit count, so we can easily display that regardless of how we otherwise handle tasks. (The details will somewhat depend on the implementation; more specifically, whether an article with multiple issue tags will be counted as one task or multiple will depend on how we structure search internally. But I imagine that's not much of a concern.)

Fetching tens of thousands of tasks to the client side is not feasible in any case, so if the suggestion mechanism does not support getting total hit count, we won't be able to display it. A task type of "all recently created articles" would be a (somewhat contrived) example. That said with a little extra effort we can probably convert anything into search-based, where totals are not a problem.

The same considerations apply to sorting as well.

I'll create subtasks of this tomorrow so that we can work on some of these items concurrently.

@Tgr @kostajh -- it sounds like you're saying that it is possible to do the three things I listed in my comment (counter in difficulty filter, sort randomly, and say how many tasks are in the list), so I'll clarify that in the specifications now. We will want to say the actual number with a cap at 200. It would be "3 of 197" and "3 of more than 200". If someone actually flips through all of them and gets to task 205, then it is fine to say "205 of more than 200".

MMiller_WMF updated the task description. (Show Details)

@kostajh @Tgr -- I've collected the deletion templates from ambassadors and linked the spreadsheet in the specifications.

We will want to say the actual number with a cap at 200. It would be "3 of 197" and "3 of more than 200". If someone actually flips through all of them and gets to task 205, then it is fine to say "205 of more than 200".

@MMiller_WMF @RHo it will make things significantly easier if we just set a hard upper limit at 200, so if the user gets to task 200, the next card is the "there-are-no-more-tasks-adjust-your-filters" card. Would that be OK?

kostajh updated the task description. (Show Details)

@RHo the mockup shows the Wikidata description, but I don't think I see that in this task description. Should that be included?

Also, could you please attach the images for placeholder, no tasks found, and end of queue?

@kostajh -- limiting at 200 is a good idea! That works for us. I'll change the specifications now. Also, I think the current mockup does not show the Wikidata description. It's just showing the preview of the article text. Do you see something different?

Change 542059 had a related patch set uploaded (by Kosta Harlan; owner: Kosta Harlan):
[mediawiki/extensions/GrowthExperiments@master] Growth tasks API: Update query limit to 200

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

Per chat with @RHo just now, we'll use a light blue background for the suggested edits module, then make more improvements in T232546

Change 542908 had a related patch set uploaded (by Kosta Harlan; owner: Kosta Harlan):
[mediawiki/extensions/GrowthExperiments@master] Suggested edits 1.0 styles

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

Change 542908 merged by jenkins-bot:
[mediawiki/extensions/GrowthExperiments@master] Suggested edits 1.0 styles

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

Change 542059 merged by jenkins-bot:
[mediawiki/extensions/GrowthExperiments@master] Growth tasks API: Update query limit to 200

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

This task seems more like an Epic so I'm moving it there, and will split off to subtasks for the remaining items. Pinging @Etonkovidova in case you want to QA the patches that have been merged already, otherwise seems like it could all be done together once the subtasks of this task are out of code review.

@kostajh @Tgr @Catrope -- I just added a new specification that came from the user tests: the "footer". I want to point it out to you specifically to make sure you notice, and to get thoughts on what's possible/easy/difficult. It might be tricky to deal with numeric abbreviations? Please let me know what you think. Does it need to be its own task?

  • Footer
    • The bottom of the module should have a footer that reads, "Other users have noted these articles need work. Help make <Wiki project> better for its <#> readers each month.
    • <Wiki project> should contain the project name, like "Czech Wikipedia" or "French Wiktionary".
    • The number of readers each month should come from unique devices. It should be rounded in a reasonable way. Perhaps if under 1 million, it should be rounded to the nearest hundred thousand, and if over a million, rounded to the nearest million. Then displayed with an abbreviation like 400k or 4 million. This could be an average of months across the last year, the most recent month, or something along those lines.

Change 546333 had a related patch set uploaded (by Kosta Harlan; owner: Kosta Harlan):
[mediawiki/extensions/GrowthExperiments@master] Suggested Edits: Add placeholder image

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

Change 546333 merged by jenkins-bot:
[mediawiki/extensions/GrowthExperiments@master] Suggested Edits: Add placeholder image

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

I think we can declare this one resolved.