Link feature UI/UX design

[oleq]

The design should follow Editor Recommendations.

A followup of ckeditor/ckeditor5-design#97.

[oleq]

In general, the process of linking comes down to the following diagram which depicts the transition from unlinked to linked state:

Still, there are many different ways to implement the UI/UX of the ? step and there are multiple factors to consider, like accessibility, number of clicks to use the feature, space consumption, etc..

The result of this research will quite likely set the course of the entire UI and user interaction in v5.

I see several different approaches to the problem but none of them is clearly superior to the others:

Balloon pinned to the selection

Balloon would disappear when the selection changes.

Pros:

• It could appear automatically when the link is selected in editable (one click less to edit).
• Contextual, visually clear – attached directly to the selection.
• It works in Accessibility Checker.

Cons:

• Must follow when content is being scrolled; tricky to implement and maintain.
• Must move to remains centered as the text of the link is written by the user; not very nice UX.
• Tricky when the link wraps to a new line (spans between two lines).
• Floats over the content and UI making some toolbar buttons and text inaccessible with mouse.
• Looks "heavy" if there are many items in it like additional fields for link attributes, some checkboxes (unlikely to happen).

A panel pinned to the toolbar button

Panel could disappear when the selection changes (?).

(also my favorite)

Pros:

• Easy to implement, always attached to the button (immune to the scrolling, text wrapping)
• Still makes sense because the panel remains in the context of the link button.

Cons:

• Floats over the content making text inaccessible with mouse.
• Looks "heavy" if there are many items in it like additional fields for link attributes, some checkboxes (unlikely to happen).

Toolbar tab

The tab becomes accessible when the link can be inserted or the link is already selected in editable. When clicked, the tab switches the toolbar to "link mode" revealing link–related inputs and stuff.

Pros:

• No extra UI floating over the content.

Cons:

• Requires an extra "click" to use.
• Bloats the toolbar by bringing tabs.
• Might not work with all types of toolbars, like very narrow toolbars (i.e. 2 buttons only), etc.
• There's no way to easily use other features (like "bold") when in "link mode".
• Switching to the toolbar "link mode" could be an accessibility killer.
• Limited space for additional fields for link attributes, some checkboxes.
• How to unlink?

Dialog

Pros:

• It's the most popular UI component in the universe.
• Provides required level of accessibility (like in CKEditor 4).
• Could accommodate lots of additional fields for link attributes, some checkboxes, even tabs. OTOH, given the minimalistic approach to v5, it won't be necessary.

Cons:

• Covers the entire webpage so nothing else can be accessed with keyboard or mouse as long as the dialog is visible. Consumes lots of space.
• Needs to be "canceled" to reach the content, even if invoked accidentally. For balloons/panels, a simple click/selection change would be enough.
• Feels disconnected from the editing process and the editor UI. Inline components feel more smooth and integrated.

---

Which strategy feels the best? Which is the easiest to implement, extend and maintain?

[scofalik]

Great research, as always.

I just wanted to say that I am fine with spending more time on researching tooltips solutions. This is something that we have not tried yet and we will never know whether we like it or not, unless we do them. Since they could be used for different features too, it's nice to get some feel of them. So, even if we scratch them and remove the tooltip solution, I don't think that trying them will be a wasted time.

As far as which solution is better, both have their problems, but I think that you overestimated them. The first one is only problematic when you scroll the selected content out of sight. I am not sure what should happen, if balloon should be scrolled-out too, or maybe it should just disappear? Other than that this is the solution Google Docs is using and I would check it closely if you are afraid about UX. Positioning can be solved, if you don't like moving tooltip, let's pin the tooltip at the beginning of the link, or move it to the side.

My question is how exactly do you insert link? You select some text, click link icon and then empty tooltip appears? What about collapsed selection?

I like the second solution less because it covers content. Other than that it is fine, too.

Dialogs sucks because they disconnect the user from the experience too heavily. I think we should use them only when everything else failed. And I don't think we should propose multi-tabs as the primary UX solution.

[oleq]

So, even if we scratch them and remove the tooltip solution, I don't think that trying them will be a wasted time.

