[Usability] Overriding defaults (Was: A Tale of a Toolbar editor)

iain <iain prettypeople org> writes:

> a) Toolbar uses applications default settings for toolbar style and
> provides an option called "GNOME Default" among the other styles that
> sets it to whatever the gnome default is.
> b) Toolbar uses GNOME Default setting, and provides the other options to
> change it.

I am not commenting on what is the best thing to do, but *if* an
application has the possibility to override the default setting
wrt. toolbar style, this is how I think it should be done (note: to
make sense of this, look at the GEdit View->Customize Toolbar menu):

        The application should have a gconf entry with four mutually
        exclusive states:

                "Gnome Default", 
                "Icons and Text"
                "Priority Text Beside Icons"

        The interface only shows three states, though:

                "Icons and Text",
                "Priority Text Beside icons"

        Here is the trick: When the user changes the state *to* the
        state that is the current default, the gconf setting is
        changed to "Gnome Default". When the user changes the setting
        to something that is *not* the current default, the
        corresponding state is saved to the database.

        Doing this has these advantages:

                - It does not use the string "Desktop Default" in the
                  interface option. This means one option less, and a
                  confusing option at that, because making sense of
                  "use desktop default" requires knowing what the
                  current default is.

                - An application where the user never did anything
                  will use the default.

                - If the user explicitly overrides the default, it
                  won't change if the user changes what the default is.

                - Instead of saying "just use the default", the user
                  can say "just use FOO", and if "FOO" happens to be
                  the default, the application will follow the default
                  from this point on.  

                  This is especially useful in applications where the
                  author has overridden the default and the user
                  wonders why it doesn't look like everything
                  else. Changing an applications style to match the
                  default will make it track the default.

        So, the only difference to the current behavior of GEdit is
        that the first menu item "Desktop Default" goes away, and when
        you change the style *to* the style that is the current
        default, the application start tracking the default.

Understanding why and how the above works requires a bit of thought on
the part of the programmer, but I think the result is simpler for the

The same thing could be done in a web browser:

Make the View menu contain two check menu items:

                "use my colors"
                "use my fonts"

that would apply to the current page. Whenever you change the setting
*into* what you have configured in the web browsers preferences page,
future loads of the current page will use the default - whenever you
change the setting into something else than the default, future loads
will use that something else, regardless of the default. If you don't
do anything, the default will be used.

This way, most pages would just use the default, but if you change it
for a given page, then, when you later return it would remember that
the default colors didn't work very well for this page and "use my
colors". Or vice-versa.

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]