Tapping the link icon for a previously created link opens link settings in the app while the same action deletes the link on the web

[designsimply]

In the app, tapping the link icon for a previously created link lets me edit it.

^{Tested with WPAndroid alpha-171 on Pixel 3 Android 9.}

On the web, that same action of clicking the link icon removes the link or "unlinks". Because of the difference, I felt it was disconcerting to tap that link icon in the app because I thought it might remove the link.

^{Tested using WordPress.com on 2019-05-17.}

Ideally, editing should be as consistent as possible in both places. However, I understand it may be an acceptable difference between web and mobile in this case and wanted to raise it as a question for design just in case. 😊

[iamthomasbishop]

Thanks for raising this concern @designsimply! This is something I have seen much confusion about this while running usability tests on mobile-web Gutenberg last year – when given tasks to add/remove links, most folks stumbled and completely missed that icon, or simply gave up and manually highlighted and removed links.

So when starting on mobile GB, I intentionally approached it differently with that in mind. I should also note that during early competitive analysis, I found that most others editors work similarly to how it works on mobile. With all that said, I'm certainly open to shifting if it makes sense, but I'd prefer not to go with a less-obvious solution just to reach parity.

Would love to hear others' opinions on this, because I can certainly be convinced by others smarter than myself :) // cc @megsfulton @SylvesterWilmott @mattmiklic @jasmussen @karmatosed

[jasmussen]

What a great discussion, and thanks for the ping. Let me restate what the current behaviors are, just so that you can correct me if I'm wrong:

Mobile web:

• Select text to highlight it, tap link button to make a link
• Tap link to show popover that allows editing that link
• Tap "unlink" button to remove that link

Mobile native:

• Select text to highlight it, tap link button to make a link
• Tap link, then tap link button to edit it
• A bottom sheet appears with options for that link, including a button to remove the link.

Is that a correct assessment?

Honestly for a mobile experience it feels like both have their pros and cons. The web version has consistency with desktop, and even if icon-only, it feels like there's an obvious way to remove the link when first selecting it. The native version, on the other hand, feels more stable insofar as all link manupulation happens in a bottom sheet that allows lots of finger friendly tapping space and even text labels. In the latter, it just feels like it's a little trickier to discover how to remove the link — you have to tap the link button first, then it's easy.

Not endemically difficult. But if we were to explore a better experience, we might look at how Google Docs does it:

You select text first, to get a contextual popover that allows you to create a link. This bit I'm not in love with personally.

But once the link has been made, tapping the link surfaces options to edit the link, or remove it, then and there.

The popover we already have in mobile web, should we have it in mobile native also, but make the "remove link" bigger?

Alternately, does it make sense for the link sheet to simply invoke immediately when you tap a link you already created, instead of having to first tap the link button? This seems like it would unify the two experiences, except for the native using a bottom sheet instead of a popover.

[iamthomasbishop]

Sorry for the delay on my reply!

Is that a correct assessment?

Spot on.

we might look at how Google Docs does it:

Totally agree. I'd like to add some link-specific options to the selection menu when a link is selected – this is something @hypest mentioned that we'll likely need to add a third-party library for, but sounds doable.

The popover we already have in mobile web, should we have it in mobile native also, but make the "remove link" bigger?

I'm not sure what you mean by the popover you have – do you mean this one?

Or are you referring to the block toolbar that has the remove link icon/button?

does it make sense for the link sheet to simply invoke immediately when you tap a link you already created

That could work, but it would make highlighting link text (especially in cases you might want to partially select a link) on the canvas pretty tricky. However, if I were to recommend an implementation right now for the sake of consistency, I would probably say let's go this route. This would mean tapping the link icon in the toolbar would remove the link (as it does on the web), and it'd be beneficial to change between the link and unlink icon so it's clearer.

I don't really love either approach, but I'd be fine with leaning on consistency.

[jasmussen]

Totally agree. I'd like to add some link-specific options to the selection menu when a link is selected – this is something @hypest mentioned that we'll likely need to add a third-party library for, but sounds doable.

That seems like it'd fix the discoverability issue at least!

I'm not sure what you mean by the popover you have – do you mean this one?

Yep, that's the one. And I agree, it's not the greatest — no reason not to make a better one!

That could work, but it would make highlighting link text (especially in cases you might want to partially select a link) on the canvas pretty tricky.

Solid point.

I don't really love either approach, but I'd be fine with leaning on consistency.

To be clear, I don't personally think it's super urgent to make things consistent here.

I would also argue that mobile native has an opportunity to design the superior experience, to which the core project should strive to align. I.e. it doesn't necessarily have to be mobile native that changes. We have some challenges with creating bottom sheets on mobile web due to how Mobile Safari behaves, and due to the fact that we can't control the soft keyboard (gory details). But we could consider the bottom sheet to be a sort of popover, so the flow becomes the same, even if some of the UI widgets differe.

So to reframe the problem: how do we make it trivially discoverable how to unlink a link in mobile native? Showing a popover or bottom sheet when intentionally tapping (not longpressing) a link, seems like it might work for us, maybe?

[designsimply]

Related: WordPress/gutenberg#8904

^{(internal reference: p7cLQ7-SV-p2#comment-1705)}

[SergioEstevao]

@iamthomasbishop do you have further thoughts about this one?

[iamthomasbishop]

@SergioEstevao My understanding is that the way that web handles this interaction isn’t well-understood, but that might be different because it’s been a while since this conversation started.

Looking around at some other apps — some of them launch the browser when a link is tapped (see Notion for example — this is unexpected to me), while some apps show a sheet or popover when you tap a link. Both of these approaches feel "hacky" in a way, to me because they seem counter to native patterns.

What I would rather do is utilize a native component like the Edit/Selection menus. In this case, if you select a bit of text, you'd see the native menu with an "Add link" menu item. If you tap on or highlight an existing link, you'd see the menu and in it an "Edit link" item and a "Remove link" item. This is basically how Google Docs handles links and it feels pretty intuitive.

Here’s an example of the edit/selection menu component (iOS top, Android bottom):

I think there was some mention about a RN library we could use for this component, although I’d prefer to use the fully native one if possible. There are a number of cases where adding items to the native menu would be beneficial, so maybe we can address multiple concerns with this addition.