Page MenuHomePhabricator

VisualEditor: Link input widget should have separate inputs for target and display text
Closed, ResolvedPublic40 Estimated Story Points

Assigned To
Authored By
Thryduulf
Sep 10 2013, 12:24 AM
Referenced Files
F13736398: edit-label-and-select.png
Feb 14 2018, 10:55 AM
F4723857: label-page-sync.png
Nov 14 2016, 10:42 AM
F4716647: links-label-editign-invite.png
Nov 11 2016, 6:40 PM
F4698802: pasted_file
Nov 5 2016, 3:44 PM
F4698804: pasted_file
Nov 5 2016, 3:44 PM
F4693560: pasted_file
Nov 3 2016, 8:07 PM
F4688837: link labels option 2 (context).png
Nov 2 2016, 4:07 PM
F4688838: link labels option 2 (inspector).png
Nov 2 2016, 4:07 PM
Tokens
"Cookie" token, awarded by RandomDSdevel."Like" token, awarded by Liuxinyu970226."Like" token, awarded by IKhitron."Orange Medal" token, awarded by Krinkle."Love" token, awarded by Elitre."Like" token, awarded by MartinK."Like" token, awarded by Cirdan."Like" token, awarded by Trizek-WMF.

Description

The link input widget should have separate fields for the link target and the displayed text.

From various comments at T50789

There are essentially two ways to create a link:

[…]

#2 You click the link button first, enter the target and get out of the dialog, at which point the link text (identical to chosen link target) will be entered.

[…]
With this method, the user will often have to adjust the link's text afterwards, for instance in the case of plurals or if the target article is disambiguated with parentheses. But it is not clear to the user that adjusting the link text is safe and won't create a broken link; indeed the crucial distinction between link text and link target remains obscure. (Changing a singular to a plural is especially difficult since editing links at the end is not allowed.)

I have checked the workflow of entering links in LibreOffice, Gmail and Word; they are all basically the same as in the Visual Editor, with two major differences:

a) the dialog popup window has a clear OK button, and [T54462]

b) the dialog popup window contains separate clearly labeled boxes for the link text and the link target.

I believe both of these changes make a lot of sense.


An English Wikipedia user comments that the current behaviour of the input widget is not intuitive at all:

"I clicked the link tool while not focused on any text, to try and add a new link. I got a largely empty box with no instructions, and the next word in the article highlighted within the box. I fiddled with it a few times, and still don't know if typing in the box A. changes the text of the link. B. allows me to select more words. C. Changes what is linked to, or D. is followed by another, nearly identical box for a secondary function"

To me this is further evidence that we need two boxes: one to enter the link target and one to enter the link display text. The second box would default to the same as the link for internal links and for external links either (ideally) the page title or (less ideally but probably easier) the filename sans extension.

See also T53438


Adam Cuerden comments again on the suggestion to have separate boxes for link target and link title:
"Yes [that would be better], but do make sure it's on the same page. Don't give one dialogue, then a second. Also, if one of the boxes is left blank, it should be auto-completed from the other box. "

For the second part of the comment they mean that if someone gives a link target (e.g. Fish) and doesn't specify any title, produce a link: [[Fish]]
If someone gives a link title (e.g. Hedgehog) but doesn't specify a target, produce the link: [[Hedgehog]].


See Also: T52945

Related Objects

Event Timeline

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

Off in T124305 there's a patch to make it easier to select the link-contents, which avoids many of the issues a "display text" field has (most notably: it's not just text). It's held up on general "what design do we want?" concerns.

Change 303956 had a related patch set uploaded (by DLynch):
LinkAnnotationInspector: add a "label" field

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

To clarify the issue about "display text", both Google Docs and the patch above will maintain all covering annotations, but will remove any partial annotations if the text is edited (e.g. <a><b><i>He</i>llo</b></a> -> <a><b>Bye</b></a>). Also if the label contains any non-text (e.g. an inline image) it will be uneditable, but this is a very rare edge case.

