Page MenuHomePhabricator

Retool quicksurveys so we can do a survey on one page only
Closed, DuplicatePublic

Description

I was asked if it was possible to run a survey on Special:RecentChanges to see how people use that feature.
This could mostly be configured via the following:

$wgQuickSurveysConfig[] = array(
	// Survey name
	'name' => 'rc-questionairre',
	// Internal or external link survey
	'type' => 'external',
	// Survey question message key
	'question' => 'ext-quicksurveys-recent-changes-question',
	'description' => 'ext-quicksurveys-recent-changes-description'
	// Possible answer message keys for positive, neutral, and negative
	// Which schema to log to
        'url' => 'http://url to survey...',,
	// Percentage of users that will see the survey
	'coverage' => '100',
	// Is the survey enabled
	'enabled' => true,
	// For each platform (desktop, mobile), which version of it is targeted (stable, beta, alpha)
	'platform' => array(
		'desktop' => array( 'stable' ),
		'mobile' => array( 'stable', 'beta' ),
	),
);

If we added an additional field "pages" field we could add the following configuration option to the survey to allow it to only run on this page.

"pages": ["Special:RecentChanges"]

This would be generic and powerful for many people that want to run surveys.

See also:

Event Timeline

jmatazzoni renamed this task from Should be possible to run page specific quicksurveys to Retool quicksurveys so we can do a survey on one page only .Sep 23 2016, 8:51 PM
jmatazzoni added subscribers: Catrope, dchen, Pginer-WMF.

@Catrope, please see @Jdlrobson's suggestion for how to rework Quicksurveys. It currently works on all pages of the site and needs some tweaking to enable us to just survey RecentChanges. Does this look like something we could do without too much trouble?

Meanwhile, Jon, can you point me to a mockup or example where I can see what a QuickSurveys survey looks like? I want to see what the experience is. Thanks.

This looks easy to do. Let's first figure out what QuickSurveys looks like and whether we want to use it.

@Jdlrobson - looking for some background on quicksurveys, found this: https://www.mediawiki.org/wiki/Extension:QuickSurveys but not much else

I should also clarify currently quick surveys do not show if one of the following is true:

  • you are viewing the main page
  • you are viewing a non-article page
  • do not track is enabled

I would expect this change would override the first 2 bullet points. Up to this point we've only needed to do surveys for readers.

Any other changes you need to make to make quick surveys useful for your team are welcomed - we want to make this as generic and useful as possible.

Desktop:

Screen Shot 2016-09-26 at 20.16.53.png (680×1 px, 387 KB)

Mobile:

Screen Shot 2016-09-26 at 20.16.34.png (685×1 px, 294 KB)

Are those screenshots, or mockups? Of what?

EDIT: Never mind, they're screenshots of what Jon linked to.

A few questions:

  • This survey is meant to appear on RecentChanges, which has a pretty different structure than the page pictured below. Is that a problem?
  • Where does the page below link you two? Do you have a mockup that shows our internal survey tool? (Or do we have to design one?)
  • What we have in mind is a one-question survey. My goal was to show the actual survey right on the page, instead of linking to a survey page. Is that possible?
  • If we have to link to a survey page, what is the point of QuickSurvey? Why wouldn't we just use Qualtrics and skip the effort to reprogram QuickSurvey?

Screen Shot 2016-09-26 at 20.16.53.png (680×1 px, 387 KB)

@Jdlrobson, I have a number of questions, above. Most notably:

  • What we have in mind is a one-question survey. My goal was to show the actual survey right on the page, instead of linking to a survey page. Is that possible? Do you have an example of one?

If there's someone else who knows more about QuickSurvey please let me know who to be in touch with on this. thanks!

Jdlrobson edited projects, added Web-Team-Backlog (Tracking); removed Web-Team-Backlog.

Hi @jmatazzoni sorry for the late reply. Is this still needed? If so let's talk about this and work out what needs to be done!

In T146495#3392596, @Jdlrobson wrote:

Hi @jmatazzoni sorry for the late reply. Is this still needed? If so let's talk about this and work out what needs to be done!

The project I needed that survey for is long completed. But the principle of being able to target a survey to a single page that is not an article page (e.g., a tool page, like Recent Changes) is still very much desired by those of us who build tools for editors.

Which raises the question, what are the current capabilities re. targeting surveys? E.g., can you target to a specific page? To a specific namespace? To certain wikis? To users by experience level? To users who have just completed a specific action? Etc. Thanks!

Which raises the question, what are the current capabilities re. targeting surveys? E.g., can you target to a specific page? To a specific namespace? To certain wikis? To users by experience level? To users who have just completed a specific action? Etc. Thanks!

I believe that current capabilities of QuickSurveys are: to display only on specified wikis, for logged-out vs everyone (maybe vs logged-in only, but see T186737: Let me choose whether to present a survey to logged-in or logged-out editors) ...and maybe nothing else. I don't remember anyone being able to use any other features, although there is clearly interest in being able to filter by UI language, account age, user rights, etc.

I think it's possible to get information (e.g., IP addresses) that would allow you to infer certain things afterwards (e.g., for geolocation), but I don't think that you can specify that it should only display to IPs that geolocated to a certain area.

Ideally there should be a separate targeting extension that other extensions could be the clients of. It's not sane to continuously reinvent the same targeting capabilities in CentralNotice, QuickSurvey, EventLogging and who knows what else.

Ideally there should be a separate targeting extension that other extensions could be the clients of. It's not sane to continuously reinvent the same targeting capabilities in CentralNotice, QuickSurvey, EventLogging and who knows what else.

Like... Notifications? OK, this is a boutade, still I don't recall the specifics of why we just can't use that system for one-time kind of things (surveys, emergency communications, you name it). I do think logged out editors don't see/have them though.

Notifications is delivery, not targeting. In that case targeting is entirely up to the calling code. For surveys we don't want to write targeting code every time, we want an admin interface for the common cases where you can set that it should appear on namespace X, to users with less than N edits, from the G region. Notifications does not have anything like that; CentralNotice is the closest, although the interface is kind of terrible and it largely relies on handwritten unsanitized Javascript, so pretty terrible security-wise.

As for delivery, Notifications sends messages to users. (Logged-in users, yes, that's also a problem, although it will hopefully go away eventually with T133452: RFC: Create temporary accounts for anonymous editors.) That's no help for delivering an in-page survey.