Re: Menu Guidelines

["Guillermo S. Romero / Familia Romero" <famrom infernal-iceberg com>]

zinie cs unibo it (2001-06-29 at 0048.28 +0200):
> Yes, it could be useful, but why nuke NS?  Perhaps you have another memory
[...]

It was a example. Let use abstract descriptions, to avoid problems. It
seems exact examples are bad.

> > No, buy more RAM or fix NS are not solutions, maybe I do not have the
[...]
> Why are you speaking in this way?  Is this the idea I gave you, that I was
[...]

It was a warning, cos when the talk appears, it includes that things
(get more this, fix that, etc). Speaking about usability, some people
do not have the money for better systems, or must use the resources
doing other things, or you can not fix the problem cos it is out of
reach.

> Of course the user can't be forced to open a terminal and play with
> killall, for similar tasks.  But for that very same reason I'm against the
> 'Quit app' option as a solution for memory or CPU hogs.
> Doesn't the 'Quit app' button imply that the user should have an idea of
> what the application is, and that he understands that the application is
> not the window he sees, but another thing behind the scenes that opens all
> these (not necessarily) similar windows with all these unrelated
> documents?

So instead "I want this, for whatever reason I have, go away ASAP, so
I use _it's_ go away", which is direct manipulation, you prefer "I
open that, try to find this in that, so it (_that_ it) tells it
(_this_ it) to go away", which is indirect manipulation.

It is longer, an indirect path with the same results and can cause
extra errors (both at user and programmer level). But if you do not
provide a Quit Foo, it then becomes the only way that does not require
you to click 5 or 10 or x close buttons.

Your solution makes things a bit complex, even if the user will never
require using a task manager due bugs, errors, resource hogs or
whatever, the solution forces the usage of that task manager or makes
the user work a lot.

You are also forgeting remote applications, they do not run in your
machine, but they appear in your screen, adding more complexity (and
no, it is not rare, at home maybe, but in labs it is normal, sometimes
even mixing X with others systems that know zero about remote
displays).

The only reason for avoiding Quit Foo is if you open multiple Foos.
And that is an advanced situation, if you got there, you know what is
going under the hood already. Of course, supposing launchers invoke
already running apps if used without modifiers or without a user
toggle button that says "when I request a new app, I want a new app,
not to reuse running apps". Which IMHO it seems to be a nice approach,
normal people do not get a mess, and those who want can get all the
messes they desire.

Another extra measure would be a "Quit Foo always asks" (Quit Foo? \n
[Quit] [Cancel] \n This question can be disabled in Preferences) so
apps that are viewers (or used as viewers) give a safety net, easy to
be removed by just visiting Preferences (or whatever name it gets).

While having a task controler, like gtop or procman will help in cases
that have problems, or for the fun of seeing what is going under the
hood or any interesting thing you may want, it should not be the
solution for a direct action: "nothing more, dismissed".

GSR