This should also make the editing of external links and numbered external links a bit cleaner, getting rid of the 'add label' button for numbered external links.

Moving from gerrit:

James F:
This creates a TextInputWidget which is just wrong; the contents covered by the link annotation could be anything up to and including <span>s, <img>s and so on; this would need to be a complete SurfaceWidget, which would totally dominate this inspector and destroy the whole design of it being a lightweight, simple control. I'm pretty strongly against this change for exactly this reason.

David L:
James: This is totally cribbing from Google Docs' design for link labels. It shows the field... if the label is simple. If it's not simple, it hides it. That lets us give people a field that works in most cases, and won't break anything otherwise.
Admittedly, I just have it *disabled* if it's not-simple, on the theory that might be less confusing, but I could go full-hidden.

Ed S:
That is technically true, however in almost all cases additional annotations to the link are covering, and can be preserved. This is the same behaviour as Google Docs. Links containing content (e.g. img) are many times rarer still. For these cases we can block/and or warn (or not).

To elaborate slightly, 303956,2 adds some protection in to make sure it won't replace the current label text if it hasn't been changed from its initial value, so even internal annotations will be preserved if you're only editing the target.

Regular users have a really understand creating a mental model of how links work, especially when the label (nearly) matches the target. Having both side by side in the edit area makes it a lot clearer what is going on. More experienced users will be able to use the edit surface as designed.

pasted_file (185×448 px, 11 KB)

(Prior to any Design feedback.)

The other options I came up with are context item:

link labels option 2 (context).png (272×900 px, 52 KB)

(With attendant "we need to think up an icon that intuitively symbolizes 'select all'" dilemma, which nobody else seems to have really cracked. My favorite, after a bunch of searching, was Blackberry's)

Or inspector:

link labels option 2 (inspector).png (390×880 px, 59 KB)

The other options I came up with are context item:

link labels option 2 (context).png (272×900 px, 52 KB)

(With attendant "we need to think up an icon that intuitively symbolizes 'select all'" dilemma, which nobody else seems to have really cracked. My favorite, after a bunch of searching, was Blackberry's)

Or inspector:

link labels option 2 (inspector).png (390×880 px, 59 KB)

I'm pretty sure that people will not edit the label with that version. Edit label is not as obvious as it is on your first proposal with two separate fields.

Speaking of which, how do you deal with a label which includes some wikitext formatting, like bold or, worse, an in-line template?

I'm glad this is being worked on.

pasted_file (185×448 px, 11 KB)

(Prior to any Design feedback.)

Please don't use these weird right-side labels. TextInputWidget's 'label' option should never have been created. :/

Unless design folks invent something new, there are two options that would be consistent with existing interfaces:

  • Just use a FieldLayout :)
  • Use a 'placeholder' and insert an invisible label somewhere for accessibility.

The patch currently behaves as:

  • If there's any block-level content in the link (e.g. an image), it disables the label field. (Cue taken from Google Docs, which completely hides the field in this case.)
  • If there's annotations on the content (bold, italic, etc), the field is enabled, and contains the plain text version. Making a change to its contents will remove all internal annotations from the link. (i.e. if it's in a block of bold text, it'll stay bold, but if part of the inside was bold, that'll be lost)

@DLynch, would it be easy enough to make it show wikitext rather than "plain text" (i.e., like the template dialog does for parameters)? Having the internal annotations silently disappear might be annoying (for the very small percentage of links that contain internal annotations).

Rich display would be nicer (but take up a lot of space). OTOH, given a link such as [[Example|the ''blue'' picture]], I'd rather see

the ''blue'' picture
Example

rather than

the blue picture
Example

– especially when the second item will silently remove the italics if I touch it.

Showing wikitext is not the right thing to do. Links with *partial* formatting are very rare, and editing their text rarer. Even in those cases the user can just edit the text directly. If the user edits the label in this very rare case they will get immediate visual feedback of the change. Let's not make perfect the enemy of the good.

