Page MenuHomePhabricator

Treat links to user pages differently than normal wikilinks
Closed, ResolvedPublic

Description

This task is about implementing specific "inspection behavior" [i] for wikilinks to user pages within DiscussionTools.

Context

Links to user pages are syntactically the same as other wikilinks: [[ Namespace: page | display text ]].

User page link syntaxOther wiklink format
[[User:NAME|NAME]][[Help:LINK|LINK]]

Although, links to user pages behave differently from other wikilinks. Namely, when links to user pages are saved to the page, the person whose user page was linked to will receive an "Alert" as described here: https://www.mediawiki.org/wiki/Help:Notifications/Types#Mentions. The same is not true when any other kind of wikilink is saved to the page.

Trouble is, as T232601 is currently implemented, user page links and other wikilinks behave the same. Should this behavior persist, we think people could become confused about how user page links (read: pings) work. For example, they could mistakenly change the display text of a link, assuming that doing so would change who gets a notification.

For more details about these issues and to see them illustrated, review: T252083#6178541.

Requirements

People should be able to:

  • Remove a "ping" from the comment they have drafted
  • Change who they are "pinging" (read: change ping from USER 1 to USER 2) without having to delete the entire contents of the previously written "ping"
    • This is no longer a requirement.
  • Lower the likelihood people will mistakenly cause the link target and text to become "out of sync."
  • Understand "pings" as being different from other links

Implementation

Approach #1A: temporary block that remains a link

  • When an @-mention is clicked in the Reply tool's visual mode:
    • People will see a dark, highlighted block that describes its contents with no calls to action; this is similar to how VE already behaves [ii]
      • The entirety of the block can be deleted
      • The block's contents can not be edited
  • When the cursor is moved atop an @-mention in the Reply tool's visual mode:
    • People will see a lightly highlighted block; this is similar to how VE already behaves [iii]
  • When someone creates an @-mention in the visual mode and switches to source mode:
    • People should see @[[User:NAME|NAME]] and be able to edit it like any other wikilink
  • When someone presses backspace into a user link when using the Reply tool's visual mode:
    • The user link should become lightly highlighted [iii]; when someone presses backspace for the second time, the entirety of the user link should be deleted.

Open questions

  • 1. How should the tool behave when someone places their cursor inside the user link?
    • It will not be possible for people to place their cursor *inside* the user link in the Reply tool's visual mode. See "Implementation" section above for more details.
  • 2. How should the tool behave when someone backspaces into user link?
    • When someone presses backspace into a user link when using the Reply tool's visual mode, the user link should become lightly highlighted [iii], when someone presses backspace for the second time, the entirety of the user link should be deleted.
  • 3. When someone deletes an @-mention in visual mode what should be deleted?
    • Should the entirety of the @-mention be deleted (read: @ + USERNAME would be deleted)?
    • Should a part of the @-mention be deleted (read: USERNAME would be deleted and @ would be kept)?
  • 4. Can you change the display text without changing the link target?
    • No, you should not be able to change the display text without changing the link target within the Reply tool's visual text input mode (this will still be possible in source mode).
      • Rationale: Changing the display text could make it more difficult for people reading and participating in the conversation to understand what is happening because of it not being clear who a comment is directed to. Based on what I've observed so far, it seems to be common practice to refer to someone by the username they've defined for themself.

Done

  • "Open questions" are resolved
  • "Implementation" are implemented

i. E.g. placing your cursor into a user page wikilink, backspacing into a user page link, etc.
ii. Screenshot showing how VE currently handles signatures when clicked:


iii. Screenshot showing how VE currently handles signatures when hovered over:

iv. Example of what leaving pings as links and presenting a special UI could look like and behave:

v. Current UI


OTHER APPROACHES

Approach #1B: block that is treated as a template

  • Implementation
    • When an @-mention is selected in the Reply tool's visual mode...
      • People would see a block that describes its contents and includes an "Edit" call to action that, when clicked, shows a special UI for editing the template's contents
    • When an @-mention is selected in the Reply tool's source mode:
      • People would see something like {{DiscussionTool ping|NAME}} and be able to edit it like any other template
  • Considerations
    • Always editable later
    • Local templates would need to be configured on every wiki (one-time cost)

Approach #1C: block that is treated as a parser function (ala T128535).
Suggested: T252083#6191172

Approach #1D: custom wikilink syntax
Details: T252083#6191323

  1. [[User:NAME]] rendered as '@NAME'
  2. [[@:NAME]] / [@NAME] / [@:NAME] rendered as '@NAME' and linking to the user page. No conflict with link parser.
  3. [[@NAME]] conflicts with page names starting with '@'.

Approach #1E: twitter style
@NAME, @NAME_WITH_SPACE rendered as '@NAME', linking to user page only on pages with DiscussionTools enabled. Probably many conflicts.

