Page MenuHomePhabricator

Enable users to open the first suggested article directly from the mobile task preview
Closed, ResolvedPublic

Assigned To
Authored By
RHo
Oct 2 2020, 6:05 PM
Referenced Files
F34944198: image.png
Feb 7 2022, 1:01 PM
F34944202: image.png
Feb 7 2022, 1:01 PM
F34939802: image.png
Feb 1 2022, 5:59 PM
F34939805: image.png
Feb 1 2022, 5:59 PM
F34938686: image.png
Jan 31 2022, 11:13 PM
F34938688: image.png
Jan 31 2022, 11:13 PM
F34926222: Screen Shot 2022-01-21 at 3.36.49 PM.png
Jan 22 2022, 12:16 AM
F34926231: Screen Shot 2022-01-21 at 4.05.21 PM.png
Jan 22 2022, 12:16 AM

Description

Problem
There is a conflict in user expectations as the current paradigm for mobile module previews is that each entire preview is one tap-target to open the corresponding module; but the new task preview card provides contains elements that leads users to expect two separate destinations – one on the inset article preview card to open the article for editing, and the other to open the the task module.
Note that this was the expectation of some participants in a recent Add links usability study.

Proposed solution
Split the task preview module into two cards with separate targets when there are non-zero Suggested edit articles.

image.png (546×874 px, 143 KB)

Notable changes from existing design:
a. Header changes from Suggested edits to the count of tasks text 1 of {total number} suggested edits
b. Remove the icon from the module preview header
c. Move the CTA button to view all suggested edits below and outside of the card, and make it full width. It links to the task module
d. The top card links to the article suggested.

NOTE: When no articles are found, the existing generic SE card with the single CTA on the whole card is shown instead.
image.png (1×790 px, 166 KB)

Event Timeline

Would this need any instrumentation changes? Off the top of my head, I don't think so -- we would instrument tapping the article card in the same way as if the user was on the suggested edits module overlay, right?

Would this need any instrumentation changes? Off the top of my head, I don't think so -- we would instrument tapping the article card in the same way as if the user was on the suggested edits module overlay, right?

I would mainly be interested in comparing interactions from and percentage of successful edits from those that enter the article from this preview card vs the suggested edits module overlay. If we can distinguish with existing instrumentation that seems OK. Does that sound right, @nettrom_WMF and @MMiller_WMF ?

Yes, @kostajh, as long as we can tell that the click happened from the summary page instead of the details page, then we will be good. Is that possible?

Yes, @kostajh, as long as we can tell that the click happened from the summary page instead of the details page, then we will be good. Is that possible?

Yes, we can do that.

kostajh renamed this task from [Leftovers] Variant C/D: Enable users to open the first suggested article directly from the mobile task preview to Enable users to open the first suggested article directly from the mobile task preview.Apr 20 2021, 9:26 AM

Change 743494 had a related patch set uploaded (by Sergio Gimeno; author: Sergio Gimeno):

[mediawiki/extensions/GrowthExperiments@master] [WIP] Suggested edits: open the first article from mobile task preview

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

I'm working on the issue and I'm finding difficult to figure out which is the best way to modify the link and HTML construction.

The reason is that prior to this requirement and as far as I can tell all modules rendered in Special:Homepage with RENDER_MOBILE_SUMMARY + RENDER_MOBILE_DETAILS supported modes would have a wrapping link added to the full HTML content. See https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/extensions/GrowthExperiments/+/master/includes/Specials/SpecialHomepage.php#304.

/**
	 * @param IDashboardModule $module
	 */
	private function renderMobileDetails( IDashboardModule $module ) {
		$out = $this->getContext()->getOutput();
		$out->addBodyClasses( 'growthexperiments-homepage-mobile-details' );
		$html = $this->getModuleRenderHtmlSafe( $module, IDashboardModule::RENDER_MOBILE_DETAILS );
		$this->getOutput()->addHTML( $html );
	}

	/**
	 * @param string $moduleName
	 * @param string $moduleHtml
	 * @return string
	 */
	private function wrapMobileSummaryWithLink( $moduleName, $moduleHtml ) {
		if ( $moduleHtml ) {
			$moduleHtml = Html::rawElement( 'a', [
				'href' => $this->getPageTitle( $moduleName )->getLinkURL(),
			], $moduleHtml );
		}
		return $moduleHtml;
	}

	private function renderMobileSummary() {
		$out = $this->getContext()->getOutput();
		$modules = $this->getModules( true );
		$out->addBodyClasses( 'growthexperiments-homepage-mobile-summary' );
		foreach ( $modules as $moduleName => $module ) {
			$html = $this->getModuleRenderHtmlSafe( $module, IDashboardModule::RENDER_MOBILE_SUMMARY );
			if ( $module->supports( IDashboardModule::RENDER_MOBILE_DETAILS ) ) {
				$html = $this->wrapMobileSummaryWithLink( $moduleName, $html );
			}
			$this->getOutput()->addHTML( $html );
		}
	}

Since the requirement in this task is to have 2 separate links in the same module preview block I think some of the current abstractions are not working well and some changes/refactor is needed.

In my opinion the link construction should be leveraged to the modules and make it configurable somehow, for instance with a class property in wrapMobileSummaryWithTitleLink in our BaseModule.

Another question is how to construct the full link href. I see this comment so I'm guessing the right separation of concerns would be for the module to receive the page URL ie: https://en.wikipedia.beta.wmflabs.org/w/index.php?title=Special:Homepage and then add the module (name, id?) as a suffix.

All feedback is welcome @kostajh @Tgr

While we're working on this, we could consider T264992: Remove mobile-details mode from Special:Homepage, though we should double check the instrumentation to assess its impact first.

And yes, we'll need some refactoring. We want something like:

  • A way to indicate that a module has a preview mode (for mobile) and a detail view (shown in the overlay)
  • a way to indicate if a module should have its preview area wrapped with a link to its detail view, or if it should not (i.e. for this task, suggested edits should not)

I think the easiest is to just move the link wrapping logic to DashboardModule::renderMobileSummary, and inject a base URL, as Sergio says. That would also get rid of the JS data generation hack.

I think the easiest is to just move the link wrapping logic to DashboardModule::renderMobileSummary, and inject a base URL, as Sergio says. That would also get rid of the JS data generation hack.

I finally moved the logic to BaseModule::buildModuleWrapper because it seemed convenient but let me know if you think it should live in DashboardModule::renderMobileSummary.

One thing I'm still missing is to differentiate the event tracking events. In an example link we use in the feed I can see geclickid=3722aqrmc62he3mthjrfrh66r99t1sne added coming from the page controller as 'wgGEHomepagePageviewToken' => $this->pageviewToken and set in the client which I have added but there is another parameter genewcomertasktoken=8acde8365832aae18906 which I can't find where it is coming from.

genewcomertasktoken is generated in SuggestedEditsModule.logCardData. It's just a random number to tie different EventLogging schemas together; could be generated anywhere else if that's more convenient.

Hi @RHo, should there be a maximum width for the "See all suggestions" button (mainly for tablet views)?

Screen Shot 2021-12-14 at 9.13.27 AM.png (1×2 px, 180 KB)

genewcomertasktoken is generated in SuggestedEditsModule.logCardData. It's just a random number to tie different EventLogging schemas together; could be generated anywhere else if that's more convenient.

In the server using MWCryptRand::generateHex( 20 ). If this is not an appropriate method please let me know

Hi @RHo, should there be a maximum width for the "See all suggestions" button (mainly for tablet views)?

Screen Shot 2021-12-14 at 9.13.27 AM.png (1×2 px, 180 KB)

Good catch @mewoph - can we should use the same button style that exists on Minerva (with max-width:28.75em)?

image.png (946×2 px, 179 KB)

Good catch @mewoph - can we should use the same button style that exists on Minerva (with max-width:28.75em)?

image.png (946×2 px, 179 KB)

This is how it would look on an iPad in portrait and landscape modes. The max-width: 28.75em is close to a 50% of the container width (without padding) on landscape mode but much more on landscape creating a bit of weird visual imo.

Landscape max-width: 28.75em

Screenshot 2021-12-15 at 16.44.13.png (1×2 px, 183 KB)

Portrait max-width: 28.75em
Screenshot 2021-12-15 at 16.43.17.png (2×1 px, 188 KB)

@RHo How about width: 50% on tablet devices? Or even an unsetwidth would just grow horizontally based on the text content
Landscape width: 50%

Screenshot 2021-12-15 at 16.52.54.png (1×2 px, 177 KB)

Portrait width: 50%
Screenshot 2021-12-15 at 16.53.04.png (2×1 px, 192 KB)

Landscape width: unset
Screenshot 2021-12-15 at 17.02.20.png (1×2 px, 199 KB)

Portrait width: unset
Screenshot 2021-12-15 at 17.02.10.png (2×1 px, 206 KB)

Good catch @mewoph - can we should use the same button style that exists on Minerva (with max-width:28.75em)?

image.png (946×2 px, 179 KB)

This is how it would look on an iPad in portrait and landscape modes. The max-width: 28.75em is close to a 50% of the container width (without padding) on landscape mode but much more on landscape creating a bit of weird visual imo.

Landscape max-width: 28.75em

Screenshot 2021-12-15 at 16.44.13.png (1×2 px, 183 KB)

Portrait max-width: 28.75em
Screenshot 2021-12-15 at 16.43.17.png (2×1 px, 188 KB)

@RHo How about width: 50% on tablet devices? Or even an unsetwidth would just grow horizontally based on the text content
Landscape width: 50%

Screenshot 2021-12-15 at 16.52.54.png (1×2 px, 177 KB)

Portrait width: 50%
Screenshot 2021-12-15 at 16.53.04.png (2×1 px, 192 KB)

Landscape width: unset
Screenshot 2021-12-15 at 17.02.20.png (1×2 px, 199 KB)

Portrait width: unset
Screenshot 2021-12-15 at 17.02.10.png (2×1 px, 206 KB)

Hi @Sgs - I agree it doesn't look so great on tablet, but wonder if this is mitigated by making the button centered in the layout as it is here on prod:

image.png (618×2 px, 97 KB)

My reasoning is that adding the max-width and centering it for everything is more straightforward than setting different widths for tablet vs mobile, but will defer to your opinion if you think it's about the same.
Here's how it looks though when I made it max-width:28.75em; width:100%; on the button and added display:flex; justify-content:center; on the container:

Tablet
image.png (1×2 px, 145 KB)
Mobile
image.png (1×786 px, 116 KB)

Change 743494 merged by jenkins-bot:

[mediawiki/extensions/GrowthExperiments@master] Suggested edits: open the first article from mobile task preview

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

Change 755945 had a related patch set uploaded (by Sergio Gimeno; author: Sergio Gimeno):

[mediawiki/extensions/GrowthExperiments@master] Suggested edits: generate task token from single place

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

Etonkovidova added a subscriber: Etonkovidova.

For @RHo review - if there is no follow-ups, please move it to Test in Production.

Checked in betalabs

mobilemobilenarrow screenmobile landscape position
Screen Shot 2022-01-21 at 3.39.27 PM.png (751×354 px, 56 KB)
Screen Shot 2022-01-21 at 3.36.49 PM.png (741×343 px, 68 KB)
Screen Shot 2022-01-21 at 4.10.52 PM.png (364×631 px, 39 KB)

Tablet:

Screen Shot 2022-01-21 at 4.05.21 PM.png (1×2 px, 628 KB)

Zero suggested tasks:

Screen Shot 2022-01-21 at 3.39.27 PM.png (751×354 px, 56 KB)

hiya @Etonkovidova and @Sgs - apologies if I missed something but I cannot see the changes on this task in cs betalabs, but only see the following:

SE preview
image.png (1×778 px, 136 KB)
Selecting first task goes to the SE module (instead of directly to the article)
image.png (1×744 px, 128 KB)

Is there a different environment I should be testing on? Thanks!

hiya @Etonkovidova and @Sgs - apologies if I missed something but I cannot see the changes on this task in cs betalabs, but only see the following:

SE preview
image.png (1×778 px, 136 KB)
Selecting first task goes to the SE module (instead of directly to the article)
image.png (1×744 px, 128 KB)

Is there a different environment I should be testing on? Thanks!

Oh scratch that, there was something funky happening on beta that is now fixed (T300591).

In design review on cs beta today 2022-02-01:

Mobile
image.png (478×742 px, 35 KB)
Tablet
image.png (450×1 px, 41 KB)

I do see just one design tweak which is to separate out the "View all suggested edits" button from the module as per the task mock and description:

c. Move the CTA button to view all suggested edits below and outside of the card, and make it full width. It links to the task module

image.png (546×874 px, 143 KB)

@Sgs - given this task has been hanging out in design review for a while (apologies), would you prefer to fix on this task or prefer I resolve this and create a new task?

Change 758458 had a related patch set uploaded (by Sergio Gimeno; author: Sergio Gimeno):

[mediawiki/extensions/GrowthExperiments@master] Newcomer task analytics: stop returning task.token from loggers

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

Change 758458 merged by jenkins-bot:

[mediawiki/extensions/GrowthExperiments@master] Newcomer task analytics: stop returning task.token from loggers

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

Change 755945 merged by jenkins-bot:

[mediawiki/extensions/GrowthExperiments@master] Suggested edits: generate task token from single place

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

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

[mediawiki/extensions/GrowthExperiments@master] Suggested edits: set this.newcomerTaskToken when showing EditCardWidget

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

Change 759518 merged by jenkins-bot:

[mediawiki/extensions/GrowthExperiments@master] Suggested edits: set this.newcomerTaskToken when showing EditCardWidget

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

@RHo I think you mentioned during the Add a link funnel meeting that this feature might introduce some analytics tampering. Could you elaborate it a bit here so we can help you thinking of solutions? Thank you

@RHo I think you mentioned during the Add a link funnel meeting that this feature might introduce some analytics tampering. Could you elaborate it a bit here so we can help you thinking of solutions? Thank you

Sure @Sgs. The Add a link funnel analysis indicates that particularly on mobile there is already a very high bounce rate from users selecting a task from the Suggested edits module and arriving on the article for editing (even before onboarding finishes loading) . This suggests a high number of people didn't intend to open the particular article task in the first place. As such, my concern is that this new change which enables a person to open the first suggested edit article directly from the homepage (without a choice) will exacerbate the bounce rate even more.
I have 2 current proposals to solve this problem (people inadvertently opening an undesirable task from the newcomer homepage):

1. Revert this change so that they have to go to the Suggested edits module first to choose an article.
image.png (494×760 px, 37 KB)
2. Add navigation arrows to allow users to look at tasks directly from the edits module.
image.png (618×918 px, 49 KB)
(indicative proposed design only)

If we decide to pursue option 2, I did still want the design fix from this task to be done whereby the "View all" button should be visually separate from the task preview module:

In design review on cs beta today 2022-02-01:

Mobile
image.png (478×742 px, 35 KB)
Tablet
image.png (450×1 px, 41 KB)

I do see just one design tweak which is to separate out the "View all suggested edits" button from the module as per the task mock and description:
c. Move the CTA button to view all suggested edits below and outside of the card, and make it full width. It links to the task module

image.png (546×874 px, 143 KB)

@Sgs - given this task has been hanging out in design review for a while (apologies), would you prefer to fix on this task or prefer I resolve this and create a new task?