[Usability]Re: Menu guidelines updated

[Adam Elman <aelman users sourceforge net>]

At 12:57 AM +0200 9/9/01, Reinout van Schouwen wrote:
> In the discussion about instant-apply dialogs you say:
>
> > --begin quote--<
> I've gone back and forth on this a couple of times, but I think this 
> is correct for object property dialogs.
>
> Basically, you don't need "Cancel" or "OK" or anything like that, 
> since the dialog is instant-apply.  If it applies to a document, you 
> don't need an "Undo" button either since that functionality should 
> already be available from the document.  So the only button you 
> might need is "Close".  And that's redundant with the close button 
> that the WM provides (or at least should provide).
> > --end quote--<
>
> So am I right in concluding that you changed your opinion on this subject?

Man, I can't keep track of my opinion on this anymore. :)  Seriously 
-- yes, I'm still going back and forth, but I definitely no longer 
think that "Undo" is probably not a good idea as a button to have on 
most dialogs like this.

> That said, I would agree that menu bars are not always appropriate 
> and that if you have a simple app with a single window, a "Close" 
> button on the window (as well as the standard close control in the 
> title bar) is plenty.

I'm not even sure the Close button on the window (as opposed to the 
WM-provided title-bar close button) is necessary.  But I'm still 
going back and forth as the discussion on this continues.

> I'm curious what you think about apps like Gkrellm and XMMS. The 
> latter draws its own mini-titlebar, the former doesn't even have 
> that but its functions can only be accessed through a context menu. 
> This may seem bad UI design, but those two apps are a typical 
> example of programs that someone would want to run in a corner of 
> his screen, occupying minimal desktop space. A titlebar, menu or 
> close button would take an unacceptable(?) amount of extra space. 
> Seen from this perspective, the lack of obvious ways to manipulate 
> the program actually adds to its functionality! Or do you disagree?

I think there are other ways to minimize the amount of screen real 
estate that a program like that takes up.  I have generally found the 
lack of WM controls on XMMS to be really irritating, although it does 
help it to look cooler.  It makes it impossible to drag across 
virtual desktops, for example.

My approach to redesigning XMMS to reduce its screen real estate 
would involve rethinking the XMMS panel applet and improving that to 
the point where it is an acceptable substitute for the XMMS window. 
(For those of you who would argue that the panel is already too busy 
-- fine.  put it on an auto-hiding side panel on the side of the 
screen.  Takes up no space, is easily accessible, and still works 
better than the current no-WM approach.)  I'm sure there are other 
pros and cons to that, but that's the kind of thing I'd think of.

I've not used Gkrellm enough to comment on it specifically.

Adam
--