Approach #2: leave pings as links; present a special UI for editing/inspecting

  • Implementation
    • When an @-mention is selected in the Reply tool's visual mode...
      • People would see a dialog specific to pings that could be customized, similar to what can be found when using Flow [iv]
      • This would enable people to edit/modify who they are pinging without needing to delete the entirety of the ping they'd previously written.
    • When an @-mention is selected in the Reply tool's source mode...
      • People would see @[[User:NAME|NAME]] and be able to edit it like any other wikilink
  • Considerations
    • Works independently of templates
    • Flexibility for defining new interactions (backspacing, cursoring in)

Approach #3: leave pings as links; present same UI that is shown for all other links

  • Implementation
    • When an @-mention is selected in the Reply tool's visual mode...
      • People would see a link dialog like any other [vi]
      • Ping/link's display text could be edited independent of its target
      • Ping/link could be removed entirely
      • A new user could be searched for
    • When an @-mention is selected in the Reply tool's source mode...
      • People would see @[[User:NAME|NAME]] and be able to edit it like any other wikilink
  • Considerations
    • Could make it more likely for the ping/link's display text and target to be out of sync (as @Esanders here: T252083#6115759)
    • Could lead people to become less confident what they have written will notify someone else, as they're expecting it to.

Event Timeline

ppelberg created this task.May 6 2020, 11:40 PM
ppelberg removed DLynch as the assignee of this task.May 6 2020, 11:59 PM

Considerations:

  • Visual and source modes have different inspector behavior, and lots of our fancy behaviors will only apply to visual mode. Source mode just inserts the link wikitext -- if you put your cursor in it and deliberately trigger the inspector via the shortcut you'll see it, but it's much less amenable to the whole "you backspaced into this" stuff.
  • T250332 could result in what's inserted by the autocomplete not being a link. If it's a template, entirely different behavior applies.

That said:

In visual mode we do have a lot of leeway to insert something which will on-save get turned into whatever the autocomplete replacement wikitext is supposed to be, but which behaves differently until then. For instance, our current behavior for signatures (in the rare places where you can access them in VE) is this:

...which is turned into the normal ~~~~ on-save.

This sort of fake block-level link would let us avoid people editing it outside of the username-picker. We could also style that however we wanted, if we don't mind breaking our normal "VisualEditor is a fairly-accurate preview of what will be posted" behavior.

ppelberg updated the task description. (Show Details)May 7 2020, 12:10 AM

Links becoming out of sync with their labels is not a problem unique to user links:

  • In VE, press ctrl+k / cmd+k
  • Type 2015, then enter to insert a link to 2015 ([[2015]])
  • Press backspace and change the 5 to a 6
  • Your link is still to 2015, but the label says 2016 ([[2015|2016]])
DLynch added a comment.May 7 2020, 4:30 PM

Links becoming out of sync with their labels is not a problem unique to user links:

Notably, we debated this general topic and behavior around it a lot while we were talking about the link-label field in the inspector in T55973.

I'm concerned about creeping perfectionism here. Let's get a link on the page. Let's let editors try it out. Let's let editors tell us if they want @ symbols added to the link labels, or if they want the user link locked in place, or anything else. Let's not try to guess the perfect behavior first.

For right now, I think we should treat this as https://en.wikipedia.org/wiki/Special:Search?ns2=1 with nothing else. Just search for a username, and make a link. For right now, I think that the link I get from the "mention" search should work exactly the same as a link I create with the regular link tool. That's consistent with the idea that this is a lightweight tool, and it's consistent with its status as a Beta Feature that can be changed in response to user feedback.

Let's get a link on the page. Let's let editors try it out.

For sure – I do not see this task, or anything being discussed in it, as blocking our plans to test the tool with people.

Where "people" means:

  • People who are new to using Wikipedia talk pages (via T246190)
  • People at our partner wikis who have experience using Wikipedia talk pages (via T252265)
  • People from other projects who have experience using Wikipedia talk pages (via T246191)

Updating the task description to include the approaches @Esanders, @iamjessklein and I discussed this morning.

Note: as mentioned in T252083#6126549, we have not yet decided on an initial approach or prioritized deciding on said approach.

ppelberg updated the task description. (Show Details)May 11 2020, 8:21 PM
ppelberg updated the task description. (Show Details)
ppelberg updated the task description. (Show Details)
ppelberg added a subscriber: Demian.EditedMay 30 2020, 1:28 AM

Feedback from @Demian
The "Issues with current treatment" are copied from this conversation: https://w.wiki/SEh.

The issues Aron surfaced below (some of which, like a link's text and target getting out of sync, we've talked about) lead me to think the best short-term approach is either: Approach #1A: temporary block that remains a link or Approach #1B: block that is treated as a template (see task description for details).

Note: I figure we can implement something more robust if it turn outs that @-mentions looking and behaving like regular links when people go from Visual --> Source --> Visual or if they were to edit an old comment presents issues.

Reasons:

  • Approaches #1A and #1B seem like they will prevent issues I., II., and III. from occuring.
  • In cases where people want to ping someone different from the person they currently created a ping for, I do not think the the level of effort and complexity in involved with 1) editing an existing @-mention to link to a different person's user page and 2) deleting an existing @-mention and creating a new one to link to someone else vary significantly enough for it to be worth preserving the "edit" functionality.

Next steps

  • Discuss and decide on which approach to take next: Approach #1A: temporary block that remains a link or Approach #1B: block that is treated as a template.

Issues with current treatment

I. "Having "User:" in the link was surprising and I might have edited that part by mistake."
II. "Users without userpage are not offered by the look-ahead search."
III. "I've chosen a userpage, but the link text did not update, I had to find out how to do that too."
Demian updated the task description. (Show Details)Jun 1 2020, 5:56 AM
Demian added a comment.Jun 1 2020, 6:13 AM

@ppelberg Thank you for the screenshots!

I think in lack of builtin templates the operational burden of installing a template on all wikis (including third-parties) for "Approach #1B: block that is treated as a template" is best avoided, therefore I'd go with "Approach #1A: temporary block that remains a link".

kaldari added a subscriber: kaldari.Jun 4 2020, 1:23 AM

It seems like Approach #1B would be a lot more feasible as a parser function (ala T128535) rather than a template.

Documenting some the feedback @Dvorapa shared in https://www.mediawiki.org/wiki/Topic:Vmu502mrhvk3l7ex:

  • The current treatment could lead people to think they've changed who they are pinging when in reality, only the link text has been changed (read: It's easy for the link target and text to get out of sync).
  • In general, the current link inspector, in this context, is confusing. For example, the dialog does little to help people understand how to change who they are pinging.

Full text:

It was a bit confusing. I tried to rewrite the text as I would do on StackOverflow, but it rewritten just the text, not the user to be pinged. I know this is wiki code limited, but I would expect the popup to help me figure out, how to change user and edit text. The popup is completely confusing, the worst experience of the 2.0 version. First there is a link header that does nothing. I don't know, why is it there. Then there is a unlink button, which to me is unnecessary. Then there is an edit button. What exactly this edit button edits? After clicking it opens edit link menu. What? Why? Follows red link and question mark image. While this might make sense in terms of Wikipedia, for people with less experience this is completely confusing. Do I have a typo in the name? Does that mean the user does no exist? Don't get me wrong, the text in Visual mode should have red link, but this menu? Again, why? Finally there is this "Text" header, again not editable. I have to click the "change text" button. Which confusingly does nothing noticeable?It was a bit confusing. I tried to rewrite the text as I would do on StackOverflow, but it rewritten just the text, not the user to be pinged. I know this is wiki code limited, but I would expect the popup to help me figure out, how to change user and edit text. The popup is completely confusing, the worst experience of the 2.0 version. First there is a link header that does nothing. I don't know, why is it there. Then there is a unlink button, which to me is unnecessary. Then there is an edit button. What exactly this edit button edits? After clicking it opens edit link menu. What? Why? Follows red link and question mark image. While this might make sense in terms of Wikipedia, for people with less experience this is completely confusing. Do I have a typo in the name? Does that mean the user does no exist? Don't get me wrong, the text in Visual mode should have red link, but this menu? Again, why? Finally there is this "Text" header, again not editable. I have to click the "change text" button. Which confusingly does nothing noticeable?

Demian added a comment.EditedJun 4 2020, 5:37 AM

It seems like Approach #1B would be a lot more feasible as a parser function (ala T128535) rather than a template.

I wonder if a solution would be possible

  1. without using <nowiki> for conciseness in source editor
  2. without doing subst, so the wikitext remains the same when later editing a comment

I've been thinking about whether these would cause conflicts with other meanings:

  1. [[User:NAME]] rendered as '@NAME': visible text changed from 'User:NAME' to '@NAME'.
    • Would change rendering of current talk pages in a non-confusing way.
  2. [[@NAME]]: renders as '@NAME' currently
    • Changes the wikilink parser, conflicts with page names starting with '@' - if there's any
  3. [[@:NAME]]: renders as '@:NAME' currently
    • Conflicts with the namespace '@' - if that's used, maybe by 3rd parties?
  4. [@NAME]: rendered as '@NAME'
    • Changes the external link parser, no conflict with protocols like 'http?:*'
  5. [@:NAME]: rendered as '@:NAME'
    • Changes the external link parser, no conflict with protocols like 'http?:*'