👍

Other than that this is the solution Google Docs is using and I would check it closely if you are afraid about UX.

Remember that GD is a closed, controlled environment. Google can implement there whatever they want, using whatever technology and hacks. CKE 5 is a component living a rough, unpredictable env called "random web page" and must work no matter how complex and hacky the surroundings might be.

My question is how exactly do you insert link? You select some text, click link icon and then empty tooltip appears? What about collapsed selection?

It's all the same. Collapsed selection or not, one must click toolbar button to insert link, activating the UI. Do you have other ideas how to optimise it? (not talking about autolinking)

Dialogs sucks because they disconnect the user from the experience too heavily. I think we should use them only when everything else failed.

👍

And I don't think we should propose multi-tabs as the primary UX solution.

👍

[depoulo]

Having implemented a floating balloon solution before, I can tell you that it is indeed not trivial to implement (although not a lot of code either, but I didn't need to solve the scrolling issue), and especially if you want to retain the selection, you'll have to either use an iFrame (this is what Google does) or temporarily wrap the selection in an HTML tag (this is what Trix does). That being said, I like it because of its minimalistic appeal.

[Reinmar]

Yeah, retaining the selection is always fun :) Fortunately, we've got a lot of experience from CKEditor 4. There's been a mechanism for saving selection before blur. It's been used e.g. when dialogs were opened or by a11y features (such as keyboard navigation through the toolbar).

In CKEditor 5 we represent the selection in the model (on the AST), so once the editable is blurred, the selection simply stays in the model on its previous position. Later, you just have to focus the editable and the renderer will take the selection from the model and render it in the DOM. It means that most of the time you won't need to think about it.

[Reinmar]

I'm for the balloon as well. It's the most "in-place" solution and, unlike a panel pinned to the toolbar, it will work when there's no toolbar (textarea/input-like editing – e.g. FB or Twitter).

I wouldn't worry about bloatiness of such a solution if you add more stuff into the tooltip, because IMO you simply shouldn't. If you need more fields (like "more" or "advanced options"), just add a button opening additional modal dialog. The tooltip should stay simple, useful for 99% cases when you only want to set one or two things.

As for unlinking – beside "Save" there should also be "Unlink" button in that tooltip.

Now, that's about the UI. What, IMO, matters the most is the UX, in case of which the actual way how the URL input is displayed plays a secondary role. Things that matter are specific use cases. E.g.:

1. When typing a sentence I want to be able to press CTRL+K at any moment, then type the address and then fill the link text (either in the editable or in the tooltip. CKEditor 4 forces (this will be fixed in 4.6 AFAIR) you to first write the text, then select it, then press the keystroke and type the URL. This must be super simple.
2. Automated and "on keystroke" linking pasted and typed URLs. E.g. if you paste a URL, then it can be safely autolinked. But if you paste a lot of content or you typed that URL in some specific way and it wasn't autolinked, just press CTRL+K having selection in the URL text and that URL should be converted into a link.
3. If you have a link which href equals text, update its href when its text is changed.
4. Allow typing at the end of the link. In most editors if you type at the end, the text is inserted outside of the link. This is tricky, because there must also be a way to escape the link.
5. How to quickly edit and existing link using only the keyboard? This is important for a11y and for simple UX. E.g. I move selection to the link by using arrow keys. IMO, that shouldn't result in opening the tooltip yet, because that could be irritating. You could, however, open the tooltip (and focus ofc) by pressing CTRL+K. Then Esc must move you back to the editable. However, clicking on the link to place selection inside it should result in opening the tooltip without any additional action.

Etc, etc. Regardless of our approach to the dialog/balloon, we must solve the above issues, because they make for 90% of the UX. Linking should be fast and smooth using mouse or keyboard.

[fredck]

Yeah, retaining the selection is always fun :)

I think that the complicated part of it is keeping it visible while the balloon has focus.

[Reinmar]

Oh, that... I remember that we've had a plugin for that in CKE4, but I recall that we didn't like it and decided to not use it. In CKE5 its implementation will be very simple and its behavior won't affect anything, so we could bring back this feature.