Also, as a volunteer, I don't want to hear "quotes on the text are making italics, that's a bug" from a newbie. That's a request for my personal comfort, Sherry ;)

Showing wikitext is not the right thing to do. Links with *partial* formatting are very rare, and editing their text rarer. Even in those cases the user can just edit the text directly. If the user edits the label in this very rare case they will get immediate visual feedback of the change. Let's not make perfect the enemy of the good.

Wise words!

I do agree that showing wikitext is the wrong way to go. This is a prime user-facing tool, which a majority of users are going to be interacting with regularly, not something far more power-usery like templates.

If we want to preserve the rare cases of internal formatting, we should go all out and have a VE surface inside the inspector... which I think makes it far too heavy for what's normally an incredibly quick action.

Technically, I suppose there's alternatives like diffing/merging the change to the label so that we keep the annotations if the section they cover wasn't touched. But that's a bunch more work on our end, and moves towards being too magic for the user to understand why the formatting sometimes stays and sometimes goes.

And what if we only display a read-only text for the label?

Label: 2013
Target: 2014

That way, people will notice there is something wrong and will be able to correct the text afterwards, using the full potential of VE.

And what if we only display a read-only text for the label?

Label: 2013
Target: 2014

That way, people will notice there is something wrong and will be able to correct the text afterwards, using the full potential of VE.

This is another good option (I may have suggested it in the past).

ps Note that we will be able to handle the example you gave just fine because the annotation (italic) spans the whole link. A better example would be:

Label: Season 2014
Target: Season 2014

And what if we only display a read-only text for the label?

Label: 2013
Target: 2014

That way, people will notice there is something wrong and will be able to correct the text afterwards, using the full potential of VE.

That would leave a primary use-case as very difficult - pasting or writing a complete replacement for the link label.

I.e. As an experienced wikitext editor, I'm accustomed to writing/pasting the link first, and then writing/pasting the label after a space or pipe. -- With VE, it is hard to select the entire label, in order to paste my clipboard on top, or in order to write it from scratch.

I really like the design given in T55973#2761021 above.
Losing occasional text-formatting is an acceptable compromise.

  • Just use a FieldLayout :)
  • Use a 'placeholder' and insert an invisible label somewhere for accessibility.
  • This would make the inspector much taller, which may or may not be acceptable.
  • When editing the link both fields will be non-empty so the placeholder will never be seen.

Google Docs uses an inline label, which may severely reduce the width if we need to make room for all languages, but this should be considered too.

Use a 'placeholder' and insert an invisible label somewhere for accessibility.

Worth considering that the common-case here is (probably) editing an already-existing internal-wiki link. With a placeholder as the only distinction, that's going to look like this:

pasted_file (151×419 px, 18 KB)

...which is perhaps initially confusing.

Then the secondary case is editing an external link, where keeping the URL field as wide as possible is preferred, because URLs can get pretty long. The advantage of the internal label there is that it really is pretty space-efficient -- no added vertical size, and it's a compact horizontal representation.

Inline labels:

pasted_file (222×478 px, 26 KB)

Google docs for comparison:

pasted_file (115×434 px, 9 KB)

I think focusing the link field first, and labelling it "link" instead of "target" (which is a bit technical) will help. We could also live-update the link as the text field is changed, which would avoid surprises when 'done' is clicked.

Losing occasional text-formatting is an acceptable compromise.

I've slept on that and now I agree.

Inline labels:

pasted_file (222×478 px, 26 KB)

Google docs for comparison:

pasted_file (115×434 px, 9 KB)

I think focusing the link field first, and labelling it "link" instead of "target" (which is a bit technical) will help. We could also live-update the link as the text field is changed, which would avoid surprises when 'done' is clicked.

I think that's the best for a link made on a raw text.
How do you deal with something like [[Parrot|{{lang|fr|perroquet}}]], where the label is built on a template?

One reason to consider keeping the internal-labels is that they're easier to slip into the existing MW extension version of the link inspector, since that has to accommodate the wiki search results alongside the fields.

