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 11:49 AM
Subject: Re: Huge Batch Reply: Lars


>"Dan \"Effugas\" Kaminsky" writes:
> > Gnomeprint is created by the interface.  If the app freezes, the
interface
> > should still function...meaning one could kill the app from here.
>
>Yes. So why do we need another Exit in another menu?


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.

By the same token, it's no longer a question that Exit has file contexts.
We've established that users expect their unfinished work to be saved, or at
least checked if they should be saved, when Exit is triggered.  The behavior
of Force Quit?  Trigger Exit, and if the process isn't gone in a 10 seconds,
raise a window saying "kill application?"

> > This is something we REQUIRE.  GC1.  This is a key safety feature, it’s
a
> > key interface issue...
>
>Please stop inferring that I have said that this is something that is
>not required. It is required, I think it should be required, it should
>be GL1 or higher, and anybody who writes an app which modifies
>information in any way without this should be drawn and quartered. :)

>
>Seat belts are a safety feature. Are they optional equipment? Not in
>any consumer vehicle I've seen, not should they be. For some reason,
>the term 'safety feature' appears to mean 'optional' to you. It
>doesn't mean that.


Fine, we're agreed.

> > I never thought I’d see my girlfriend get so pissed about a UI thing.  I
> > mean, UI, my girlfriend PISSED?
>
>OK. Can she explain why it pisses her off, other than the fact that
>it's something different from what she's learned? If she can, great;
>we'll learn something from her (using your girlfriend to mean 'all
>people pissed off by this', of course :). I've got a feeling my wife'd
>be pretty ticked, too. However, I'd have a hard time getting her to
>articulate any reason why beyond the fact that it's different from
>what she's used before.


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.

I mean, something is up here. I told my GF about screenplays, she was like
"that's pretty cool".  I told her about the menuprint stuff, she said "ok"
and kinda gave me a look like "I'm no geek, stop telling me this stuff."

Then I told her that people wanted to change the name and contents of file,
and move quit.

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
interface, average joe users happen to find the File menu VERY VERY USABLE.
It *works*, it's *ALWAYS* there, it's comforting, and it maps to a "brain
image" of how programs work.

Off the top of your head, right now, how do you print?  File::Print.  Off
the top of your head, right now, how do you save?  File::Save.  Off the top
of your head, how do you Exit?  File::Exit/Quit/Whatever, it's always on the
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
selected text?  No standard.

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.

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.

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.

My girlfriend, my 75 year old grandmother, and every user I know will RUN IN
FEAR away from GNOME if it f***s with file.  I can get them to sign a
petition if you like, there's SERIOUS user anger that's triggered if you try
to break this.

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.

> > >I do think that it would be a mistake to have it in more than one
> > >menu, though.
> >
> > What about Force Quit v. Exit?  Quick easy way to kill process very
> > logically.
>
>If you can keep GTK responding after the app has frozen, sure. I'd
>more likely do an xkill from a wm menu. Besides, if we get old Win95
>users, they'll likely just hit Ctrl-Alt-Del for the process window.


Maybe Gnome should overlay it with a separate process that deals with
generating these specific menus, so they stay alive when the app dies?