[openbeos] Re: BeOS/Haiku UI question

Stephan Assmus <superstippi@xxxxxx> wrote on Wed, 15 Feb 2006 00:01:53 
+0100
> Hi Koki,
> 
> > There is a preferences window with the following four buttons:
> > 
> > # Default
> > # Cancel
> > # Done
> > # Tab close button
> > 
> > Say I open a window, and change one setting. Each button would have 
> > the
> > following effect:
> > 
> > Default - Resets the settings to the 'factory default'.
> > Cancel - Closes the window as if I never opened it. The change is 
> > lost.
> > Done - Closes the window and saves/activates the settings.
> > 
> > But what about the tab Close button? Should it have the same effect 
> > as
> > the Cancel button? Or should it act as the Done button? What is the
> > expected behaviour in BeOS/Haiku?
> 
> I asked myself the same thing at least a couple of times. My decision 
> was 
> always one of these three:
> 1) Have no Close button in the tab, forcing the user to make a 
> choice. :-\
> 2) Have the Close button do the same thing as Done.
> 3) Have no "Done" button, hopyfully suggesting to the user that 
> simply 
> closing the window will commit the settings.
> 
> It is also interesting how the settings are applied. For example, if 
> settings take effect immidiately (which is the preferred way, but 
> sometimes, there is no visual feedback that settings are applied 
> immidiately), then there is no need for the "Done" button and 3) 
> would be 
> the preferred way. But I know that some settings are better not 
> applied 
> immidiately, for example when that is computationally expensive.
> It is also worth noting that all BeOS preflets (IIRC) implicitely 
> apply 
> settings as soon as you make them, closing the window "does nothing" 
> as the 
> new settings are already active.
> BTW, why not change the "Cancel" button into a "Revert" button, 
> meaning 
> that the settings are restored to what they were when you opened the 
> window. This is also working best with immidiately applied settings. 
> This 
> way, none of the buttons closes the window, except for the actual 
> close 
> button in the tab.

Stephan,

You raise an interesting point relative to how the changes are applied, 
and what effect this can/should have on the interface. It may be that 
this needs to be approached from the perspective of how the changes are 
applied, such as:

(1) When changes are applied in real time
(2) When changes are applied/cancelled when closing the window

For (1), I am inclined to having Revert, Cancel and Close buttons, plus 
the close tab (this redundancy can save mouse movement). This would be 
like the Preferences windows in BeMail.

In the case of (2), I would use Revert, Cancel and Apply (or Save?) 
buttons; I am not sure whether having the close tab would be a good 
idea, though, as closing the windows does not necessarily imply that 
the changes have been saved, and can therefore be confusing.

I would always try to use (1) whenever possible.

With regards to replacing Cancel with Revert, I am not so sure it would 
be wise to do so, as they offer two distinctive (and necessary) 
funcionalities: the former reverts the settings and closes the window, 
while the latter reverts the settings but keeps the window open. If you 
did replace Cancel with Revert, then cancelling would require two 
clicks (Revert + Close) instead of one (Cancel). Or maybe I am missing 
something?

Cheers!

Koki

Other related posts: