V8 Url Link Picker Title UI Weirdness

[marcemarc]

When you use the Url Link Picker in Umbraco 8.6, have noticed editors struggling with two things related to the UI of the Url Picker... when setting the Link title...

Firstly:

If the editor is picking a page from the site to link to, then they are inadvertently adding the Link title text first, because it's presented first,

then when they pick the content item from the tree... 'what they have entered' is replaced with the name of the item they have picked.

But that isn't necessarily what they wanted the Link title to be!

I'm wondering if it's better to only update the Link Title with the picked Content Item name if the Link Title field is empty at the time of picking? although if somebody mis-picked and had to pick again you would expect it to update, so I guess you'd set a flag if somebody manually typed in the Link Title first...
... or maybe it would be clearer if the Link Title wasn't positioned in between the manual link and the content picker.

Secondly:

If a URL is entered manually into the link picker, and the Link Title is left blank:

Then clicking 'Submit' (is Submit the right word here?) to close the dialog leaving the blank Link title results in this being automatically populated with the manual Url:

If you click the 'Edit' button, to edit the link, you'll see the 'link title' has definitely been automatically updated to be the link URL:

Often this leads to an accessibility issue, where the Link title is written out as the link 'title' attribute, and this isn't a useful title to have? Is it ever useful to set the Link Title to be the Url?

If the Link title can be left blank it allows you to handle the situation in code easily, otherwise you have to check if Link Title != Link Url to determine if it has some useful text in!

There is this previous issue about the link picker overlay: #7749 but I don't think these two points are duplicated here.

[abjerner]

@marcemarc I agree with what you're describing (that guy in the other issue was absolutely also onto something 😀).

I'm however not entirely sure how we best change improve the UX around the link title. Maybe we should rethink the entire dialog?

To an editor, it may not be entirely clear what a link title actually is. Some editors may not even know about the title attribute and what purpose it has. And in the past, we've used the link title as the actual text of the link, but as the value for the title attribute in other cases.

If we think about accessibility, the best solution would in some cases be to have a field for the link title and another for the link text. This is currently not possible. Maybe some use cases require a value aria-label as well?

It may be out of scope, but what if a link needs additional information as well? Eg. an icon? A description?

To at least solve some of these issues, we're utilizing our Elements package to create link items based on IPublishedElement.

Say we have a list of links, it could look like this (sorry for the Danish):

While the link item is based on IPublishedElement, clicking Add/Tilføj will initially open Umbraco's link picker overlay:

Submitting the selected link will close the link picker overlay, but then open a new overlay for editing the actual IPublishedElement, pre-filled with the link and even the link text:

Supposedly the new block editor should be able do something similar, so maybe this should be the desired way to create links going forward? Then if you need a link title, you add a property for it to the element type. If you need a link text, you add a property for it to the element type. And so on...

IMO this will let developers and editors create super flexible links. But there is of course the downside that links may then be more complex and harder to setup - especially if you are new to Umbraco and this setup.

Again, I'm not sure what the best approach to resolve this is, but I felt my thoughts were worth sharing. Above is the solution we've found that works best for us - at least until something better comes along.

I've been considering writing our own link picker overlay from scratch - partially to address some of the points in my issues, but also generally to improve the UX. But as there are only 24 hours in the day, the progress has only gone as far as it being an item on my TODO list.

---

Anyways - I may have gone slightly off topic, so if we strictly look at the link title, maybe the user could be prompted to confirm or reject or confirm the link title being overwritten if a link title has been entered manually? And maybe the link data type should allow turning this prompt on or off?

I can figure out if using the overlay service for such a prompt would take up too much space - if so, we may have to create a new UI compontent for this 😮

[marcemarc]

Hi @abjerner, yes when I was seeing this, I wasn't really sure on the solution either... so I thought I'd voice the problem. (we use Nested Content now for links too, and it's just more natural for the editor to ignore the LinkTitle when it's presented on the dialog, and have textboxes as part of the Nested Content item)... but reading through your reply has got me thinking, and the reason I think why it causes confusion is a bit klunky is the dialog is trying to do three 'different things' and competing with itself, and in your issue, you identify the 'busyness' of the user interface... so many options.. the grouping and order of the elements isn't simple and obvious.

