18

We've a grid where users can select multiple rows and perform actions on them. When rows are selected, we show action buttons at the top of the grid. We've been thinking about making these actions available in a context menu where users can right click on the grid and see this menu. We think it's useful in some cases where the selected rows are at the bottom and user won't have to scroll all the way up to click on those actions.

Any thoughts about right click on the grid from UX perspective?

It is a web-app. We've homegrown design system on top of Material.

Improve this question
5
  • 6
    Is it web-based or a native desktop application? Are you following any standardized design framework?
    – maxathousand
    Commented Sep 26, 2019 at 20:27
  • 2
    It is a web-app. We've homegrown design system on top of Material.
    – singhspk
    Commented Sep 27, 2019 at 11:51
  • 1
    But what about the already existing right click from the browser? The most common already have that..
    – Mark Schultheiss
    Commented Sep 27, 2019 at 12:10
  • 2
    Just another thought, you might have considered that already and it could introduce other UI problems but: If the issues is about scrolling, something like a position: fixed could help to keep the action buttons visible even when scrolling down. Maybe even collapsing/uncollapsing the action area to save display space.
    – nuala
    Commented Sep 28, 2019 at 14:12
  • So I understand all your users have a mouse (or other pointing device with at least two buttons)?
    – Hagen von Eitzen
    Commented Sep 29, 2019 at 13:34

9 Answers 9

Reset to default
25

I think it is a great idea to use right click to context menu. It is a norm in desktop application and I see no reason for it not to be the case in web interfaces. And many if not all tools from Google and Microsoft now use right click actions to offer content related actions. And right click can be nicely replaced with long tap on touch-enabled devices, which also became commonplace.

The only problem with them is that they are difficult to discover, so I would say you still should keep that action row on top of the table.

Good thing that pretty much every tool with table based UI uses right-clicks for content menu: gmail, google sheets, excel on desktop and on the web. So you have that going on for you, plus if visual state of the row changes on hover or click, you can assume that people expect to see context menu on right click.

First, gangsta move, before spending time on implementing the functionality, just make sure to track if users are right clicking and then you can consider if it worth it or not.

Improve this answer
6
  • 2
    Maybe new users? experienced ones used to the current (lack of) right click functionality will probably not try to use it, as they have no expectation of there being anything that will happen if they were to do so.
    – Baldrickk
    Commented Sep 27, 2019 at 9:38
  • 27
    Regarding discoverability: I did not know that Gmail had a right-click menu until I read this post. I don't think users expect or assume right-click will do anything in web applications. To be honest, I usually discover that a web application has a right-click event when I try to access the normal browser right-click menu and can't (and then I get mad at the application)
    – Scribblemacher
    Commented Sep 27, 2019 at 11:58
  • 1
    The other problem is mobile users, if that's a use case for you.
    – DrewJordan
    Commented Sep 27, 2019 at 13:18
  • @DrewJordan Doing anything with databases on a mobile phone seems wrong somehow. Use the proper tool for the job.
    – Mast
    Commented Sep 27, 2019 at 16:43
  • @Scribblemacher I do agree, and I feel the same. Nevertheless there is a place and time for custom context menus. And is some cases options in custom menu should cover options from standard menu.
    – Jurijs Kovzels
    Commented Sep 28, 2019 at 21:19
14

It would be good UX for a general UI, but it is bad UX on the web.

Your custom right click menu will block the regular one, what is against the principle of least surprise and possibly against what the user wants to do. Maybe he likes to use the browser's context menu, e.g. for copy, select all or even some more advanced options of current browsers, like creating screenshot.

On a web page, you should never intercept events, that are usually handled by the browser or OS. Some browsers are blocking it (or allow to block it) anyway, others it may not block it, but it can annoy users, that are used to using the context menu, shortcuts, or other keyboard or mouse events that you choose to handle with your website.

Maybe you know this from sites, that intercept ctrl-f for their own search function, like discourse forums. You want to search the current page, the forum intercepts the shortcut and offers to search the whole forum.

In summary:

  • In desktop applications and apps, it is a good choice and expected that way.
  • Never do it in web applications. A website is not an app, but a (scripted) document.
Improve this answer
2
  • 4
    I wholly agree with this answer. I often discover a webp application's right-click when trying (and failing) to access the browser right-click. Stealing native browser behavior is really annoying to me. The most frustrating is how Github maps / to their site search. As a Vim user, I'm trained to hit / for searching pages.
    – Scribblemacher
    Commented Sep 27, 2019 at 12:03
  • I wouldn't assume that all users see the difference between a web application and a desktop application. Many don't. Your answer is well-founded but certainly shouldn't be considered as universally applicable.
    – Brad
    Commented Feb 9, 2021 at 2:16
5

I've actually tried to right click on some cells to see if I could add more rows or columns (and sometimes it doesn't happen at all and I have to look for another tool). So, from my experience/opinion as a user, it's a good idea I would like to see more often.

From a UX designer perspective I would tell you to test it in some way, asking the user which tools he would like to see on that context menu. Maybe you can have some answers with a card sorting workshop :)

Gl!

Improve this answer
5

This post I will answer like a web user.

