Open Bug 42339 Opened 24 years ago Updated 3 years ago

Apply button in Preferences

Categories

(SeaMonkey :: Preferences, enhancement)

Product:
SeaMonkey
Component:
Preferences
Type:
enhancement
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Milestone:
Future

People

(Reporter: bugzilla, Assigned: samir_bugzilla)

References

Details

(Whiteboard: [2012 Fall Equinox])

Attachments

(1 file)

screenshot of how it looks, if anyone cares
29.03 KB, image/gif
Details 
Why are there no apply button in Preferences? Would it be very hard to do?
I can see where this could come in handy.   For example, if you're playing
around with different font sizes.   You shouldn't need to click OK, and then go
back into preferences again to change it again.   An Apply button would come in
handy.
Summary: Apply button in Preferences → [RFE] Apply button in Preferences
ben...?
Assignee: matt → ben
Severity: normal → enhancement
reassigning to myself. I just added an apply button..it wasn't too hard.  It 
will be harder if we decide to do as some other apps do, namely, only enable 
the Apply button when a change has been made (i.e. if once you press apply, the 
Apply button becomes disabled until you change a preference, at which point it 
becomes enabled).  However, I don't think it's necessary to do this, since it's 
just extra coding and there's no real benefit from it.
Assignee: ben → BlakeR1234
a discussion on mIRC in #mozilla seems to have yielded the decision to add this 
to the non-modal prefs dialog only (which, on non-unix os's, can be turned on 
via a pref I don't have handy at the moment).  Everyone OK with this?

cc akkana and ben
Status: NEW → ASSIGNED
german - would that be the correct order of buttons, OK - Apply - Cancel ?  I 
notice in the AIM preferences, the order is OK - Cancel - Apply (which seems a 
bit awkward to be)
IE has "[ Ok ]  [ Cancel ]  [ Apply ]" which seems to be the most used variant.
*** Bug 43370 has been marked as a duplicate of this bug. ***
This dialog is modal however, and "Apply" means nothing in that context...

Also, with a non-modal pref dialog, "OK" is meaningless, the choices become 
something akin to 

[ Apply ] [ Undo ] [ Close ]


Agreed about the terminology in the nonmodal case.  Note Blake's earlier comment
about adding it only when the dialog is nonmodal (which is the default on Unix);
though actually, even in 4.x where the dialog is modal, I would have loved to
have had an apply button, in particular for font-switching so that I could see
the font I was switching to and still have the dialog up in case I didn't like
the look of the new one.
The Apply button seems to have dispeared latley. Is it not going in or did it 
get lost with the landing of the new Modern skin?
Priority: P3 → P4
Target Milestone: --- → M20
Was just messing with font types/sizes earlier and found it really annoying to
have to hit OK and reopen prefs to test every selection. I realize this is a
relatively minor bug, but I'd still like to see an apply button implemented.
Allowing prefs to update without closing the prefs dialog is fine, but please 
don't do it with an `Apply' button.

`Some applications use an Apply button to approximate the behavior of immediately 
updating the document or using a sample area. This method confuses the meaning of 
OK and Cancel and is not recommended.'
<http://developer.apple.com/techpubs/mac/HIGuidelines/HIGuidelines-146.html>

If the prefs dialog is modal, it should have `Ok' and `Cancel' buttons along the 
bottom, and the prefs should only be updated when the `Ok' button is pressed.

If the prefs dialog is non-modal, it should have a close box and no buttons at 
all along the bottom (except for possibly `Revert' at the bottom of each panel to 
revert that panel's settings), and the prefs should update whenever a control is 
manipulated. (For text fields, this means whenever focus leaves the text field.)

I disagree with that.  That may be true on a mac (in which case we'll certainly 
do it that way on a mac), but convention on Windows is an Apply button.
What mpt says applies to all platforms. True, Windows users may be less aware of 
the inconsistency of having Apply, Cancel and OK buttons, but the problem is 
still there. And, Mozilla being XP, we need to use a solution that is appropriate 
for all platforms.

Changing all the fonts in the entire application every time focus leaves the
font selection UI element sounds heavyweight and slow.  Waiting for the user to
click Apply after changing several fonts seems a lot friendlier.  And I agree
with Dave that the current interface, where you have to click OK to try the
font, then bring the dialog back up, then click on fonts and wait again for the
font panel to load, is a major hassle.  It's the worst font selection UI I've
ever used, which is saying something coming from a Unix user!
Simon, we strive to follow platform convention all over the product, even if it 
means non-XP solutions.  That shouldn't be a major factor in this decision, 
especially since platform-specific overlays for prefs already exist.  And where 
did you get the idea that Apply shouldn't be used on all platforms?  
Microsoft's Windows 98/2000 UI guidelines at 
http://msdn.microsoft.com/library/default.asp?
URL=/library/books/winguide/ch00a.htm clearly says that using Apply is fine.  I 
know that you and Matthew are heavy mac users, but we also need to take Windows 
guidelines into consideration.

None of the alternatives presented are, imo, good ideas.  `OK' shouldn't just 
save prefs and leave the window open, and you shouldn't have to press `Cancel' 
to leave the window.

And I think the idea of saving prefs onblur is horrible (assuming the pref 
dialog was ever non-modal).  It's sort of like the case presented in 
http://iarchitect.com/tabs.htm#tab2.  What if you want/need to do field 
validation?  You're going to throw up an alert every time the user switches 
tabs or clicks in a different control?  And as akkana says, this would 
probablly be painfully resource-intensive.  Not to mention the fact that it's 
inconsistent with every settings and preference window I've ever seen on 
Windows.  And a Revert button at the bottom of each pane?  Sorry, but I really 
hate this solution.

The HIGs advise against having an `Apply' button not because it's not standard on 
Mac OS, but because it decreases usability -- and that's true no matter what 
platform you're on. I only quoted from the HIGs because I was feeling lazy. Sorry 
about that.

Firstly, in a dialog without an `Apply' button, the `Cancel' button makes no 
changes outside the dialog; but with an `Apply' button, the `Cancel' button does 
make changes outside the dialog. That is inconsistent. Secondly, where changes 
have been made in a dialog without an `Apply' button, the `Ok' button will make 
changes outside the dialog; but with an `Apply' button, the `Ok' button may or 
may not make changes outside the dialog, depending on whether the `Apply' button 
has been pressed previously. That is also inconsistent. And thirdly, the 
existence of an `Apply' button can (I have seen it happen) mislead users into 
thinking that they must always choose `Apply' before they can choose `Ok'. That 
wastes the user's time.

Akkana: manipulating the controls in the Fonts panel would not change `all the 
fonts in the entire application', it would only change those fonts in the content 
of the Web page(s) and message(s) currently being displayed. Once the Mozilla 
applications have separate prefs dialogs, the `and' in that previous sentence 
will become an `or', making it even faster. And if there are still performance 
problems with that, that's a problem with the layout engine and/or style system 
(e.g. lack of interruptable layout), it is not a problem with the UI.

Blake: performing field validation after the user has left the field is bad UI 
anyway. None of the controls currently in the prefs dialog require such 
validation, and I can't think of any additional field which would both require 
such validation and which wouldn't be better handled in its own dialog (where the 
enabledness of the `Ok' button could be toggled depending on the validity of the 
currently-entered value). Validity of fields in the prefs dialog which require 
numeric values, such as screen resolution and port numbers, should be ensured 
simply by preventing the user from entering non-numeric characters into the 
fields in the first place; it should not be done by using an error dialog, once 
the user has left the field, to tell the user how naughty they've been.

