On Fri, 21 Jun 2002, John Levon wrote:

> On Fri, Jun 21, 2002 at 02:52:17PM +1000, Allan Rae wrote:
>
> > FYI, you have eyes and a brain that is capable of pattern recognition.
> > We gave you a cursor (even one you can control with a mouse) you can
> > do the search and replace by hand.  Like we did in the good old days
> > when I were a lad. Oh wait that's sarcasm again.  Or is it hyperbole?
>
> It's just very silly.

My impression of your suggestion too.

> > I wish I could say "I feel your pain." about something as minor as
> > an ellipsis.  But I can't.
>
> Because it is NOT minor. "Hey, one minor ellipsis, one extra pref
> checkbox, who cares ?" - crap. Building a good user interface is in some
> significant part all about these supposedly "minor" things. This is also
> the stuff it's easiest to get wrong, because nobody EVER complains about
> things like this, but they make a real difference. I can only request
> you read that link I gave you, they explain this stuff far better than I
> could.
>
> > I also can't understand why useability is
> > a valid arguement for you but not for me.
>
> a) because you don't seem to understand the basic concepts

I think you are being pedantic and you think I don't understand...

> b) because you state it is unimportant (see above)

it is not worth losing sleep over, getting a migraine or an ulcer from
or suffering a heart-attack or anurism for.  It is important enough to
try to get right for the majority of cases but there are more
important things in life than worring oneself silly over an ellipsis.
Ask yourself: Is someone going to be completely confused or surprised
or injured if a dialog pops up when no ellipsis is present in the menu
entry?

I think not.  I did however suggest that the ellipsis should be
removed from the menu since the default setting doesn't pop up a
dialog and as such that case *is* more misleading -- because the
ellipsis built up an expectation that wasn't satisfied leading to
confusion.  Does this demonstrate an understanding of the basic
concepts?

After all the dialog does have a title and informs the user what is
expected of them.

> c) it is a valid argument for you, but you don't seem to making a strong
> case for it

I gave an example usage which you dismissed out of hand.  Obviously
our two editing experiences are very different.  Unfortunately you are
not willing to accept my usage experience as a valid one.

> > I am not opposed to cleaning up the interface or the code -- so in
> > that respect I am in agreement with you.  I just don't see why we need
> > to be so uptight about a few minor oddities.
>
> Then all I can suggest is that you think a bit harder about how these
> "minor oddities" accrue, and how unpleasant they make things, in sum.
>
> > So why can't we have a feature some others don't?
>
> All other things being equal, no reason. But all other things are not
> equal, so this is not relevant.

Not equal?  Not relevant?  For you perhaps.   We have a feature that
may cause a UI problem because an ellipsis may or may not be present
in the menu besed on what a check-box is set to.  Your solution is
remove the option and one of the features.  Don't you see how silly
this solution is?

I tried to make you see how silly it was by suggesting we remove the
search-and-replace feature as well.

> > Why can't we keep a feature that is useful at present?
>
> It's inconsistent with every other application's File->New behaviour. It

It's an _*option*_ that works especially well for the common case I
described.  It's not even the default behaviour.

> causes crufty code (see patch below). It complicates the awful prefs
> dialog. Anybody who actually uses it has at least three simple, better,
> ways of doing the same.

How about a fourth:

        File->New
        File->Named New...

anyway, your buffer-new patch seems almost okay except I can't
navigate to a directory and then name the file I must instead type the
whole path (if that path isn't the default one).

> It means the lack of an ellipsis is a lie (never surprise the
> user, and yes, it's still a surprise even if the user has to turn
> it on explicitly). Nobody uses it, FSVO nobody.

FSVO?

Well I guess I'm Mr.Nobody if I understand your last statement.
Have you bothered to ask on the users list yet who uses it and why?
Or are you basing your "nobody" arguement on hypothesis?  Or solely on
your editing experiences?

> > Just because an ellipsis won't be present if the non-default operation
> > is selected?  This seems excessive to me.
>
> No, for all the reasons above.
>
> > Allan. (ARRae)  Who will be leaving RSN to watch England beat Brazil.
>
> Hah, that's what lyx-devel said last time...

Disappointing.  Like they have been so often before.  They didn't seem
to want to win.  Maybe they were just too hot and tired but they'd
been in the region for at least a month so aclimatisation shouldn't be
an arguement.

> Here's a patch to remove it. It also adds a feature, namely buffer-new
> mychoice.lyx.
>
> # diffstat kill_ask.diff
> ...
>  7 files changed, 17 insertions, 124 deletions
>
> Removing cruft is good.

It'd still be nice to browse to set the path.

Allan. (ARRae)

Reply via email to