Page MenuHomePhabricator

Homepage: impact module
Closed, ResolvedPublic

Description

This is a task for building one of the modules in the newcomer homepage: the impact module.

Main audience: Newcomers who may be motivated to edit by seeing the impact of their contributions.

Primary targeted persona(s): Jae-Hee (Social Changer); Yankov (Knowledge Sharer)

Secondary persona(s): Josef (Reactive Corrector); Mina (Box Checker)

Invision mockups: https://wikimedia.invisionapp.com/share/KUQV2QDJ8A7#/350926581_NH-Impact_Module (in places where the mockups and the specifications on this task disagree, the specifications take precedent.)

Summary: This module contains a list of pages that the newcomer edited, along with the pageviews those pages have had. We are using pageviews as our best proxy for "impact". There are many rules we could apply for how exactly to calculate the pageviews, and there are many things we could consider around how responsible the newcomer is for the pageviews (for instance, adding a comma is a lot less impactful than writing the entire page). But to keep things simple, the main objective here is to indicate to newcomers that they have impact, as opposed to communicating with exact precision what their impact is. We also want the module's numbers to change dynamically over time so that it is interesting for users to revisit the module day after day.
We can refine business rules later on. The module has an "activated state" for newcomers who have edits in the article space and an "unactivated state", meant to communicate to users who do not yet have edits in the article space that they should make some edits so they can see their impact. The module links out to the Pageviews Analysis tool. When we test this module, we will want to be able to see how it will look for arbitrary real users from multiple wikis. This will help us calibrate the rules around pageview display.

The specifications below are detailed. If anything about these specifications is not performant, we can discuss how to alter them.

Activated state: when a user has one or more edits to the article namespace

  • Copy and links
    • The title of the module should read "Your impact". The team is still discussing this title.
    • The subtitle should read, "People are viewing the articles you edited! Views since you edited (last 60 days):"
    • The bottom of the module should have a link that reads, "You've made X edits (see all)". "X" should be the total number of edits the user has made in any namespace, and should be bold. The whole phrase should link to the user's Contributions page.
  • Choosing pages and calculating pageviews
    • Definition: "edits" counts any edit, no matter the size, whether it was reverted, or whether it was a revert. We are only counting edits to the article namespace, namespace 0. The talk namespace does not count.
    • Definition: "pageviews" is the number of pageviews since (inclusive) the first day that the user edited the page. If the user has edited the page multiple times, the first time they edited it is when the counting begins. Pageviews should include the day the user first edited. Although this includes many of the user's own pageviews, we think they will be able to understand that. This means the user will start seeing some data the day after they make an edit. For pages that the user first edited on the same day they are viewing this module, there will be "null" pageviews, since data will not yet be available.
    • Among the set of 10 most recent pages that the user has edited, choose the 5 pages that have the most pageviews since the user first edited them (or in the last 60 days, if their first edit was more than 60 days ago -- because of constraints of the API). If a user has edited a page multiple times, their most recent edit of that page is what is counted for deciding whether it is part of the 10 most recent pages. For this sort, "null' sorts below 0 pageviews. If the user has edited fewer than 5 pages, show them all.
    • Display those 5 pages in descending order of pageviews.
  • Listing pages
    • Thumbnail of the article's lead image (with image placeholder icon if no image is available)
      • Tooltip should read, "Go to article"
    • Article title
      • Tooltip should read, "Go to article"
    • Number of pageviews since the user first edited the article. This should show the full number, as opposed to any abbreviation (e.g. "1234" instead of "1.2k") and it should allow the number to accommodate language conventions (e.g. "1.234" vs "1 234", etc). For articles with null pageviews, display an icon that conveys, "Check back later". Icon TBD. Until we have an icon, display "--". Another potential approach is to display the average daily pageviews of that page from the last month or so, or the number of pageviews from the previous day to the edit, but to visually indicate that that number is still just a placeholder until the real count will be available the next day. This decision is pending additional design work.
      • Tooltip should read, "See detailed page views"
  • Clicking on the row
    • Clicking on the thumbnail or article title should bring the user to the article in the same tab.
  • Clicking on the number of views should bring the user to the "Pageviews Analysis" tool in the same tab.
    • The tool should show the article the user clicked on.
    • The dates should go from the day of the user's first edit on that article through the present day.
    • It should display in the language of the wiki that the click came from.

Unactivated state: when a user has zero edits to the article namespace

  • The title of the module should read "Your impact"
  • The subtitle should read, "You have not yet edited any articles. This area will show the impact of your edits."
  • Display "0 edits to articles". "0" should be bold.
  • Display "X edits to other kinds of pages (see all)". "X" should be the total number of edits the user has made in any namespace, and should be bold. The whole phrase should link to the user's Contributions page.
  • Although the mockup currently distinguishes between English Wikipedia and Commons, the "cross-wiki" idea is something we'll reserve for a future version.

