Page MenuHomePhabricator

Disambiguation Pages: Visually differentiate disambiguation links on Wikitext Editor link selector
Open, Needs TriagePublic3 Estimated Story Points


As a Wikitext Editor contributor using the link toolbar to search for knowledge to reference in my article, I can:

  • Visibly differentiate disambiguation links as a different type of content than articles that come up on my suggestions

Proposed solution:
We are proposing changing the copy to better describe what a disambiguation page means in the Wikitext editor link pop-up, and making the feedback state more explicit (with standardized OOUI icons).

WE_Link Selector.png (3Γ—4 px, 1 MB)

StatusMessageNew OOUI iconOld icon
loadingChecking page existence... Title widget has its own loading indicator.Animated stripesSpinner
existsThis page exists on {{SITENAME}}article
insert-link-exists.png (24Γ—24 px, 273 B)
notexistsThis page does not exist on {{SITENAME}}articleNotFound
insert-link-notexists.png (24Γ—24 px, 430 B)
externalExternal linklinkExternal
insert-link-external.png (24Γ—24 px, 227 B)
disambigThis page is not a content page, it lists topics with similar namesarticleDisambiguation
insert-disambiguation.png (24Γ—24 px, 724 B)
invalidThe title you specified is invalid.error
insert-link-invalid.png (24Γ—24 px, 487 B)

Event Timeline

ldelench_wmf set the point value for this task to 3.

@nayoub One issue with the status icon and message being below the input box is that when the dropdown menu is open the status info is not visible:

disambig-dropdown.png (253Γ—540 px, 19 KB)

I might have missed the discussion, but have we considered switching to an OOUI TitleInputWidget? Then it'd match the VE selector (I think? Perhaps there are differences.) It'd look something like the following:

wikieditor-ooui.png (324Γ—549 px, 17 KB)

Of course, it's a bit hacky to have just this one input element in a different style, but perhaps if we converted only the two inputs it'd be okay and wouldn't make this task too large?

I've added details of the new messages to this ticket's description.

Change 715916 had a related patch set uploaded (by Samwilson; author: Samwilson):

[mediawiki/extensions/WikiEditor@master] Remove unused image: insert-link-error.png

Change 715916 merged by jenkins-bot:

[mediawiki/extensions/WikiEditor@master] Remove unused image: insert-link-error.png

Following RTL meeting, we are updating the UX wording to "This is not a content page; it lists topics with similar names."

Another aspect that we didn't talk about earlier: the title dropdown also needs to support external links, which the default TitleInputWidget doesn't. I think the changes are not too great; for anything recognised as a URL, we'd need

  • a different image/icon (I've not yet really looked at where these images come from, but maybe they're just icons and so linkExternal will be fine?);
  • to not uppercase the first character; and
  • to show it in blue instead of red.

Change 717068 had a related patch set uploaded (by Samwilson; author: Samwilson):

[mediawiki/extensions/WikiEditor@master] [WIP] Update messages in the link-insertion dialog

I've got a bit further to go with this: sorting out the behaviour when the internal/external radio buttons are changed; what happens for invalid titles (which generally aren't invalid for external links); how the four messages change with various interactions; whether not selecting from the dropdown should be considered selecting (to maintain existing behaviour); etc.

I keep referring to other uses of the TitleInputWidget, and realising that this overloading of it (with external URLs) is a bit unusual. VE handles this by putting the internal/external choice above the title input, so it's clearer what mode it's in and there's no ambiguity about switching. The WikiEditor link-inserter tries to guess what's an external link.

Anyway, I'll get it all sorted, but it does just make me wonder what different design choices might be made in the (near?) future when this link-inserter is swiched away from jQuery UI (T209059). I don't want to build too much customization into this widget (away from other places where page titles are chosen, e.g. VE, TemplateWizard, etc.), if they're just going to be undone again. It might be easier to make this current change to 'stock' title-selecting, and iterate from there.

I've set up a patchdemo with the current state of my work:

Definite follow-up patches to this patch will add OOUI widgets for the link-text input field and the radio buttons. I don't want to do it all in one patch because it'll just get bigger and bigger.

The first part of this is ready for review. I'm working on the follow-up patches now.

Actually this isn't quite ready: need to fix up the behaviour when no title is selected from the autocomplete menu (it should display a message about whatever text is present in the title/target text box, regardless of whether the user clicks an item from the popup menu or not).

I've been trying to get the blur/non-selecting behaviour correct, but ultimately it feels like I'm battling against what the TitleInputWidget is wanting to do. I've created T291056, because that seems to be one key bit that works differently, and other behaviour I think is just going to have to change (to be in line with title-selecting everywhere else in MediaWiki, which is a good thing, I think! But might be a source of discontent with this change).

Change 721248 had a related patch set uploaded (by Samwilson; author: Samwilson):

[mediawiki/extensions/WikiEditor@master] Change link-insert field to OOUI