🚀 go-pugleaf

In article <199309021153.AA00922@tsf.laas.fr>,
David Powell  <David.Powell@LAAS.FR> wrote:
>
>Try typing "sm" faster - I think the functionality you want is
>already there.

Yes it is there, but if you skip a beat (on a 486) you often end up
somewhere you don't want to be.  I'd rather see a true type-to
function where you don't have to type it just right and super fast to
make it work.

In article <26596i$jne@titan.ucs.umass.edu>, dtodd@titan.ucs.umass.edu
(David M. Todd) wrote:

> In article <199309021153.AA00922@tsf.laas.fr>,
> David Powell  <David.Powell@LAAS.FR> wrote:
> >
> >Try typing "sm" faster - I think the functionality you want is
> >already there.
> 
> Yes it is there, but if you skip a beat (on a 486) you often end up
> somewhere you don't want to be.  I'd rather see a true type-to
> function where you don't have to type it just right and super fast to
> make it work.

But the drawback of your suggestion is that: say you want to go to the
"s"'s, so you type an "s", then you change your mind and want to go to the
"m"'s. In your system, that would take you to the "sm"'s instead. You'd
have to add a way to cancel your request in your system. The present system
is self cancelling if you wait long enough. 
  ___
   |
 \_|IM RATLIFF
   Dept. of Economics
   University of Arizona

In article <jratliff-020993104001@econ179.bpa.arizona.edu>,
>> Yes it is there, but if you skip a beat (on a 486) you often end up
>> somewhere you don't want to be.  I'd rather see a true type-to
>> function where you don't have to type it just right and super fast to
>> make it work.
>
>But the drawback of your suggestion is that: say you want to go to the
>"s"'s, so you type an "s", then you change your mind and want to go to the
>"m"'s. In your system, that would take you to the "sm"'s instead. You'd
>have to add a way to cancel your request in your system. The present system
>is self cancelling if you wait long enough. 

Personally, I'd rather have a cancel key (ESC?) for when I change my
mind and able to type right to a reference than to have to type
quickly to hope to get in the right neighborhood.


|~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ David M. Todd ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~|
|Department of Psychology, University of Massachusetts, Amherst, MA 01003 USA|
|Phone: 413/545-0158 ___ <David.Todd@Psych.UMass.EDU> ____  Fax: 413/545-0996|

In article <265gaj$t7i@titan.ucs.umass.edu>, dtodd@titan.ucs.umass.edu
(David M. Todd) wrote:

> In article <jratliff-020993104001@econ179.bpa.arizona.edu>,
> >> Yes it is there, but if you skip a beat (on a 486) you often end up
> >> somewhere you don't want to be.  I'd rather see a true type-to
> >> function where you don't have to type it just right and super fast to
> >> make it work.
> >
> >But the drawback of your suggestion is that: say you want to go to the
> >"s"'s, so you type an "s", then you change your mind and want to go to the
> >"m"'s. In your system, that would take you to the "sm"'s instead. You'd
> >have to add a way to cancel your request in your system. The present system
> >is self cancelling if you wait long enough. 
> 
> Personally, I'd rather have a cancel key (ESC?) for when I change my
> mind and able to type right to a reference than to have to type
> quickly to hope to get in the right neighborhood.

I'll offer the cop-out defense of the current implementation: :)

Apple publishes Human Interface Guidelines, to which all applications are
supposed to conform. The HIG specifies the "correct" behavior in exactly
this context: The HIG requires exactly the behavior which EN currently
obeys. EndNote would have to _violate_ the HIG in order to incorporate your
suggestion. Part of the motivation behind the HIG is that it guarantees
(unless software companies violate them!) a consistent interface between
applications.

One common example of this behavior is the standard file dialog boxes. When
you see a list of files to open, this is how you quickly move to one. The
Finder windows work exactly the same way.
  ___
   |
 \_|IM RATLIFF
   Dept. of Economics
   University of Arizona

In article <jratliff-020993162647@econ179.bpa.arizona.edu>,
Jim Ratliff <jratliff@bpavms.bpa.arizona.edu> wrote:
>Apple publishes Human Interface Guidelines, to which all applications are
>supposed to conform. The HIG specifies the "correct" behavior in exactly
>this context: The HIG requires exactly the behavior which EN currently
>obeys. EndNote would have to _violate_ the HIG in order to incorporate your
>suggestion. Part of the motivation behind the HIG is that it guarantees
>(unless software companies violate them!) a consistent interface between
>applications.
>
>One common example of this behavior is the standard file dialog boxes. When
>you see a list of files to open, this is how you quickly move to one. The
>Finder windows work exactly the same way.
>  ___

BEing a PC user, I'm not familiar with the Apple guidelines, and I
understand your wanting consistency.  Windows seems to use the
type-to-or-cancel approach which seems more useful to me.  I suppose
there could be a preferences switch which gives us the choice, or at
least lets us alter (slow down) the speed at which we have to type to
make use of the feature.


|~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ David M. Todd ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~|
|Department of Psychology, University of Massachusetts, Amherst, MA 01003 USA|
|Phone: 413/545-0158 ___ <David.Todd@Psych.UMass.EDU> ____  Fax: 413/545-0996|