Future: a list of capabilities that may be needed in future versions, listed here for planning purposes.

  • Dropdowns or toggles inside the module that allow the user to configure which set of pages they see listed. These configurations would be sticky.
    • Most recent pages edited vs. least recent pages edited
    • Most viewed vs. least viewed
    • Most bytes changed vs. least bytes changed
  • Dropdowns or toggles inside the module that allow the user to configure the time period of the pageview counts, e.g. "Past week", "Past month", "All time". These configurations would be sticky.
  • We may want to implement more sophisticated logic for the five pages that are shown, perhaps preferring to show a combination of pages that have a lot of views with a couple listings of pages that were most recently edited.
  • We may want to "count" edits to other namespaces. Many newcomers make their first edits on their User page or Sandbox. It may be good to acknowledge that work in this module.
  • We may want to show a visual "sparkline" style graph as shown in the mockups that shows pageviews over time, or something else.
  • We may want to include tooltips or links that explain how pageviews are counted, or what "namespaces" are.
  • We may want to show cross-wiki numbers, not just the numbers from the wiki the user is currently viewing.
  • We may want to allow the user to show their impact module in public, as opposed to viewing it privately. This would mean something like a "public-facing skin".
  • We may want to allow users to block articles from being in the list. For instance, perhaps they edit some article all the time, and they are sick of it taking up a slot in there list of five. Perhaps they can "x" it away to free the spot up.
  • We may want to draw on pageviews earlier than the 60 day limit from the PageViewInfo extension.

Below is an early mockup the is labeled. In places where the mockups and the specifications on this task disagree, the specifications take precedent.

image.png (827×850 px, 143 KB)

Related Objects

Event Timeline

There are a very large number of changes, so older changes are hidden. Show Older Changes

@Etonkovidova -- thanks for that suggestion. The version I think we should change to is, "People are viewing the articles you edited! Views since you edited (last 60 days):" I'll change this in the description. I just think we have to explain the number a little bit, and I'm worried it's a little long. We'll see what it looks like. I also am going to make a change to the language about the user's total edits to make that clearer, now that I'm seeing the mockup.

@kostajh -- I got some additional feedback on this. Maybe we should just let the article name link to the article? And have the number link to the Pageviews Analysis tool? I do want to drive people to the tool, but maybe we should stick with the paradigm of article name linking to the article. @Cntlsn, what do you think?

Change 494362 merged by jenkins-bot:
[mediawiki/extensions/GrowthExperiments@master] Styling for Impact module

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

Change 494398 had a related patch set uploaded (by Sbisson; owner: Sbisson):
[mediawiki/extensions/GrowthExperiments@master] Impact: update copy text according to task

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

Change 494398 merged by jenkins-bot:
[mediawiki/extensions/GrowthExperiments@master] Impact: update copy text according to task

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

@Etonkovidova -- thanks for that suggestion. The version I think we should change to is, "People are viewing the articles you edited! Views since you edited (last 60 days):" I'll change this in the description. I just think we have to explain the number a little bit, and I'm worried it's a little long. We'll see what it looks like. I also am going to make a change to the language about the user's total edits to make that clearer, now that I'm seeing the mockup.

@MMiller_WMF @Etonkovidova
Please check the following slightly edited copy. It doesn't sound too good but works best in terms of layout. What do you think?

Your impact v1.0 New copy.png (780×480 px, 105 KB)

@kostajh -- I got some additional feedback on this. Maybe we should just let the article name link to the article? And have the number link to the Pageviews Analysis tool? I do want to drive people to the tool, but maybe we should stick with the paradigm of article name linking to the article. @Cntlsn, what do you think?

@MMiller_WMF @kostajh
That's more or less what I was also thinking. I would let the thumbnail and article title link to the article page (for behavior consistency) and let number link to the Pageviews Analysis tool. Can we then have two different tooltips for the two links?

Your impact v1.1.png (780×740 px, 120 KB)

Page preview popup could also be an option, I'm just not sure how relevant it would be to show the article preview in that scenario (the user has already edited the page so it should know what it is about, but maybe has edited many articles and doesn't really remember??!?)

If we agree on new text and links behavior I would update the mockups accordingly

@Cntlsn -- regarding the edited copy, are you proposing the wording change only because it will fit better? Or for another reason? If it's because of the fit, then I don't think we should change it, because we won't be able to account for how the fit will change once it's translated into other languages. For instance, Czech tends to make text longer than English.

