#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.
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)
Change History (35)
#2
@
11 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.
10 years ago
#4
@
10 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
@
10 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:
↓ 7
@
10 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
@
10 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
@
10 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. :)
#9
@
10 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:
↓ 11
@
10 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
@
10 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.
10 years ago
#13
@
10 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.
This ticket was mentioned in Slack in #core-editor by iseulde. View the logs.
10 years ago
#19
@
10 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:
↓ 24
@
10 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.
This ticket was mentioned in Slack in #core by drew. View the logs.
10 years ago
#24
in reply to:
↑ 20
@
10 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.
10 years ago
This ticket was mentioned in Slack in #core by drew. View the logs.
10 years ago
#27
@
10 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
@
10 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
@
10 years ago
- Keywords needs-patch added; has-patch removed
- Priority changed from normal to high
#30
@
10 years ago
- Owner set to azaozz
- Resolution set to fixed
- Status changed from reopened to closed
In 32017:
Current:
Proposed: