Page MenuHomePhabricator

Add red link experience to empty search results for Codex/mobile
Open, LowPublic

Assigned To
None
Authored By
Amire80
Dec 3 2018, 12:13 PM
Referenced Files
F31010850: Screenshot_20191105-071423_Chrome.jpg
Nov 5 2019, 3:15 PM
F28511094: image.png
Mar 29 2019, 4:59 PM
F28511070: image.png
Mar 29 2019, 4:59 PM
F28381541: image.png
Mar 13 2019, 4:17 PM
F28381527: image.png
Mar 13 2019, 4:17 PM
F28381525: image.png
Mar 13 2019, 4:17 PM
Tokens
"Orange Medal" token, awarded by Krinkle."Like" token, awarded by alexhollender_WMF."Love" token, awarded by CKoerner_WMF.

Description

Description

When the precise search term was not found, desktop MediaWiki search results include a red link using which a new article can be created:

image.png (1×2 px, 966 KB)

Such a red link doesn't appear on the Codex or mobile search results (which will be eventually replaced by Codex). We should add one so that people can more easily create pages from mobile.

Note: there are two different search experiences on mobile: JS and non-JS. The non-JS experience is shared between desktop and mobile and as such any updates will need more consideration. It has its own task here: [will add link].

Designs

current desktopcurrent mobileproposed mobile
image.png (1×2 px, 966 KB)
image.png (1×724 px, 157 KB)
image.png (1×724 px, 173 KB)

When the precise search term was not found, desktop MediaWiki search results include a red link using which a new article can be created. Such a red link doesn't appear on the mobile search results. We should add one so that people can more easily create pages from mobile. There seem to be two cases to consider here (both sometimes have the additional "Did you mean" element present):

no page found, search term not found in other pagesno page found, search term found in other pages
en.wikipedia.org_w_index.php_search=Harmony+koreeeeee&title=Special%3ASearch&go=Go&ns0=1.png (737×1 px, 137 KB)
en.wikipedia.org_w_index.php_search=Elsie+Naomi&title=Special%3ASearch&profile=advanced&fulltext=1&advancedSearch-current=%7B%7D&ns0=1.png (688×1 px, 200 KB)

Developer notes

For mobile, this is blocked on T282473

This will require changes to the Codex Typeahead search using inheritance right now. While that code remains in that form this may work against our removal of technical debt so we may want to stall this until that happens.

Deprecated searchoverlay code

Showing the red link on https://en.m.wikipedia.org/w/index.php?search=Fooassa&title=Special%3ASearch&profile=default&fulltext=1&ns0=1
involves removing the CSS rule: .mw-search-createlink the red link drawer will then work

TODO

  • It should be possible to trigger red link creation from the Codex search component
  • Remove the CSS hiding the red link creation links on the special:search page on mobile.

Related Objects

Event Timeline

There are a very large number of changes, so older changes are hidden. Show Older Changes

And to clarify are we talking about all new red links?
If so such a link could easily be added e.g. as an information icon/link to the existing red link drawer workflow:

Screenshot_20191105-071423_Chrome.jpg (2×1 px, 325 KB)

@alexhollender - could you make a mock of this when you get a chance?

Have you considered to add a link to an help page that would provide best practices to create articles?

Were you imagining this link would appear near the "Create page" button (either in the empty search results screen, or in the drawer that appears when tapping a red link), or on the new page creation screen? I wonder if it would make more sense to offer it to people once they've decided to create a new page?

In T211006#5645194, @alexhollender wrote:

Have you considered to add a link to an help page that would provide best practices to create articles?

Were you imagining this link would appear near the "Create page" button (either in the empty search results screen, or in the drawer that appears when tapping a red link), or on the new page creation screen? I wonder if it would make more sense to offer it to people once they've decided to create a new page?

I think our best option would be to present it within the drawer, as @Jdlrobson suggested in T211006#5636346

Jdlrobson renamed this task from Add redlink experience to empty search results on Mobile (JS version) to Add red link experience to empty search results on Mobile (JS version).Mar 17 2020, 4:26 PM
Jdlrobson renamed this task from Add red link experience to empty search results on Mobile (JS version) to Add red link experience to empty search results on Minerva (JS version).
Jdlrobson edited projects, added MinervaNeue; removed MobileFrontend.
Jdlrobson added subscribers: Tacsipacsi, Ammarpad.
Jdlrobson raised the priority of this task from Low to Needs Triage.Mar 17 2020, 5:49 PM

Resetting priority given it was at one point high and I was the one that lowered it to low. It might be more important now in light of current events.

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

ovasileva triaged this task as Medium priority.EditedMar 18 2020, 2:36 PM

This seems risky to continue with right now. Let's discuss in standup. There's a few open questions here:

  • Overall risk
  • Effects to moderation
  • Do we want separate experiences for red links within articles and within search (and if so, should the former get it's own task)
  • Should we include help information as suggested by @Trizek-WMF and how?

@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
JTannerWMF subscribed.

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

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

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

Jdlrobson renamed this task from Add red link experience to empty search results on Minerva (JS version) to Add red link experience to empty search results on wvui (JS version).Jun 8 2021, 7:22 PM
Jdlrobson renamed this task from Add red link experience to empty search results on wvui (JS version) to Add red link experience to empty search results for wvui/mobile.
Jdlrobson edited projects, added WVUI; removed MinervaNeue.
Jdlrobson updated the task description. (Show Details)
Jdlrobson updated the task description. (Show Details)
LGoto subscribed.

This task was closed as part of backlog upkeep. If you believe it was closed in error, please respond on the ticket.

Closed in error. Still a valid issue we want to address.

Volker_E renamed this task from Add red link experience to empty search results for wvui/mobile to Add red link experience to empty search results for Codex/mobile.Sep 9 2022, 8:20 PM
Volker_E removed a project: WVUI.
Volker_E updated the task description. (Show Details)

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.

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.

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 pages2) no page found, search term found in other pages
en.wikipedia.org_w_index.php_search=Harmony+koreeeeee&title=Special%3ASearch&go=Go&ns0=1.png (737×1 px, 137 KB)
en.wikipedia.org_w_index.php_search=Elsie+Naomi&title=Special%3ASearch&profile=advanced&fulltext=1&advancedSearch-current=%7B%7D&ns0=1.png (688×1 px, 200 KB)

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.

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.

ovasileva lowered the priority of this task from Medium to Low.Apr 11 2023, 5:58 PM
ovasileva moved this task from Groomed to Current Fiscal Year on the Web-Team-Backlog board.

In August 2021, @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)

@ovasileva: Per emails from Sep18 and Oct20 and https://www.mediawiki.org/wiki/Bug_management/Assignee_cleanup , I am resetting the assignee of this task because there has not been progress lately (please correct me if I am wrong!). Resetting the assignee avoids the impression that somebody is already working on this task. It also allows others to potentially work towards fixing this task. Please claim this task again when you plan to work on it (via Add Action...Assign / Claim in the dropdown menu) - it would be welcome. Thanks for your understanding!