Re: And So The Question Is......

In article <hS1%j.11830$tF1.10434@trnddc01>,
Wes Groleau <groleau+news@xxxxxxxxxxxxx> wrote:

Gregory Weston wrote:
direction (and therefore not the distance) of movement, and you're now
requiring the user to maintain extra awareness of the nature of the item
they're clicking on. Including the distinction between packaged vs

?!? I can't speak for anyone else, but I don't click on something
unless I am trying to do something to it or with it.

Um. I should think that goes without saying.

And to the best of my knowledge, I have never had an urge
to perform an unidentified action on an unidentified object.

Nor I. That would be weird, IMO.

Can you cite empirical research for the number of people
worried about the efficiency of random clicking?

Since I said nothing about that topic and am not aware of it having come
up in this thread prior to your post, I don't see why you would ask me
for supporting information about it.

The issue actually being discussed is the explanation for a
highly-consistent set of data gathered by many people over a roughly
2-decade span through rigorous and reproducible experimentation. As
always happens in this discussion, no-one has actually offered, or even
claimed, contradictory data so they argue that the explanation can't be
true because it's contrary to their intuition and hope people won't
notice that they haven't actually addressed the hard numbers that are at
the root of the debate.

The data indicate, without exception and often contrary to the
predictions of the researchers, that accessing a given command from a
context menu is slower than accessing that same command from a
screen-rooted menu structure by a margin that is mathematically
significant even in its best case and quite drastic at its worst.

The explanation is simply that for several reasons the item in the
context menu is harder to hit accurately. One of those reasons - a big
one in current mainstream implementations of contextual menus - is that
the vector from the mouse at the time of invocation to the desired
command is highly variable, dependent on several factors not all of
which are obviously significant to, or even easily perceived by, the
user. As a result, the opportunity to establish muscle memory and the
ability to make high quality predictions about the location of the
desired item are both compromised severely.

If I want to use Finder's "Compress" command, for a context menu invoked
at exactly the same point on screen that command will be in a different
location depending on whether the object I'm compressing is a folder, a
BBEdit document, or a Numbers document. Simply rename the object and the
vector could change again. Move the mouse - not the object, but the
mouse - a single pixel and the vector could change yet again. For the
screen-rooted menu, not one of those elements is a factor. The only
penalty comes from the need to root the mouse relative to the menu
structure which the same data say is dwarfed by the issues inherent in
the context menu.

I'll reiterate that I am not arguing that people shouldn't use context
menus if they want to. That would make me a hypocrite and there are
certainly factors other than pure efficiency that drive most peoples'
use. I wouldn't even claim that the penalty is significant in human time
scales. I'm just saying that people shouldn't encourage other people to
use a less efficient mechanism by propagating the misinformation that
it's actually more efficient. Unless of course they've become the first
person to finally acquire contradictory data. I'd be fine with it if
someone said: "I've determined that context menus *are* faster. Here are
the numbers and here's the testing methodology." It would be a
refreshing change from the standard argument, which can essentially be
summed up as "nuh-uh."

--
"Harry?" Ron's voice was a mere whisper. "Do you smell something ... burning?"
- Harry Potter and the Odor of the Phoenix
.

Relevant Pages

  • Re: [RFC/PATCH 0/22] W1: sysfs, lifetime and other fixes
    ... >> which is managed by bus master dirver, but also some logic over it, ... Why do you think caller is in process context? ... Control thread was created to process that work, ... Using connector for exaple you may send command REMOVE_*, ...
    (Linux-Kernel)
  • Re: Why doesnt foreach return a value
    ... Every Tcl command is implemented as a C level function. ... What we want at the script level is the ... What changes occur is very specific to the context. ...
    (comp.lang.tcl)
  • Re: there are too many context menues
    ... I am refering to the shy toolbar. ... 'clickless' command. ... put an arrow pointing up on the right click context menue that ... out the shy menue. ...
    (microsoft.public.word.docmanagement)
  • Re: there are too many context menues
    ... I am refering to the shy toolbar. ... 'clickless' command. ... put an arrow pointing up on the right click context menue that ... out the shy menue. ...
    (microsoft.public.word.docmanagement)
  • Re: Hiding the Menubar
    ... with a context menu than with the screen-rooted menu. ... So you have no data on efficiency. ... And in some applications the link between ctrl-click and right-click is ... the invocation is right-click and the common frameworks map ...
    (comp.sys.mac.misc)