Page MenuHomePhabricator

Newcomer tasks: unactivated state of impact module should drive newcomer tasks
Closed, ResolvedPublic

Description

This task is about exploring ways to make the impact module more actionable for those with no contributions once the task recommendations module is introduced to the homepage.

In the unactivated state, the impact module should contain:

  • The same heart graphic used in the intro overlay for newcomer tasks.
  • Large text: "0 edits so far"
  • Smaller text: "Help extend free knowledge to the world by editing topics that matter most to you."
  • Button (mobile only): "See suggested edits". Selecting this opens the full suggested edits overlay, as if the user had tapped into it from the homepage. It should not open the overlay on top of the impact overlay. When users close the suggested edits overly, we want them to see the homepage, not the impact module.
  • Module footer text: "Start with a few suggested edits, then see how many people are viewing your contributions here. " This text has no links or buttons in it.
  • The formatting in the footer for both platforms should have "suggested edits" in bold.
  • We should not expend effort supporting no-Javascript users.

This should be its state even if there are no articles available in the suggested edits feed.

Instrumentation: we should add an event for when the user taps the call-to-action button on mobile.

Redlined mocks on Figma https://www.figma.com/file/Pgo6fPGaDDiqXWGfMI8oiF/Growth-features?node-id=0%3A1

Desktop
Mobile

Event Timeline

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

Thanks, @Cntlsn. We definitely don't want to address task recommendations in this Phab task, since we're going to figuring out task recommendations more broadly for the homepage -- either in a task recommendations module, or as a next step for the start here module.

I think that "tutorial" idea is more along the lines of what we need. But I don't think it's good that it will be redundant with the other modules. One additional idea might be to et the unactivated impact module "refer" to the other modules. It might say something like, "You don't have any edits to articles yet! Try asking your mentor for advice on how to get started (over there ---->). Or do the tutorial to learn how to edit (up there ^)." I'm not sure how this would actually look, though.

Let's bring this up again after we get through the questions in T223219.

Me and @MMiller_WMF discussed about this, the most correct call-to-action to be featured in the unactivated state of the Impact module would be a link to structured editing, but the team is not gonna work on this in the near term.

I still feel it is important to offer some kind of call-to-action in the unactivated state of the impact module, so until the structured editing would eventually be available, we can prompt the user to choose between the relevant activities we are offering in the homepage at the moment:

  • follow a step-by-step tutorial
  • ask the mentor
  • check for questions asked by other users on Help desk (I deliberately excluded asking a question to help desk as it would add even more redundancy and users might feel confused on whether it would be better to ask their question to their mentor or the help desk...)

The options we are offering might feel redundant, but at least would offer the user some kind of help (mostly in the mobile scenario, where the user in the fullscreen view of the impact module is temporarily far from the proposed options).
We can measure the interest in the call-to-actions and adapt later.

I have added more comprehensive mockups in T223219

@MMiller_WMF it looks like @Cntlsn said we are going to work on this later, how much later Q1 next FY later? Just wanting to move it off the current sprint board to the appropriate place.

RHo renamed this task from Homepage: unactivated state of the impact module should include a call to action to make edits to Homepage: unactivated state of the impact module should guide users on how to "activate their impact".Aug 5 2019, 9:18 PM
RHo updated the task description. (Show Details)
MMiller_WMF added a subscriber: RHo.

@RHo -- this is the impact module improvement task that we'll want to do soonest -- it's just about the initial unactivated state of the module, as depicted in this mockup.

MMiller_WMF removed a project: Growth Design.
MMiller_WMF updated the task description. (Show Details)
MMiller_WMF edited projects, added Growth-Team; removed Growth-Team (Current Sprint).
MMiller_WMF moved this task from Inbox to Upcoming Work on the Growth-Team board.

@RHo -- I asked you a question in Invision about whether the desktop version has a button or call-to-action. After that, this task will be ready to go.

MMiller_WMF renamed this task from Homepage: unactivated state of the impact module should guide users on how to "activate their impact" to Homepage: unactivated state of impact module should drive newcomer tasks.Oct 18 2019, 8:44 PM
MMiller_WMF renamed this task from Homepage: unactivated state of impact module should drive newcomer tasks to Newcomer tasks: unactivated state of impact module should drive newcomer tasks.Oct 18 2019, 8:47 PM

We think this improvement will work well with future variant tests of the homepage layout.

De-prioritizing off the sprint board in favor of other tasks.

@MMiller_WMF @RHo I have a couple of clarification questions:

  • Should this version of the impact module be shown if there are no articles for suggested edits (probably an edge case)?
  • Should the "See suggested edits" button open the suggested edits module on top of the overlay or take the user back to the homepage (and scrolled to the suggested edits pane)?
  • For mobile, do "See suggested edits" button and the bold "Suggested edits" in the footer have the same action?

@mewoph -- good questions. Here are the responses, and I will also update the task description with them:

Should this version of the impact module be shown if there are no articles for suggested edits (probably an edge case)?

Yes, because this case should only happen if the user has set pretty constrictive filters for suggested edits (like an obscure topic and a rare task type). If they have no articles available, they should be able to change their filters to get some. And if they have no article available because something is broken, well then the real problem is that suggested edits is broken, not that impact is broken as a by-product.

Should the "See suggested edits" button open the suggested edits module on top of the overlay or take the user back to the homepage (and scrolled to the suggested edits pane)?

The button should take the user to the full suggested edits overlay (not back to the homepage), but it should not put that overlay on top of the impact overlay. It should close the impact overlay, so that the user winds up in the same place as they would be if they had tapped into suggested edits from the homepage. We don't want them to close the suggested edits overlay only to be back on the impact overlay underneath it.

For mobile, do "See suggested edits" button and the bold "Suggested edits" in the footer have the same action?

The mobile footer shouldn't have any actions. Although the words are bold, tapping them should not do anything. The button is the only thing with an action.

Change 662028 had a related patch set uploaded (by MewOphaswongse; owner: MewOphaswongse):
[mediawiki/extensions/GrowthExperiments@master] WIP: Updated unactivated state of impact module

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

@RHo @MMiller_WMF Just double checking, should "Suggested" be capitalised in "See Suggested edits"? IIRC we talked about this before and stayed with lower case, e.g. "See suggested edits".

In the task description, there is a reference to lowercase "See suggested edits" for button text and capitalised for the footer.

@RHo @MMiller_WMF Can the formatting for the footer be the same on desktop and on mobile? I've set up two separate messages to account for the bold "Suggested edits" — @kostajh mentioned that this could add additional work for translators.

@mewoph -- a few notes from today that I will add to the task description:

  • It should not be capitalized: "suggested edits".
  • Let's make the formatting in the footer the same, both bold.
  • We should not spend effort on supporting no-Javascript users for this feature.

@MMiller_WMF Confirming the instrumentation data for the "See suggested edits" button click, would impact-see-suggested-edits link ID with link-click action be ok?

@mewoph -- yes, that sounds good. @nettrom_WMF -- FYI on this new action_data value.

Change 662028 merged by jenkins-bot:
[mediawiki/extensions/GrowthExperiments@master] Updated unactivated state of impact module

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

For @RHo review - the following differences between mockups and implementation have been confirmed (in comments) as correct.

  • no capitalization of Suggested edits
  • suggested edits are bolded
Desktop mockup
Desktop betalabs
Desktop betlabs small screen
Mobile mockup
Mobile betalabs

Notes:
(1)

  • Button (mobile only): "See suggested edits". Selecting this opens the full suggested edits overlay, as if the user had tapped into it from the homepage. It should not open the overlay on top of the impact overlay. When users close the suggested edits overly, we want them to see the homepage, not the impact module.

Clicking on the button "See suggested edits" will open the full suggested edits overlay only if SE module has been activated.
A new user before activating the SE module, opens the Impact module -> then clicks "See suggested edits" -> will be returned to the Homepage.
The behavior above could be more logical - users should be presented with the intro tour immediately after clicking on "See suggested edits" instead of being returned to the same Homepage from which they just clicked o Impact module.

(2) Double checking - the link to the Special:Contributions page is removed.

(3) Special:Imapct/User: looks ok.

Change 665318 had a related patch set uploaded (by Kosta Harlan; owner: Kosta Harlan):
[mediawiki/extensions/GrowthExperiments@master] [WIP] Impact: Launch start editing CTA when suggested edits is unactivated

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

A new user before activating the SE module, opens the Impact module -> then clicks "See suggested edits" -> will be returned to the Homepage.

The behavior above could be more logical - users should be presented with the intro tour immediately after clicking on "See suggested edits" instead of being returned to the same Homepage from which they just clicked o Impact module.

Good point, done in this patch.

(2) Double checking - the link to the Special:Contributions page is removed.

I think that preceded this change. But yeah we should probably either add the link or remove the "(see all)" when there are no contributions. @RHo do you have a preference on that?

A new user before activating the SE module, opens the Impact module -> then clicks "See suggested edits" -> will be returned to the Homepage.

The behavior above could be more logical - users should be presented with the intro tour immediately after clicking on "See suggested edits" instead of being returned to the same Homepage from which they just clicked o Impact module.

Good point, done in this patch.

(2) Double checking - the link to the Special:Contributions page is removed.

I think that preceded this change. But yeah we should probably either add the link or remove the "(see all)" when there are no contributions. @RHo do you have a preference on that?

Thanks for checking @kostajh, let's remove "(see all)" when there are no contributions.

Change 665318 merged by jenkins-bot:
[mediawiki/extensions/GrowthExperiments@master] Impact: Launch start editing CTA when suggested edits is unactivated

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

Moving to PM review - FYI only. No issues.

Checked in testwiki wmf.32 - all is done.

A new user before activating the SE module, opens the Impact module -> then clicks "See suggested edits" -> will be returned to the Homepage.

Done

(2) Double checking - the link to the Special:Contributions page is removed.

I think that preceded this change. But yeah we should probably either add the link or remove the "(see all)" when there are no contributions. @RHo do you have a preference on that?

Thanks for checking @kostajh, let's remove "(see all)" when there are no contributions.

Done

Going to take a quick gander first since this is new

let's remove "(see all)" when there are no contributions.

I don't think we made a patch for this part of the requirements yet.

This looks great, but I had noticed some very minor tweaks and also a correction for an inconsistency I added in my design on Mobile (the background colours) that I hope should be an easy fix?

Screenshots from testwiki:

Desktop wide
Desktop narrow
Mobile

Tweak items

Item DescriptionScreenshots if any
1. Text colour for the Header ("0 edits...") and subheader ("Help extend....") should both be Base10 (#202122) and not Black.
2. Desktop Bottom-padding on the .growthexperiments-homepage-module-impact-unactivated-desktop .growthexperiments-homepage-module-body should be 16px (not 19px)Actual
Expected
3. Desktop Bottom-padding on .growthexperiments-homepage-module-impact-unactivated-desktop .growthexperiments-homepage-module-footer should be 16px (not 11px)Actual
Expected
4. Mobile - Add side padding 1em to the subheader .growthexperiments-homepage-module-impact-unactivated-mobile-overlay-subheader-subtextActual
Expected
5. Mobile footer text font-size is smaller than the 16px size in testwiki. It should be font-size: 13px with 19.5px line-height (re-using the Minerva thumbcaption style if possible), or else using the .growthexperiments-homepage-module-text-light text style.Actual:
Expected
6. ( Bottom-padding on footer .growthexperiments-homepage-module-impact-unactivated-mobile-overlay .growthexperiments-homepage-module-footer should be 16px (not 17px)

Corrections due to my error in speccing (I have since updated the Figma file and task description):

7. Footer text should be in Base 20 colour (not Base10) - this is for both Desktop and Mobile
8. The background colours on Mobile should be the same as desktop, with Base90 under the main module content, and white on the footer

oops forgot to ping @mewoph - please see my above comment for tweaks and corrections. And please ask if anything is unclear.

Thanks @RHo! I'll use this task to track the changes for mobile details and desktop views and will use https://phabricator.wikimedia.org/T274820 to track changes to mobile summary view since I already have a patch open for that (will change the background colors for mobile summary there)

Change 667030 had a related patch set uploaded (by MewOphaswongse; owner: MewOphaswongse):
[mediawiki/extensions/GrowthExperiments@master] Update unactivated impact module styles for mobile details & desktop

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

Updated desktop:

Updated mobile details:

Change 667030 merged by jenkins-bot:
[mediawiki/extensions/GrowthExperiments@master] Update unactivated impact module styles for mobile details & desktop

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

@RHo - thanks to @mewoph for the screenshots posted above. Also I verified that all changes from your comments seem to be in place.
If all look ok to you, you may mark the ticket as Resolved.

@RHo - thanks to @mewoph for the screenshots posted above. Also I verified that all changes from your comments seem to be in place.
If all look ok to you, you may mark the ticket as Resolved.

Awesome, thanks both for the changes and checks, looks great!