Re: [9fans] mouse vs key

Re: [9fans] mouse vs key

[rob pike]

I tried one of those tactical feedback mice on Windows, just to
see what it could do.  I too was thinking of giving feedback: turning
scrollbars into little troughs, sticking at window edges, that sort of
thing. But then I learned that all it does is vibrate.  Nonetheless,
with drivers installed and all that, I couldn't get it to do anything
tactile at all.  The jury is still out, if the court is even convened.

-rob

Re: [9fans] mouse vs key

[Boyd Roberts]

> The jury is still out, if the court is even convened.

i do remember thinking (when i was using the blit) that
i wish that damn code would give me back my mouse!  then
you'd make a massive overcorrection and the mouse cursor
would be anywhere except where you wanted it to be.

Re: [9fans] mouse vs key

[Douglas A. Gwyn]

Boyd Roberts wrote:
> i do remember thinking (when i was using the blit) that
> i wish that damn code would give me back my mouse!  then
> you'd make a massive overcorrection and the mouse cursor
> would be anywhere except where you wanted it to be.

The way we implemented cursor hysteresis (using a tablet pen
rather than a mouse) in the PEAC system, for example in
locking onto menu items, was simply to track the actual
locator device coordinates all the time but "snap" the
displayed cursor location to whatever grid once we were
within lock range of a grid position (e.g. something like
1/2 of an item width for menus).  That is much better than
adjusting the locator coordinates to always match the jumped
cursor location.  Our users were very happy with the
behavior: solid visual feedback when an item became
clickable, a "dead space" around the exact grid location
within which small locator motions would not change what
was clicked on, and continuous locator mapping into the
display space so that one's motor intentions were always
consistent with observed behavior.

[9fans] ls -m

[rob pike]

The [muid] format was not chosen at random.  I was worried about
ls -lm producing three uids.  Just printing another uid after the gid
would be confusing: two make a couple but three are a lot to keep
straight intuitively.  I wanted ls -m to be useful without -l, but to
have a format that reminds you of its output.  (Quick: what are the
units in ls -s?)  I also considered the possibility of the muid
showing up in other places, such as history(1), in which a purely
positional mnemonic wouldn't be available.  As it stands, if you
see [muid] anywhere, you have a clue what it means.  I chose a
bracket format because it is a parenthetical remark about the file;
it contains no permission information, for example.

So I understand the objection but I still think it makes sense to
present the muid differently.

-rob

[9fans] mouse vs key

[Scott Schwartz]

Re-reading Tog's articles, I'm struck by one thing:  The studies he cites
were done using the Mac GUI, which has specific properties that make the
mouse efficient (Fitt's law: targets along an edge are faster to access).
Most other systems lack those properties, which might effect the outcome.

Also, elsewhere he's said that mouse chords are a bad idea. 
Possibly not the best source for a defense of Acme. :-)

Re: [9fans] mouse vs key

[Dan Cross]

In article <20010520013841.25839.qmail@g.bio.cse.psu.edu> you write:
>Re-reading Tog's articles, I'm struck by one thing:  The studies he cites
>were done using the Mac GUI, which has specific properties that make the
>mouse efficient (Fitt's law: targets along an edge are faster to access).
>Most other systems lack those properties, which might effect the outcome.

That's interesting; could you elaborate on what those properties
are?

	- Dan C.

Re: [9fans] mouse vs key

[Matt H]

Hello Scott,

SS> (Fitt's law: targets along an edge are faster to access).
SS> Most other systems lack those properties, which might effect the outcome.
I've been looking forward to tactile feedback mice for this kind of
reason. When them mouse crosses a window boundary for instance, it
resists for a short time to help you target your mouse.

Logitech have now released one :
http://www.logitech.com/cf/products/productoverview.cfm/79?24


SS> Also, elsewhere he's said that mouse chords are a bad idea. 
SS> Possibly not the best source for a defense of Acme. :-)

hehe but they were convinced that a combination of mouse and keybard
were positive which does lend some weight to my idea of assigning
stuff to the function keys. Function keys are also present on the
world's keyboards (AFAIK). Making them programmable would be cool. In
fact if you made them a directory you could bind them in either
collectively or individually. Takes me back to my BBC Model B and is a
function I've missed in modern computers.



-- 
Best regards,
 Matt                            mailto:matt@proweb.co.uk

Re: [9fans] mouse vs key

[Boyd Roberts]

From: "Matt H" <matt@proweb.co.uk>
> 
> I've been looking forward to tactile feedback mice for this kind of
> reason. When them mouse crosses a window boundary for instance, it
> resists for a short time to help you target your mouse.
> 

iirc jim or a version of the window system that ran in the blit
used to have 'gravity' so that the cursor would 'stick' to the
scrollbar.  rob will correct me on this.

i'm not sure such features are a good thing.