13

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.

  • 6
    Is it web-based or a native desktop application? Are you following any standardized design framework? – maxathousand Sep 26 at 20:27
  • 2
    It is a web-app. We've homegrown design system on top of Material. – singhspk Sep 27 at 11:51
  • 1
    But what about the already existing right click from the browser? The most common already have that.. – Mark Schultheiss Sep 27 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 Sep 28 at 14:12
  • So I understand all your users have a mouse (or other pointing device with at least two buttons)? – Hagen von Eitzen Sep 29 at 13:34
23

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.

  • 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 Sep 27 at 9:38
  • 22
    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 Sep 27 at 11:58
  • 1
    The other problem is mobile users, if that's a use case for you. – DrewJordan Sep 27 at 13:18
  • @DrewJordan Doing anything with databases on a mobile phone seems wrong somehow. Use the proper tool for the job. – Mast Sep 27 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 Sep 28 at 21:19
12

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 create 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, on others it will not be blocked, but annoy users, that are used to use the context menu, shortcuts, or what events 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.
  • 2
    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 Sep 27 at 12:03
4

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!

4

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

  • 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 Sep 26 at 14:21
1

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

  • 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 Sep 26 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 Sep 27 at 9:41
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.

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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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