Re: [Usability] SM UI plan

[Seth Nickell <snickell stanford edu>]

> > Using a pull-down menu with deferred application to perform an action is
> > a blatant mis-application of controls. Controls that may reasonably be
> > used to perform actions are toolbars, menus (in menubars!), and command
> > buttons. That is probably the most serious problem with the interface.
> 
> hmmm, whatever...
> seth, no offense to you, but I think the guys at redmond /at this times/ 
> know a little more about interfaces than you...

There are people at Redmond that do, this is true, but Microsoft
actually tends to suffer from much the same problems as GNOME (dominated
by developers), and has in the past and continues to produce some of the
shittiest interfaces known to man. 

The Windows95 use of option buttons with OK is a very awkward interface.
I suspect it was chosen intentionally to make the user have to pause
before they performed a potentially regrettable action (a worthwhile
goal). Non-standard interfaces can sometimes be used to good effect when
the desired property is to make people think about what they are doing.
For example, making it awkward to accept a dialogue that will format my
hard disk is probably a good thing. Using pulldown menus looks more
attractive but is even more inconvenient, probably beyond justification
(other than artistic reasoning).

I can think of a few interfaces that introduce an extra layer of caution
without creating this confusing mixed-mode interface (conversational
interface on a desktop environment). One particularly good one would be
to put the options as seperate items in submenus in the menu bar. For
example:

Actions->Can't Think of a Name->Logout
Actions->Can't Think of a Name->Shutdown

etc

Misuse of a control simply is not justifiable. There are other options.

> > > 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?
> 
> seth, I'm pretty sure my mom doesn't want to see an "stand by" option
> there, that for all intentions and purposes, simply do NOT work...

I've agreed with capnbunzo privately that it may be worth hiding options
that do not apply to a particular computer at all. There's always a
tradeoff between visibility/consistency and simplicity. One of the most
problematic aspects of the Macintosh is the lack of explanation given
when an option is unavailable. Interface design is about a lot more than
simplicity. Sometimes simplicity has to be sacrificied to gain
consistency, users are more likely to be aggravated when things change
than if there are two extra buttons.

You are right that your mom probably doesn't want to see a stand-by
option greyed out. But another class of user, say, travelling executive
who gets his notebook from the IT department, will be confused if the
available options change between computers with no explanation. I myself
wondered at times why I could shutdown some computers from the menu and
not others (its a gdm option, but I didn't know that at the time).

A good interface has high visibility.

> and she will ask me why... (again... and again)...
> 
> > 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.
> 
> that's /maybe/ good for a geeky, not for my mom...
> she does not want to fix nor discover things (leave alone easily) 
> with the computer, she simply want to _use_ it.

Which is precisely why its important to provide an option to fix broken
things for her. Computers suck, and they will always be broken in ways
the user does not want. It is unrealistic to assume that the
computerness of the computer will never show through. The trick is
making it easy enough to fix things that users can get on with what they
actually want to do. In some ways this is problematic on *nix systems
because of user accounts and the confusing need for an administrator
password, but such is the material we are given to work with.

Having a one button click to "make the button work again" would be a
boon to many users. Sure, it would be nice if the button wasn't disabled
in the first place, but distributions will always do annoying things
like that.

-seth