On Wednesday 28 March 2012 17:31:00 Sebastian Kügler wrote: > I tend to think we don't. Apply can be done in multiple ways: > > - instantly: works well for single-action widgets, such as radio buttons, > buttons, sliders, togglebuttons, ... > - apply after timeout: works well where the executed action is heavier > (search a list from a textfield) > - selecting an item from a list if only a single selection is possible > > it doesn't work where you are making multiple adjustments to an object until > you're happy, in that case you want to apply / save your settings and > dismiss the dialog, here you'll need a button. An example here would be the > time picker dialog, or -- indeed -- Activity Settings =) > > The general rule should be to not use Apply buttons, and for dialogs, > dismiss them when clicked outside. (This is btw also how the Harmattan > components work, and I think it leads to smooth workflows.) Note that > dismissing the dialog means that settings are *not* applied / changed, so > in some cases, we'll still need Apply/Save/OK/whatever. > > Does this make sense?
It generally does make sense, yes. The challenge is, however, how to make the distinction clear to the user. There are some clear cases: - If a more complex action (like creating an activity) is initiated, where the user first sets parameters and the action should only be actually executed after the user is happy with her choices, a dialog with buttons is the method of choice. And here, I'd vote for also having a "Cancel" button (Cancel, not Close!) so the user has to explicitly cancel the action/process she initiated. - For single-action things like selecting an element (like our "Selection Dialog"[1]), it's totally obvious that an apply or cancel button would just be overhead. The more ambiguous case, however, are configuration dialogs. Currently, our Settings App uses instant apply, and I'm still convinced that this is a good thing which we should keep if possible in any way. Editing an Activity is - at least from a user's perspective - pretty much the same thing. So why is an apply button needed here? This still looks primarily like a technical thing to me, because some changes here involve heavy work in the background and we don't want to do that heavy work every time a user taps something in the dialog (which is absolutely reasonable from a technical perspective). So what if changing a setting in the Settings App involves heavy work in the background as well? Does that mean we use an Apply button just for this specific setting? For me, the amount of CPU cycles, RAM or I/O operations needed for a change to take effect is not a good criterion, because that's not what the user cares about. Therefore we need a user-understandable explanation for why we use instant apply in Settings but a dialog with buttons for configuring an Activity. If we can find that, I rest my case. I'm not against submit buttons as such, but we have to make sure that users always know when they need to press a button for changes to take effect and when they don't, without checking the title bar of each dialog for the presence of a button. Cheers, Thomas [1] http://community.kde.org/Plasma/Active/Development/ActiveHIG/Widgets/SelectionDialog _______________________________________________ Active mailing list Active@kde.org https://mail.kde.org/mailman/listinfo/active