Re: Huge Batch Reply: Lars

["Dan \"Effugas\" Kaminsky" <effugas best com>]

-----Original Message-----
From: Lars Torben Wilson <torben@coastnet.com>
To: Dan "Effugas" Kaminsky <effugas@best.com>
Cc: gnome-gui-list@gnome.org <gnome-gui-list@gnome.org>
Date: Wednesday, August 05, 1998 12:51 PM
Subject: Re: Huge Batch Reply: Lars


>"Dan \"Effugas\" Kaminsky" writes:
> > Because it makes logical sense.  The menuprint is owned by the *system*,
not
> > by the application.  In Windows right now when a program crashes I need
to
> > press control-alt-delete and try to find that program's entry, and kill
> > that.  It'd be much nicer to have a button that works when even the app
> > doesn't and be able to force quit.
>
>So you keep saying. I just keep wondering what in the above paragraph
>means that there should be an exit item in both menus. We seem to be
>agreeing that it should be in the (system-owned, if you like)
>Gnomeprint menu.


Well, I see NO reason why it shouldn't be in the gnomeprint, but I see every
reason it should remain in file.  I agree, the titles shouldn't be
identical, nor should the actions, so I think, hurm, what pisses me off
about windows...AHA!

> > The file menu is one of those things that's just INCREDIBLY consistent,
I'm
> > sure the Mac HCI guidelines REALLY lock down its contents.
> > (Note...Kaminsky's Second Law...)  That's just it...consistent
interface,
> > time after time after time after time makes users SCREAM if something
isn't
> > done right.
>
>Look, I'm not now, nor have I ever, said that we should lose the File
>menu. I just disagree that quitting has anything to do with files,
>except that they are closed as a result.


That's a BIG except.

While you don't seem to be advocating removing the file menu, others are.
And I was saying *WHY* people are so addicted to file and are willing to
bitch and moan if I suggest that it get tossed.

My GF is more vociferous than me on this issue.  SHE'S NO UI GEEK?!?!?

> > When a non-geek like my GF(how'd that happen?) SPAZZES OUT OVER A GEEK
> > ISSUE, that means something.  It means that, unlike the rest of the
>
>The only thing one data point ever means is that you need more data
>points.:)


It's highly unusual for any normal user to really care about an element of a
user interface.  If I said, "What if we got rid of minimize", she'd be like,
well, I kind of like that, don't do that.  She got *angry* when I suggested
we get rid of exit, in true devil's advocate fashion ;-)

> > Off the top of your head, right now, how do you print?  File::Print.
Off
>
>Yes. Because I want to Print my File.
>
> > the top of your head, right now, how do you save?  File::Save.  Off the
top
>
>Yes. Because I want to Save my File.
>
> > of your head, how do you Exit?  File::Exit/Quit/Whatever, it's always on
the
>
>I want to Exit my App. So if app-wide stuff is under Gnomeprint, I look
there.


1)  What part of menuprint is self-documenting that it refers to app stuff?
Tooltip that says Program?  Control might be a better name.
2)  What do you do *now*?  Right off the top of your head, you KNOW the
answer.  No thought, no work.  That was the real point.
3)  You might, as a GNOME developer.  Most will get very confused if they
don't see Exit under File.  Here's another way to visualize it:  The doorway
into an application really should be File.  It's the first thing you are
meant to deal with after booting the app.  It's the front lobby.  Doesn't it
make sense for the first thing you're supposed to go to to also be the first
way you're supposed to leave?  And doesn't it also make sense that you'd
"pack up" before you go?

> > bottom.  Off the top of your head, how do you change preferences?  Note
the
> > "uhhh".  No standard.  Off the top of your head, how do you double space
the
>
>'scuse me. I didn't 'uhhh'. You did. Don't put words in my mouth, even
>if they're not real words. :) Application-wide preferences go under an
>application-wide menu.


No, RIGHT NOW.  Right now you HAD to uhhh because RIGHT NOW it depends on
what app you're dealing with RIGHT NOW.

> > selected text?  No standard.
>
>A formatting menu, perhaps? Just because you can *conceivably* put
>everything under one menu doesn't mean that anyone will. Anything is
>conceivable if you loosen your definitions far enough.


There is no standard right now, so it's an uhhh.  You'd hafta check the app.

> > Most monitors out there are small, at low bit depth, with bad refresh.
Pop
> > a user in front of a nice, big, 24 bit 21" screen, and they'll love it.
>
>WTF?:)
>
> > Most preference systems have no standard for where preferences should
go.
> > Pop a user in front of an interface that ALWAYS gives them preferences
in
> > the same, predictable places, and they'll love it.
>
>Precisely.
>
> > There is no menuing order that you can pop a user in front of that
doesn't
> > have file where the user isn't going to be annoyed right off the bat,
since
> > most computer users START from Windows or Mac or have heard a little bit
of
> > lingo.  The situation is compounded when random application specific
entries
> > start *FLOODING* the one harbor of consistency they have.
>
>What? Who said anything about adding stuff to the File menu (which I
>presume you're talking about)?


John R. Sheets, and a couple others.

Am I the only person here who realizes there's little to no consensus on
what these new menus should contain, or even if there should BE new menus?
Some people want to keep file, others are open to trashing it, others want
to totally redefine their contents(want to modify the contents of a file
inside of I/O home File?  Sure!)

> > One final note:  When you get down to it, IT REALLY DOESN'T MATTER WHY
USERS
> > HATE IT.  It just matters that they do.  Nobody uses something they hate
>   > unless they have to.  To me, that's a BIG hit on usability.
>
>Great. If users consistently hate it, even after getting to understand
>and use it, that's useful data. So far we have a user who hates
>the idea of it, but hasn't actually used it. Not yet useful.


We have users who got confused...