Page MenuHomePhabricator

Help panel: provide ability to vary links by context
Open, Needs TriagePublic

Description

The help panel is a feature that allows newcomers to post questions directly to their wiki's help desk while they are in the middle of editing a page. The panel also provides a set of five recommended help links that are quite popular -- in wikis with the help panel between 40% and 50% of users who open the help panel click one of the links. The challenge is that different links are appropriate in different contexts. One might need different links in mobile vs. desktop, in wikitext vs. visual editor, for editing talk pages and editing articles, etc.


Per T209297#4770939 and T209297#4790781, we want the ability to vary links in the help panel by context. Context can be desktop or mobile, visualeditor or wikitext. Additionally, one could envision a desire to vary links by namespace, and if the user does not have edit rights to a protected page.

If a given wiki wants the same links to appear in all contexts they can set a "default" list.

I would suggest building this out via a configuration value, like:

$wgGEHelpPanelLinks = [
	'default_edit' => [
		'title' => 'Wikipedia:Tutorial/Editing',
		'display_text' => 'Editing tutorial'
		// 4 more links.
		// These links are used across all contexts unless they are
		// overridden below
	],
        'default_page_creation' => [
            // These links would be the default set show for page creation context.
        ],
        'protected' => [
            // These links would override the default_edit and default_page_creation, and be used across all contexts if 
            // the page is protected and the user does not have edit rights. 
        ],
	NS_MAIN => [
                'default_edit' => [ 
                     // same as default at root level, sets defaults for all contexts in this namespace 
                ],
                'default_page_creation' => [ 
                     // same as default at root level, sets default for page creation links for all contexts in this namespace 
                ],
                'protected' => [ 
                    // same as protected at root level, sets links for any protected page in this namespace
                ],
		'mobile' => [
			've' => [
				// 5 links
			],
			'wikitext' => [
				// 5 links
			],
		],
		'desktop' => [
			// same structure as mobile above
		]
	],
	NS_PORTAL => [
		// same as NS_MAIN above
	]
];

When the links are rendered in the help panel, we could consider appending query parameters to the URL such that they can be easily captured in event logging (T209982). For example Wikipedia:Tutorial/Editing in NS_MAIN on mobile VE might be output in the help panel as /wiki/Wikipedia:Tutorial/Editing?platform=mobile&editor=ve&namespace=1. This way we don't have to try to reconstruct the context in the event logging code that captures clicks on the help panel links.

Event Timeline

kostajh updated the task description. (Show Details)
kostajh removed a project: Epic.
MMiller_WMF renamed this task from Provide ability to vary links by context to Help panel: provide ability to vary links by context.Dec 4 2018, 11:05 PM

Consider varying links for creating new page vs. editing an existing page. (Proposed by @Trizek-WMF in the instrumentation specification document)

@MMiller_WMF in standup you mentioned that we decided not to allow "protected" context links, but I had a different understanding. My understanding of the contexts we want to provide support for is in the body of this task, plus Benoît's idea about "creating-new-page" context (default is regular edit).

@kostajh -- sorry for the confusion. We do want to be able to support different links for the protected page context. I think maybe it was that we were talking about whether to allow the help panel in those situations (with or without different links), and we do want to.

Alternative structure suggested by @SBisson

$linksConfig = [
	[
		'links' => [
			[ 'title' => 'Foo', text => 'Foo' ],
			[ 'title' => 'Bar', text => 'Bar' ],
		],
		'criteria' => [
			'platform' => 'mobile', // 'mobile', 'desktop', '*'
			'editor' => 'visual' // 'visual', 'source', '*'
			'protected' => true, // true, false, '*'
			'action' => 'new', // 'new', 'edit', '*'
		]
	],
	[
		'links' => [
			[ 'title' => 'Foo', text => 'Foo' ],
			[ 'title' => 'Bar', text => 'Bar' ],
		],
		'criteria' => [
			'platform' => 'mobile', // 'mobile', 'desktop', '*'
			'editor' => 'visual' // 'visual', 'source', '*'
			'protected' => true, // true, false, '*'
			'action' => 'new', // 'new', 'edit', '*'
		]
	]
];

(I know this has been agreed on while ago... but want to voice a different opinion)

Most wiki people usually have no idea how to fix the config values, and SWAT is usually time-consuming and cause more bureaucracy than just editing MW pages. (You have to get a SWAT slot, and need to be available on an evening or even after 1 AM [depending on DST, it can be 2 AM since we do not observe DST] for kowiki people's timezone.
If this is wiki-page? Just get an admin/interface-admin on local, or steward (if there are no A/IA) fix it. I hope this can be transferred to the on-wiki page at some point.

+1 @revi. Maybe we don't need that for now, but if the feature is deployed on more/all wikis, we will definitely need a way to just edit Mediawiki interface messages.

We now have links that actually vary by context, per T209297, so this is something we will want to work on.

Change 488929 had a related patch set uploaded (by Sbisson; owner: Sbisson):
[mediawiki/extensions/GrowthExperiments@master] [wip] Help panel: vary links by context

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

@MMiller_WMF, @Catrope and I met to discuss this.

From Marshall's perspective, he'd like a list of default links and then the ability to override them per context. Marshall is not opposed to maintaining verbose configuration with duplicated links/labels across multiple contexts.

One concern in implementing this feature is how the configuration is going to be managed. As noted in this task, there is a desire to move configuration into on wiki (e.g. Mediawiki:HelpPanelLinks). We could envision a three column layout, column A for title, column B for label, column C for "context", containing data like platform=*,editor=ve,action=*,namespace=2,3. We'd have to provide some documentation at the top of the wiki config page to make it clear how this should all work.

A few open questions before we proceed much further with this work:

  • We haven't done analysis on which links are clicked or what users do after clicking links
  • We don't yet know how search will impact the need for per-context help links
  • We aren't sure of all the possible contexts we care about

We also talked about how it would make sense to implement on-wiki configuration of the existing set of help links before adding the more complicated configuration for varying by context. A task for this does not AFAICT yet exist, but @MMiller_WMF could create one and schedule it.

I believe our conclusion was to put this back in Upcoming Work until the on-wiki config is implemented. For now, we have some useful code from Stephane with an implementation of how this could work, and we've also talked through some of the challenges of this.

kostajh moved this task from Inbox to Upcoming Work on the Growth-Team board.

One concern in implementing this feature is how the configuration is going to be managed. As noted in this task, there is a desire to move configuration into on wiki (e.g. Mediawiki:HelpPanelLinks). We could envision a three column layout, column A for title, column B for label, column C for "context", containing data like platform=*,editor=ve,action=*,namespace=2,3. We'd have to provide some documentation at the top of the wiki config page to make it clear how this should all work.

Please do not try to define a custom format for storing key-value data. Instead, please use something already defined and widely accepted by the tech community (both wiki and non-wiki), like JSON (we already have a content model for pages containing JSON, I am pretty sure that means it's possible to get a PHP associative array directly, however, I'm not sure). Using JSON for storing those data will make understanding (for sysops) how the data should be modified a way easier. Also, it will mean you won't need to implement some behavioir for cases the page won't be in correct format, since it's impossible to store something that's not valid JSON to a page with JSON as its content model.

Instead, please use something already defined and widely accepted by the tech community (both wiki and non-wiki), like JSON (we already have a content model for pages containing JSON, I am pretty sure that means it's possible to get a PHP associative array directly, however, I'm not sure).

Hi @Urbanecm, thanks for the suggestion! JSON definitely has a number of advantages. I had considered it but wasn't sure if it would be acceptable to communities who would need to keep this up to date. Could you point me to an example where a Mediawiki namespace page is using JSON to maintain configuration for a public facing tool?

Follow up from yesterday's comments, we also talked about a different approach of using categories to annotate which pages should appear in the help panel links section. The challenges here would be (1) this can't be restricted to admins, (2) we can't easily use custom labels, (3) we'd have to figure out how to include pages that are not on the target wiki (i.e. kowiki help panel has a link to a help page on mediawiki.org). I don't think we'd go this route but documenting the idea here anyway.

Instead, please use something already defined and widely accepted by the tech community (both wiki and non-wiki), like JSON (we already have a content model for pages containing JSON, I am pretty sure that means it's possible to get a PHP associative array directly, however, I'm not sure).

Hi @Urbanecm, thanks for the suggestion! JSON definitely has a number of advantages. I had considered it but wasn't sure if it would be acceptable to communities who would need to keep this up to date. Could you point me to an example where a Mediawiki namespace page is using JSON to maintain configuration for a public facing tool?

Not sure about definition of a public facing tool, but Citoid uses it, see MediaWiki:Citoid-template-type-map.json.

Follow up from yesterday's comments, we also talked about a different approach of using categories to annotate which pages should appear in the help panel links section. The challenges here would be (1) this can't be restricted to admins, (2) we can't easily use custom labels, (3) we'd have to figure out how to include pages that are not on the target wiki (i.e. kowiki help panel has a link to a help page on mediawiki.org). I don't think we'd go this route but documenting the idea here anyway.

Looks horrifying. I don't think we have a cat that's configuring how the sw behaves.

Change 488929 abandoned by Sbisson:
[wip] Help panel: vary links by context

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

Not sure if the team has scheduled working on this, but since I was told to be bold, I'm boldly adding Wikimedia-Hackathon-2019, since I consider this as a good project for it.

Yes, this could be a good one for the hackathon, but let's make sure to consider it alongside of T215911: Help panel: Manage help panel links on wiki

That task may need some design input. At the moment, not everyone understands that concept of namespaces and have minks varying may be confusing. So namespaces, or the reason why the links have changed, should be explained at some point in the panel.

I think this is more implementable now that we have Special:EditGrowthConfig, though it's an open question to me of how many help link variants (mobile? VE/wikitext? namespace?) are actually needed.

It would also be cool to implement this with T211513: Help panel: show search link content and help link content inside help panel, though they don't need to be done at the same time, of course.

I mentioned this here at en-WP VPT. It'd be very nice if this could be implemented in a way that'd apply beyond just the help panel, since there are situations where we want to differentiate between e.g. source editor and VE beyond there. There are some presently existing templates like {{If mobile}} that might work.