Question

I'm currently working on a web application and the powers above have decided that overriding the browser's right-click menu with our own application-specific one is the way to go.

I totally disagree. I feel that when someone is using a web browser they have certain expectations about what should happen when they use the right-click functionality of a pointing device, and violating these expectations by purposefully supplanting this functionality is very disconcerting (annoying?) to the user.

What do you think? Have you ever seen right-click done well in a web app? I mean in a way that you actually thought, "Yes, this right-click functionality was a great decision."?

Was it helpful?

Solution

It's generally not a good idea:

Expectations

Users, especially power users, expect to be able to right-click on elements in desktop applications in order to get a menu of element-specific actions. This expectation does not exist for web applications - indeed, the expectation is that right-clicking in a web page will give you the standard web-page menu where you can print, open links in new windows, view source, etc.

Reliability

Because the ability to override built-in menus has been so abused in the past (mostly by naive programmers attempting to disable saving images), many browsers prohibit it or make it difficult for client code to override in a reliable fashion.

The Exception

If you are creating a web app that closely simulates the behavior of an existing and well-known desktop app, it may be appropriate to put the effort in required to implement sensible right-click menus. However, you should then also follow the usual recommendation for these menus in desktop apps: use them to provide quick access to context-specific operations, but also provide another means of accessing the same features.

OTHER TIPS

No, because it's simply not discoverable. Of course, this depends on the application, but likely users won't have a clue to right click.

When a user is on the Web ("the Internet") they expect to use one button. Think about all the Apple Mighty Mouse users who will have trouble using your site.

Easiest way to prove to your boss whether the idea will work or not: test on real users. You should be doing this anyway.

Google Docs is the only web-app where I appreciate any attempt at all to use right-click functionality; and they have it implemented spot-on.

Update: To clarify a bit, I think the implementation is great because Google Docs (the whole site/app) is very good at making you forget that you're in a web-browser.

One more thought: DON'T! Between IE6/7/8, Firefox 2/3, Chrome, Safari and the other lesser known browsers and versions it sounds like an nightmare to support across the board. Unless your user's number in the millions the testing alone is probably a good enough reason to avoid it.

Shog9's answer is the best direct answer to your question, but another reason to avoid contextual menus in web applications is that it is a golden opportunity to break away from the use of contextual menus.

Most Windows and *nix GUI applications rely heavily on contextual menus to implement a large part of their functionality. One reason that the Mac OS has traditionally been praised for high usability is that true menu options and toolbar elements have been favored over contextual menus, which quickly become a ghetto of nested lists (especially if other applications are allowed to embed functionality).

Web applications are a breath of fresh air to UI designers precisely because the interface must be usable and powerful without the use of the right click menus. Furthermore, casual users are surprisingly not put off by new UI paradigms in web applications, whereas experimentation on the desktop is often anathema.

The age of the in-browser application thus is a great opportunity for developers to rethink UI paradigms. Right click menus are a cop-out on the web.

Right click menus work well in web apps. As long as your users understand what is going on. There are several context menu implementations available. Outlook Web Access provides a context menu for working with email.

Since right click is used so rarely on websites I would say it's a bad idea and would not be considered "Best Practice".

If you do something different than almost all the sites on the internet then you are requiring your users to spend time learning your app/site.

Also, Mac users traditionally do not have 2 mouse buttons and not all mac users know how to "right click" by using the option click combo or whatever it is these days.

So I wouldn't do it unless you really have a valid case to do so.

I've noticed FCKeditor has a right click context menu... it might make sense in this example, as the WYSIWYG editor is generally given to people with no HTML experience, and more Microsoft Word experience, and in that case, they expect the right click to do something to their text they're typing.

I would, generally, say it is bad practice though. Could a floating modal suffice?

I am not taking a position over this, but...

If you decide do go on the right-click aproach, check out the YUI! framework.

They already have a context-menu implementation that is cross-browser compatible.

It depends on the type of app. I always thought this was a bad idea, but web apps are getting closer to desktop apps all the time. So I asked the master of usability (Nielsen) and surprisingly, he's all for right-clicks!

...high-skilled users are often disappointed when an application doesn't support right-click -- for example, if it's implemented in Flash and brings up the Flash player menu instead of contextually-appropriate application commands.

If it's a web site, it's a bad idea. Users quickly get irritated with web sites that break their favourite browser's functionality. Don't do that :)

If it's a web application, it's not necessarily a bad idea, but you should still be cautious.

Consider whether:

  • the user is going to feel sufficiently immersed within your application that they're going to feel naturally inclined to want a context menu;
  • you're not just compensating for otherwise-poor UI design;
  • the browser's existing functionality makes sense within the context of your application.
  • I think it is a bad idea to have a right click functionality.

    It is not a good idea for normal web applications. I have seen it done in flash/silverlight "web" applications where the user has an expectation of being more like a "desktop" application.

    I think it heavily depends on what type of app it is.

    For example, it makes sense in Google Spreadsheets - where the right-click acts more like Excel, and gives you options such as allowing you to copy the highlighted range of cells - you would not be able to do this with the regular right-click menu.

    But unless your webapp really calls for it, it's probably just going to annoy users.

    This would depend on the context. For a public web site, I would be against it. For a web application, especially an internal company application, I would be more accepting.

    As for apps that handle this well, one that comes to mind is the web version of Outlook. I use it on a regular bases to access company email, and I find the right-click menu functionality bery useful.

    In general I don't aggree with "right click menu" in web app but if it is a must you have to add an alternative method working side by side with the context menu and don't depend on the user experience.

    No, and it will never really work anyway since the user can prevent your attempts to over-ride it.

    Yes: you should have context menus. Actually, you don't have a choice. The browser is going to give you a right click menu but the only context will be for a web page. So when you click on an order line, say, the browser will offer you such actions as Back, Save As, View Source and Print. You may not be happy with these. So the question is: do you want to override these with something more suitable for the context? As web apps become more like desktop apps the answer will increasingly be yes.

    Licensed under: CC-BY-SA with attribution
    Not affiliated with StackOverflow
    scroll top