Incoming code review request.

Change 580407 had a related patch set uploaded (by Jdlrobson; owner: Tacsipacsi):
[mediawiki/skins/MinervaNeue@master] Show red link at top of search results (non-JS version)

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

@Tacsipacsi - We are currently slowing down our deployments over the next couple of weeks. As a result, we'll be pausing the work here for now. In the meantime, we would like answer some of the questions outlined above - in particular, we want to get an idea of the effects this change would have on moderation as well as solidify the designs. I will update this task once we have more info on this.

Notes from a quick chat @ovasileva and I had just now...
It seems like we, everyone who has commented on this ticket thus far, are in agreement there ought to be a workflow(s) for creating articles from search results that is well adapted to to mobile (device, context, etc.).

It also seems like there is good amount of uncertainty around who might engage with this workflow, why they might engage with this workflow, the impacts them engaging with this workflow could have on others [1] and as a result, how this workflow ought to be designed.

With this in mind, +1 to the root of the point @Trizek-WMF raised in T211006#5630616: "Have you considered to add a link to an help page that would provide best practices to create articles?"

IMO, it seems like a valuable first step would be to create and instrument just enough of the experience for us to be able to answer the following questions (not an exhaustive list) with more confidence than we are able to right now:

• Who is attempting to create articles from search results on mobile?
• Why are they engaging with the workflow for creating articles from search results on mobile? E.g. where on the spectrum of "I'm curious." <------> "I want to publish this new article right now." are they?
• For people at varying points along this spectrum, what guidance/help do they need most in this moment to meet their needs/expectations?

1. See @ovasileva's comments here: T211006#5979746

It looks like the first step would be for the Web team, so I am moving this to the Editing Tracking tag.

Per T211006#5980933 please bump this back to backlog when we have a plan so we can work out what to do with @Tacsipacsi patch

This configuration setting is essential for wikis which over a half of the visitor are mobile users such as Korean Wikipedia. In addition, small wikis, which need to be more developed, have to give users more options or opportunities to create a new page. I think if it is optional and set to "false" by default, it will not cause a lot of problems.

Change 580407 abandoned by Jdlrobson:
[mediawiki/skins/MinervaNeue@master] Show red link at top of search results (non-JS version)

Reason:
Given https://phabricator.wikimedia.org/T211006#5979746 and https://phabricator.wikimedia.org/T211006#5021515 I recommend doing this in MediaWiki:Common.css as an interim state instead of doing this in Minerva.

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

Hello! I just wanted to chime in and provide some thoughts from the Campaigns team perspective: We have created a new tool that allows campaign event organizers to easily create event pages with event registration support (see: event registration). We have a testable version on the beta cluster, and we are planning to release to Meta-wiki soon (in about a month or so).

Unfortunately, the main way that organizers would create event pages for this feature (i.e., search for an event page > click on red link > create page) is just not possible for mobile web users, from my understanding. While many campaign organizers today still do their organizing work in desktop (since it is too challenging to do in mobile), we have consistently heard from them that they want better support for mobile editing and mobile user flows, including within the campaign experience. So, with all that being said, I just wanted to share that the Campaigns team would be very excited to see this tickets worked on in the future,. With these changes, organizers would be more easily able to create event pages in mobile, and thereby more easily access features created by our team in mobile. Thank you!

I wanted to add that design research has found that showing red links on the search results page is detrimental for many searchers: seeing the text that says "X article does not exist" causes a substantial amount of user abandonment, even when there are relevant search results a few lines below that. Basically many users think that the Wikipedia content doesn't exist because there is no exact title match, despite their being a good relevant result based on doing a full text search. These users are presumably also not creating a new article page before abandoning the search/site. I actually am not sure what the numbers look like at all for new articles that are created from red links as the result of a failed search.

From a search perspective, I would actually love to not have the red link text in that position on search results pages, though I don't have strong feelings about alternatives at the moment.

I think that is the case for improving the search appearance so this link gets turned into a button that says ‘Create new article’ or something, not the case for removing the ability to create new pages from the search altogether.

In T211006#8330254, @stjn wrote:

I think that is the case for improving the search appearance so this link gets turned into a button that says ‘Create new article’ or something, not the case for removing the ability to create new pages from the search altogether.

This.

I don't have numbers, but this red link is probably one of the most common ways to create articles for people who do create them.

In T211006#8330235, @MPhamWMF wrote:

I wanted to add that design research has found that showing red links on the search results page is detrimental for many searchers: seeing the text that says "X article does not exist" causes a substantial amount of user abandonment

Exactly what wording did this research use? Because the default message says

Create the page "X" on this wiki! See also the search results found.

while enwiki’s customized message indeed says

The page "X" does not exist. You can create a draft and submit it for review, or you may create the page "X" directly, but consider checking the search results below to see whether the topic is already covered.

