activity configuration UI

[Thomas Pfeiffer]

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