It sounds like we agree about linking to the article. I will update the specifications in the description. When you update the mockups, please read through the description again so that all the language matches up. It's been changing a little over time.

Regarding tooltips, I hadn't thought about this at all. @SBisson -- are tooltips simple enough that we could add them to the specifications, or are they more something that should go in the "Future" section?

Regarding tooltips, I hadn't thought about this at all. @SBisson -- are tooltips simple enough that we could add them to the specifications, or are they more something that should go in the "Future" section?

Very simple to add; no problem.

Change 494714 had a related patch set uploaded (by Sbisson; owner: Sbisson):
[mediawiki/extensions/GrowthExperiments@master] Impact module: change links and copy

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

Change 494714 merged by jenkins-bot:
[mediawiki/extensions/GrowthExperiments@master] Impact module: change links and copy

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

I updated the description to include tooltips.

@Cntlsn -- please let us know what you think around my previous question about the copy in the module.

Change 494863 had a related patch set uploaded (by Sbisson; owner: Sbisson):
[mediawiki/extensions/GrowthExperiments@master] Impact: update tooltips

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

I updated the description to include tooltips.

@Cntlsn -- please let us know what you think around my previous question about the copy in the module.

@MMiller_WMF Agreed on all and changed the tooltips copy in the mockup accordingly

@Cntlsn -- I don't see the changed mockups. Where can I find those?

Change 494863 merged by jenkins-bot:
[mediawiki/extensions/GrowthExperiments@master] Impact: update tooltips

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

@Cntlsn -- I don't see the changed mockups. Where can I find those?

Link to mockups updated in the task description

Thanks, @Cntlsn. Could you please also include a mockup for the "Unactivated" state. Also, do you recommend that we abbreviate long numbers like "1.3k", or should it actually be like "1,324"?

@MMiller_WMF

Could you please also include a mockup for the "Unactivated" state.

Included, sorry I forgot about it

Also, do you recommend that we abbreviate long numbers like "1.3k", or should it actually be like "1,324"?

  • I did abbreviate numbers bigger than 999 as a general design practice with numbers in list items, basically to avoid the possibility of having big numbers conflict with the article title real estate
  • it is true that I'm a bit dubious about it. To me "1.3k" is intuitive, but I might be biased. At the same time the internationalization of numbers is a bit a tricky, for instance "1,324" in most european countries would be read as a number with a decimal part... https://language-boutique.com/lost-in-translation-full-reader/writing-numbers-points-or-commas.html

Mediawiki deals with numbers quite properly. You have 1234 in base and it is displayed to the user according to the language rules (1,234 for English, 1.234 for German, 1 234 for French, 1234 for Spanish...).

Abbreviations need extra work IIRC. Special:ContentTranslationStats (the links I'm providing) is not using abbreviations FWIW.

@Trizek-WMF thanks a lot for your input!

Also thinking about it, I'm feeling like we have enough real estate to fit quite a large number (considering it's pageviews in the last 60 days since the user edited)

Screenshot 2019-03-12 10.08.57.png (404×848 px, 66 KB)

Also thinking about it, I'm feeling like we have enough real estate to fit quite a large number (considering it's pageviews in the last 60 days since the user edited)

Let's abbreviate then. :)

I wan thinking about the following, but there are certainly better ideas:

  • 999k, with an explanation of what "k" stands for when you hover it
  • 999+ with the real number displayed when you hover it

@SBisson -- do you have any opinion on translations from the engineering perspective? @Cntlsn and I think that there is enough room for the full number, but you are the one in the code. Will having long numbers break things? Will trying to translate abbreviations break things?

Moving to design review and assigning to @Cntlsn for him to post detailed comments on any differences between the implementation and the design.

@SBisson -- do you have any opinion on translations from the engineering perspective? @Cntlsn and I think that there is enough room for the full number, but you are the one in the code. Will having long numbers break things? Will trying to translate abbreviations break things?

CLDR has rules for abbreviating large numbers across languages and cultures. It's not just simple translation, grouping can be different too. For example, in India they often group by lakh and crore instead of thousands. We do use CLDR but I don't know if we have easy access to this specifically. If you think it's important I'll dig deeper.

I'm more concerned with article titles being super long because they often are. I haven't tested what the current implementation looks like in those cases but I would probably start there and leave the numbers alone.

Thanks, @SBisson. I think you are saying that the easiest path is to just use the normal number "1234". Let's do that. I will edit the description to be clear.

@Cntlsn, could you please edit the mockup?

@Cntlsn, could you please edit the mockup?

mockup updated!

@Cntlsn -- I'm looking at the mockup linked in the task description, and it still says "1.3k".

