Communicate long-press functionality in a web UI

Question

So, barring Google Drive and some other applications, it seems to be mostly seen as a no-no to override the browser's default right-click context menu. The pattern that seems to have emerged in lieu of this is to present a "more" button that the user clicks with their primary mouse button, that brings up a secondary interface (context menu, sidebar, bottom sheet, etc.).

I dislike this pattern however, because it takes up real-estate and draws the user's attention away from the main content. I personally find the pattern to be rather disorienting, especially when you're dealing with a grid of items rather than a vertical list.

I think a good alternative to the "more" buttons is to provide "long-press" options. This functionality can be supported across basically every browser on every device, since its technical implementation is simply a setTimeout call.

Unfortunately, because the "more" buttons are so pervasive and the long-press functionality is so un-pervasive (in the world wide web at least). I'm struggling to find the best way to educate our users about this functionality.

Here is what I've come up with so far:

The idea is that throughout the App, when you see the touch icon on an item inside of a list, it indicates that the items can all be long-pressed. This takes up less real-estate than having "more" buttons on every single item, since only the first items in the lists have the hint. If you're on a device with a mouse, then hovering over the "touch" icons provides a tool-tip with some context.

In this specific example, clicking/tapping the cards takes you to the items dedicated viewing page, but long-pressing the cards keeps you on the same page and brings up a sidebar/bottom sheet (depending on screen width)

---

Can you list some shortcomings with the pattern I've come up with? How can the pattern above be improved?

Answer 1

In addition to other answers:

Major shortcoming: long press is already in use.

Where? Windows devices with touchscreen use long press of finger to initiate right click at given location. Anywhere, including web browsers. (Example on Youtube).

The effect of executing custom action on long press can be therefore unpredictable and it could depend on the operating system and/or browser. For example some browsers could initiate both actions at once, i.e. open the right-click context menu and perform your action on the same long press.

Instead:

• put the action into the context menu or
• add on-screen button(s) to switch mode of operation (either for next action or permanently). This is basically the functionality of tools palette which users already know from Photoshop, GIMP, (Paint - of course...) etc.

Long press (a.k.a. "tap and hold") on touchscreen to open context menu is very old concept, if anyone remembers for example Windows Mobile 5 (2006) which used touchscreen with stylus. Long press was indicated by progress indicator - building of dotted circle around the location of the long press. (Example on Youtube.)

Unless you have some solid workaround of this problem, you should not ignore this shortcoming, especially when designing web UI, which is expected to be platform independent. Without solid workaround available, I would categorize severity of this problem as a stopper.

---

EDIT:

Another suggestion what you can do about your UI is from game The Incredible Machine (1993). (Example on Youtube.) It is focused on solving exactly your type of problem and does it in very elegant and intuitive way, using only left button click and left button drag. Besides basic options available for each kind of item, it also covers dragging links between objects or indication of disallowed action. (It uses icons, but nothing limits you in utilizing text labels or different layout of menu options.) Options for an item are displayed after the item is activated (clicked).

• Optionally, you can respond also to hovering pointer, either by highlighting the item (communicating that "this item allows interaction") or directly by displaying its menu options. This can be a nice bonus for mouse users, but touchscreens usually do not support hovering.

Heavy-duty users will appreciate if they can activate menu options by keyboard (after selecting the item). Did you know that this works even on this page you are reading (after you activated it in your profile page: tab Edit Profile & Settings > menu preferences > check Enable keyboard shortcuts). Here on StackExchange I always edit my posts by pressing E instead of locating edit link visually (and then finding it by mouse pointer). So if you can add E for edit, R for rename etc., it could add value to your UI, because for some heavy-duty users, it is often more comfortable to blindly press a key on keyboard than pointing to small rectangular icon/label using the mouse.

Answer 2

The major shortcoming I see with your approach is that you are introducing a rather uncommon interaction paradigm. This will make your app unique, likely at the cost of confusing users at least in the beginning.

I dislike this pattern however, because it takes up real-estate and draws the user's attention away from the main content.

As the touch icon you use takes up pretty much the same amount of real-estate, I'd say you're better off with the more common menu indicator ⋮ to be clicked.

Another shortcoming: long-pressing just takes longer than a simple click/tap. And it might interfere with drag/drop interaction.

Answer 3

It's difficult to overload a common action like click (tap)

I've been able to ask a few people what they think of the latest Mac Book Pro with larger track pad and force touch and all of them have disabled the force touch option.

Think about the friction this adds to the user when they now have to distinguish between clicking and really clicking something.

That's not to say a tap-hold option can't work for your particular users but in general there is bound to be some people who just happen to click slow and can now only access the functionality behind one of your two types of clicks.

Here are a few things to keep in mind when going the long-press route...

Try not to place vital functionality behind the action

It's difficult for users to discover new interactions so if the only way to accomplish a critical task is to tap longer on things then some of them will be blocked from doing their job. If the long-press action is just "icing on the cake" then it may enhance the experience of frequent users. As with everything else you need to test this with your customers because a more tech-savvy crowd is more familiar with long-press used in place of a right-click

Users will need to be trained

This isn't a common enough interaction for most people to understand so an animated tap and hold pop-up asking the user to do something followed by a "you got it!" message will be needed for first time users. This only needs to be done once of course and the user can extrapolate the action to other controls with the icon once they've successfully performed the action.

Let the user know when they are performing a long-press

It's hard to get the duration just right because too long and it feels sluggish while too short and I can no longer click. On mouse-down I would try fading in a ring over about 400ms so nothing shows for regular clicks and then having the ring draw around the tap point over 1200ms. You will need to tweak the numbers while testing with users but it needs to be longer than 1 second because that's the cut off where a spinner must be shown.

There are probably other things to consider but once you start really weighing all the factors showing a list of context sensitive options doesn't seem so bad :)

Good luck and thanks for contributing!

Answer 4

I would say don't invent or reinvent a fundamental interaction unless you have a really good reason.

I would also add that adding a hint to one or some cards is not enough to communicate the 'this works for all' or 'this works for all things that look similar'.

Users like explicit indicators and cues.

The visual recognition and familiarity is important, rather than having to think about anything. It doesn't seem much to have to think about, but even slight hesitations accumulate to become an annoyance - especially if the long press turns out not to be something for a particular card.

You don't want to add icons to everything that doesn't have a long press, and the long press won't be relevant everywhere on your site, so you should be explicit where it is relevant, to avoid surprises.

It looks like you're already thinking of using a card-like style and typically the 'more' context is offered via a discrete icon in the top right corner of the card - same icon, same place, everywhere it can be used.

Apart from anything else, a long press takes a relatively long time compared to a click.

The examples below show popular menu indicators and don't really add a lot to the real estate. They certainly add more value in their access to functionality and in their affordance than they take away in real estate - especially since the real estate is often a void anyway.

Trello

Facebook

LinkedIn

Twitter

Strava

Answer 5

You can use progress indicators

In your case this could be achieved with linear progress indicator:

The indicator is superimposed on the element you want to long-press. When the user holds the element the progress indicator advances proportionally and the user stops the progress indicator stops loading.

I haven't tried this in the real world but it seems like a nice signifier for long press.

Answer 6

Android had recently added this feature of long pressing Google applications on touch screen devices. So I would also recommend understanding who the user is more on a device level. .

And test it, the Kabab menu sometimes works depending on the user and if they are curious. But because there is no context to these menus it will be the issue to solve.

What is it that causes these certain cards in you concept to have the need for a secondary interface? This is where I would still be asking the question. If this more common to have this feature, then it might be the question of does the system UI need to be adjusted to bring these features up to the surface as a primary UI need.