Active Settings refactoring done

[Thomas Pfeiffer]

> > Why do we have a close icon? Cant the user just tap in the background
> > and it closes the overlay automatically? (Once again an interaction
> > principle from the desktop that is not needed here in my opinion)
> 
> honestly, I think that the "it's too desktopy" argument is the worse one
I
> ever read, and is quite concerning that it's coming up in different
areas
> without giving actual reasons.

Fania's argument was not "it's too desktopy". Her argument was "it's not
needed here". She has not explained why it's not needed in this particular
context yet, so that question is still left to be answered ;)
 
> is it the case of a metaphor not being suitable? maybe, didn't see
actual
> valid argumentations for it tough.
 
> what is the cost of removing things like close/cancel buttons?
> wether we want it or not, users will try a transfer of learning
> (http://learnweb.harvard.edu/alps/thinking/docs/traencyn.htm, both
positive
> and negative) when confronted with those interfaces so expectations on
how
> some tasks will be accomplished will be there.
> 
> tapping outside to dismiss is nice, not intuitive at all tough (as
nothing
> really is) could be that is something that gets learned very fast, I
don't
> have an answer for it.
> 
> So, does this thing have enough advantages to be changed? i don't know,
and
> i'm not really against it, I would just like having good arguments
supporting
> that.

Well, this is really a difficult question. We need to distinguish actual
modal
dialogs from popups and layers though.
For a modal dialog it may make sense to have ok and cancel buttons,
because
when you open a modal dialog, your task is focused on that particular
dialog.
You usually only want to close it if you either have completed your task
or have
decided not to complete it.

However, not everything has to be a modal dialog.
For example, I did not include a cancel button in the SelectionDialog
because it
is basically a drop-in replacement for comboboxes. And the layer that pops
out
of a combobox when you click the expand button does not offer a cancel
button
either. The reason why we use a centered box instead of a layer popping
out of the
widget itself is that on a touch device you want everything users interact
with to 
be as big as possible, so we place it on the screen's center to have
maximum available
space. Compare the current two types of dialogs in the Date and Time
settings dialog:
The dialog for selecting an ntp server feels more lightweight than the one
for choosing
a timezone, because it has no cancel button. 

I think whether we want cancel buttons on e.g. the Add Items dialog is
something
that can be discussed. But putting ok/cancel buttons on everything that
pops up 
anywhere simply does not make sense.

And as for the thing we were actually talking about, which is the settings
dialog in the
browser: This thing simple is not a window. It does not open on a new
layer. Instead,
the browser "navigates" to a configuration "page". So a close button is
simply wrong
there.
And that's why sebas agreed and already replaced it with the appropriate
back button ;)