Touchscreen behavior for the interesttarget attribute

[mfreed7]

What is the issue with the HTML Standard?

Some references first:

• The interest invokers explainer's touchscreen section
• The OpenUI discussion thread about touchscreen behavior
• Some quick mockups of what the proposed behavior could look like. (Better ones are coming soon.)

This issue is a narrowed down version of the OpenUI discussion above, to hone in on the right final behavior. Essentially, the explainer lays this out:

For touchscreen users, the widely-adopted standard for “showing interest” in an element is the long-press gesture. For native apps, this is the user-expected shortcut to show context menus and access other actions without explicitly activating the element. (See this comment for more context on this point, from developers.)

On the web... most browsers already overload the long-press gesture to provide additional functionality [such as context menus]. Users often appreciate these additional capabilities, and do not want to lose access to them. Therefore, this proposal provides a way to keep both capabilities: the interesttarget behavior and the existing context menus and behaviors.

To show interest in an element via touchscreen, the user simply long-presses that element. This does not activate (e.g. click) the element, it merely triggers interest in the element. This long press immediately fires the "interest" event, but also shows any context menus that would have shown if the interesttarget attribute were not present. So both things happen together. In the case of a popover target element, the idea is that the hovercard popover shows up in addition to the context menu, so that the user can tap on either of those things.

That's the current direction, coming out of OpenUI discussions. This plan seems to have fairly broad consensus from the developers in OpenUI, who seem happy that it will meet their use case. In particular, that use case has been fairly definitively established as: Showing interest on a touchscreen must be done via long-press, and that long-press must simultaneously provide access to the popover hovercard and the UA-provided context menu. Exactly how that's done is up for debate. The explainer goes into detail about the proposed approach, which shifts around the context menu and exposes a "safe area" in which to render the hovercard.

This issue is to check that with the folks in WHATWG, to see if the proposed approach is workable, or if there are better suggestions for how to meet the use case.

[annevk]

I don't understand how the suggestion works because on iOS when you long press a link the entire screen is taken over.

[mfreed7]

I don't understand how the suggestion works because on iOS when you long press a link the entire screen is taken over.

Right - that's similar to what happens on Android as well. That behavior would need to change for elements that have interesttarget, as described in the explainer.

[annevk]

I don't really see how that would work given what we display today. You'd have to not display the preview or something, which I'm not sure is in the end user's best interest. It also seems rather risky to show both platform and web developer UI side-by-side.

[mfreed7]

I don't really see how that would work given what we display today. You'd have to not display the preview or something, which I'm not sure is in the end user's best interest.

I agree you'd have to not display the page preview, and in its place leave room for the page's (popover) version of that preview. This is why it seems actually better for the user. Take the Github example right on this page. Long-pressing a username on mobile Safari gives a rather large full preview of the page you get if you click that link. It includes login links, lots of extra stuff, and critically is not interactive at all. While I can see a button marked "Follow" in that preview, I can't tap it. If I do tap it, that navigates me to the new page (potentially losing state from the previous page), and then from there I can tap "Follow". But now I need to know to hit Back to get back to where I was before, and hope that bfcache or form preservation keeps whatever I had been doing there. Total interaction: Long press, tap once, tap twice, Back button.

Contrast that with the new experience, with interesttarget: the preview is smaller and more concise, exactly like the one you see on desktop. There is a "follow" button, which is directly interactive, and can be tapped. That closes the context menu (which I didn't need for this interaction) and likely closes the hovercard also. I'm now back to the original page, having never left it. And I accomplished my goal with a single long-press and a single tap. This feels much closer to the desktop experience to me, and much more user friendly. This is also what a majority of developers would prefer, at least from the OpenUI discussions.

It also seems rather risky to show both platform and web developer UI side-by-side.

I initially shared your concern, but we discussed this at some length in OpenUI, with the conclusion being there's no actual risk. Let me know whether that discussion alleviates your concerns also.

[smaug----]

It would be amazingly confusing if one user action triggers two unrelated UIs.

[hober]

I don't really see how that would work given what we display today. You'd have to not display the preview or something, which I'm not sure is in the end user's best interest.

I agree you'd have to not display the page preview, and in its place leave room for the page's (popover) version of that preview.

It would be jarring for a previously system-wide behavior to suddenly start doing something unpredictably different, but only in some web views on some web content. That's not a user experience regression we're interested in.

[martinthomson]

This seems to be entirely an encroachment into the rights of different browsers to present different UX. Safari have chosen to use a long press to present a preview (a useful feature). Whether that is subject to changes that are negotiated in a standards forum is a matter of whether Safari consents to that or not. It seems like the answer is "not".

Is there some other way that someone might signal interest in a particular element that isn't a long press? Could I touch the element and wiggle my finger around a little (which is scrolling, but not)?

[mfreed7]

It would be amazingly confusing if one user action triggers two unrelated UIs.

FYI this is what Safari currently does. For example, see the top and bottom half of this screenshot after long-pressing a URL:

With the interesttarget proposal, this would look nearly identical, except that the card at the top wouldn't include the (not useful) Login, hamburger menu, and other extraneous UI elements, which are only there because this is an anonymous preview of the URL, not a customized version coming from the page itself.

I agree you'd have to not display the page preview, and in its place leave room for the page's (popover) version of that preview.

It would be jarring for a previously system-wide behavior to suddenly start doing something unpredictably different, but only in some web views on some web content. That's not a user experience regression we're interested in.

I don’t think this would be jarring. From most users' point of view, I don't actually think they'd see this as materially different, even. They'd likely see it as an evolution of the current UX, wherein a) the hovercard can be customized by the developer, and b) the buttons they see on the screen can actually be tapped. If done well, I bet many users would think the browser made things better.

This seems to be entirely an encroachment into the rights of different browsers to present different UX. Safari have chosen to use a long press to present a preview (a useful feature). Whether that is subject to changes that are negotiated in a standards forum is a matter of whether Safari consents to that or not. It seems like the answer is "not".

So my original proposal (which was “option 1” in this comment) was to leave this behavior (exactly how to show interest via touchscreen) to the user agents to define. However, Webkit (rightly, in my view) pushed for us to define the exact mechanism for showing interest on touchscreen also. As a result of that push, at OpenUI we hashed through all of the options, and came up with something that feels like a great balance between what the UA can decide and what the site has the power to show.

With the current proposal (see e.g. here), the UA is still in charge of several things:

1. The position and size of the UA-provided context menu.
2. The available space and location for the developer/site-provided hovercard.
3. The decision whether to show interest at all. For example, on very small screens, the UA might decide to only show the context menu and not trigger interest, because there's no space.

With these abilities retained, this feels like the UA hasn’t given up many “rights”, and in the balance, users and developers have gained a powerful (and popular) UX pattern that works across input modalities. Feels like a win to me.

Is there some other way that someone might signal interest in a particular element that isn't a long press? Could I touch the element and wiggle my finger around a little (which is scrolling, but not)?

We explored this at some length in OpenUI, and the result seems to be a fairly strong conclusion: on mobile platforms, there is a long-standing precedent for how to “show interest” in something. You long press it. Users have learned this behavior, and would be confused or unsure about how to use any other “magic” gesture such as “touch and wiggle”. (Sounds funny, but we did explore several such options, e.g. long-press for a specific time, long-press-and-drag and a few others that didn’t get minuted.) Design system authors involved with the conversation were adamant that the only viable UX pattern that users will understand and use is long-press.

Mobile apps other than web browsers use long-press for this interaction, on both iOS and Android. It’s only because mobile browsers already have a context menu that we now have to figure out how to include both things.