So the three things?

• Enter a Url
• Pick a Content Item
• Pick a Media Item

In each of these circumstances, a link is produced, and in each of these circumstances the Link Title attribute might need to be set... the confusion is the three options are presented at the same time, they are not clearly visually separated and tasks from one of the 'options' appears to 'update' the other section... eg picking an item changes the url field and makes it grey and uneditable...

So I think, you are right, it is the whole dialog that is the cause...

My thinking therefore from a UI perspective that the resolution might be to separate these three different 'ways' of setting a link.

So when you 'Add a link'
There is a further step, to ask:

Enter Link Url
Link To Content
Link To Media

It's an extra step in the process, but would then allow the dialog presented for the Link entry to then be focussed on the particular task (linking to Media currently opens another dialog), possibly the link json would need to store it's type, so that when you Edit an already picked link, the appropriate dialog is automatically shown...

One issue is switching between types, if you made a mistake, but currently if you had picked a Url, and needed to change it to be a typed version, you can't - so if it 'wasn't easy to switch between chosen types' to begin with it wouldn't be a regression... you have to delete the link and recreate it

Or is that too complex for adding a link?
It might feel like an extra step would be slower, but I observe editors so often having to open the link picker twice, it might not be?

Or maybe the + add link option, before the dialog has the three options, so there is no extra step, to opening the focussed dialog for the particular link scenario?

================================

Alternatively, have also felt for a while, and @leekelleher talked about it in our CG talk a few years ago, at there being slightly 'richer' core property editors for common web interactions, so for example their being a 'Button' Property Editor in the core, that allows you to set the typical options we all use for displaying a call to action button, or group of buttons - that yeah, can easily be handled with Nested Content, or Macro, but you could do something really visually nice with the editing experience, and save time for implementors, who are just implementing the same thing on every site - or indeed with Uno in mind...

[nul800sebastiaan]

Thanks for the discussion all!

As we saw in the alt attribute issue the title attribute is probably not all that helpful anyway in most cases and certainly can be actively harmful in A11Y scenario's, so maybe it should be completely de-prioritized anyway?

As Anders said: yes, the block editor will allow you to completely build up links with icons and any other elements you might need. But this is a highly specialized use case and probably won't work in (for example) the rich text editor.

Combined with Anders' related isssue it is clear that we have some quite interesting UX challenges.
Yes, we acknowledge (and have talked at HQ about this) that the link picker is currently not using great UX and we would love for it to be a whole lot better.

We're currently not actively working on improving the UX of this picker but we would welcome proposals that can be implemented through a PR. Please don't work on implementation yet, we'd love to see a mock-up first to make sure we're all on the same page before spending too much time implementing the proposal.

[umbrabot]

Hi @marcemarc,

We're writing to let you know that we would love some help with this issue. We feel that this issue is ideal to flag for a community member to work on it. Once flagged here, folk looking for issues to work on will know to look at yours. Of course, please feel free work on this yourself ;-). If there are any changes to this status, we'll be sure to let you know.

For more information about issues and states, have a look at this blog post

Thanks muchly, from your friendly Umbraco GitHub bot :-)

[umbrabot]

Hiya @marcemarc,

Just wanted to let you know that we noticed that this issue got a bit stale and might not be relevant any more.

We will close this issue for now but we're happy to open it up again if you think it's still relevant (for example: it's a feature request that's not yet implemented, or it's a bug that's not yet been fixed).

To open it this issue up again, you can write @umbrabot still relevant in a new comment as the first line. It would be super helpful for us if on the next line you could let us know why you think it's still relevant.

For example:

@umbrabot still relevant
This bug can still be reproduced in version x.y.z

This will reopen the issue in the next few hours.

Thanks, from your friendly Umbraco GitHub bot 🤖 🙂

[marcemarc]

@umbrabot still relevant