Friday, February 22, 2008

Clash of the Context Menus

The information age we live in is currently in transition from desktop applications to web applications. During that transitional phase, some oddities occur – like the clash of context menus. In the screenshot below, you can see what happens when you right-click a Google Docs document in Firefox, if you tell the browser to not allow web pages to replace the context menu (at Tools -> Options -> Content -> Advanced -> “Allow scripts to ... Disable or replace context menus”):

As you can see, the Docs menu is mostly hidden as it’s overlaid by the browser menu. I could easily toggle my Firefox settings to prevent this collision; however, this brings with it a bunch of other problems both on Google Docs (which doesn’t have all I want in the context menu, and sometimes triggers different actions) as well as other sites (you probably know the “this image is copyrighted” JavaScript alert when you right-click a picture to e.g. make fair use of it... or just see its URL, or resolution or something).

As an example of a typical problem with the Google Docs menu; if I opened one window showing a Docs table of contents, and I open one linked document from this ToC by selecting “Open link in new window” from Google’s menu... then when I open another document the same way, my other open document will be replaced (no new window will actually be opened as promised by Google’s context menu).

What I currently end up with is toggling the setting back and forth depending on what’s needed... not an ideal situation.

Update: Tony Ruscoe in the comments inspired a cool workaround solution for this: you can press Escape to close just the browser context menu, leaving the web app menu open and rendering it fully visible. This works at least in Google Docs/ at least with some browsers I tried, and is a good alternative if you like to use either context menu depending on the task at hand.

The following screenshot depicts another situation. In this case, the user visits the Google.cn homepage, which has auto-completion & transliteration. However, the user also installed Google’s IME (Input Method Editor) for transliteration. The result? Another clash of context menus:

As one solution, I wonder if it’s possible for web apps to cater for this by moving the location of their context menu elsewhere – like to the right or the top. Not an ideal solution either, though, as it’s less usable for those who don’t have context menu clashes – I wonder if it’s possible for web apps to test if there is a collision appearing in the first place, to only then go for fallbacks like relocating the context menu?

This is probably not the only type of collision of the two worlds, and there may be new ones in the future. Some initiatives, like Google Gears, Flock or Mozilla Prism, try to merge or bridge the desktop and web apps world, with so far mixed success. Right now it’s hard to tell if we’re indeed seeing a mere temporary transition from one phase to another, or a merging of the two worlds, or a permanent dual phase. If it will indeed be a transitional phase with a clear-defined end state – the replacement of all desktop apps with web apps – then we have to admit we’re only at the beginning; the desktop world is currently still the only realistic place for many power applications like photo retouching, movie editing or 3D modeling. It seems for a couple of more years at least, we have to workaround the bugs caused by the collision.

Clash of the Context Menu ... by Philipp Lenssen | Comments (15)

>> More posts

Advertisement