How do you deal with something like [[Parrot|{{lang|fr|perroquet}}]], where the label is built on a template?

Is that a regular pattern somewhere? I don't think I've seen it used before, and am interested to see examples.

How do you deal with something like [[Parrot|{{lang|fr|perroquet}}]], where the label is built on a template?

Is that a regular pattern somewhere? I don't think I've seen it used before, and am interested to see examples.

I've quick-searched on articles I've written and found that exemple here: ''[[Gorre & Daphetid Railroad|{{lang|en|Gorre & Daphetid Railroad}}]]''

I've also searched (ctrl+F) on Histoire du communisme, the biggest article on fr.wp, where I've found:

  • [[groupe Barta|{{citation|groupe Barta}}]] or [[De chacun selon ses moyens, à chacun selon ses besoins|{{citation|De chacun selon ses facultés, à chacun selon ses besoins}}]]
  • [[Kang Kek Ieu|{{citation|Douch}}]]

There is also cases like [[1er octobre|{{1er}} octobre]] or [[18e congrès national du Parti communiste chinois|{{18e|congrès}} national]].

Some cases can be rewritten for sure, but not always.

How do you deal with something like [[Parrot|{{lang|fr|perroquet}}]], where the label is built on a template?

Most likely we will just not support cases where the link contains non-text through this particular interface, but they aren't that common.

I think it is important to separate the problem from possible solutions. As I understand it, the main problem occurs when adding a link without any previous text selection. In that context, the way to add a label has not much visibility. This generates confusion about where is the label supposed to be edited and makes it difficult workflows based on a different order than the one supported by default.

Provide a separate field for the link label as suggested above, makes label editing more explicit, but it is duplicating content that is already in the document which causes some different problems.

I was trying to explore a way to make the label editing more inviting right where it is going to be, without any duplication:

links-label-editign-invite.png (763×1 px, 413 KB)

When adding a link with no selection, instead of showing no content in the text, a placeholder element can be added in-place (styled similar to the link that it will become later) for the user to indicate the label, while a selector can be also available to pick the link target.

The content provided by the user in one field can inform the other (e.g., if I write "rice" as label, the Rice article should be among the suggestions when I click on the page search).

This is just a rough idea, but I'm curious to hear whether a solution along these lines is considered to help with the issue identified, or use it to identify which parts of the problem that I may be missing.

As I understand it, the main problem occurs when adding a link without any previous text selection.

I think the biggest problem here is in editing links.

For example, a user is editing a sentence like [[Tim Berners-Lee]] was born in [[1965]]. and wishes to correct the typo (he was actually born in 1955). Editing the visible text in VisualEditor without correcting the link target will result in [[1965|1955]]; editing the link target without correcting the text will result in [[1955|1965]]; both of these mistakes are easy to make in the current interface and difficult to spot when reviewing, if you're not looking at the wikitext source code.

As I understand it, the main problem occurs when adding a link without any previous text selection.

I think the biggest problem here is in editing links.

Thanks for the illustrative examples, @matmarex.
This issue seems to happen when editing a link that uses the page title as label. This may bring expectations of such information to remain in sync when changing the link (or even not being aware of the target potentially being different from the textual representation).

I think those cases (where the label and page name matches) could be detected by VE and provide some support to quickly solve the out-of-sync status. For example, I illustrated below how we can surface that once the user changed the label, the link is pointing to the old page but that can be changed to point to a page that matches the new label. Clicking on the suggestion (or using keyboard down arrow to select it + enter) will update the link target without writing it twice.

label-page-sync.png (263×972 px, 23 KB)

In the example above, having separate fields for editing label and target won't be very useful since we are not accessing the editing mode where those would be shown. It can be argued that making the edit label non-editable on the editing surface could force users to access the link editing panel, but that makes other scenarios more complex (e.g., quick label corrections, or using more complex content as link labels).

Another idea (strawman): If a wikilink's target is identical to label, we could just synchronize the target with the label when the label is changed. In both the link context and the link inspector, there would be a "lock/unlock" button to toggle this behavior for the currently focused link.

I think this would eliminate the user errors of the kind we see now. On the other hand, it would make it somewhat annoying when you actually wanted to change the label (especially when writing in languages with rich inflexion).

Another idea (strawman): If a wikilink's target is identical to label, we could just synchronize the target with the label when the label is changed. In both the link context and the link inspector, there would be a "lock/unlock" button to toggle this behavior for the currently focused link.

I think this would eliminate the user errors of the kind we see now. On the other hand, it would make it somewhat annoying when you actually wanted to change the label (especially when writing in languages with rich inflexion).

Is that like T56947?

This issue seems to happen when editing a link that uses the page title as label. This may bring expectations of such information to remain in sync when changing the link (or even not being aware of the target potentially being different from the textual representation).

I do think that's only half of the issue, mind you. There's:

  • It's easy to let the link text and URL get out of sync, if they were initially the same. This will show up with internal wikilinks, and URLs which are shown in full.
  • It's hard to change the link text completely. Selecting the entire thing by dragging is prone to accidentally selecting outside the link annotation and thus un-linking it when you start typing. Common case: people who paste in a URL letting it auto-link, and then want to add a descriptive label.

Your suggestion helps with the former, but not the latter. I grant that this is entirely anecdotal, but I started working on this task because the latter issue was bugging me in-practice while I used VE (whereas the former hadn't actually come up for me) so it's the one I have more personal connection to. :D

Is that like T56947?

Sort of. T56947 proposes basically exactly what @Pginer-WMF suggested -- a "you might want to update this" popup -- whereas @matmarex's suggestion is a more-aggressive version of that which forces the update unless you explicitly opt out.

I think it's basically the system proposed there, yeah. We don't currently have a convenient "suggest a change" system in context popups like this, but it's certainly addable if we want it. Making it keyboard-accessible as suggested would break the current paradigm, but it's not like context popups are currently keyboard-accessible anyway, so...

Another idea (strawman): If a wikilink's target is identical to label, we could just synchronize the target with the label when the label is changed. In both the link context and the link inspector, there would be a "lock/unlock" button to toggle this behaviour for the currently focused link.

Thanks for the proposal, @matmarex. As pointed out above, the difference is about how much automatic we need the process to be.

Changing the target automatically solves the problem without requiring the users to notice what is going on, which works rally well when it does the right thing. However it creates a stronger inconsistency of expectations when editing a link and has a higher cost for false positives:

  • Inconsistency of expectations. Some links will change their target and others won't. Changing "lemon" to "orange" will change the target, but changing "lemons" to "oranges" won't. Conversely, with the proposed approach editing the document will change always the label for all kinds of links, but it will provide a suggestion to change the target too for some of them.
  • Cost for false positives. The Tokyo article indicates that it is the "capital" (linking to "Capital of Japan", not to "Capital". The user can add a link to "Capital of Japan", change it to just say "capital" and either miss that it now points to a different article or get annoyed by having to recreate the link again on an autocorrect-like situation.
  • It's hard to change the link text completely. Selecting the entire thing by dragging is prone to accidentally selecting outside the link annotation and thus un-linking it when you start typing. Common case: people who paste in a URL letting it auto-link, and then want to add a descriptive label.

This is an interesting case too, thanks for pointing to this, @DLynch. I wonder if we could facilitate things by selecting the whole label when the link is selected/added (similar to what "add label" does for quick links). This can be applied to either to (a) links with a URL as label, or (b) links that got their label automatically and have not been edited before.
It is hard to anticipate how that may interfere with all the other editing processes, but it may be worth prototyping an example to check how it feels in practice.

Another problem to take into consideration are disambiguation pages. Example:

  1. I add a link to https://en.wikipedia.org/wiki/John_Quested_(producer)
  2. I then change the label (which has automatically been set to "John Quested (producer)") to just "John Quested".

In this case I do not want any automatism to change the link, and actually not even a suggestion to do so.

In this case this can easily be detected, as https://en.wikipedia.org/wiki/John_Quested is marked as disambiguation page. But doing the same steps with https://en.wikipedia.org/wiki/Albert_Einstein_(album) should work, too, without changing the link accidentally to https://en.wikipedia.org/wiki/Albert_Einstein, even though that page isn't a disambiguation.

Jdforrester-WMF set the point value for this task to 40.

For clarity, this task isn't likely to have work on it soon.

In general, this goes strongly against the design philosophy of the tools, making the process of adding links much "heavier" and context-switching. Re-validating the research results would take a lot of time and effort. In practice users don't have as many problems with this area as with others that are higher importance.

Well that news is a big disaapointment as the inability to quickly, easily, reliably and unambiguously change the destination the destination and/or description of a link is the biggest single impediment to Visual Editor.

When changing a link you could want to do one of three things:

  1. Change the label
  2. Change the target
  3. Chang both.

The only way to be sure that the change you want to make is the one being made is to:

  1. delete the current link, making sure to note the exact title and capitalisation of any section links
  2. type the label
  3. select the label
  4. open the link dialog
  5. enter the link, appending section links if necessary
  6. close the link dialog.

In Google Docs you need to.

  1. select the link
  2. open the link dialog
  3. change what needs to be changed
  4. close the link dialog

Google Docs users, to my knowledge, don't find this unnecessarily heavyweight but rather simple and reliable.

Well that news is a big disaapointment as the inability to quickly, easily, reliably and unambiguously change the destination the destination and/or description of a link is the biggest single impediment to Visual Editor.

When changing a link you could want to do one of three things:

  1. Change the label
  2. Change the target
  3. Chang both.

The only way to be sure that the change you want to make is the one being made is to:

  1. delete the current link, making sure to note the exact title and capitalisation of any section links
  2. type the label
  3. select the label
  4. open the link dialog
  5. enter the link, appending section links if necessary
  6. close the link dialog.

When you want to change the label, can't you just change the label text without opening the link editor? But yes, in certain label-edit scenarios, one hack you have to rely on is to make sure there is at least one character left behind with the link and delete that character last ... that hack is probably unpleasant, but at last for simple label text edit scenarios, it should work just fine?

... that hack is probably unpleasant, but at last for simple label text edit scenarios, it should work just fine?

It works okay, assuming that you actually know that you have to follow all of those steps. However, I think that we've proven that this is an invalid assumption in at least a substantial fraction of cases. We have thousands of editors who are accustomed to changing a link such as [[2016]] to [[2017]] by only changing the visible number. When you do that in VisualEditor, you end up with [[2016|2017]].

When you want to change the label, can't you just change the label text without opening the link editor?

The problem is that when you do that you could be intending to change the label without the link or you could be intending to change both label and link. There is no way for the software to know which you intend, and no way for the naive user to know which has actually happened without actively opening the link editor, but it is likely that the assumption will be that both were changed (per @Whatamidoing-WMF). Remember that VE is focused towards inexperienced and less-computer-literate users rather than power users, so there will be a very high proportion of users who do not know that you need to actively check what VE is doing.

Related to this, some way of identifying in the VE editing surface whether a link is piped or not would be useful in many different scenarios. I've only just thought of this but I've run out of time to investigate whether there is an existing task for this or not, so I'll pop it on VE/F and return to it this evening.

When you want to change the label, can't you just change the label text without opening the link editor?

There is no way for the software to know which you intend, and no way for the naive user to know which has actually happened without actively opening the link editor, but it is likely that the assumption will be that both were changed (per @Whatamidoing-WMF).

There is no way for the software to know, but the software could pay attention to some clues. As I mentioned in T55973#2792012, if a link targets a page that matches exactly the link label, and a user changes that label to the name of a different page, the software can suggest the target also to be updated. That would give visibility to the user on the mismatch between label and target, and let the user to update the target in one click if needed as some word processors do with spellcheckers.

if a link targets a page that matches exactly the link label, and a user changes that label to the name of a different page, the software can suggest the target also to be updated.

That would be very annoying every time someone needs to change the ending of a link. [[Example]]s is a good link. [[Example|Examples]] is bearable. Having Clippy ask you if you want to change the link from [[Example]] to [[Examples]] every time you try to fix the grammar in a sentence is not bearable.

if a link targets a page that matches exactly the link label, and a user changes that label to the name of a different page, the software can suggest the target also to be updated.

That would be very annoying every time someone needs to change the ending of a link. [[Example]]s is a good link. [[Example|Examples]] is bearable. Having Clippy ask you if you want to change the link from `[[Example]] to [[Examples]] every time you try to fix the grammar in a sentence is not bearable.

I think that whether the approach is annoying or not would depend on its execution, and how prominently the suggestion is presented. Clippy represents the annoying extreme of suggestion mechanisms: causing distraction as an animated character, and providing unreasonable suggestions ("what made Clippy think this could be a letter?"). In this case, the approach should be much more subtle (no animated characters) and the connection on why a suggestion is provided is quite clear (so even if it is not what you want, there is not a big surprise that the suggestion was provided). More like Google instant than Clippy.

In that particular example, given that "Examples" is a redirect to "Example", we can probably show no suggestion at all.

Deskana lowered the priority of this task from Low to Lowest.EditedAug 7 2017, 5:17 PM
Deskana added a subscriber: Deskana.

There is an insane amount of complexity with links in wikis due to the nature of how much they're used. Any change in this area would divert a lot of product and design time away from other projects, thus making changes here incredibly costly. Given the limited benefit of doing work here compared to other projects, this task is not going to be worked on any time soon. That is, after all, why James declined it twice. The debate here is interesting, but it is mostly academic at this point.

I'm really not at all sure that the actual benefits of this task to the people who are at the sharp end are actually understood by the developers. There is a reason that this has been resurrected at least twice, has at least four duplicate tasks, and the requests for it continue more than 5 years after it was first requested. Indeed this is one of just two tasks (T51969 is the other, and this is far more important than that) that are standing between where we are now and VE being intuitively easy for both new and power editors to use simply and reliably for non-specialist editing in almost all reasonable circumstances without making unforced errors.

Links are utterly fundamental to the way wikis work and VE is intended to be used by inexperienced users, so it is completely and utterly mind boggling to be told that something that forces unintuitive workarounds to achieve something that should be absolutely basic skill level 0.2 (at most) will not be fixed.

One possible approach to explore would be to expose a shortcut for editing the label that results in selecting the link label in place. In this way, there is no duplication of the places used to edit the label (avoiding the issues described above) while making the entry point for editing the label more explicit. We need to be cautious for the later not to cause issues, and test with users accordingly if we decide to explore this direction anytime.

The idea is illustrated below:

edit-label-and-select.png (263×1 px, 71 KB)

  • A separate section of the inspector is added about the label. The current label can be cropped if too long, it is there just for reference.
  • Clicking on the section hides the inspector and selects the text label inside the link for the user to type the new one. Temporary time-based tooltip can appear to indicate to "type the new label" if needed.

@Pginer-WMF That looks like it would resolve at least most of the issues I have with the current set-up, and as long as it is obvious that truncation has happened when it has then there are no immediate problems with it I can see.

FYI: Issues which are caused by the lack of a clear separate visualization of both link destination and link title on the German-language Wikipedia can be seen with this tool.

Looks like we're going with the solution Pau proposed above – please see T124305 for details.

Change 303956 abandoned by Jforrester:
LinkAnnotationInspector: add a "label" field

Reason:
It was decided to go with Iad48fb55 instead.

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

Deskana claimed this task.

The solution in T124305#4321883, which is implemented and will be live in two weeks, should effectively resolve this task.

Change 303956 restored by Esanders:
LinkAnnotationInspector: add a "label" field

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

Change 303956 merged by jenkins-bot:
[VisualEditor/VisualEditor@master] LinkAnnotationInspector: add a "label" field on mobile

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