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
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?
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.
Correct URL is http://msdn.microsoft.com/library/books/winguide/ch09c.htm
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.
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
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. ***
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.
*** 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.