[prev in list] [next in list] [prev in thread] [next in thread] 

List:       mozilla-ui
Subject:    The prefs problem (was: Re: Domain- or URL- *or
From:       mpt26 () student ! canterbury ! ac ! nz (Matthew Thomas)
Date:       1999-10-18 9:47:26
[Download RAW message or body]

[mozilla-prefs added to recipients; mail-news removed from follow-ups]

Earlier, I wrote:
>...
> > > ... And I that's really enough time (five hours) to spend on one
> > > e-mail message, I think. Now go on, tear my idea to shreds. You
> > > know you want to.
> >
> > I do want to. And I'll do it in less than 2 hours. Ha! Beat that.
> >...
> 
> You're right, of course. It's a ridiculous design. Ok, back to the
> drawing board. (follows)

Right. Let's look at this logically. [cue groans from the assembled Mozillans]

There are various user preferences in Mozilla, and part of the advantage
of having a combined browser, mailer, and newsreader is that many of
these preferences can apply to two or three of those sub-apps at once.

There are also various types of what I might call, um, `modes' in
Mozilla, for which it is useful for prefs to have different values.
These types of mode are:
* mail accounts
* news servers
* browser zones (proposed -- which is what started this discussion in
  the first place).

Thankfully, these types of mode are mutually exclusive -- we wouldn't
need to specify preferences for a specific browser zone AND for a
specific mail account at the same time, for example, because the
situations don't intersect.

Now, there are some prefs for which modes don't apply -- we set them
once, and there is no good reason for them to vary in specific
situations (I'm not talking about varying over time, here). Examples of
these prefs include the home page location, Offline preferences
(synchronization etc), and all the Composer prefs.

Secondly, there are some prefs which it only makes sense to specify
*for* a given mode, not generally. An example of this is the server
hostname for a mail account -- a default pref for server hostname
wouldn't be of much use. Whether these settings can then be classified
as `preferences' or not is arguable, but since things such as the
mail-check interval (which would be useful to specify as a default) and
the hostname (which would *not* be useful to specify as a default) are
so closely related, it makes sense to have the non-defaultable thingies
in the prefs dialog too.

And thirdly, there is a large group of preferences which are useful to
set up both as a default *and* for particular zones/accounts/servers.
Examples of these are style sheets, fonts, and stuff like JavaScript and
auto-loading of objects. (Remember, with the advent of HTML mail, these
examples apply to mail accounts too.)

So, mathematically speaking, we have two sets of preferences:
{A} those which are useful to specify a default for, for the whole of
    Mozilla;
{B} those which it are useful to specify differently for different
    zones, mail accounts, or news servers.

Sets {A} and {B} are intersecting (the intersection produces the third
group described above), and neither of them is a subset of the other.
And therein lies the interface organization problem:

* If you try to separate them (as Neil did), you end up having
  duplication of preference controls for {A intersection B}. (Neil
  proposed duplicating the controls in the main prefs dialog for some
  prefs, such as JavaScript, in the zone-specific preferences dialog.)
  This breaks the HF principle of consistency quite badly.

* If you try to combine them (as I did), you end up having to disable
  the controls for {A <intersection> B'} when editing the preferences
  for a zone/account/server, and having to disable the controls for {B
  <intersection> A'} when editing general preferences. This breaks the
  HF principle of modelessness, as well as making the prefs dialog a bit
  more complicated than it already is.

Neither of these solutions is particularly outstanding. To make things
worse, the user is expecting preferences not to be classified by whether
they apply to modes or not, but to be classified by *subject* -- so all
mail preferences appear together, for example. And that, combined with
the fact that A and B intersect, means you can't separate the prefs into
modal/non-modal categories that can go in separate dialogs, without
annoying the hell out of the user (because it isn't obvious whether a
given pref is one or the other).

I need another night to think about this, but in the meantime, if you
have any wonderful ideas, share them. (I also need to download another
nightly build and see what prefs there actually are, because
http://www.mozilla.org/docs/refList/user-interface/specs/prefs/ hasn't
been updated in over a year. Grrrrr.)

Dammit, we need Jakob Nielsen contributing to this list.

ttfn
-- 
Matthew `mpt' Thomas, usability weenie
http://critique.net.nz/

[prev in list] [next in list] [prev in thread] [next in thread]