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?

In T264460#6778624, @kostajh wrote:

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?

In T264460#6781508, @MMiller_WMF wrote:

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.

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.

In T264460#7564401, @Tgr wrote:

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)?

In T264460#7567692, @Tgr wrote:

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

In T264460#7570232, @mewoph wrote:

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

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

In T264460#7570608, @RHo wrote:

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

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

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

In T264460#7572732, @Sgs wrote:

In T264460#7570608, @RHo wrote:

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

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

Portrait max-width: 28.75em

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

Portrait width: 50%

Landscape width: unset

Portrait width: unset

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:

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

Mobile

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

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

Checked in betalabs

• works as expected in terms of functionality (T299742: Mobile suggested edits module does not work when zero tasks are available in filters has a patch)

mobile	mobilenarrow screen	mobile landscape position

Tablet:

Zero suggested tasks:

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	Selecting first task goes to the SE module (instead of directly to the article)

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

In T264460#7666008, @RHo wrote:

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	Selecting first task goes to the SE module (instead of directly to the article)

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	Tablet

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

@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

In T264460#7681755, @Sgs wrote:

@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.
2. Add navigation arrows to allow users to look at tasks directly from the edits module.	(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 T264460#7666008, @RHo wrote:

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

Mobile	Tablet

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

@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?