image.png (320×517 px, 45 KB)

@Cntlsn -- I'm looking at the mockup linked in the task description, and it still says "1.3k".

fixed!

@Catrope @SBisson
I have found a small, but potentially annoying, experience bug:

  • with page previews feature on
  • when hovering over an article title (it has to be at least the 2nd item in the list)
  • the panel gets displayed but it's hard to enter its area with the cursor (for instance to reach the cog)

Moving this to In Progress so that @kostajh @SBisson or @Catrope can pick up the bug noted above by @Cntlsn.

Alessandro will break the bug out of this ticket then move this ticket to Marshall's column

I just went through this, and I don't see any major issues. I think the only outstanding issues are:

  • @Etonkovidova -- you have a few of this: . Could you specify what the issues are?
  • @Cntlsn -- you and I discussed today how to treat the page previews. Could you please add a comment with your recommended treatment? We may not need to break it to a separate task.
  • @Cntlsn -- I noticed that there might be too much space under the header. In the screenshot below, you can see that the content of the module starts farther down the page than the content for the adjacent mentorship module.

image.png (179×840 px, 33 KB)

  • @Cntlsn -- I emailed you about the icons for images, but I'll repeat it here. I noticed that the icon for "no image available" is doesn't match the mockup. Here is the mockup:

image.png (91×116 px, 5 KB)

Here is Test Wiki:
image.png (101×120 px, 4 KB)

Should we change this?

@MMiller_WMF only two green exclamation point are left my notes on them are below.

The dates should go from the day of the user's first edit on that article through the present day.

The current label says: "Views since you edited (last 60 days):" The first edit of an article can be made more than sixty days ago. Pageviews has an option to select last 60 days (e.g. https://tools.wmflabs.org/pageviews/?project=test.wikipedia.org&platform=all-access&agent=user&start=2019-02-23&end=2019-04-24&pages=Plants_in_space), but it's not a default.

It should display in the language of the wiki that the click came from.

Needs to be checked in prroduction.

  • @Cntlsn -- you and I discussed today how to treat the page previews. Could you please add a comment with your recommended treatment? We may not need to break it to a separate task.

I think the bug is caused by the fact that the article preview popup would attach itself to the parent div and not to the article link. For instance, when <a class="article-title" is set to vertical-align:top the bug is gone, but of course we don't want the article titles aligned to top. So can we find a way to attach the article preview popup to the article title?

Screenshot 2019-04-26 17.42.03.png (906×828 px, 145 KB)

  • @Cntlsn -- I noticed that there might be too much space under the header. In the screenshot below, you can see that the content of the module starts farther down the page than the content for the adjacent mentorship module.

image.png (179×840 px, 33 KB)

This is caused by the fact that the first paragraph in the impact module is wrapped in a <p> tag that has top margin, while the icon and mentor name of the mentorship module are not.
@Catrope a quick fix would be to add margin-top: 1em; to <div class="growthexperiments-homepage-mentorship-userlink">

  • @Cntlsn -- I emailed you about the icons for images, but I'll repeat it here. I noticed that the icon for "no image available" is doesn't match the mockup. Here is the mockup:

image.png (91×116 px, 5 KB)

Here is Test Wiki:
image.png (101×120 px, 4 KB)

Should we change this?

@MMiller_WMF I remember that when the module was first deployed somebody told me that those icons I was using were not the correct ones and we should have used the article icon instead, but I can't seem to find that comment anywhere atm.
Actually, now that I've done some research we do have a very similar OOUI icon to the one used in the mockups:

Screenshot 2019-04-26 18.05.27.png (270×386 px, 16 KB)

With the OOUI icon it would like this :)

Screenshot 2019-04-26 18.21.49.png (648×576 px, 83 KB)

I'm about to submit a patch that fixes all 3 issues described above (I hope).

Change 506716 had a related patch set uploaded (by Sbisson; owner: Sbisson):
[mediawiki/extensions/GrowthExperiments@master] UI fixes to Impact and Mentorship modules

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

Change 506716 merged by jenkins-bot:
[mediawiki/extensions/GrowthExperiments@master] UI fixes to Impact and Mentorship modules

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

@Etonkovidova -- thanks for the explanation around the remaining issues. I think the thing about "60 days" is fine -- what we really want is for users to see the pageviews since they first edited, but we are limited by the API in terms of what number we can display right in the module (though we are not limited in the Pageviews Tool's UI). So let's leave it the way it is, and we'll hope that someone at Hackathon address the 60 days issue in the API via T220143.

Otherwise, I am done with my review, and this should stay in my column until we check it in production wikis.

The impact module has been functioning correctly in production for weeks.