We could do this by adding the link in the message for the privacy policy. We designate which message key to use in the 'privacyPolicy' value within config.

Hey @aminalhazwani who do you need review from in this task?

From the engineering standpoint all of them should be feasible.

For the pop-up I would reuse an OOUI popup if that is a thing rather than making a new one.

The first one where the link is in the footer text is the easiest since I believe it would not need any changes to the code base. That text and link are a message you configure when deploying the survey.

Hey @aminalhazwani who do you need review from in this task?

I was looking for general feedback on the proposals but know that you ask it was worth being more precise with my request, thank you for being proactive and sharing your input on engineering feasibility.

I did a second iteration on the proposals and I am going to summarize the pros and cons.

Proposal	Pros	Cons
Add an additional link to the meta page of the survey next to the link to the privacy statement	Easy implementation engineering-wise.	Users need to leave the page to find out more. Smaller text at the bottom is usually identified as not so useful legal text. The working might also need to be more self explanatory: what am I going to find on this "meta page"?
Display an info button next to the survey question	Additional information is immediately accessible and contextual.	Interaction might be not be explicit even if the info button is an established design pattern. Implementation is more complex, eg. hover vs touch interaction with a small input area.
Display an info button next to the privacy statement	Secondary information is provided as a secondary interaction.	Interaction is less obvious as the info icon can feel like a simple signifier for the footer text.

With all things consider I would lean for the second option, which is adding a second button next to the survey title/question. Is this feasible in the current scope @Madalina? If yes we could create a shared task with the GDI team for this additional texts.

Option A: I have a small concern around the "meta page". Will this be translated in multiple languages? If the users leave the page, is there a risk of them not taking the survey?
Option B: This looks like best option depending on the complexity of the implementation
Option C: Also concerned that users might not understand what to do with the info button

To answer your question @aminalhazwani, we should estimate/investigate how complex implementation of Option B might be from an engineering point of view.
Push come to shove, my instinct is to go for Option A with just the privacy statement and get some user feedback.

Thoughts/question on Option A: Do the links pop open a new window or link within the current window?

If it links within the current window, we could experience loss of respondents; However, if they return to the language-sitename they were originally on while the survey is still running it should reappear on whatever page they visit next (unless they opted out by clicking X, which is fine, or cleared their browser cookies between getting the survey, visiting the link, and returning to the site, but we can't control for that). If they choose to opt out after reading the meta page, then that is okay - we don't want someone responding who wouldn't have consented to respond if they were informed of the details of the survey.

The meta page will need to be translated; GDI will send it for community translation as soon as the text is complete and we figure out which languages we're baseline/piloting with.

My tendency would be to try and include the meta page if we can, as that's where we'll get user feedback through the Talk page, specifically if someone does not want to answer the survey but does want to comment on it, and have information about what we mean by unsafe/uncomfortable. The privacy page is required but is usually a legal form that does not provide much detail (see example: https://foundation.wikimedia.org/wiki/Legal:Performance_Perception_Survey_Privacy_Statement)

Push come to shove, my instinct is to go for Option A with just the privacy statement and get some user feedback.

@Madalina I agree, let's go for option A for now.

Regarding your question on users potentially leaving the page, yes there's a risk of them not taking the survey. To answer also @TAndic's question the current link behavior lets user decide if they want to open a link in the same page or in a new tab (we don't force links to be open in a new tab with code via the target="_blank" attribute). So if they would simply click or tap the link it would open the destination in the same tab. If they ctrl/cmd+click, right click+open in a new tab/window, or long press to open in a new tab on mobile, then yes, the destination would be in a different tab.

I updated the description on T292416: Safety Perception Survey: in-product experience with QuickSurvey so that we can see the full user flow. If we all agree we could put this task back to the backlog and do a second evaluation after having collected some user feedback.

Thanks @aminalhazwani ! Agreed on my side.

@Madalina we can move this task back to the backlog, cheers!

We had a couple more conversations about this and it looks like option B might be doable. So let's go ahead with B.

We are discussing this task in the engineering meeting. Some outstanding questions:

• Whether Option A is the best for the user as the info window obscures the questions.
• How we would signify the tooltip should be included (maybe a span class), and then also how to add the translation key (likely as a config value).
• How to use OOUI.js when we aren't currently using it in QuickSurvey.

@Madalina mentioned that with option B we'd need translation for the meta page, and risk losing the uer.

What happens with the translation? Could use tooltip [do we have access to jquery ?] - Is there a generic default? The privacy page is required but is usually a legal form that does not provide much detail (see example: https://foundation.wikimedia.org/wiki/Legal:Performance_Perception_Survey_Privacy_Statement)
Is there a generic default for 'meta page' OR SHOULD THERE BE ONE?
Is this meta page optional or required for each quick survey?
maybe something like

name: 'meta-page-test-survey',
	answers: [
		{ key: 'yes', label: 'Yes' },
		{ key: 'maybe', label: 'maybe' },
                { key: 'no', label: 'no' }
	],
	thankYouMessage: 'thank you come again',
	shuffleAnswersDisplay: false,
	freeformTextLabel: 'something',
	instanceTokenParameterName: 'uniquetoken',
	question: 'Is this gonna work?',
	isMobileLayout: false,
	surveySessionToken: 'ss',
	pageviewToken: 'pv',
         // default is false -if false, go to default meta page if available 
        // OR is no qsMetaPageData, then show default - just depends                               
        qsMetaPageRequired: 'false', 
       // string containing display, not sure if html/css markup available
        qsMetaPageData: 'Now is the time for all good folk to come to the aid of their country'

With qsMetaPageRequired - that is probably overkill, but don't know how granular we need to be on this
qsMetaPageData would contain the meta page text

title and body text - nice if can use html tags...

cannot use html tags in string values of keys
qsMetaPageTitle: 'Meta Title' if bold title becomes <strong>30 days</strong>
qsMetaPageData: "Now is the time for <span style='color: red;'>all good folk</span>to come to the aid of their country"

Maggie Epps 10:11 AM
we might want to add a config value that, when true, adds this popup html,
re: qsMetaPageRequired: 'false',
Jason Sherman 10:11 AM
the other thing we could do is add additional optional strings and update the template to use it conditionally

extensions/QuickSurveys/includes/Survey.php -> add key for metaPageHead and metaPageBody saying that page present or not, parameter in __construct( add metaPageHead and metaPageBody with default of empty string), add $this->metaPageHead = qsmetaPageHead to construct title, and $this->metaPageBody for string containing message body
in Survey.getMessages()

	/**
	 * Gets the list of i18n message keys that the survey uses
	 *
	 * @return string[]
	 */
	public function getMessages(): array {
		$messages = [
			$this->question,
		];

		if ( !empty( $this->description ) ) {
			$messages[] = $this->description;
		}

		if ( !empty( $this->privacyPolicy ) ) {
			$messages[] = $this->privacyPolicy;
		}

               // new section
               if ( !empty( $this->metaPageHead ) ) {
			$messages[] = $this->metaPageHead ;
		}

                if ( !empty( $this->metaPageBody ) ) {
			$messages[] = $this->metaPageBody ;
		}
		return $messages;
	}

extensions/QuickSurveys/includes/Survey.php

remember - add metaPageHead and metaPageBody to class, or maybe no:

	/**
	 * @var string|null header or title to meta page
	 */
	private $metaPageHead ;

	/**
	 * @var string|null string containing body of metaPage text
	 */
	private $metaPageBody ;

extensions/QuickSurveys/includes/Survey.php

public function toArray(): array {
	return [
		'audience' => $this->audience->toArray(),
		'name' => $this->name,
		'question' => $this->question,
		'description' => $this->description,
		'module' => $this->getResourceLoaderModuleName(),
		'coverage' => $this->coverage,
		'platforms' => $this->platforms,
		'privacyPolicy' => $this->privacyPolicy,
                        
                 //new
                 'metaHead' =>$this->metaPageHead,
                 'metaBody' = >$this->metaPageBody
	];
}

extensions/QuickSurveys/i18n/en.json

add keys and values, example:

"ext-quicksurveys-metaPageHead": "Meta Title",
"ext-quicksurveys-metaPageBody": "String containing meta page body",

Whether Option A is the best for the user as the info window obscures the questions.

How we would signify the tooltip should be included (maybe a span class), and then also how to add the translation key (likely as a config value).

How to use OOUI.js when we aren't currently using it in QuickSurvey.

Is Option A the best for the user (as the info window obscures the questions)?
maybe, really I am not sure about this as it seems to be a designer question - but ability to place window will be dependent on library script library used

How do we signify the tooltip should be included (maybe a span class), and then also how to add the translation key (likely as a config value)?
need image for clicking (in ooui library) update WikimediaMessages, en.json file, then playing with the front end for the JavaScript to display data

How do we use OOUI.js when we aren't currently using it in QuickSurvey?
we are not sure, may be able to just add it after other JavaScript libraries, would have to test. maybe will need to rewrite the view layer, some css to make the buttons correct size - Jason, Essex and Ellen discussed and believe that this is probably another spike, concerning what would need to happen to bring in OOUI.js and the ramifications on the code base

Is Option A the best for the user (as the info window obscures the questions)?

Happy to chime in here. In order to build an argument we have to take context into consideration. What is the context in which a user might open this pop-up dialog? They probably already read through the survey, but they are still unsure about the intent and scope of such survey. They want to learn more, but without having to leave the page for finding an answer on their own. We have to acknowledge that the survey is being displayed to them hence potentially interrupting their original intent and navigation flow. That's where the info button comes into play. It's a standard pattern that is being used to incrementally reveal more contextual information only when users want to. If a user is purposely opening the dialog we can assume that is fair if some of the survey content is hidden behind it.

Greetings, I would like to provide some feedback here based on the meeting Ellen, Jason and I had regarding the same. From what I recall, we all agreed that we would

1. Need to find out if OOUI could work alongside our current library -> thus making a refactor minimal. We would/could create a new component that imports the tooltip library.
2. Perhaps create a POC to flesh look at the usability and complexities of implementing Option A or B. The POC could also verify the aforementioned bullet point.
3. Mock up pseudo-code of the Vue component
4. Verify what pages would/will be impacted by this effort.

from @jsn.sherman and @essex

1. Library in question is wvui
2. Proposal to make a new component and try including it.

@Scardenasmolinar says OOUI does server side rendering. wvui will be deprecated eventually.

@jsn.sherman Not much wvui code to begin with, as it mostly uses pure vue. Would it be a small migration from wvui to OOUI?

@ERayfield there may be a tooltip availalble.

Vue migration to OOUI js guide

General OOUIjs guide

OOUIjs demo

Review: This looks like a thorough investigation to me!

@aminalhazwani this should be ready for you to look at!

If we would decide to add the pop-up dialog I would also lean towards adding the OOUI component since it already includes styles for RTL languages, accessible markup and keyboard navigation. While if we decide to pursue stand alone JS I would rather make a contribution to Codex instead of developing a bespoke component for QuickSurvey only.

Onto you @Madalina!