Include 'source anchor' in wpLink quicktags modal for improved ui/ux

[netweb]

Over on bbpress.org a common issue for users is links posted are missing the 'source anchor'.

(The issue isn't seen on ​http://wordpress.org/support/ due to bbPress v1.x as different editor is used)

The following behaviour is also seen when creating a post/page in WordPress using the 'text' editor.

The default modal for the 'link' quicktag includes form fields for URL and Title, in many cases users (particularity those unfamiliar with HTML) think the 'Title' will be the text that can be 'clicked' on to take you to the 'destination anchor' when in fact this is the <a> elements title attribute and not the 'source anchor'.

As an example of what we expect to see:

...some text...
Here's a photo of 
<a href="http://example.com/neatstuff.gif" title="Me scuba diving">me scuba diving last summer</a>
...some more text...

This is what we end up seeing (not that you can see these anchors without viewing the source):

...some text...
Here's a photo of 
<a href="http://example.com/neatstuff.gif" title="Me scuba diving"></a>
...some more text...

Using the modal in it's current state after adding the URL and Title via the modal the cursor is returned before the closing anchor tag to facilitate the entry of the 'source anchor' though for whatever the reasons might be this is often skipped, ignored, or un-noticed by the user.

Per the screenshots in the follow up comment in a moment I propose we extend the existing modal to include a form field for the 'source anchor' to improve usability/user experience.

[netweb]

Current:

Proposed:

[designsimply]

Another possible alternative: make the behavior match the visual editor where the link button is not clickable until link text has been selected first.

[iseulde]

I'd say the text editor is for more advanced users who know HTML. We could disable that button if no text is selected, but what about users who just want to add it later (the cursor is moved to the right place).

[netweb]

The current ambigousness of the text Title vs the currently non-existant Link Text to everyday users who do not have any HTML skills is the crux of the issue, these users expect that the Title will contain the anchor text that will be seen on screen, they have no idea that this is actually the title="Me scuba diving" anchor title element.

I'm not sure what the ideal UI/UX for this should be, be it a verbiage clarification of the Title string and context, or including the Link Text string and form field, but it should something better than it's current iteration.

As we start moving the Rosetta (International WordPress.org forums) sites to bbPress 2.x and "down the road" WordPress.org support forums to bbPress 2.x we need the "text editor" to be friendly for all users, not just advanced users who know HTML.

[iseulde]

So there is no visual editor available? It sounds like you're giving them the wrong tool. If they don't have any HTML skills, why give them an editor that will generate HTML?

Would renaming it to "Title attribute" help? Or would just disabling it if no text is selected be better?
I'm still not sure if that addresses the main issue though.

[netweb]

Replying to avryl:

So there is no visual editor available? It sounds like you're giving them the wrong tool. If they don't have any HTML skills, why give them an editor that will generate HTML?

Correct, the Visual Editor is not enabled by default, it can be enabled via a filter though, the issue of using the Visual Editor vs the Text Editor are both historical (forum users want a simple BBCode type experience) and complicated due to these two issues:

• Switching between the Visual Editor and Text Editor the code/post/text changes (This hasn't been closely looked at since switching to TinyMCE v4.x, but is planned)
• Allowing users to replace the Visual Editor with their own editor of choice

bbPress 1.x is NOT a WordPress plugin and uses its own editor, adding a link on WordPress.org support only prompts for the link, no title or link text, it works and it's simple ​https://wordpress.org/support/forum/alphabeta#postform

As bbPress 2.x IS a WordPress plugin we rely on WordPress' text editor "out of the box" so to speak.

Replying to avryl:

Would renaming it to "Title attribute" help?

I don't think renaming Title to Title attribute would help, this would still be clear as mud for those with no HTML knowledge.

Replying to avryl:

Or would just disabling it if no text is selected be better?

At the moment I think that would be better, though still not ideal, some conditional scripting foo would help but I agree in that I don't think this addresses the main issue.

p.s. I have no such JavaScript foo skills, so that is one reason I've not looked at this as an option ;)

[iseulde]

If the user wants to BBCode, then fine, they can use the text editor. I think there's even a TinyMCE plugin for it. In this case you still have an advanced user (I think) who would understand HTML.

It sounds like the main issue is that you don't provide a visual editor. :)

[helen]

I think I would like wpLink to show a Link Text field and hide/remove the title field, which is not something that really should be used much if at all anyway. This is much more in line with other editing experiences out there, and also friendlier for places where selecting text isn't nearly as easy (touch devices). If no text is selected, then it inserts the text + link. If text is selected, then it pre-populates the field and allows you to edit it.

[iseulde]

Currently the link button is disabled in the visual editor if no text is selected. Then that should change? What you describe btw happens when using the TinyMCE link plugin. :)

[helen]

Replying to avryl:

Currently the link button is disabled in the visual editor if no text is selected. Then that should change? What you describe btw happens when using the TinyMCE link plugin. :)

Yeah, it would need to change. And I'm sure it works in any number of places in that way, pretty common editing flow.

[iseulde]

Yeah, it would need to change. And I'm sure it works in any number of places in that way, pretty common editing flow.

Fixed in the patch. Cleans up the plugin quite a bit.

[iseulde]

First attempt...

[azaozz]

In 31713:

wpLink: replace the "Title" field with a "Text" field and populate it with the link text when editing an existing link or with the selected text if any.
Props iseulde. See #28206.

[azaozz]

In 31714:

wpLink: change the text label to Link text, always focus the URK field, fix Ctrl/Cmd + K shortcut. See #28206.

[helen]

In 31715:

wpLink: Title case "Link Text", as it's an existing string.

see #28206.

[helen]

On using it more - wondering what we should do if somebody enters a URL but no text. Also wondering if perhaps the focus should be in the link text field if it's present but empty (that is, the button/shortcut was invoked without a selection). Reverse tabbing is always a little weird.

[azaozz]

Yes, on opening we should focus the link text field when empty. Will add that.

Thinking that on saving, when the link text is shown and is empty, we should treat it the same as the URL field. If a link is being edited, remove it, if this was a new link, don't insert it.

[ocean90]

In 31724:

JSHint: Remove an unused variable.

see #28206.

[TobiasBg]

Replying to azaozz:

Thinking that on saving, when the link text is shown and is empty, we should treat it the same as the URL field. If a link is being edited, remove it, if this was a new link, don't insert it even if there is an URL.

We could also just use the URL as the link text, if no link text was specified, maybe...
Not inserting a link at all might be unexpected for users who don't completely get the concept of "hiding" a URL behind a link text.

[DrewAPicture]

Let's call this fixed. For all intents and purposes, the experience is the same, save for a few details:

• Links can now be added regardless of whether text is selected
• The Link Text can be edited in the modal (as expected)
• Removing the Link Text and clicking Add Link has no effect on the existing link or link text (as expected)

[helen]

Let's put the URL field on top and just have it always get initial focus - reverse tabbing is always weird, as noted in #30468.

[azaozz]

In 32017:

wpLink: always show the URL field at the top.
Fixes #28206.