Do not show the onboarding pop up again to the same user. Are we able to determine that for logged out users?

Yes, that would then be stored in a cookie.
The only problem with cookies is that they're not as strongly tied to a particular user: on shared computers, user A may have already clicked it away and user B won't see it anymore (probably not a big deal). Those browsing without cookies (incognito, other machine, wiped cookies) will see it again.

We should however determine when to get rid of this, though.
After some time, the intended audience (people who may already know search, but are not yet familiar with Quick View) will have been reached, and we should stop showing it, since it's only going to hinder new users (for who this message likely isn't particularly relevant), or annoy existing users who have already seen it (but continue to do so due to missing cookies)
Can someone figure out if & when we want to disable this thing & create a ticket for it?

Additional note: how about the "you can turn this off in Preferences" sentence?
Anonymous users don't have preferences.
Should we continue to show this sentence regardless? Should we show another message instead?

Moving to Needs Design since Seddon has some questions for Sneha on this. Seddon will chat with Sneha. Can move it to Ready for Development if there are no changes based on that discussion.

@CBogen I just saw this comment about questions Seddon had. I haven't had a chance to talk to him so not sure now if it can be moved.

@matthiasmullie I think we should leave the "you can turn this off in preferences" message for all users. If you are logged out, I suppose the user will be prompted to log in when they click on preferences. If the user has the account they can log in and access the preferences. If the user does not have an account, then it is still clear that to access this feature you need an account.

As for when should we get rid of this message, we should definitely create a new ticket for this. Good catch as the copy "Introducing Search Previews" won't be relevant in a few months time. I am not sure what would be the best time period for most users to have used the feature. It could be time based (e.g. 3 months), or we can turn it off when all our milestones are done or when we have enough data analytics to inform future decisions. Not sure which one would be the best approach. We can discuss this in design weekly. Other option is to change the title to something less introductory like "Opening Search Preview" and leave it for longer duration.

Not sure it should be an AC, but worth mentioning to whoever develops this that the code should be scoped and simple to be removed in the future. (we do not want classes and code scattered everyone, but a nice folder with all the info in it, so that in 3 month we can easily remove it.

In T311669#8267733, @SimoneThisDot wrote:

Not sure it should be an AC, but worth mentioning to whoever develops this that the code should be scoped and simple to be removed in the future. (we do not want classes and code scattered everyone, but a nice folder with all the info in it, so that in 3 month we can easily remove it.

Added to the AC, thanks @SimoneThisDot!

@SimoneThisDot @matthiasmullie @CBogen

Based on the discussion above, I am proposing we change the title (and as a result the icon) in the onboarding popup so that it can be shown a few months later too to new users coming to search page. It allows us to leave it on beyond what may be considered "new feature update". Below is a mock. Let me know if you have any comments or else I would like to update the AC if its still possible to do so.

In T311669#8273874, @Sneha wrote:

@SimoneThisDot @matthiasmullie @CBogen

Based on the discussion above, I am proposing we change the title (and as a result the icon) in the onboarding popup so that it can be shown a few months later too to new users coming to search page. It allows us to leave it on beyond what may be considered "new feature update". Below is a mock. Let me know if you have any comments or else I would like to update the AC if its still possible to do so.

Should be fine to update the AC at this point; no one has picked up this ticket yet.

Change 837684 had a related patch set uploaded (by Vadim Kovalenko; author: Vadim Kovalenko):

[mediawiki/extensions/SearchVue@master] Tutorial/message to introduce quick view and inform users of quick view turn on/off option

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

Hi @Sneha . I have a few questions about some ACs.

Ensure that any interactions immediately under the pop up are disabled while the pop is up.

What exact elements under the popup should be disabled? Footer/Other search results, etc?

Do not show the onboarding pop up again to the same user. Are we able to determine that for logged out users?

I set a specific popup cookie to track visibility named wikitutorialPopup with true/false flag (@CBogen , is this cookie name correct regarding SDAW conventions?). If we want to connect this feature to the "Preferences", I'd rather track this process in a separate ticket.

cc: @matthiasmullie

@vadim-kovalenko

Ensure that any interactions immediately under the pop up are disabled while the pop is up.

This may not be necessary in real code. But when I tested my prototype (due to its limitation), people were able to click anywhere on the tutorial box to activate quick view for the snippet below it. So I just wanted to ensure it doesn't happen in code.

Do not show the onboarding pop up again to the same user. Are we able to determine that for logged out users?

Yeah for logged out I was thinking it would be cookies. But others may be able to chime in on this in more depth.

In T311669#8308207, @vadim-kovalenko wrote:

I set a specific popup cookie to track visibility named wikitutorialPopup with true/false flag (@CBogen , is this cookie name correct regarding SDAW conventions?). If we want to connect this feature to the "Preferences", I'd rather track this process in a separate ticket.

cc: @matthiasmullie

Not sure what the naming conventions are in the code - @matthiasmullie can probably better answer!

Change 837684 merged by jenkins-bot:

[mediawiki/extensions/SearchVue@master] Tutorial/message to introduce quick view and inform users of quick view turn on/off option

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

Checked on enwiki betalabs - all look/behave as expected. The link issue is filed separately - T321636.

The screenshots are for references to check in production:

old Vector	Vector (2022)	Monobook	Timeless

I have two change request.

1. Are we able to change the position of the tutorial so the dot appears on the text as right now both in the mock and more prominently in some of the screenshots above it looks like it is pointing at the white space. Sometimes there is no second line so perhaps to mitigate that we can have the dot appear on the first line? And also shift it a little over to the left to further avoid it pointing at white space.

2. Change the word "see" to "view" in the copy.

In T311669#8361310, @Sneha wrote:

I have two change request.

1. Are we able to change the position of the tutorial so the dot appears on the text as right now both in the mock and more prominently in some of the screenshots above it looks like it is pointing at the white space. Sometimes there is no second line so perhaps to mitigate that we can have the dot appear on the first line? And also shift it a little over to the left to further avoid it pointing at white space.

2. Change the word "see" to "view" in the copy.

@Sneha for changes (rather than missed AC), can you please create a new ticket? thanks!

okay created a new ticket T322216 for it