If the research didn’t include the default message, maybe a new one that includes it should be conducted, and if its results are better, you should simply convince enwiki to converge to the default message.

Exactly what wording did this research use? Because the default message says

I think it was whatever wording was on the specific wikipedias they researched. But that being said, I think the key takeaway for me was that the wording didn't actually matter at all: it was the fact that the very first thing the users saw was a red link, whose visual design pattern implies that what they are looking for doesn't exist. I don't think they are even reading anything, because in some of the cases, it was very clear that the first result was exactly what they were looking for, but the red link's visual design pattern was enough for them to abandon their search.

I think a button as suggested above -- or some other visual design pattern that doesn't imply a failed search -- would be more helpful towards reducing search abandonment. Without talking to the design team a bit more, I don't have a strong stance yet what would work best to encourage new article creation.

I don't have numbers, but this red link is probably one of the most common ways to create articles for people who do create them.

I think this is probably true, but I think it's because we don't have a particularly intuitive/simple way to create new articles. The two most salient ways that come to mind for me are red links on a search results page (and we know the majority of searchers don't actually reach the special:search page if the title match autocomplete in the go bar doesn't return results), or typing in a new URL. Compare this to other modern platforms users may be used to like Twitter or Instagram, which make it very easy and conspicuous how to create new content (to be clear, I'm not trying to imply that we want to replicate this design pattern, but it is at the least what most users are used to for creating content on the web).
I would personally like to see a more intuitive/accessible flow for creating new articles instead of relying on what looks like a failed search. I don't think that necessarily means removing the ability to create a new article from the search results page, but I don't think it should be a primary pathway for this. I think the design research made it clear that many casual searchers were looking to read content to learn about something. If this content doesn't exist, they had neither interest or ability to create that content, as they didn't know enough about it in the first place (the initial reason they were searching for information on it). For a majority of users searching for information on Wikipedia to learn something new, I don't think it's even possible for them to create missing content when they are unable to find that information via search.

@MPhamWMF it's been a while since I looked at this task, but from my understanding there are two distinct cases here:

1) no page found, search term not found in other pages	2) no page found, search term found in other pages

does your discouragement to show red links apply in both cases, or mainly in the second case? I'm not sure exactly what "abandonment" means, but it seems like in the first case there's less (or nothing?) to abandon (unless "abandonment" also includes not attempting to do a subsequent search?).

Thanks for the clarification @alexhollender_WMF. By abandonment, I meant that users were leaving the special:search page -- I don't remember if they were leaving Wikipedia completely.

To your point, in the first case where there are no results, I don't think the red link makes abandoned searches any more likely.

I wanted to voice my opinion not to block any of this work, so don't let me get in the way of an otherwise well thought out improvement. The changes I'd like to see us move towards -- e.g. better definition around who the different users of search are and what their needs are, and which/how many products should exist to support them -- is a much larger conversation than the scope of this ticket. In the meantime, I think having a more uniform search experience is probably a good thing.

That being said, this might be a good use case if this goes forward to see if we can record a difference in successful searches after red links are added. There isn't a great single measure of that, but if adding red links does increase search abandonment, we might see a decline in click through rates from the search results page.

In T211006#8329796, @ifried wrote:

Hello! I just wanted to chime in and provide some thoughts from the Campaigns team perspective: We have created a new tool that allows campaign event organizers to easily create event pages with event registration support (see: event registration). We have a testable version on the beta cluster, and we are planning to release to Meta-wiki soon (in about a month or so).

Unfortunately, the main way that organizers would create event pages for this feature (i.e., search for an event page > click on red link > create page) is just not possible for mobile web users, from my understanding. While many campaign organizers today still do their organizing work in desktop (since it is too challenging to do in mobile), we have consistently heard from them that they want better support for mobile editing and mobile user flows, including within the campaign experience. So, with all that being said, I just wanted to share that the Campaigns team would be very excited to see this tickets worked on in the future,. With these changes, organizers would be more easily able to create event pages in mobile, and thereby more easily access features created by our team in mobile. Thank you!

Hello all - I am chiming in from the Campaigns team as well. This is likely already known to people on this ticket, but adding here for clarity that this is also an issue on tablet devices.

In August 2021, @Jdlrobson wrote:

In T287342#7253941, @Jdlrobson wrote:

I think both would be a suitable way to solve this problem, given its temporary (I hope)

I think that, in the absence of any efforts to solve this task, the most sensible option at the moment should be done: CSS for removal of ‘create new article' links should be removed from Minerva/MobileFrontend.

<TimStarling> temporary solutions have a terrible habit of becoming permanent, around here (https://bash.toolforge.org/quip/AU7VTzhg6snAnmqnK_pc)