In T91285#1654273, @Quiddity wrote:Would it be possible to have the cursor default to outside the link, after inserting it?
Because: With the Current/updated behaviour, I have to add a [right-arrow] keypress, in order to keep typing, after entering a link. This is complicated, non-intuitive, and not consistent with other richtext editors (afaik).
It's especially a concern here, given the previous link continuation bug behaviour, where I'm accustomed to an erroneous display, and I've learned to ignore link text continuing past where it was meant to end (until I hit [enter] or otherwise trigger a re-render).
Current behaviour (post-update):
- I type foo bar
- [ctrl-k]test
- [enter]
- zow
This results in
foo bar [[test zow]]
My desired behaviour: (identical to gmail, etc)
- I type foo bar
- [ctrl-k]test
- [enter]
- zow
This results in
foo bar [[test]] zow
Description
Description
Related Objects
Related Objects
- Mentioned In
- T93854: Facilitate editing the text of a link (especially adding text to the beginning/end of it)
T121895: Pasting text for a link label removes the link
T91285: Change how link annotations work to actively enter/leave the annotation - Mentioned Here
- T265166: Link context not shown after editing a link
T91285: Change how link annotations work to actively enter/leave the annotation
Event Timeline
Comment Actions
The problem with this is that the cursor being outside the link means no context, so no feedback that the link was created and is going to the right place.
Comment Actions
The text would be blue/purple/red, so that's feedback that a link was created. The user would've established that it was going to the right place, whilst entering the link using the handydandy link inspector. :-)
Comment Actions
Other websites with editing interfaces - Quora comes most readily to mind - don't provide a URL as feedback after making a link (in the sense of showing both the external link and the clickable text that leads to it), they just show the text that, when clicked, will lead somewhere. So leaving the cursor inside the link is counter to what editors experience elsewhere.
More importantly, people adding information to a Wikipedia page, using VE, can't (currently) make a link and then continue typing text, because what they type gets incorporated into the link. Rather, they have to use a right-arrow to escape the link, then start typing. That again is counter to what they experience in other websites with WYSIWYG editing - make a link, and when they keep typing, what they type is plain text.
Comment Actions
Sure, though in testing we've seen that most users don't notice such things as obviously.
The user would've established that it was going to the right place, whilst entering the link using the handydandy link inspector. :-)
The point about after-action feedback is that it confirms for people who aren't as confident as you that it'd worked. :-)
"Other people have terrible interfaces" is not the best argument, but I appreciate that providing a similar editing tool to that which users may have experience of elsewhere is not a bad thought.
More importantly, people adding information to a Wikipedia page, using VE, can't (currently) make a link and then continue typing text, because what they type gets incorporated into the link. Rather, they have to use a right-arrow to escape the link, then start typing. That again is counter to what they experience in other websites with WYSIWYG editing - make a link, and when they keep typing, what they type is plain text.
True. Remember that VisualEditor is not a WYSIWYG editor, despite the consistent disinformation spread by people outside the development team that that's the objective. :-)
Comment Actions
I don't understand why it's important to capture the user in link-label editing just so they know there is a link there. They would have just hit Insert, and the dialog would have gone away, so I would hope they would expect a link to be there. If they're not sure, they could always click back on it. Can you point to those user tests results, since they sound counter-intuitive?
Or, if it's really necessary to keep the user captured, could we at least let the space bar escape the link-label editing? The most common case, I think, would be to say "blah blah [[whatever]] and more text". Having the normal/common case work smoothly would be awesome, even if it makes other cases slightly more difficult.
Comment Actions
Showing the link context after insertion means we don't need a confirmation stage in the link inspector. If we moved out of the link after insertion we'd need another way to tell the user which link they just inserted as its easy to make mistakes with autocomplete widgets.
Comment Actions
Adding a link works as described in this task now. I couldn't easily find when it was changed.
Comment Actions
I'm still seeing a problem:
(1) I type "The CEO", then select (highlight) the word "CEO"
(2) I click on the link icon (or ctrl-K; same difference)
(3) The "Add a link" dialog appears
(4) I select (click on ) "CEO of public schools"
(5) The dialog disappears
(6) I hit the space bar, continuing to type my sentence
(7) VE deletes the (linked) word "CEO", because the focus is still inside the linked text. THIS IS WRONG. I should not have to hit the right-arrow key to move the focus; that's not only an extra keystroke, it's not in the least bit intuitive for a new user.
VE behaves differently if, in step 4, I click "Done" or hit "Enter" on my keyboard, rather than clicking on a choice - it displays the link dialog, as confirmation. It also displays the link dialog if, in step (4), I click on the second choice, which is CEO as a redirect - it treats that user choice as being the equivalent of not making a choice at all, but instead clicking on "Done".
Why, after the "Add a link" dialog is closed by a link being created, doesn't VE always display the link dialog as confirmation? Then there wouldn't be any question that the user knows what the link is.
A related issue: the design of the link dialog box is problematical. WIthin that dialog box, there are four clickable links/items, none of which are a way of the user saying "Sure, looks good to me". And if the user hits "escape", which might be expected to close the dialog box, that instead invokes a new dialog, asking if the user wants to leave editing mode without saving.
The only way that I can see for a user to say that the created link is okay (that is, to get the link dialog to close without changing the link that has been created is for the user to click on text in the main window - text that is outside the dialog. That is not exactly obvious. It would be really nice for the user to be able to click "OK" or "continue" or "Done", within the dialog, to close that dialog. Or to have an "x" that closes that dialog.
And, to add injury to insult, if the user, who has been - in this scenario - typing the start of a sentence, tries to exit the link dialog by clicking to the right of the [linked] text "CEO", to continue typing the sentence, the result isn't what might be expected. VE interprets that as the user wanting to change the label for the link - because the focus is still inside of "CEO". That's somewhat logical, in that the user may have missed the "Change text" link in the link dialog - but if the user hadn't been trained to think "just click outside the dialog box to close it", this wouldn't be an issue.
Comment Actions
Why, after the "Add a link" dialog is closed by a link being created, doesn't VE always display the link dialog as confirmation? Then there wouldn't be any question that the user knows what the link is.
This was fixed in T265166.
And if the user hits "escape", which might be expected to close the dialog box, that instead invokes a new dialog, asking if the user wants to leave editing mode without saving.
If I press escape while editing a link, it closes the link editor, but doesn't leave editing mode (unless I press escape again)