The context (or pop-up) or right-click (as a default) menu was originally created to reduce the amount of movement that a user had to make to activate a function that would operate on text or objects. If, for example, you were creating a large drawing, you could select an object at the bottom of your screen and operate on that object without moving to the pull-down menu or toolbar at the top of the screen. As others have noted, the context menu was considered a shortcut, but for some applications like graphics programs or project management tools, the context menu was actually the primary way to access common functions.
Context menus were probably more designed for expert users as an efficiency aid. So, when using context menus with the Web, a web application, or a software application, will those context menus actually reduce the effort? One of the design principles for context menus was that only functions that were available in the current context (e.g., a particular type of object was selected) would be displayed - no disabled items, only active functions. Over time, several variations of context menus started appearing: 1. The lean, efficient menu with no disabled functions 2. Context menus with a mix of enabled and disabled functions 3. Hybrid context menus where part of the menu was static because it applied to many cases and another part that was dynamic. 4. Context menus with submenus So, one question to ask when using context menus is whether they will provide a more efficient user interface for an important sample of users. I tested context menus in the 1980s when they were a new UI object and helped write early specs and style guides that included context menus that were activated by the secondary mouse button. The overriding goal was to reduce physical work and improve efficiency. Chauncey On Tue, Feb 10, 2009 at 5:13 PM, Shimone Samuel <shim...@shimone.info>wrote: > Although less destructive, offering web users right click is like > offering them keyboard shortcuts: you're counting on them to > interact with your website uncommonly. While you may find a few power > users who appreciate the enhancement, far fewer users will notice such > a feature in the same way they might notice Search, RSS, or Contact > for instance. > > With that said, right-click in a browser-based applications has > potential if: > > a) it does not contain essential interactivity > b) is clearly communicated to the user > c) is available by other means (e.g. button, hyperlink) > > Adding enterprise to the equation is a bit different as that is an > acutely targeted demographic. If the application is built for a > specific company, the company has the option to educate their users > directly. > > > . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . > Posted from the new ixda.org > http://www.ixda.org/discuss?post=38441 > > > ________________________________________________________________ > Welcome to the Interaction Design Association (IxDA)! > To post to this list ....... disc...@ixda.org > Unsubscribe ................ http://www.ixda.org/unsubscribe > List Guidelines ............ http://www.ixda.org/guidelines > List Help .................. http://www.ixda.org/help > ________________________________________________________________ Welcome to the Interaction Design Association (IxDA)! To post to this list ....... disc...@ixda.org Unsubscribe ................ http://www.ixda.org/unsubscribe List Guidelines ............ http://www.ixda.org/guidelines List Help .................. http://www.ixda.org/help
