WordPress.org

Make WordPress Core

Opened 3 years ago

Closed 2 years ago

Last modified 2 years ago

#28206 closed task (blessed) (fixed)

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

Reported by: netweb Owned by: azaozz
Milestone: 4.2 Priority: normal
Severity: normal Version: 3.9
Component: Editor Keywords: needs-patch
Focuses: ui Cc:

Description

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.

https://i.cloudup.com/OD27HnfBmt.png

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.

Attachments (2)

28206.patch (1.8 KB) - added by iseulde 2 years ago.
28206.2.patch (11.5 KB) - added by iseulde 2 years ago.

Download all attachments as: .zip

Change History (35)

#1 @netweb
3 years ago

Current:
https://i.cloudup.com/c6OFtiv1eo.png

Proposed:
https://i.cloudup.com/ZQl1399adq.png

#2 @designsimply
3 years ago

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

This ticket was mentioned in Slack in #bbpress by netweb. View the logs.


3 years ago

#4 @iseulde
3 years ago

  • Keywords close reporter-feedback added
  • Version changed from 3.9.1 to 3.9

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).

#5 @netweb
3 years ago

  • Keywords close reporter-feedback removed

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.

#6 follow-up: @iseulde
3 years ago

  • Keywords reporter-feedback added

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.

#7 in reply to: ↑ 6 @netweb
3 years ago

  • Keywords reporter-feedback removed

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 ;)

#8 @iseulde
3 years ago

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. :)

Last edited 3 years ago by iseulde (previous) (diff)

#9 @helen
3 years ago

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.

#10 follow-up: @iseulde
3 years ago

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. :)

#11 in reply to: ↑ 10 @helen
3 years ago

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.

This ticket was mentioned in Slack in #core-editor by helen. View the logs.


2 years ago

@iseulde
2 years ago

#13 @iseulde
2 years ago

  • Keywords has-patch added
  • Milestone changed from Awaiting Review to 4.2

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
2 years ago

#14 @iseulde
2 years ago

First attempt...

This ticket was mentioned in Slack in #core-editor by iseulde. View the logs.


2 years ago

#16 @azaozz
2 years ago

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.

#17 @azaozz
2 years ago

In 31714:

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

#18 @helen
2 years ago

In 31715:

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

see #28206.

#19 @helen
2 years ago

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.

#20 follow-up: @azaozz
2 years ago

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 even if there is an URL.

Last edited 2 years ago by azaozz (previous) (diff)

#21 @ocean90
2 years ago

In 31724:

JSHint: Remove an unused variable.

see #28206.

This ticket was mentioned in Slack in #core by drew. View the logs.


2 years ago

#23 @helen
2 years ago

  • Type changed from enhancement to task (blessed)

#24 in reply to: ↑ 20 @TobiasBg
2 years ago

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.

This ticket was mentioned in Slack in #core by drew. View the logs.


2 years ago

This ticket was mentioned in Slack in #core by drew. View the logs.


2 years ago

#27 @DrewAPicture
2 years ago

  • Resolution set to fixed
  • Status changed from new to closed

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)

#28 @helen
2 years ago

  • Resolution fixed deleted
  • Status changed from closed to reopened

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.

#29 @DrewAPicture
2 years ago

  • Keywords needs-patch added; has-patch removed
  • Priority changed from normal to high

#30 @azaozz
2 years ago

  • Owner set to azaozz
  • Resolution set to fixed
  • Status changed from reopened to closed

In 32017:

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

#31 @DrewAPicture
2 years ago

  • Priority changed from high to normal

This ticket was mentioned in Slack in #core by netweb. View the logs.


2 years ago

This ticket was mentioned in Slack in #forums by netweb. View the logs.


2 years ago

Note: See TracTickets for help on using tickets.