I'm not yet familiar with the code involved. From a uniqueness aspect I think some of these might be feasible.
The wikilink editor would be disabled for these in DT's visual editor, the link could be deleted as one entity.

It seems like Approach #1B would be a lot more feasible as a parser function (ala T128535) rather than a template.

We should definitely consider it. I'd want to check with the people who worked on Echo to see what the potential issues are. It may also require changes to DisucssionParser in Echo.

If we go with 1A for now we can still easily switch to this or 1B later without breaking anything.

Lofhi added a subscriber: Lofhi.Jun 4 2020, 11:22 AM

What would happen when you write [[User:NAME|OTHERNAME]]?

What would happen when you write [[User:NAME|OTHERNAME]]?

A link to the page 'User:NAME' that reads OTHERNAME. Ex.: OTHERNAME.

I've been thinking about whether these would cause conflicts with other meanings...

@Demian can you elaborate on what the ideas you shared above are in response to? Are they an effort to overcome certain constraints/side effects of Approach #1B? If so, which constraints/side effects?

...I ask the above in an effort to more clearly understand what you're describing and the implications of it.

Demian added a comment.EditedJun 5 2020, 4:21 PM

I've been thinking about whether these would cause conflicts with other meanings...

@Demian can you elaborate on what the ideas you shared above are in response to? Are they an effort to overcome certain constraints/side effects of Approach #1B? If so, which constraints/side effects?

Yes, T252083#6191323 is a spin on @kaldari's idea:

It seems like Approach #1B would be a lot more feasible as a parser function (ala T128535) rather than a template.

The syntax alternatives I've proposed are neither templates, nor a parser function: it's an addition to the syntax of wikilinks or external links.
It could be considered an alternative for Approach #1B using a link instead of a template.

Demian added a comment.EditedJun 5 2020, 4:24 PM

Kaldari's idea could be called #1C and the wikilinks #1D, if need be.

ppelberg updated the task description. (Show Details)Jun 10 2020, 6:28 PM
ppelberg updated the task description. (Show Details)
matmarex moved this task from To Triage to Triaged on the VisualEditor board.Jun 10 2020, 7:11 PM

I don't want "1B" (the "let's put templates on every wiki" approach).

ppelberg updated the task description. (Show Details)Jun 12 2020, 6:52 PM
ppelberg updated the task description. (Show Details)
ppelberg updated the task description. (Show Details)Jun 12 2020, 7:05 PM

I've been thinking about whether these would cause conflicts with other meanings...

@Demian can you elaborate on what the ideas you shared above are in response to? Are they an effort to overcome certain constraints/side effects of Approach #1B? If so, which constraints/side effects?

Yes, T252083#6191323 is a spin on @kaldari's idea:

Understood – thank you for confirming this, @Demian. Initially, we're going to take Approach #1A: temporary block that remains a link. More details below.


DECIDED
Initially, we are going to take Approach #1A: temporary block that remains a link.

REASONS
We think Approach #1A will:

  • Reduce the likelihood people will experience issues I., II., and III. described in T252083#6178541.
  • Afford us the flexibility to revise this approach should other issues arise and/or more robust functionality be required (e.g. editing pings rather than having to delete and recreate them).
  • Not require people at local wikis to do any kind of customization
  • In cases where people want to ping someone different from the person they currently created a ping for, I do not think the the level of effort and complexity in involved with 1) editing an existing @-mention to link to a different person's user page and 2) deleting an existing @-mention and creating a new one to link to someone else vary significantly enough for it to be worth preserving the "edit" functionality.

The above is now represented in the task description.

Demian updated the task description. (Show Details)Jun 12 2020, 10:22 PM

Initially, we're going to take Approach #1A: temporary block that remains a link. More details below.

For future reference I've added a brief summary of #1C-#1E approaches, these are small alterations of #1A. I think #1D will be worth considering from a UX perspective at the appropriate time.

Initially, we're going to take Approach #1A: temporary block that remains a link. More details below.

For future reference I've added a brief summary of #1C-#1E approaches, these are small alterations of #1A. I think #1D will be worth considering from a UX perspective at the appropriate time.

Oh, that's helpful...thank you for doing this, @Demian.

Change 608073 had a related patch set uploaded (by Esanders; owner: Esanders):
[mediawiki/extensions/DiscussionTools@master] Create a PingNode so user pings are single focusable nodes

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

Change 608073 merged by jenkins-bot:
[mediawiki/extensions/DiscussionTools@master] Create a PingNode so user pings are single focusable nodes

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

ppelberg closed this task as Resolved.Thu, Aug 27, 11:57 PM
ppelberg edited projects, added Skipped QA; removed Editing QA.

This is working as expected.

Restricted Application added a project: User-Ryasmeen. · View Herald TranscriptThu, Aug 27, 11:57 PM