I have a confession: I'm always trying to use right-click on the web tools (web applications that work like a tool, like Google Drive) and nobody care with this. Rarely I saw someone using it. Otherwise, I will feel strange, maybe unhappy, if you do it on a website or e-commerce.

Congratulations for your idea. Please, try it and tell us if it works.

But before it I will list some considerations as a UX Professional:

  • Make a list of good and bad reasons/consequence why you would like to do it.
  • Just do it if is really necessary. And If look natural for the users like swipe an image in a mobile screen to see next.
  • The user has any other reason to use right-click? If yes, don't do it.
  • How do you communicate the user that they can do it as it's not common action?
  • Make a prototype and test with some users (real users, not your boss or not your mom and not your friends).
  • Analyze how often your users need these actions. All the needed time to develop and teach the user worth it?

Google Drive does it very well.

enter image description here

Improve this answer
1
  • 3
    I would point out that although google drive does this and might be popular with power users, they have these actions visible by clicking an icon, so you could be using google drive for a long time and not realise the right-click actions even exist. I would suggest testing your users with google drive to validate your idea.
    – Calum
    Commented Sep 26, 2019 at 14:21
2

No, it's not bad UX, but it's risky and requires additional concerns

  • What happens if the user's right button doesn't work? a trivial task becomes impossible
  • What happens with touch screens?

However, I think there are undeniable benefits in your approach, so I think you can do it, just keeping a way to make this context menu or its related actions work even without right click. This secondary set of actions will cover those cases mentioned above, increase visibility of the system's capabilities and its affordances, Supporting Internal Locus of Control, which is one of the 8 Golden Rules of Interface design

Improve this answer
2
  • 3
    1) The OP is not talking about replacing the top menus but duplicating them, so there is no "impossible". 2) I have a menu button (on both my laptop keyboard and external keyboard) that does the identical thing as "right click on the current selection". Maybe people are not familiar with said button? 3) Good question on touch screens.
    – Jeff Y
    Commented Sep 26, 2019 at 20:30
  • 1
    Not all keyboards have that key. My work laptop, two of my personal keyboards (one is an intentionally small wireless one, the other has replaced that key in the standard layout with a key to control the LED backlighting (didn't realise when purchasing)) and most of the standalone keyboards at work don't have that key. It's really annoying.
    – Baldrickk
    Commented Sep 27, 2019 at 9:41
1

Right-click context menus have very bad discoverability, hence they should not be used as the only means of getting to functionality. They are meant for shortcuts, so as long as you keep the buttons on top, yes, this is exactly what they are for and it's good to offer that shortcut.

I do think that 'allo' makes a good point about on web it's blocking the browsers functionality and that goes against the principle of least surprise. I wonder if there is some consensus about that between UXers?

Improve this answer
0

I don't think there is a clear answer to the question if a context menu is good from a UX perspective or not. Others have pointed out many aspects in their answers. What I would like to emphasize from these is the fact that the context menu should only be an additional way, not the only way to execute these actions. I see the problem that unexperienced users might not discover the option, but they do have an alternative and experienced users can enjoy the more comfortable solution.

But I'd like to focus on the reason why you're even thinking about creating a context menu. You say the problem is that users have to scroll to reach the action buttons. Ain't it possible to make sticky buttons that stay at the top of your screen while you're scrolling through the contents of the grid? Depending on whether you're developing a desktop application, a web application, or mobile application there might be other positions where you could pin these actions to.

Another thing that I've seen is to offer buttons on each row (left or right). Of course this is only feasible if the number of actions is low.

Personal opinion/experience: Coming from a web development background I try to avoid right-clicks (partly because it automatically competes with the browsers context menu). We've used both of the mentioned approaches for actions on grid rows, e.g. buttons for copying and deleting a row at the end of each row, but in general we rather have sticky buttons on top that do not scroll away. I did not feel the need to add a context menu for grids yet, but I could imagine doing this in the future if needed. What we've used context menus for instead, is mainly for more advanced actions (in the sense of actions that only experienced users might want to do/are allowed to do) or meta-information like "tell me how this row has changed in the past" or similar.

Improve this answer
0

One point that I don't think has been made is that the context menu always uses the element the click occurs on as its context. This is a bit tricky on a table, where you are clicking on a cell, but want the context to really be the row containing the cell. Even more so when it's not just the parent row, but a group of parent rows.

The context makes more sense if the user understands the table as a 'list', where the items happen to have several pieces of data each. I think it makes less sense if this is a 'true' table, with relationships formed by rows and columns.

In this situation, I would prefer the tools shown on the top and bottom of the grid as you mentioned, with some polish to ensure they stay visible (sticky header/footer) when a selection is made.

Improve this answer
0

Yes, right click on tables (and all other elements) in an Web App to display a contextual menu is considered bad UX design for the following reasons:

  • Bad discoverability: Web users don't expect context menus on right click that are different from the browser context menu (breaks 'confirmaty with user expectations' and 'self-descriptiveness')

  • Bad interoperability: You can't make sure on the web that every device will behave the same way with a right click.

  • Also you should follow the Material Design Guidance, that says

    How elements look and behave should indicate if gestures can be performed on them.

Possible Solution

Here is one example how you can add a dropdown menu to your table that is self-descriptive:

enter image description here

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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