Re: [Usability] SM UI plan

[Gregory Merchan <merchan phys lsu edu>]

On Fri, Oct 12, 2001 at 10:41:56PM -0700, Seth Nickell wrote:
> We actually just tried to redesign the logout mechanism to remove
> *EXACTLY THIS PROBLEM*, I'm sort of wondering why you are trying to
> re-introduce it?!?

I concur with Seth, but I suspect Havoc and Paul were merely unaware 
of the work done.

> > This is my preference. A big benefit of this I see is that it allows
> > for logout options to be easily added or taken away without having to
> > change the basic user interface at all. They just have to be added to
> > the drop down list.
> >
> > This is useful for when users do and do not have permission to reboot
> > or shutdown a machine.
>
> So you are suggesting that if I don't have permission to do something it
> should be mysteriously absent from the menus? At least have the decency
> to inform me that the option exists but I may not excercise it. Even
> better (much better!) is to provide a mechanism for me to easily
> discover why it is that I can't access this option, and perhaps provide
> a mechanism for me to fix it.

Let me try to succinctly describe the 0-1-n model for everyone who hasn't
heard of it and for anyone who may have forgotten.

A computer system may be characterized by the number of non-root,
unique, simultaneous users it supports. According to this characteristic, 
a useful classification groups them as having either 0, 1, or n (any) 
number of such users.

That's the model. Working with that model we can identify certain needs as
particular to a class or as common to them all. We should endeavor to support
each class. A simple example:

 0 non-root, unique users.
   In a kiosk, everyone uses the same account. The interface must be simple
   or familiar enough to allow people to walk up and use it. There is
   no logging in; 'guest' is always logged in. In addition to being simple,
   the system must be tamper-proof, idiot-proof, drunk-proof. Usually only 
   a few programs are available. The guest has no need of administrative 
   function and should be prevented from performing them. The kiosk still
   needs an administrative interface for the maintainer; the maintainer
   probably does not regard the kiosk as a computer, but as any other
   serviceable device such as a photocopier, vending machine, or
   air-conditioner.
   GNOME is already used in this way: 
     http://www.dnalounge.com/backstage/src/kiosk/

 1 non-root, unique user at a time.
   The typical family computer is in this class. I assume everyone is
   familiar with this.

 n non-root, unique, simultaneous users.
   The typical work environment is this. Many people have accounts. Any
   number of them are logged in at the same time. The BOFH controls all.
   As in the kiosk, the users do not own the hardware. Turning off the
   computer may or may not be an option. Some users have more privileges
   than others. The range of skills is very large. A help desk may be
   available. Security may be a great concern. There's much more to this
   than I'll mention now.
   For an account of one of the challenges GNOME will face, see here:
     http://www.usenix.org/publications/library/proceedings/lisa95/full_papers/gittler.txt

To answer Seth's question:
> So you are suggesting that if I don't have permission to do something it
> should be mysteriously absent from the menus? . . .

Mu. No answer because the question contains an invalid assumption; in a 
kiosk or a particular work environment, the presence on the menus of an
unavailable command would be mysterious - the absence would not even be
notices.

>                                         . . . At least have the decency
> to inform me that the option exists but I may not excercise it. Even
> better (much better!) is to provide a mechanism for me to easily
> discover why it is that I can't access this option, and perhaps provide
> a mechanism for me to fix it.

When this applies, it applies to more than just administrative functions.
If I recall correctly, we intend to address this in the HIG.

Cheers,
Greg Merchan