Re: Mighty trackpad?

Sandman wrote: 
In article <rxyKe.1404$XL3.298@xxxxxxxxxxxxxxxxxxxxxx>,
 TheLetterK <theletterk@xxxxxxxxxxxxxxxxxx> wrote:


You'll probably spend less time if you avoid the context menu. 

I will spend less time going to the menu at the top of the screen
annd click instead of just click? How do you work that logic?


Easy. People almost never consider the time taken to actually hit a
target (hitting a target at the edge of the screen is faster than
hitting a target in the middle of a screen, even if the distance is
further--because you can move the cursor faster when attempting to hit
a target at the edge of the screen)


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.

Fitt's law can be summarized as such:

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. Since Fitt's Law is not the be-all end-all determinate equsion for the evaluation of an interface (complexity is just as important, or more) we usually end up finding that screen *edges* are the most used real-estate, espeite being more difficult to hit.

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.



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.

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. 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.

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).



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.



While the difference between the two methods is largely irrelivent,
it's inaccurate to claim context menus are more efficienct or
nessesary.


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.
Not when you select the content you wish to manipulate before going to the menu. This is why a 'select' button makes more sense than an 'invoke context menu' button.

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.
.

Relevant Pages

  • Re: Mighty trackpad?
    ... >> target to hit is contextual menues. ... > not that menus in a near-cursor position are easier to hit than a menu ... >> Contedtual menues change to work with the context at hand. ... But the Edit menu also has a selection for "Compose ...
    (comp.sys.mac.advocacy)
  • Re: Mighty trackpad?
    ... is as easy or as hard to hit as Contextual Menu->Check Spelling... ... Nor the issues inhereted from a context menu's inconsistancies. ... Navigating and selecting menu items is no different in the main menu than it is in a contextual menu. ... 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. ...
    (comp.sys.mac.advocacy)
  • Re: Mighty trackpad?
    ... > target (hitting a target at the edge of the screen is faster than ... > further--because you can move the cursor faster when attempting to hit ... Contedtual menues change to work with the context at hand. ... You don't need to hit a target when you're using contextual menues, ...
    (comp.sys.mac.advocacy)
  • Re: One Inch Punch
    ... >>If you hit something and tighten all the muscles at that moment.. ... acting like the mucles tightening. ... its not adding anymore power to the collision. ... target, it goes too slow to keep up a shockwave effect. ...
    (rec.martial-arts)
  • Re: DoomRL style targting
    ... attackers the chance to fire past blocking creatures to hit a further ... can continue onwards to the desired target. ... intentionally attempting to fire past a creature. ...
    (rec.games.roguelike.development)