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:

enter image description here

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.

enter image description here

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)

enter image description here


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

  • 9
    If you really want "more" functionality without an extra button, and the context is desktop use, over-ride right click menu despite what people say. This is a much more intuitive way to get a context menu. I think it's fine as long as your site has a strong "application" feel. – user31143 Mar 24 '17 at 16:48
  • If more browsers would implement the HTML5 ContextMenu feature we wouldn't have this problem. – EMBLEM Mar 24 '17 at 20:55
  • 1
    In case you go with the right click, see my answer here – Francisco Presencia Mar 25 '17 at 1:38
  • 2
    I'd hate to use this with my laptop's click-pad. I click by tapping (clicking is loud), to send a held click I have to tap-release-tap-hold. I'd much rather right click (two-finger tap) or just click a three-dot menu. – matega Mar 25 '17 at 16:04
up vote 4 down vote accepted

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.

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.

  • my idea was that the touch icon only has to be displayed on a single card, as opposed to all of them, so it takes up o(1) space instead of o(n). Drag and drop is a good point though. – Luke Mar 24 '17 at 15:39
  • 13
    "long-pressing just takes longer" yes, and even though it's a little thing, that can be quite annoying for frequently used actions. – user31143 Mar 24 '17 at 16:41
  • @LukeP If your app is intended to be used with mouse only, you could theoretically show the menu button on hover. – Tin Man Mar 25 '17 at 13:44

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.

tap hold training

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!

  • "... This only needs to be done once of course..." Yes and no. Don't forget that 1) if people don't use your app everyday, you might need to remind them about this functionality when they revisit your app, and 2) if some elements have this functionality and some don't, you'll need to clearly set them apart. – Tin Man Mar 25 '17 at 13:41

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

enter image description here

enter image description here

Facebook

enter image description here

enter image description here

LinkedIn

enter image description here

enter image description here

Twitter

enter image description here

enter image description here

Strava

enter image description here

enter image description here

  • 1
    +1 "even slight hesitations accumulate to become an annoyance - especially if the long press turns out not to be something for a particular card." This is such a good point by Roger. With two different types of clicks I now have to try them both on everything only to be disappointed much of the time. – DaveAlger Mar 25 '17 at 15:24

You can use progress indicators

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

long-press 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.

  • so the idea is that the progress indicator is always visible even when the item is not being clicked? – Luke Mar 24 '17 at 17:55
  • @LukeP Yes but just a little bit, in order to signify that this element can be long-pressed. – Kristiyan Lukanov Mar 24 '17 at 18:02
  • I've seen this before, cant' remember where (but I think it was mobile); the progress is not necessarily always visible, it blends with the element's background (the bar would have a white background in your cards). The moment the user clicks the card, a small, blue bar starts to fill at the bottom of the element. – Josh Part Mar 24 '17 at 18:05
  • 1
    A popular design I've seen for this is a radial progress bar around the cursor. So when you click and hold, a little spinner type thing pops up and fills up, and one can release their mouse for a long-press when it is at 100% – CobaltHex Mar 24 '17 at 19:34
  • 1
    I feel like I've seen this in a couple places in Google Maps (like when dismissing notifications during navigation), except where the entire element's background becomes the progress indicator on a long-press. – BalinKingOfMoria Mar 25 '17 at 3:28

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. Android long press on Gmail app icon.

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.

Your Answer

 
discard

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.