Re: Mighty trackpad?

Sandman wrote: 
In article <IZBKe.1494$XM3.118@xxxxxxxxxxxxxxxxxxxxxx>,
 TheLetterK <theletterk@xxxxxxxxxxxxxxxxx> wrote:


You are talking about Fitt's Law, 

In this instance, yes.


which ironically concludes that the easiest target to hit is contextual menues.

Actually, it concludes that they're easiest to invoke, not manipulate.


From the point of invokation to the point of a menu item being selected, a contextual menu and the main menu is identical in termms of Fitt's Law. File->Save As... is as easy or as hard to hit as Contextual Menu->Check Spelling... - the difference is that "File" is a lot harder to hit than "Contextual menu".
Define 'a lot'. Even if you do buy this argument (I don't), you still haven't explained the complexity discrepency. Nor the issues inhereted from a context menu's inconsistancies.



hard to hit: anywhere on screen not covered below
easier to hit: screen edges
very easy to hit: screen corners
easiest to hit: mouse position

And since no entry in a context menu is at the position of the cursor when it's invoked, fitt's law shows that screen corners are the best position for a menu.


Of course not - see above. Invokation of the menu is all we are talking about here. Navigating and selecting menu items is no different in the main menu than it is in a contextual menu.
Sure it is. You've already 'bounced' to a stop when you activate a static menu item placed at the edge of a screen.



A target at the position of the cursor is easiet to hit because there's no time taken to acquire or hit it. It basically means that single-fuction buttons on the mouse will always be faster than menus, not that menus in a near-cursor position are easier to hit than a menu arrayed across the edge of the screen. Unless, of course, your trying to claim that menus take up no screen space, save for the exact point where the menu was invoked.


I don't fully understand what you are trying to say here. 
Context menus are only easier to hit if they take up no space.



neither do they consider the
inherent complexity caused by menus that change based on the arbitrary
position of the cursor.

Contedtual menues change to work with the context at hand.

Yes, that's obvious.


Exactly. It is obvious.
Yes, it's pretty obvious that context menus are related to the context of it's inkovation. Their usage, however, is not obvious--as demonstrated by the masses of people woh just don't understand them.



Never does it change to play your mp3 files when you select a word in text edit.

Any change at all is as bad as random changes.


Of course not.
Yes, it is. Ignoring user familiarity for a moment, you would suffer no performance loss due to random context menu arrangement. The locations are always relative, and you'll always have to visually acquire the target to hit it--so the arrangement of the entires just doesn't matter at all, if the menu changes at all.



If it invoked a standard set of functions ('cut', 'copy', 'paste', etc) and never changed, then it would make sense. As it is, it's just added complexity for nothing.


Of course not. It adds functionality that would be impossible or illogical in the main menu.
No it doesn't. You haven't shown any examples where a static menu bar would not be as effective as a context menu.



If you select a word in text edit, the contextual menu will contain actions relevant to the selection - as opposed to the big menu, which will always contain lots of action that are completely *irrelevant* to the context.

And since menus typically aren't one large menu with all it's functions lumped to gether, your argument is invalid. Static menus are almost always arranged in some sort of logical grouping ('File', 'Edit', 'Tools', etc).


Exactly, but using MT-NewsWatcher as an example. The Edit menu has context-specific actions, such as Cut and Copy, which is disabled unless you have context selected.
Their locations remain constant though. They don't disappear and reappear depending on the position of your cursor when the menu was inkoved..

But the Edit menu also has a selection for "Compose as..." which lets me select the encoding for the message. Am I to think that it changes the encoding for the text selected or for the entire message?
Since *message* encoding is inherently a task attributed to the entire message, this is readily apparent. Though why pull anectodal evidence to support your position? Where in my post did I claim MT-newswather was a good example of strong static-menu UI design?

If the same both options were (also) found in a contextual menu when I right-clicked a word, it would be obvious that it would relate to the word I had selected.
And if you simply greyed out 'message encoding' when specific lines of text were selected, you would accomplish the same effect.



The time taken to actually move the mouse and
click is neglegable when compared with the time taken to figure out
what you need to do, and accurately hit a target.

You don't need to hit a target when you're using contextual menues, it's right where your mouse is.

No, it's not. If you move even 1/64nd of an inch, you've now invalidated your 'Fitt's law' defense. Context Menus are much, much larger than the cursor's position when the menu was invoked.


Not for invokation. See above. 
But for actually hitting the target? Yes.



Of course not, especially when there are things you can do with contextual menues that is impossible using the main menu. A perfect example of context interaction would be a web page. The main menu applies to the entire web page, and not any context.

But using the contextual menu, you can apply commands to specific context, such as links and images, zoom in flash movies and so on. These commands are ONLY available in contextual menues since having them in the
main menu bar would be insane.

Hardly. There's no reason static menu bars can't manipulate specific content.


Please detail this. Any given web page might contain some 100 links and 50 images for example. How do I open the logo image in a new window using nothing but the main menu?
Position your cursor at the top-left section of the image. Hold down the left mouse button. Drag to the lower-righthand section of the image. Let go. Manipulate as desired via static menu. Better yet, remap the right mouse button to be 'select', and simply right click on the image before going to the static menu.

Are you suggesting a series of sub menues for every single image and link on the page? 
Why would you think this?
.

Relevant Pages

  • Shell Extension in C#
    ... registered in the * section of Classes in the registry. ... context menu, for a .txt file let's say, all is well, but if i select ... want to run through the code snippet for MY created menus. ... selecting multiple files+OPEN ...
    (microsoft.public.dotnet.csharp.general)
  • Shell Extension in C#
    ... registered in the * section of Classes in the registry. ... context menu, for a .txt file let's say, all is well, but if i select ... want to run through the code snippet for MY created menus. ... selecting multiple files+OPEN ...
    (microsoft.public.dotnet.general)
  • Re: Command Design pattern - extension.
    ... When selecting a UI element ... want to show a context menu. ... we need a subset of these menus ... I'm looking at the same functionality of Visual studio, ...
    (microsoft.public.dotnet.framework)
  • Command Design pattern - extension.
    ... When selecting a UI element I ... want to show a context menu. ... Used a command pattern for it with the UI ... we need a subset of these menus ...
    (microsoft.public.dotnet.framework)
  • Re: Prevent moving when copying
    ... Select the files in Windows Explorer, ... hit Ctrl+V to paste the files. ... After selecting the itemin Windows Explorer, ... context menu key, hit C to select the Copy action, select ...
    (microsoft.public.windowsxp.help_and_support)