Page MenuHomePhabricator

[SPIKE] Assess risk for various quicksurvey improvements
Closed, ResolvedPublic

Description

Questions to answer

  • What is the relative difficulty of adding a free-form text option to a survey. Example survey

Question 1: What is a survey

  • answer one
  • answer two
  • other: _______
  • What is the relative difficulty of presenting two questions with a "next" button?

Question 1: What is a survey?

  • answer one
  • answer two
  • answer three

link: next
Question 2: What is not a survey?

  • answer one
  • answer two

Guidelines for next steps

The following guidelines were discussed by the team and should be carefully considered in next steps:

  • New functionality added should be well tested
  • Minimize changes. Readers Web does not have much bandwidth to maintain this extension so every effort to minimize code paths should be made. For instance, if a freeform text option is added and a radio form is used, all surveys should use the radio form presentation regardless of whether they include a freeform text.

Event Timeline

ovasileva triaged this task as Medium priority.May 29 2019, 10:04 AM
ovasileva moved this task from Incoming to Needs Prioritization on the Web-Team-Backlog board.

I've started looking into this today. Just wanted to post a status update to avoid straying too far off course:

What is the relative difficulty of adding a free-form text option to a survey. Example survey

The survey uses OOUI and currently presents three buttons:

localhost_8181_wiki_Foo (1).png (732×600 px, 55 KB)

I am currently exploring replacing those buttons with a radio selection and submit button:

localhost_8181_wiki_Foo.png (802×600 px, 62 KB)

I am thinking that radio selection (with or without a text input) would be the only mode supported going forward.

Niedzielski added a subscriber: pmiazga.

@ovasileva, we're bringing this onto the board since I had started looking into this. @pmiazga noted it was in needs analysis so I apologize if answering the questions was intended for a later date. Please let me know if you'd like me to stop.

What is the relative difficulty of adding a free-form text option to a survey. Example survey

If we can pursue a consistent presentation no matter the question type (free-form or fixed), I think this should be reasonable UI change and config change. The former is discussed in the preceding comment, the latter may use a special key in the answer config. E.g., instead of:

...,
"answers": [
	"ext-quicksurveys-example-internal-survey-answer-positive",
	"ext-quicksurveys-example-internal-survey-answer-neutral",
	"ext-quicksurveys-example-internal-survey-answer-negative"
],
...
...,
"answers": [
	"ext-quicksurveys-example-internal-survey-answer-positive",
	"ext-quicksurveys-example-internal-survey-answer-neutral",
	"ext-quicksurveys-example-internal-survey-answer-negative",
	"ext-quicksurveys-example-internal-survey-answer-freeform"
],
...

In the JavaScript, we can use the message value of ext-quicksurveys-example-internal-survey-answer-freeform to provide the text input hint and the key name to indicate type.

What is the relative difficulty of presenting two questions with a "next" button?

I think there are two primary challenges to adding this functionality:

  1. How will the UI change?
  2. How will the config change?

There are a number of OOUI layouts that would work fine for the presentation, depending on which is wanted. Here are some examples:

We could even launch a dialog on button press, such as the booklet dialog. I don't recommend it though since the dialog approach would probably want some distinction from single question surveys.

Anyway, I think this is doable but will require some OOUI and QuickSurvey expertise.

For the config change, I think that's going to be more work. This would most likely be a breaking change so that we could associate the a group of answers per question. E.g., instead of:

{
...
	"@question": "survey question message key",
	"question": "ext-quicksurveys-example-internal-survey-question",
	"@description": "The message key of the description of the survey. Displayed immediately below the survey question.",
	"description": "ext-quicksurveys-example-internal-survey-description",
	"@answers": "possible answer message keys for positive, neutral, and negative",
	"answers": [
		"ext-quicksurveys-example-internal-survey-answer-positive",
		"ext-quicksurveys-example-internal-survey-answer-neutral",
		"ext-quicksurveys-example-internal-survey-answer-negative"
	],
...
}

Something like:

{
...
	"form": [ {
		"@question": "survey question message key",
		"question": "ext-quicksurveys-example-internal-survey-question",
		"@description": "The message key of the description of the survey. Displayed immediately below the survey question.",
		"description": "ext-quicksurveys-example-internal-survey-description",
		"@answers": "possible answer message keys for positive, neutral, and negative",
		"answers": [
			"ext-quicksurveys-example-internal-survey-answer-positive",
			"ext-quicksurveys-example-internal-survey-answer-neutral",
			"ext-quicksurveys-example-internal-survey-answer-negative"
		] }, {
		"@question": "survey question message key",
		"question": "ext-quicksurveys-example-internal-survey-question",
		"@description": "The message key of the description of the survey. Displayed immediately below the survey question.",
		"description": "ext-quicksurveys-example-internal-survey-description",
		"@answers": "possible answer message keys for positive, neutral, and negative",
		"answers": [
			"ext-quicksurveys-example-internal-survey-answer-positive",
			"ext-quicksurveys-example-internal-survey-answer-neutral",
			"ext-quicksurveys-example-internal-survey-answer-negative"
		] }
	]
...
}

As mentioned, this would be a breaking change for any existing configuration and would also require test, UI, and documentation changes in itself. It's worth also calling out the associated with breaking config change due to existing users and existing functionality.

My apologies but I'm not quite sure what to do with this resolved spike. I propose:

  1. I'm going to leave this assigned to me for the present but moved to code review.
  2. We'll discuss this in next standup and I'll request a volunteer to walk through this feedback hopefully in 15-30 minutes.
  3. The volunteer will yay / nay the reasoning.
  4. If nay, I'll address the issues identified. If yay, I'll move to sign off and assign to @ovasileva for determining what, if any, tasks are worth pursuing and creating.

I'm happy to do some other process with this as well, just let me know

My apologies but I'm not quite sure what to do with this resolved spike. I propose:

  1. I'm going to leave this assigned to me for the present but moved to code review.
  2. We'll discuss this in next standup and I'll request a volunteer to walk through this feedback hopefully in 15-30 minutes.
  3. The volunteer will yay / nay the reasoning.
  4. If nay, I'll address the issues identified. If yay, I'll move to sign off and assign to @ovasileva for determining what, if any, tasks are worth pursuing and creating.

I'm happy to do some other process with this as well, just let me know

Thanks for all your work here @Niedzielski! I spoke to @leila about this task and learned that @bmansurov will be able to make the changes if we're available for code review. Let's discuss during standup. I think the best next step might be for @bmansurov to review the approach and we can collaboratively create the tasks afterwards.

Niedzielski updated the task description. (Show Details)
Niedzielski subscribed.

@bmansurov it would be great if you can prioritize this task on your end. That can unblock us from achieving the goal we set for this quarter and help us get a better sense of editor gender distributions. :)

The results of the spike look good to me.

@leila we're interested in the free form version of the spike only, am I right? Is the two step version of the survey outside the scope of the work we want to do?

@bmansurov correct. currently the first question in the task description. (being able to add an "other" option with a free form text box in front of it where the respondent can enter text in.)

@Niedzielski in T224552#5226564 were you able to generate the text input inside the radio option? Or is it just a mock? Text input doesn't seem to extend the OptionWidget in OOJS UI.

@bmansurov, I changed the existing ButtonSelectWidget container with RadioSelectWidget.

For the freeform text input, I think you can supply a TextInputWidget as a label:

return new OO.ui.RadioOptionWidget( {
  label: new OO.ui.TextInputWidget( { placeholder: mw.msg( answer ) } ),
  data: { answer: answer }
} );

There is an exact example in the demos but it seems a little broken as it doesn't accept text.

For the old fixed text buttons, I replaced ButtonOptionWidget with RadioOptionWidget.

I don't know much OOUI so I used the following references:

By the way, I recommend creating a new and clarified task (or updating this one) if you're starting implementation to avoid potential confusion

@bmansurov, perfect! Do you think it is ok to close this task or is more work needed?

bmansurov claimed this task.

All is good. I like closing tasks, so I'll close this one. Hope I'm not departing from your team's norms.