I've always thought of the cancel button as discarding all changes made since
the apply or ok button was clicked. The apply button enables the user to apply
changes (s)he is sure of and proceed to make more changes without having to
close and re-open the dialog.
I have seen users who appear to think they must press the apply button before
clicking the ok button. I sometimes do it myself when using windows, mostly
because I have encourntered buggy applications under windows that actually do
require the user the press the apply button (at least in certain cases). I
don't, however, see any usability degradation from a correctly implemented set
of ok/apply/cancel buttons.

Another possible way to solve the problem is to list the current selected fonts
in the fonts section of prefs and diaplay a "change..." button which brings up a
separate dialog for editing font prefs... this wouldn't be my first choice (my
first choice being to have an apply button like most windows apps do) but it
would be much more practical than the current setup so I thought I'd suggest it
anyway.
Priority: P4 → P3
Target Milestone: M20 → mozilla1.0
Priority: P3 → P4
not gonna worry about this at the moment...
Assignee: blakeross → matt
Status: ASSIGNED → NEW
Priority: P4 → P3
Target Milestone: mozilla1.0 → ---
It is true that Win32 has a very liberal and established use of 'Apply' in the 
control panels (apply as in make the change while leaving the dialog open) 
while Mac usually do it in the way MPT describes. Win32 apps are very 
inconsistent though in terms of what happens once things are "applied".
But, one of larger problems is that the prefs are all different, sometimes 
things can be 'previewed' using an apply and seen immediately, other though can 
only be applied when the prefs dialog is closed. Prefs are an open architecture 
that allow any app provider (like e.g. Chatzilla or Chameleon) to add their own 
panel. 'Apply' will not be suitable to all of them.

I would suggest then that since we have a cross-platform toolkit we bail on 
this one, as it is too complicated to get the UI right across all the platforms 
and across all the various panels. An alternative might be that select panels 
have a 'preview' button, like the font panel that the original reporter of this 
bug mentioned.

Mozilla being cross-platform is not a good reason not to do this -- we can use 
a platform-specific overlay. But having an `Apply' button is not compulsory on 
Windows, so we should only do it if it is good UI, and I don't think it is.
Found this in the Interface Hall of Shame:
<http://www.iarchitect.com/msoft.htm#MSOFT8>

Another possibility is to enhance prefs so they work similar to gnomecc (Gnome
Control Center) under Linux.
In gnomecc, each category appears is its own "sub-window" (I'll call is
sub-window since I'm not sure what the right term would be) within the main
window and has its own OK and Cancel buttons so that changes can be applied to
each category individually. The main prefs window doesn't have OK and Cancel
buttons but must be exited via File->Exit (I would probably advocate having an
Exit button on the prefs window).
Ugh. Gnomecc is one of the worst user experiences I've ever had. Please don't let 
us go there. Its problems are too legion to mention.

>Secondly, where changes have been made in a dialog without an `Apply' button, 
>the `Ok' button will make changes outside the dialog; but with an `Apply' 
>button, the `Ok' button may or may not make changes outside the dialog, 
>depending on whether the `Apply' button has been pressed previously. That is 
>also inconsistent.

I don't see that as inconsistent or confusing.  The "OK" button doesn't always 
make changes; it makes changes if you've changed any options since opening the 
dialog (or since clicking "Apply").  The user isn't going to click "OK" and 
wonder why no changes occurred immediately just because there's an "Apply" 
button.
*** Bug 72715 has been marked as a duplicate of this bug. ***
*** Bug 76480 has been marked as a duplicate of this bug. ***
RFE cleanup. RFE is already indicated by the Severity field...Sorry for the 
spam!
Summary: [RFE] Apply button in Preferences → Apply button in Preferences
over to samir/moz1.0.

also compare with bug 44032.
Assignee: matt → sgehani
Target Milestone: --- → mozilla1.0
Target Milestone: mozilla1.0 → mozilla1.1
I can see possibilities where I would use the Apply button
even when the dialog is modal. For example:

1) I click on a pref. I change some settings I am sure of.
2) I go to 10 other settings and change them all.
3) I decided to forego the changes. Thus I clicked Cancel.

Result: All changes are discarded. Even the ones made in (1).

Expected: If there were an Apply button, I would have
pressed it after (1). Then after I press Cancel in (3),
only those prefs I want cancelled will be cancelled.

Currently what I do is:
1) I click on a pref. I change some settings I am sure of.
2) I click Ok.
3) I open the box again.
4) I go to 10 other settings and change them all.
5) I decided to forego the changes. Thus I clicked Cancel.

The extra step of closing and reopening the window would
have been avoided had there been an Apply button.

Bamm

*** Bug 161490 has been marked as a duplicate of this bug. ***
> The extra step of closing and reopening the window would have
> been avoided had there been an Apply button.

Agreed.  It would be very useful for staying within Preferences and applying
incremental changes.  Since there's no way of knowing if the user is going to
visit a non-modal dialogue after having first gone to a modal one, the
assumption shouldn't be made that the modal dialogue will be the *only* thing
the person will be viewing / changing.
*** Bug 164186 has been marked as a duplicate of this bug. ***
> Agreed.  It would be very useful for staying within Preferences and applying
> incremental changes. 

Yes, *please* consider how the user will operate the GUI.

Consider how fluid things would be if, once in the Preferences windows, the
user could:
1. change a setting,
2. click Apply to see how the change looked,
3. make a second change (change back, try new value, or set different setting),
4. Click Apply to see how the next change looked.

Consider how much extra gesturing effort is required without an Apply button:
1.  change a setting,
2.0 click Okay to see how the change looks,
2.1 move the mouse cursor from where the Preferences window was displayed to
    where some other window's View menu is displayed,
2.2 press or click on the View menu,
2.3 drag or move down to the Preferences... menu item,
2.4 release or click on the Preferences... menu item,
2.5 (possibly deal with window placement in the window manager),
2.6 move the mouse cursor from where the Preferences... menu item was displayed
    to wherever the new Preferences window appeared,
3.  make a second change (change back, try new value, or set different setting),
4.  click Okay to see how the next change looks.

Multiply that extra effort by the number of settings changes the user wants to
do at one time.


*** Bug 204969 has been marked as a duplicate of this bug. ***
retargeting
Target Milestone: mozilla1.1alpha → Future
*** Bug 217551 has been marked as a duplicate of this bug. ***
> Consider how fluid things would be if, once in the Preferences windows, the
> user could:
> 1. change a setting,
> 2. click Apply to see how the change looked,
> 3. make a second change (change back, try new value, or set different setting),
> 4. Click Apply to see how the next change looked.

I absolutely agree with you: the "Font" window is presently unusable because of
lack of that "Apply" button. I don't consider the theoritical issues about the
correctness of its semantics, I am just an ending user and I just say that the
usability of the present "Font" window is close to zero.
Product: Browser → Seamonkey
*** Bug 276383 has been marked as a duplicate of this bug. ***
*** Bug 296160 has been marked as a duplicate of this bug. ***
Both Comment 32 and Comment 36 looks still valid in favor for adding Apply button
Priority: P3 → --
Whiteboard: [2012 Fall Equinox]
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: