Deep prefs hierarchy

10 views
Skip to first unread message

Ben Bucksch

unread,
May 23, 2000, 3:00:00 AM5/23/00
to mozilla-...@mozilla.org
Matthew, I think, you're fighting on the wrong front. Mailnews is an
area where hardly 2 people agree. Mozilla's solution are prefs. As our
product advances, the prefs *will* grow. The solution is not to remove
the prefs - this means restricting users. Of course, the prefs should be
designed (semantically) well. But the real solution to the problem is to
organize prefs well.

In the long term, I'd like to organize them in a deep hierarchy, with
the "frontpage" (the panel you get by clicking an a parent node) of a
subtree not being a collection of misc prefs (which didn't well fit in a
subpanel), but the most important ones. That way, a user with limited
needs wouldn't have to care about the deep hierarchy. If a user misses a
pref on the "frontpage", he can explore the hierarchy in more depth.

(See also bug 17199.)

--
<http://www.bucksch.org>


Matthew Thomas

unread,
May 27, 2000, 3:00:00 AM5/27/00
to Ben Bucksch
Ben Bucksch wrote:
>
> Matthew, I think, you're fighting on the wrong front. Mailnews is an
> area where hardly 2 people agree. Mozilla's solution are prefs.

Whoa, whoa, backtrack here.

Would it be possible to write a mail program which had no prefs at all
(apart from letting you set up your mail server)? Indeed it would.

So, why do we include prefs at all? The simple answer is: `because a
pref-less program would be a pain to use'. The generalization of that
answer is: `to make the program more usable'.

Your logic seems to be that the more prefs we add, the more usable the
program will be. But that logic is just as flawed as that of the Third
farmer who thinks `well, if I apply one tonne of fertilizer my harvest
increases by 20 percent, so if I apply two tonnes of fertilizer my
harvest will increase by 40 percent'. So he applies two tonnes of
fertilizer, and then finds that the harvest actually *decreases* because
the fertilizer concentration in the soil is too high.

You get to a point of diminishing returns eventually with prefs, too.
Eventually the decreased usability from a number of factors (outlined
below) starts outweighing the extra usefulness you are providing.

> As our
> product advances, the prefs *will* grow.

I find it interesting that you assume that any `advance' necessarily
means an increase in prefs complexity, rather than a decrease.

If Mozilla programmers worked out an algorithm for detecting when each
particular setting of one boolean pref was appropriate, and when the
other was appropriate, then a pref could be removed. I would call that
an advance, but it would be decreasing the complexity of the product.

For example, if someone implemented the algorithm I suggested in
<http://bugzilla.mozilla.org/show_bug.cgi?id=17325> for calculating how
often the layout engine should perform incremental reflows, then Mozilla
would perform better overall, no matter what your configuration. And a
pref could be removed from the program (albeit one that's not currently
shown in the prefs dialog), and that would be a good thing.

Or an example for Messenger: if Mozilla could automatically detect
whether a mail server was POP or IMAP, then you could probably remove
the POP/IMAP popup menu from the account settings, and that would be a
good thing.

I actually think the number of prefs in Mozilla right now is about right
-- if we're aiming at intermediate-to-advanced users. But I can foresee
that extra prefs are going to be added, so some of the more inane
existing prefs really need to be removed to make way for them.

> The solution is not to remove
> the prefs - this means restricting users.

Unless you are an anarchist (and I'm guessing you're not), I assume you
agree with the general idea of a country having laws. Laws exist to
restrict people in what they can do, for the benefit of society as a whole.

Similarly, if you allow users to change too much of how the program
works, you harm the user population as a whole.
* The program gets bloated (in both disk space and memory space
required) from all the options available.
* The program becomes more unreliable, as a finite quantity of QA gets
thrown at a geometrically increasing number of pref combinations.
* Development slows, as developers have to take into account expected
behavior with each possible pref as they maintain their code.
* And of course, users become confused as they are confronted with a
preferences dialog which starts to resemble a Boeing 747 cockpit.

So you do need to have restrictions on how much the user can do -- you
do need to limit configurability. That sounds unbearably fascist, but
usability engineering is often like that.

> Of course, the prefs should
> be designed (semantically) well. But the real solution to the problem
> is to organize prefs well.

But, as I've said before, even a perfectly-designed prefs dialog will
only get you so far.

> In the long term, I'd like to organize them in a deep hierarchy, with
> the "frontpage" (the panel you get by clicking an a parent node) of a
> subtree not being a collection of misc prefs (which didn't well fit in
> a subpanel), but the most important ones. That way, a user with
> limited needs wouldn't have to care about the deep hierarchy. If a
> user misses a pref on the "frontpage", he can explore the hierarchy in
> more depth.

>...

In reply to that, I can do no better than to quote Gordon Henriksen's
message in n.p.m.ui from a month ago:
|
| The problem with this is that you generate a very complicated
| interface with an overwhelming array of options. Hierarchies are
| grand, but often a particular option will logically belong in two or
| places in your hierarchy. However, offering multiple, identical (or,
| worse, non-identical) interfaces to the same bit in the preferences
| file is demonstrably nothing short of baffling, even to savvy users;
| instead of exploring an interface by simply crawling into each crevice
| and back out again in an orderly progression, you have to constantly
| ask yourself, "Have I been here?" In effect, such a hierarchy becomes
| a confusing graph. At the same time, not having an option in places
| where it logically belongs causes as much frustration, perhaps
| preventing discovery: A shopping site which offers only a hierarchical
| organization of products will probably lose a large number of sales to
| potential customers who cannot find what they want. (I've been that
| customer on more than one occasion.)
|
| And, no, "advanced user" checkboxes do not help. If an option exists,
| it's almost certain that someone will want to get at it, advanced user
| or not, and hiding it merely frustrates issues further.
|
| The right thing to do is select only the best options for preferences
| and, meanwhile, investigate and implement direct manipulation
| mechanisms for users to control the bizarre behaviors that you're
| squirreling away.

--
Matthew `mpt' Thomas, Mozilla user interface QA
<http://critique.net.nz/project/mozilla/>


Ben Bucksch

unread,
May 28, 2000, 3:00:00 AM5/28/00
to mozilla-...@mozilla.org
Matthew Thomas wrote:
> I find it interesting that you assume that any `advance' necessarily
> means an increase in prefs complexity, rather than a decrease.

As soon as I add a feature, somebody doesn't like it and wants to turn
it off. With Pref UI, of course.

I welcome suggestions to bug 23582 (*without* removing funtionality).

> If Mozilla programmers worked out an algorithm for detecting when each
> particular setting of one boolean pref was appropriate, and when the
> other was appropriate, then a pref could be removed.

What if it's really a user preference?

You usually answer with direct manipulation, but this adds the
complexity you remove from the prefs dialog to the day-to-day UI. I
don't want the UI I see x hours a day littered with widgets I use twice
a year.

> Or an example for Messenger: if Mozilla could automatically detect
> whether a mail server was POP or IMAP, then you could probably remove
> the POP/IMAP popup menu from the account settings, and that would be a
> good thing.

No, my server is both an IMAP and a POP server (sometimes).

> * The program gets bloated (in both disk space and memory space
> required) from all the options available.
> * The program becomes more unreliable, as a finite quantity of QA gets
> thrown at a geometrically increasing number of pref combinations.
> * Development slows, as developers have to take into account expected
> behavior with each possible pref as they maintain their code.

Mozilla Mailnews is not a "slim-line" client. There are others.

> So you do need to have restrictions on how much the user can do -- you
> do need to limit configurability. That sounds unbearably fascist, but
> usability engineering is often like that.

And you will loose most users on the way.

How would you feel, if functionality you relied on every day is suddenly
removed, just because some UI guru thought, it wasn't worth the
checkbox?

--
<http://www.bucksch.org>


Matthew Thomas

unread,
May 30, 2000, 3:00:00 AM5/30/00
to mozilla-...@mozilla.org, mozill...@mozilla.org
Ben Bucksch wrote:

>
> Matthew Thomas wrote:
> >
> > I find it interesting that you assume that any `advance' necessarily
> > means an increase in prefs complexity, rather than a decrease.
>
> As soon as I add a feature, somebody doesn't like it and wants to turn
> it off. With Pref UI, of course.

Well, duh, stop adding so many features.

> I welcome suggestions to bug 23582 (*without* removing funtionality).

As we've already established, for part of that particular issue
(formatting on send), what you call `functionality' I call rudeness. And
for the other part (formatting on receive), I've already suggested using
a submenu in the View menu rather than controls in the prefs -- and I
have been suggesting exactly that for months now.

> > If Mozilla programmers worked out an algorithm for detecting when
> > each particular setting of one boolean pref was appropriate, and
> > when the other was appropriate, then a pref could be removed.
>

> What if it's really a user preference?

If it's something where a considerable proportion of people have it one
way and a considerable proportion have it another way, and Mozilla can't
work out which way the user wants automatically, then by all means
include a preference for it.

> You usually answer with direct manipulation,

Sometimes. Sometimes direct manipulation is the appropriate answer,
sometimes better pref organization is the appropriate answer, and
sometimes the appropriate answer is not including the configurability at all.

> but this adds the
> complexity you remove from the prefs dialog to the day-to-day UI. I
> don't want the UI I see x hours a day littered with widgets I use
> twice a year.

s/UI/program/
s/widgets/features/

> > Or an example for Messenger: if Mozilla could automatically detect
> > whether a mail server was POP or IMAP, then you could probably
> > remove the POP/IMAP popup menu from the account settings, and that
> > would be a good thing.
>

> No, my server is both an IMAP and a POP server (sometimes).

So is mine. But if we can assume that, for example, given the inclusion
of an offline mode, people almost always prefer to use IMAP over POP
(and I'm not saying we can assume that, but a statistical survey with
overwhelming results might lead us to conclude that we could), then we
could ask the server `do you do IMAP?', and if so then do IMAP,
otherwise do POP.

At the very least, we could just disable the option if we determine that
the server only does one or the other, so as to remove the possibility
of the user making a completely avoidable and unnecessary error.

I mean, let's face it, you don't see any of the characters on your
favorite sci-fi TV program specifying whether they want to receive a
message by POP or IMAP. They have better things to do. The future does
not have a deep prefs hierarchy.

> > * The program gets bloated (in both disk space and memory space
> > required) from all the options available.
> > * The program becomes more unreliable, as a finite quantity of QA
> > gets thrown at a geometrically increasing number of pref
> > combinations.
> > * Development slows, as developers have to take into account
> > expected behavior with each possible pref as they maintain their
> > code.
>

> Mozilla Mailnews is not a "slim-line" client. There are others.

I'm not looking for a slim-line client, necessarily. I just want Mozilla
to be a program that will be useful for the greatest possible number of
Internet users. I want that to happen, so that the browser/mail/Usenet
client market is dominated by open source software (if not,
unfortunately, free software), rather than closed source software
produced by a single company.

If that's not what you want too, then one of us may well be working on
the wrong project.

Now, in some cases, making Mozilla useful for the greatest possible
number of Internet users means adding features; in other cases, it means
removing features. That's something you just have to accept. You can't
just go on adding bits forever, like some sort of Tower of Babel.

Because if you do, users will lose interest as Mozilla becomes harder
and harder to use, and producers of customized versions of Mozilla will
lose interest as reasonably usable distributions of Mozilla become
harder and harder to produce. Not only that, but mozilla.org might well
find itself in 2003 having to totally scrap the current codebase,
*again*, and rewriting the whole thing from scratch, *again*, because
the old code has got too unwieldy and bloated, *again*. And I'd really
rather that didn't happen to Mozilla -- I'd much rather have developer
time spent on refining it than rewriting it.

> > So you do need to have restrictions on how much the user can do --
> > you do need to limit configurability. That sounds unbearably
> > fascist, but usability engineering is often like that.
>

> And you will loose most users on the way.

Oh right, that explains the complete dominance of the Windows and Mac
versions of emacs in the text editing market on those platforms. Because
emacs is so configurable, *everyone* wants to use it.

> How would you feel, if functionality you relied on every day is
> suddenly removed, just because some UI guru thought, it wasn't worth
> the checkbox?

>...

It would depend on whether removing the `functionality' improved my
productivity or not. And if it was truly a UI guru making the decision,
chances are it *would* improve my productivity, and I would experience a
mild epiphany as I discovered that fact.

Ben Bucksch

unread,
May 30, 2000, 3:00:00 AM5/30/00
to mozilla-...@mozilla.org
Matthew Thomas wrote:
> Well, duh, stop adding so many features.

... (imagine the response)

I think, I can argue that each feature I added was worth it by
increasing usability for either Mozilla users or recipients of their
msgs.

And they resulted in more, uncomprehensable prefs - so uncomprehensable,
that even one QA guy had (has?) a really hard time to understand some of
them. Another important one was not even added to the UI at all just
because of this reason. Wording is surely part of the problem, but only
to a small extend.

I really don't see a solution to this kind of problem other than a
better prefs architcture that hides certain parts well and in a good
manner.

> And for the other part (formatting on receive), I've already
> suggested using a submenu in the View menu rather than controls in
> the prefs -- and I have been suggesting exactly that for months now.

Do you expect this menu to appear in a movie?

> I mean, let's face it, you don't see any of the characters on your
> favorite sci-fi TV program specifying whether they want to receive a
> message by POP or IMAP. They have better things to do. The future does
> not have a deep prefs hierarchy.

You argue not to include such an important technical detail like the
server type on one hand and OTOH you suggest to include menuitems for
prefs which I never intended to be included in the UI at all?

IMO, the recognition on/off is really a minor technical detail, like all
of the recognition. I wrote the converter so carefully that I don't
expect any normal user to want to turn it off except for philosophical
reasons - just because it (hopefully) never fails for them in a way that
does harm (I don't consider the plain adding of style harm, as long as
it doesn't fail often).

> Now, in some cases, making Mozilla useful for the greatest possible
> number of Internet users means adding features; in other cases, it means
> removing features.

I disagree (assuming the features are not dumb).

> You can't just go on adding bits forever

> Because if you do, users will lose interest as Mozilla becomes harder
> and harder to use,

This adding of bits is usually called progress. We need to find a
solution to add features without degrading usability instead of just
ripping features.

> Not only that, but mozilla.org might well
> find itself in 2003 having to totally scrap the current codebase,
> *again*

(You're jumping from UI to code.) You can achieve really complex *and*
good systems, if you have the right architecture.

Note that we didn't (intentionally) reduce features during the rewrite,
in fact we added a lot of them.

> Oh right, that explains the complete dominance of the Windows and Mac
> versions of emacs in the text editing market on those platforms. Because
> emacs is so configurable, *everyone* wants to use it.

- You know how mainstream "chooses" its software
- emacs is an unfair example. The GNOME panel is a better one: It is
configurable, but in a GUI friendly manner.* And I do think, it would be
choosen *because* of the configurability, if there were fair market
conditions.

* panel = taskbar. It lets you add "applets", programs which can
interact with the user on the panel (not just displaying icons and
reacting on clicks).

> It would depend on whether removing the `functionality' improved my
> productivity or not. And if it was truly a UI guru making the decision,
> chances are it *would* improve my productivity, and I would experience a
> mild epiphany as I discovered that fact.

I for myself don't trust most UI gurus. Well possible that I may depend
on a feature he/she not even understands (or its importance for me).

--
<http://www.bucksch.org>


Matthew Thomas

unread,
May 30, 2000, 3:00:00 AM5/30/00
to mozill...@mozilla.org
Ben Bucksch wrote:
>...

> I think, I can argue that each feature I added was worth it by
> increasing usability for either Mozilla users or recipients of their
> msgs.

So far, that's *possibly* true. (I'm not saying it's definitely true; I
haven't seen a list of features you've added.) But you can't do that
forever. Humans' ability to comprehend the extent of what is available
in software is finite.

> And they resulted in more, uncomprehensable prefs - so
> uncomprehensable, that even one QA guy had (has?) a really hard time
> to understand some of them.

Last time I checked, Scott Putterman (the guy who said, a week ago, `We
thought this [pref should be removed] too until it was explained to us
what this pref does :)') was a programmer, not a QA person.

Of course, a programmer tends to understand features better than a QA
person does, and a QA person in turn tends to understand features better
than an average user does. So if the *programmers* don't understand the
feature ... be afraid, be very afraid.

> Another important one was not even added
> to the UI at all just because of this reason.

Thereby, surely, removing most of the point of the pref existing in the
first place. (Which pref is this, by the way?)

> Wording is surely part
> of the problem, but only to a small extend.

Yep. There's a lot of bad wording in the prefs right now -- ranging from
highly abstruse on the one hand to gratingly condescending on the other.

> I really don't see a solution to this kind of problem other than a
> better prefs architcture that hides certain parts well and in a good
> manner.

Yes, but even the perfect prefs UI will only get you so far.

... I'm getting a sense of deja vu with that sentence.

> > And for the other part (formatting on receive), I've already
> > suggested using a submenu in the View menu rather than controls in
> > the prefs -- and I have been suggesting exactly that for months now.
>

> Do you expect this menu to appear in a movie?

What?

>...


> You argue not to include such an important technical detail like the
> server type on one hand

Absolutely. The idea that users should have to care about something as
technical as server type is just lame.

The same with the IMAP option for `Server supports folders that contain
subfolders and messages' in 4.x (haven't got a Mozilla build handy to
see if this is in Seamonkey too). Well, how the smeg am *I* supposed to
know if my IMAP server supports folders that contain subfolders and
worple worple whatsit? Why doesn't Mozilla create a temporary folder and
try to put a subfolder and a dummy message in it, and see if it works?
Then we'd both know, and I wouldn't have to answer so many obscure questions.

> and OTOH you suggest to include menuitems for
> prefs which I never intended to be included in the UI at all?

If I had my way, there wouldn't need to be any UI for those prefs at
all, because the prefs wouldn't exist. Link recognition would be always
on (for protocols only, and not for currently-fashionable server
prefixes like www. and ftp.), because the algorithm would be safe enough
to have false-negative and false-positive rates of practically zero. And
smiley recognition would exist, but only in colorization form (blue
eyes, red mouth, or whatever depending on the locale), so that any false
negatives or false positives would cause minimal disturbance.

So */_ style recognition would be the only thing a pref was required
for, since some people might find it distracting if they or their
correspondents happened to often use the */_ characters around words for
purposes other than formatting. And all you'd need to control that would
be a single boolean menu item.

All I'm trying to do with the submenu is make the best of a bad job, the
bad job being that the converters are all in Mozilla and that they are
all (necessarily, in their current state) optional.

> IMO, the recognition on/off is really a minor technical detail, like
> all of the recognition.

And like viewing attachments in-line or as links. And like viewing full
headers or normal headers. And where are *they* in the prefs? Oh, that's
right, they're not in the prefs, they're in the View menu.

> I wrote the converter so carefully that I
> don't expect any normal user to want to turn it off except for
> philosophical reasons

Just ignoring the truth value of that statement for a moment, are you
saying that philosophical reasons are illegitimate?

> - just because it (hopefully) never fails for
> them in a way that does harm (I don't consider the plain adding of
> style harm, as long as it doesn't fail often).

Myself, I wouldn't regard formatting (such as styling and linkifying) as
harmful, but I would regard smilefying as disingenuous (to say the
least) because it actually misrepresents the actual characters entered
by the sender.

| - (: - (: - (: - In Deepest Sympathy - :) - :) - :) -
|
| Dear Fitz
| Allow me to express my sympathy at your recent loss. I
| realize this must be a very hard time for you, and I want you to
|...

That's also one of the reasons I object to adding */_ formatting to an
HTML message on sending: because the formatting can't easily be turned
off by the recipient (unless they *happen* to be using Mozilla, which
presumably knows what the Mozilla-specific SPAN CLASSes mean), so it is
impossible for the recipient to tell whether the sender intended that
formatting to be there or not.

>...


> > You can't just go on adding bits forever

> > Because if you do, users will lose interest as Mozilla becomes
> > harder and harder to use,
>

> This adding of bits is usually called progress.

That's because the civilization we're in happens to be the Western one,
which is obsessed with the adding of bits. It's not because adding of
bits is a good idea for a user interface, which it almost always isn't.

> We need to find a
> solution to add features without degrading usability instead of just
> ripping features.

We Can't Do That Forever.

> > Not only that, but mozilla.org might well find itself in 2003 having

> > to totally scrap the current codebase, *again*


>
> (You're jumping from UI to code.)

That's what `Not only that, but' means.

> You can achieve really complex *and*
> good systems, if you have the right architecture.

And if we knew how to do that reliably, there wouldn't be nearly so much
of a need for the open source software process and its bug-finding eyeballs.

Perhaps in 50 or 100 years, when software engineering has matured to a
reasonable level of knowledge like (for example) plumbing or electrical
engineering has, what you say might be true, and achieving really
complex and good systems will be fairly easy.

> Note that we didn't (intentionally) reduce features during the
> rewrite, in fact we added a lot of them.

And look how crappy the UI ended up ... No, that's unfair, sorry. The UI
is crappy for completely different reasons. :-)

But Mozilla is currently missing lots and lots of little features from
4.x, the sort of features which (usually) don't need any prefs at all.
The ability to draw a box around a contiguous series of items in a tree
widget (e.g. bookmarks or addresses), in order to select those items.
System-style new mail notification on Mac OS
<http://bugzilla.mozilla.org/show_bug.cgi?id=18730>. The ability to
cancel dragging of the scrollbar thumb by dragging away from the
scrollbar <http://bugzilla.mozilla.org/show_bug.cgi?id=22175>. Little
things like that.

> > Oh right, that explains the complete dominance of the Windows and
> > Mac versions of emacs in the text editing market on those platforms.
> > Because emacs is so configurable, *everyone* wants to use it.
>

> - You know how mainstream "chooses" its software

That still doesn't explain why BBEdit (which, as far as I know, isn't
bundled with any version of Mac OS) is vastly more popular than emacs on Mac.

> - emacs is an unfair example.

Or, to put it on more of a level playing field, why vi is quite popular
on Unix in spite of being considerably less configurable than emacs.

> The GNOME panel is a better one: It is
> configurable, but in a GUI friendly manner.* And I do think, it would
> be choosen *because* of the configurability, if there were fair market
> conditions.

I couldn't comment, since I haven't used GNOME.

>...


> I for myself don't trust most UI gurus. Well possible that I may
> depend on a feature he/she not even understands (or its importance for
> me).

>...

That, I believe, is one of the points of open source. If 0.5 percent of
the user population will use a particular feature, then compile a
special version for that 0.5 percent -- don't just foist the feature
upon the other 99.5 percent of us.

Ben Bucksch

unread,
May 30, 2000, 3:00:00 AM5/30/00
to mozilla-...@mozilla.org
Matthew Thomas wrote:
[adding features]

> But you can't do that
> forever. Humans' ability to comprehend the extent of what is available
> in software is finite.

The human working with the software doesn't have to understand all of
its fine details. The user should be able to work with it while only
understanding the basics and explore parts of it in more depth it wants.

I don't comprehend all of science, but parts of it to variing extenses.

That's exactly the reason why I proposed the deep prefs hierarchy: You
only need to see the imporant layers, but can explore parts in more
depths. Feel free to propose a better strategy.

> Last time I checked, Scott Putterman (the guy who said, a week ago [...]

I was speaking of other prefs which I had to implement. It was a QA
person.

> So if the *programmers* don't understand the
> feature ... be afraid, be very afraid.

I am, that's why I didn't want to include it into the UI. And you
propose to move it into the menu...

> [...] (Which pref is this, by the way?)

Hiding feature 31906 on/off (i.e. graphical quote tags vs. plain). More
in this newsgroup after its checked in.

> Yes, but even the perfect prefs UI will only get you so far.
>
> ... I'm getting a sense of deja vu with that sentence.

No surprise, it's directly related to the topic. Would be nice, if you
actually *proved* the validity.

> > > And for the other part (formatting on receive), I've already
> > > suggested using a submenu in the View menu rather than controls in
> > > the prefs -- and I have been suggesting exactly that for months now.
> >
> > Do you expect this menu to appear in a movie?
>
> What?

This was one of your arguments why not to include the server type pref.
And I think, it has *some* validity, at least the direction is OK, I
think.

> The same with the IMAP option for `Server supports folders that contain
> subfolders and messages'

This is way hidden in an advanced server dialog. This kind of
configuration should be provided by the server admin anyway (often
through some kind of preconfiguration). Also, most users leave prefs
they don't understand untouched, and that's usually OK (also in this
case).

In some cases there are ways to guess the correct pref setting
automatically, but this would be no less ambiguous than my TXT->HTML
recognizer, for which you and others want to have prefs. Similarly,
there will be people (maybe myself) who want to set the server prefs
manually to know for sure things are right. So, you won't be able to get
rid of the prefs (which is what you want). You can just lift the
requirement to set them.

> > and OTOH you suggest to include menuitems for
> > prefs which I never intended to be included in the UI at all?

[...]

Why would the colorization of smilies be less distracting than the
styling of structured phrases?

You easily find yourself in a position where you try to hardcode your
own prefs (this might be the case for you here and I sometimes saw this
at myself :-( ).

> And like viewing attachments in-line or as links. And like viewing full
> headers or normal headers.

Are you saying that were optimal?

I think, we won't need the latter anymore in Mozilla as you can expand
can collapse parts of the headers directly and view all headers with one
mouseclick on a header name.

For the wrap long lines item: I don't see the point of not wrapping, it
forces horizontal scrollbars.

> are you saying that philosophical reasons are illegitimate?

Not at all. (But they usually appear under tech-savvy folks in this
case. That's why I didn't intend to expose them in the Prefs UI. Maybe I
was wrong.)

> Myself, I wouldn't regard formatting (such as styling and linkifying) as
> harmful, but I would regard smilefying as disingenuous

Yes, a failure here is indeed harm.

> HTML message on sending: because the formatting can't easily be turned
> off by the recipient (unless they *happen* to be using Mozilla, which
> presumably knows what the Mozilla-specific SPAN CLASSes mean),

Again: Mozilla users have no advantage at all in this case (apart from a
link in the docs maybe). Just look at the HTML source.

> so it is
> impossible for the recipient to tell whether the sender intended that
> formatting to be there or not.

Now that we have the prefs, the intention is implied. If you are likely
to send msgs which cause the recognizer to fail, then by all means turn
it off. I (and many others) am not and I want to have it on.

> > This adding of bits is usually called progress.

> It's not because adding of


> bits is a good idea for a user interface, which it almost always isn't.

I hold an ancient machine against it. The difference? To a large part
better (easier, higher efficiency of the user, more tasks supported)
software, and this "better" needed a *lot* of "bloat".

> Perhaps in 50 or 100 years, when software engineering has matured to a
> reasonable level of knowledge like (for example) plumbing or electrical
> engineering has, what you say might be true, and achieving really
> complex and good systems will be fairly easy.

Nobody said, it were easy. But todays systems are already very complex.
Mozilla's code has several million lines. Now think about Windows 2000.
It's not perfect, but it wouldn't work at all without an architecture
that fits at least mostly. You propably have no idea, why is going on
under the hood.

Note, that we propably wouldn't discuss now, if software architects took
the path you try to take: Limit functionality to address complexity
instead of creating a decent architecture.

> Or, to put it on more of a level playing field, why vi is quite popular
> on Unix in spite of being considerably less configurable than emacs.

Because some poeple like it
- traditional
- slim
Neither is the market of Mozilla Mailnews.

> That, I believe, is one of the points of open source. If 0.5 percent of
> the user population will use a particular feature, then compile a
> special version for that 0.5 percent -- don't just foist the feature
> upon the other 99.5 percent of us.

In most cases, it's more than 0.5%. And there are many such preferences.
So, we would have to have one binary for each combination of prefs? You
end up compiling your own version. Painful for developers, impossible
for others.

The alternative is to have one newbie Mozilla and one for power users.
This has already been talked down. (See recent "Babying" thread on
.general.) If you are convinced of that idea, go ahead and create your
own chrome, maybe even from scratch. I think, this is the only way to
achieve your goals. I'd be interesed to see the result (really).

You *cannot* remove features I and others rely on from default Mozilla
just for anticipated usability increase for newbies. See, (assuimg I
don't want to maintain my own version,) you reduce my efficiency.

--
<http://www.bucksch.org>


Ben Goodger

unread,
May 30, 2000, 3:00:00 AM5/30/00
to
Matthew Thomas wrote:
> Now, in some cases, making Mozilla useful for the greatest possible
> number of Internet users means adding features; in other cases, it means
> removing features. That's something you just have to accept. You can't
> just go on adding bits forever, like some sort of Tower of Babel.
---
I agree with pretty much everything you've said in this thread so far. I
believe useful application will not just throw buckets of checkboxes at
the user, it will provide a selection of settings that match
common/essential user preferences. More fine grained control can be
integrated at a different level, e.g. Microsoft Word does various types
of text transformation automatically, the first time it does it
helpfully providing a way to disable the feature. MS Word also varies
the content of visible menus based on the tasks performed by the user
the most. These are just a couple of examples of the ways apps are
getting smarter.

The good thing about Mozilla's architecture is that by and large it
allows users to add pieces that perform whatever arcane extension they
desire (especially in UI land) by just installing an add on component. I
think 'power' accessories should be grouped into such components and
made available for download separately so that those that want them can
get them. They will then appreciate their features, and most people can
enjoy a simplified default client.

ben.vcf

Garth Wallace

unread,
May 30, 2000, 3:00:00 AM5/30/00
to
"Ben Bucksch" <mozill...@bucksch.org> wrote in message
news:39335CD7...@bucksch.org...

> Matthew Thomas wrote:
> > > and OTOH you suggest to include menuitems for
> > > prefs which I never intended to be included in the UI at all?
> [...]
>
> Why would the colorization of smilies be less distracting than the
> styling of structured phrases?

IMO opinion colorized ASCII-art is uglier than those
graphics. I still can't tell the difference between
the graphics that replace :-) and ;-) though.

Garth Wallace

unread,
May 30, 2000, 3:00:00 AM5/30/00
to
"Matthew Thomas" <mp...@student.canterbury.ac.nz> wrote in message
news:39333DAA...@student.canterbury.ac.nz...
> Ben Bucksch wrote:
> >...

> If I had my way, there wouldn't need to be any UI for those prefs at
> all, because the prefs wouldn't exist. Link recognition would be always
> on (for protocols only, and not for currently-fashionable server
> prefixes like www. and ftp.), because the algorithm would be safe enough
> to have false-negative and false-positive rates of practically zero.

I'm all for this. I don't think we should auto-link URLs without
protocols. There's a bug floating around in bugzilla for a
context menu item "Load selection as URL" (or something like
that) which would make these redundant anyway.

Garth Wallace

unread,
May 30, 2000, 3:00:00 AM5/30/00
to
"Ben Bucksch" <mozill...@bucksch.org> wrote in message
news:39348199...@bucksch.org...

> Garth Wallace wrote:
> > I still can't tell the difference between
> > the graphics that replace :-) and ;-) though.
>
> <http://bugzilla.mozilla.org/show_bug.cgi?id=39046>

Thanks.

> BTW: Mail to you address bounces, even without "__":
> <gwa...@planetall.com>... Deferred: Connection refused by
> mailhost.planetall.com.
> Message could not be delivered for 5 days

Hmm. That's odd. I'll check up on that.
Thanks for telling me!


Ben Bucksch

unread,
May 31, 2000, 3:00:00 AM5/31/00
to mozilla-...@mozilla.org
Garth Wallace wrote:
> I still can't tell the difference between
> the graphics that replace :-) and ;-) though.

<http://bugzilla.mozilla.org/show_bug.cgi?id=39046>

BTW: Mail to you address bounces, even without "__":


<gwa...@planetall.com>... Deferred: Connection refused by
mailhost.planetall.com.
Message could not be delivered for 5 days

--
<http://www.bucksch.org>


Karl Ove Hufthammer

unread,
May 31, 2000, 3:00:00 AM5/31/00
to
"Garth Wallace" <gwalla@__planetall.com> wrote in message
news:8h1tid$3p...@secnews.netscape.com...

| "Matthew Thomas" <mp...@student.canterbury.ac.nz> wrote in message
| news:39333DAA...@student.canterbury.ac.nz...
| > Ben Bucksch wrote:
| > >...
| > If I had my way, there wouldn't need to be any UI for those prefs at
| > all, because the prefs wouldn't exist. Link recognition would be always
| > on (for protocols only, and not for currently-fashionable server
| > prefixes like www. and ftp.), because the algorithm would be safe enough
| > to have false-negative and false-positive rates of practically zero.
|
| I'm all for this. I don't think we should auto-link URLs without
| protocols.

I agree. Mozilla trying to act smarter than it is *will* lead to problems.
If Mozilla tries to auto-link protocol-less URLs, people will write URLs in
this way, and Mozilla *will* make false matches (thinking that something
which isn't a URL is a URL or not recognizing something that *is* a URL).

--
Karl Ove Hufthammer

Stuart Ballard

unread,
May 31, 2000, 3:00:00 AM5/31/00
to
Karl Ove Hufthammer wrote:
>
> I agree. Mozilla trying to act smarter than it is *will* lead to problems.
> If Mozilla tries to auto-link protocol-less URLs, people will write URLs in
> this way, and Mozilla *will* make false matches (thinking that something
> which isn't a URL is a URL or not recognizing something that *is* a URL).

<example point="agree">

URLs begin with http://on the www.I am a poor typist and don't put
spaces after my periods.You can also get web pages on ftp.This involves
using URLs that start with ftp://usually.But you can also use a command
line tool.

</example>

(Btw, the above is admittedly pathological and I would forgive one false
positive in this case (ftp://usually.But) because it's very hard to
avoid without encoding knowledge of the TLDs. The only way to avoid it
that I can think of would be requiring at least one / on an ftp url,
which might be okay... people don't often write ftp urls to the roots of
machines, and when they do they usually know to write the /.)

Stuart.

Ben Bucksch

unread,
May 31, 2000, 3:00:00 AM5/31/00
to mozilla-...@mozilla.org

huf...@bigfoot.com (Karl Ove Hufthammer) wrote:

> > I don't think we should auto-link URLs without protocols.
>

> I agree. Mozilla trying to act smarter than it is *will* lead to
> problems.
> If Mozilla tries to auto-link protocol-less URLs, people will write
> URLs in
> this way, and Mozilla *will* make false matches (thinking that
> something
> which isn't a URL is a URL or not recognizing something that *is* a
> URL).
>

* This is one opinion. Others have the opposite one. We already had a
lot of discussion about it.
* Please give me a concrete and realistic example, where the
recognizer fails.
* I don't see how it harms to have some rare false positives. If you
really dislike abbreviated URLs being linked, you can remove the
formatting with CSS, see my website.
* Please already do write URLs abbreviated, e.g. "www.mozilla.org". I
don't like it, but it is a fact.
Strictly, raw email addresses are also abbreviated URLs, because
they existed before the WWW. And they are used *a lot* in this
form. I am convinced that we should recognize them.

--
<http://www.bucksch.org>

Ben Bucksch

unread,
May 31, 2000, 3:00:00 AM5/31/00
to mozilla-...@mozilla.org, mozill...@mozilla.org
Ben Bucksch wrote:
> * Please already do write URLs abbreviated

s/Please/People

--
<http://www.bucksch.org>


Stuart Ballard

unread,
May 31, 2000, 3:00:00 AM5/31/00
to
Ben Bucksch wrote:
>
> Strictly, raw email addresses are also abbreviated URLs, because
> they existed before the WWW. And they are used *a lot* in this
> form. I am convinced that we should recognize them.

I agree with this if you can do it safely. But how do you distinguish
between the following, some of which are email addresses and some
aren't...

myuser@mymachine (on an intranet - no . because the default domain is
implied)
myuser@localhost (in case the intranet example seems too contrived)
myuser@dk (yes, there is an A record and presumably an MX on the dk TLD
- see http://dk/ (doesn't work right in windows, but that's no reason
not to support something that's in the standards)
myu...@oracle.database.name (an oracle SQL login string, not an email -
may or may not have . in it)
5413t90w...@myhost.com (a news article reference or email message
ID)
excite@home (the name of a company)
myu...@groups.jabber.org (a Jabber IM address, may or may not correspond
to an email address; this one can be avoided by ensuring that Mozilla
recognizes a jabber: url scheme as something distinct from an email
address)

The one that really bothers me is the email/news message ID, because a
lot of people's standard quoting header is "In message
313413...@something.com, John Doe wrote:"...

(note that I really do hope you can come up with a reliable method and
that I personally would be able to cope with that one major false
positive, but it would be confusing for a newbie - if you see that
message ID underlined, you would probably expect to get a link to the
message, not an email to an address that doesn't exist).

Stuart.

Ben Bucksch

unread,
May 31, 2000, 3:00:00 AM5/31/00
to mozilla-...@mozilla.org
Stuart Ballard wrote:
> myuser@mymachine (on an intranet - no . because the default domain is
> implied)

I don't understand the "no": The adress is a valid intranet address and
is in fact used in this form.

> excite@home (the name of a company)

Abuse.

> myu...@groups.jabber.org (a Jabber IM address, may or may not correspond
> to an email address; this one can be avoided by ensuring that Mozilla
> recognizes a jabber: url scheme as something distinct from an email
> address)

Not sure what you mean with the last part.

> The one that really bothers me is the email/news message ID, because a
> lot of people's standard quoting header is "In message
> 313413...@something.com, John Doe wrote:"...
>
> (note that I really do hope you can come up with a reliable method and
> that I personally would be able to cope with that one major false
> positive, but it would be confusing for a newbie - if you see that
> message ID underlined, you would probably expect to get a link to the
> message, not an email to an address that doesn't exist).

I completely agree, but I have no solution either.

--
<http://www.bucksch.org>


Stuart Ballard

unread,
Jun 1, 2000, 3:00:00 AM6/1/00
to
Ben Bucksch wrote:
>
> Stuart Ballard wrote:
> > myuser@mymachine (on an intranet - no . because the default domain is
> > implied)
>
> I don't understand the "no": The adress is a valid intranet address and
> is in fact used in this form.

Sorry - my statement was loosely punctuated and you misparsed it (or at
least parsed it differently than how I intended). It should have been
written:

(no "." because the default domain is implied)

I was just clarifying *why* it was a valid email even though it had no
"." in the second part - just in case your solution to recognize email
addresses had been to allow them if there is a "." after the "@".

> > excite@home (the name of a company)
>
> Abuse.

Still commonly used though (along with Comcast@home and all of its other
sub-companies).

> > myu...@groups.jabber.org (a Jabber IM address, may or may not correspond
> > to an email address; this one can be avoided by ensuring that Mozilla
> > recognizes a jabber: url scheme as something distinct from an email
> > address)
>
> Not sure what you mean with the last part.

I'm thinking that if jabber users discovered that they could type in
"jabber:myu...@groups.jabber.org" and have moz recognize it *correctly*,
this could become widely used. Jabber is still in the early enough
stages of community-building that it would be possible to usefully
promote good habits :)

[my verbose quote about message IDs snipped]


>
> I completely agree, but I have no solution either.

I guess that recognizing anything containing an "@" followed by a "." is
the case with the least false positives and false negatives. The
message-id issue bothers me, but it is a small amount of pain for a
large amount of gain.

One possibility would be to make all the linkifying generic and
regexp-based, and put it in (super-advanced, possibly no UI at all) user
preferences, then add a couple of overriding regexps as default
corresponding to the phrases that are the defaults for any news programs
we can find that include message IDs. I believe gnome-terminal has a
generic regexp-based linkifying mechanism that it (under)uses just to
recognize http URLs.

Just a thought.
Stuart.

Ben Bucksch

unread,
Jun 1, 2000, 3:00:00 AM6/1/00
to mozilla-...@mozilla.org
Stuart Ballard wrote:
> Ben Bucksch wrote:
> > Stuart Ballard wrote:
> > > myuser@mymachine (on an intranet - no . because the default domain is
> > > implied)

> I was just clarifying *why* it was a valid email even though it had no


> "." in the second part - just in case your solution to recognize email
> addresses had been to allow them if there is a "." after the "@".

This was the overwheling suggestion in the last thread about this topic.
I don't like it exactly for this reason, but I gave in and filed bug
37215.

> > > excite@home (the name of a company)
> >
> > Abuse.
>
> Still commonly used though (along with Comcast@home and all of its other
> sub-companies).

By far not as common as e.g. omitting "http://" though. I think, I can
live with that.

> I'm thinking that if jabber users discovered that they could type in
> "jabber:myu...@groups.jabber.org" and have moz recognize it *correctly*,
> this could become widely used.

It will, as soon as there is a Jabber component which provides a
protocol handler for "jabber:". No change im my coded needed.

> I guess that recognizing anything containing an "@" followed by a "." is
> the case with the least false positives and false negatives. The
> message-id issue bothers me, but it is a small amount of pain for a
> large amount of gain.

This seems to be the opposite to what you said above. Do you say that
the "Excite@Home" abuse is more widely used and important than the usage
of correct intranet addresses? I don't think so.

> One possibility would be to make all the linkifying generic and
> regexp-based

Bug 23327.

Won't help us with URLs, because the recognition is IMO too complicated.

--
<http://www.bucksch.org>


Ben Bucksch

unread,
Jun 1, 2000, 3:00:00 AM6/1/00
to mozilla-...@mozilla.org
Seth Russell wrote:
> I think there should be a new protocol designated for message ID's.

There is a scheme (not protocol, which is the means by which it is
retrieved): "mid:" (RFC2111).

It won't help us, because other mailers obviously don't use it.


Removing .general
--
<http://www.bucksch.org>


Seth Russell

unread,
Jun 1, 2000, 3:00:00 AM6/1/00
to Stuart Ballard
Stuart Ballard wrote:

> The one that really bothers me is the email/news message ID, because a
> lot of people's standard quoting header is "In message
> 313413...@something.com, John Doe wrote:"...
>
> (note that I really do hope you can come up with a reliable method and
> that I personally would be able to cope with that one major false
> positive, but it would be confusing for a newbie - if you see that
> message ID underlined, you would probably expect to get a link to the
> message, not an email to an address that doesn't exist).

I think there should be a new protocol designated for message ID's.
So that we could say something like
see LocalMessage://39358A1C...@netreach.net anywhere in a
message (email, usenet, jabber chat, web) and it would ~hyperlink~ to
the message as stored by some local application. If the message had
not been stored, then someone could hook methods to retrieve it. If
we had a local message ID protocol, then we would be better able to
integrate the web, usenet, email, and jabber with each other and with
personal information managers. Not to mention that it would solve
your problem of the ambiguity with email addresses.

cc: netscape.public.mozilla.*
Seth Russell
http://robustai.net/ai/word_of_emouth.htm
Click on the button ... see if you can catch me live!
http://robustai.net/JournalOfMyLife/users/SethRussell.html
Http://RobustAi.net/Ai/Conjecture.htm

Matthew Thomas

unread,
Jun 4, 2000, 3:00:00 AM6/4/00
to mozill...@mozilla.org
Ben Bucksch wrote:
>
> Matthew Thomas wrote:
> [adding features]
> >
> > But you can't do that forever. Humans' ability to comprehend the
> > extent of what is available in software is finite.
>
> The human working with the software doesn't have to understand all of
> its fine details. The user should be able to work with it while only
> understanding the basics and explore parts of it in more depth it
> wants.

Ideally, yes. But in practice, there is no way to achieve this. When you
add interface-requiring features you add, those features have to be
accessible from *somewhere*, even when they will hardly ever be used.

If your logic was applied to atlases, all maps in atlases would be drawn
on a 1:1 scale <http://www.bibliomania.com/Fiction/Caroll/CompleteWorks/p6-ch11.html#Marker43>.

>...


> That's exactly the reason why I proposed the deep prefs hierarchy: You
> only need to see the imporant layers, but can explore parts in more
> depths. Feel free to propose a better strategy.

I already have. Just include the most commonly-used
features/preferences, up to a point where the greatest possible number
of users find Mozilla to have a comfortable feature set for them. And
then ... *stop*. Work on making Mozilla more perfect, rather than more complex.

>...


> > So if the *programmers* don't understand the
> > feature ... be afraid, be very afraid.
>
> I am, that's why I didn't want to include it into the UI. And you
> propose to move it into the menu...

Yes, but remember that's my second choice. My first choice is not to
have it at all.

> > [...] (Which pref is this, by the way?)
>
> Hiding feature 31906 on/off (i.e. graphical quote tags vs. plain).
> More in this newsgroup after its checked in.

... Uh oh. Not again.

The approach you should be taking here is the same as the approach you
should be taking with :-) smileys. Style the plain text how you want (in
this case, colorization as is done (to a limited extent) by 4.x and (to
a greater extent) by Deja.com would be a good choice), but *don't* hide
the > characters themselves; otherwise, Mozilla will become the laughing
stock of the Internet for its recipient-side munging of plain-text messages.

> > Yes, but even the perfect prefs UI will only get you so far.
> >
> > ... I'm getting a sense of deja vu with that sentence.
>
> No surprise, it's directly related to the topic. Would be nice, if you
> actually *proved* the validity.

Sorry, it seems too obvious to need a proof ... but never mind. Let's
take Yahoo as the best-known example of a well-designed deep hierarchy,
such as the one you are proposing for the prefs dialog.

I'd use the Open Directory Project as my example instead, but the design
of its hierarchy leaves a lot to be desired. And that's the first point.
Designing a hierarchy with `a place for everything, and everything in
its place' is enormously difficult to do, as the designers of Yahoo
quickly discovered
<http://www.wired.com/wired/archive/4.05/indexweb.html?pg=3>. The poor
hierarchical structure of the ODP (see my examples at
<http://www.kuro5hin.org/?op=comments&sid=2000/4/5/231558/8633&cid=22#22>)
would suggest that the number of highly-skilled ontologists willing to
volunteer for an open-source effort is fairly small.

The second point is that even with a reasonably well-designed hierarchy,
Yahoo has lots of cross-references between categories. This is largely
because any given topic has a number of different attributes, or
`facets', which it can be categorized under
<http://theme.music.indiana.edu/tech_s/mla/facacc.rev>.

In a prefs hierarchy, which facet the prefs are arranged under at each
level is decided pretty arbitrarily. In Communicator 4.x, the primary
facet is an odd mixture of component and skill level: a category for
each component in Communicator, and an `Advanced' category. The
secondary facet is popularity: a `main' pane in each branch, apparently
for the most commonly-used prefs for that component (though you have the
sneaking suspicion that some prefs are put there only because the
designers couldn't work out which of the other categories to put them
in), followed by a number of other nodes.

And in those nodes, the tertiary facet, we're back to components -- a
node for addressing messages, a node for mail servers, and so on. In
some cases (e.g. the `Mail Server Info' dialog opened from the `Mail
Servers' category) we go into 4th-level facets, this time based (like
the secondary facet) on skill level.

But who's to say that that order of facets is necessarily the best one?
For example, would it not make sense to have popularity as the primary
facet -- that is, to have a `front page' on the prefs dialog for the
most commonly-used prefs throughout the entire suite? If not, why not?
Or how about the approach taken by Tardis, which is to use components as
the facet for categorization at every level, pretty much ignoring
popularity and skill level completely? Is that a good idea? Why or why not?

The more preferences you include, the more decisions like this you have
to make, and the more likely it is that a given preference (or even an
entire subcategory) could legitimately belong in more than one parent
category. Yahoo, as I said, gets around this by using cross-references,
but I think it would be a great shame if Mozilla got so complicated that
we had to descend to that. As Gordon Henriksen said in the message I
quoted earlier, including cross-references or duplication in the
hierarchy makes the user think `wait a minute, haven't I been here
before'? And female computer users in particular have told me that
offering multiple ways to get to a particular feature is one of the
things which makes computer programs harder (not easier) for them to
learn and use.

With Yahoo, of course, even cross-references aren't enough, and they
have to also include a search function for finding directory listings.
But I don't think even you, Ben, would dare to suggest a search function
in the prefs dialog for finding prefs in your deep prefs hierarchy.

Or would you?

>...


> In some cases there are ways to guess the correct pref setting
> automatically, but this would be no less ambiguous than my TXT->HTML
> recognizer, for which you and others want to have prefs. Similarly,
> there will be people (maybe myself) who want to set the server prefs
> manually to know for sure things are right. So, you won't be able to
> get rid of the prefs (which is what you want). You can just lift the
> requirement to set them.

Yes, but we only need prefs for suchy features because we recognize that
in these cases Mozilla is trying to be too clever, and many users may
resent that. Ideally, those near-AI-complete
<http://www.tuxedo.org/~esr/jargon/html/entry/AI-complete.html>
`features' wouldn't be there at all.

>...
> Why would the colorization of smilies be less distracting than the
> styling of structured phrases?

Because it wouldn't be changing the fundamental representation of the
characters which the sender had actually typed. It wouldn't affect the
line-spacing of the line (in the case where the string of characters :-)
happened to be in an ASCII art picture, for example). And it would be
less of a large block of color than a graphical smiley is.

>...


> > And like viewing attachments in-line or as links. And like viewing
> > full headers or normal headers.
>
> Are you saying that were optimal?

Yes, because -- like smiley conversion and style detection -- they are
preferences you are likely to want to toggle immediately for one or more messages.

This applies to some prefs in components other than Messenger, too,
which is why I suggested the `Preferences Toolbar' for the most
commonly-used prefs in each component <http://bugzilla.mozilla.org/show_bug.cgi?id=38521>.

> I think, we won't need the latter anymore in Mozilla as you can expand
> can collapse parts of the headers directly and view all headers with
> one mouseclick on a header name.

Ooo, direct manipulation!

> For the wrap long lines item: I don't see the point of not wrapping,
> it forces horizontal scrollbars.

<http://cantua.canterbury.ac.nz/~mpt26/art/ascii/faq/#viewing> (second item)

>...


> > HTML message on sending: because the formatting can't easily be
> > turned off by the recipient (unless they *happen* to be using
> > Mozilla, which presumably knows what the Mozilla-specific SPAN
> > CLASSes mean),
>
> Again: Mozilla users have no advantage at all in this case (apart from
> a link in the docs maybe). Just look at the HTML source.

And you regard viewing the source of a message, and deciphering SPAN
CLASSes, as an acceptable user interface for determining whether or not
the sender meant one thing or another? Surely you jest.

> > so it is impossible for the recipient to tell whether the sender
> > intended that formatting to be there or not.
>
> Now that we have the prefs, the intention is implied. If you are
> likely to send msgs which cause the recognizer to fail, then by all
> means turn it off. I (and many others) am not and I want to have it
> on.

Oh, bollocks. `It's not our fault, your honor ... It states quite
clearly on page 472 of the manual that this car will automatically
engage the brakes at full strength if accelerated to more than 120
kilometres per hour. This option can be disabled by flicking the switch
located under the driver's seat; if the driver involved in this accident
failed to read the manual, and chose not to disable this option, we
disclaim all liability ...'

If a preference is on by default, the responsibility lies with the
authors of the program to make sure it doesn't do anything malicious.
And where a preference is offered at all, the responsibility still lies
with the authors of the program to make the user aware of any bad
consequences that could arise from setting it to one value or another.

With this feature, I don't think that it's possible to make the user
aware of such consequences in a way which wouldn't be annoying -- which
is why the feature shouldn't exist at all.

> > > This adding of bits is usually called progress.

> >...


> > It's not because adding of bits is a good idea for a user interface,
> > which it almost always isn't.
>
> I hold an ancient machine against it.

Pardon?

> The difference? To a large part
> better (easier, higher efficiency of the user, more tasks supported)
> software, and this "better" needed a *lot* of "bloat".

I still find it curious that it's acceptable to have to wait more than
about five seconds for a computer to be ready for your input. At school
I used Commodore 64 computers, which took about 0.5 seconds to boot. My
family used to have an Amiga computer, and (booting from a *floppy*
drive) it took 50 seconds to boot. The Windows machine which replaced it
took 1 minute 50 seconds. The Macintosh on which I'm writing this takes
2 minutes. There's something going wrong here. The time to wait should
be going *down*, not up, as the technology improves.

The same applies to application software. I have to wait 20 seconds for
Microsoft Word to load, and about the same for Communicator 4.7. Mozilla
(yes I know it's alpha, unoptimized, blah blah blah) takes about a
minute. This is Gates' Law in action -- every 18 months, the speed of
software halves.

I would regard a loading time, for a computer and for any application on
that computer, of anything more than five seconds as a usability bug.
It's the critical factor which determines, for example, whether a member
of my family looks up something in a dead-tree encyclopedia, or a CD-ROM
encyclopedia, or a Web encyclopedia. At the moment, they only resort to
the latter two when the first doesn't have the information they want,
because the first is faster -- even without the clever searching
facilities offered by the electronic versions.

>...


> > Or, to put it on more of a level playing field, why vi is quite
> > popular on Unix in spite of being considerably less configurable
> > than emacs.
>
> Because some poeple like it
> - traditional
> - slim
> Neither is the market of Mozilla Mailnews.

Why not? Says who?

>...


> The alternative is to have one newbie Mozilla and one for power users.
> This has already been talked down. (See recent "Babying" thread on
> .general.) If you are convinced of that idea, go ahead and create your
> own chrome, maybe even from scratch. I think, this is the only way to
> achieve your goals. I'd be interesed to see the result (really).

<http://critique.net.nz/project/mozilla/about/>
<http://alphanumerica.com/projects/mozilla/skins/aphrodite/>

> You *cannot* remove features I and others rely on from default Mozilla
> just for anticipated usability increase for newbies. See, (assuimg I
> don't want to maintain my own version,) you reduce my efficiency.

>...

Why are you assuming that I'm talking about novice users (or `newbies',
your instinctive way of insulting them)? I'm talking about the greatest
possible number of users -- which, in most cases, means aiming at the
average user. Not the expert. Not the novice user. The *average* user.

Garth Wallace

unread,
Jun 4, 2000, 3:00:00 AM6/4/00
to
"Matthew Thomas" <mp...@student.canterbury.ac.nz> wrote in message
news:3939E620...@student.canterbury.ac.nz...

> Ben Bucksch wrote:
> >
> > Matthew Thomas wrote:
> >
> > Hiding feature 31906 on/off (i.e. graphical quote tags vs. plain).
> > More in this newsgroup after its checked in.
>
> ... Uh oh. Not again.
>
> The approach you should be taking here is the same as the approach you
> should be taking with :-) smileys. Style the plain text how you want (in
> this case, colorization as is done (to a limited extent) by 4.x and (to
> a greater extent) by Deja.com would be a good choice), but *don't* hide
> the > characters themselves; otherwise, Mozilla will become the laughing
> stock of the Internet for its recipient-side munging of plain-text
messages.

What's the big deal here? It's only in the UI,
it does nothing to the messages themselves.
It's actually quite convenient, especially when
the sender neglected to snip quotations.

> > > Yes, but even the perfect prefs UI will only get you so far.
> > >
> > > ... I'm getting a sense of deja vu with that sentence.
> >
> > No surprise, it's directly related to the topic. Would be nice, if you
> > actually *proved* the validity.
>
> Sorry, it seems too obvious to need a proof

Famous last words :)

> >...
> > In some cases there are ways to guess the correct pref setting
> > automatically, but this would be no less ambiguous than my TXT->HTML
> > recognizer, for which you and others want to have prefs. Similarly,
> > there will be people (maybe myself) who want to set the server prefs
> > manually to know for sure things are right. So, you won't be able to
> > get rid of the prefs (which is what you want). You can just lift the
> > requirement to set them.
>
> Yes, but we only need prefs for suchy features because we recognize that
> in these cases Mozilla is trying to be too clever, and many users may
> resent that. Ideally, those near-AI-complete
> <http://www.tuxedo.org/~esr/jargon/html/entry/AI-complete.html>
> `features' wouldn't be there at all.
>
> >...
> > Why would the colorization of smilies be less distracting than the
> > styling of structured phrases?
>
> Because it wouldn't be changing the fundamental representation of the
> characters which the sender had actually typed. It wouldn't affect the
> line-spacing of the line (in the case where the string of characters :-)
> happened to be in an ASCII art picture, for example). And it would be
> less of a large block of color than a graphical smiley is.

Personally, I'd rather not have anything happen to
the smileys. But that's just me.

> > > And like viewing attachments in-line or as links. And like viewing
> > > full headers or normal headers.
> >
> > Are you saying that were optimal?
>
> Yes, because -- like smiley conversion and style detection -- they are
> preferences you are likely to want to toggle immediately for one or more
messages.
>
> This applies to some prefs in components other than Messenger, too,
> which is why I suggested the `Preferences Toolbar' for the most
> commonly-used prefs in each component
<http://bugzilla.mozilla.org/show_bug.cgi?id=38521>.
>
> > I think, we won't need the latter anymore in Mozilla as you can expand
> > can collapse parts of the headers directly and view all headers with
> > one mouseclick on a header name.
>
> Ooo, direct manipulation!
>
> > For the wrap long lines item: I don't see the point of not wrapping,
> > it forces horizontal scrollbars.
>
> <http://cantua.canterbury.ac.nz/~mpt26/art/ascii/faq/#viewing> (second
item)

Isn't this the point of format=flowed?

> > > HTML message on sending: because the formatting can't easily be
> > > turned off by the recipient (unless they *happen* to be using
> > > Mozilla, which presumably knows what the Mozilla-specific SPAN
> > > CLASSes mean),
> >
> > Again: Mozilla users have no advantage at all in this case (apart from
> > a link in the docs maybe). Just look at the HTML source.
>
> And you regard viewing the source of a message, and deciphering SPAN
> CLASSes, as an acceptable user interface for determining whether or not
> the sender meant one thing or another? Surely you jest.

I think he was advising *you* to look at the source
and see why it's not a problem, not "view source" as
a fallback for all users.

> > > Or, to put it on more of a level playing field, why vi is quite
> > > popular on Unix in spite of being considerably less configurable
> > > than emacs.
> >
> > Because some poeple like it
> > - traditional
> > - slim
> > Neither is the market of Mozilla Mailnews.
>
> Why not? Says who?

Well, traditional is right out anyway. It's got a
graphical interface, for one thing :)

Slim is out, because it's built into a *browser*.
Anyone who wants a slim mailer/newsreader
will get something stand-alone.

> >...
> > The alternative is to have one newbie Mozilla and one for power users.
> > This has already been talked down. (See recent "Babying" thread on
> > .general.) If you are convinced of that idea, go ahead and create your
> > own chrome, maybe even from scratch. I think, this is the only way to
> > achieve your goals. I'd be interesed to see the result (really).
>
> <http://critique.net.nz/project/mozilla/about/>
> <http://alphanumerica.com/projects/mozilla/skins/aphrodite/>
>
> > You *cannot* remove features I and others rely on from default Mozilla
> > just for anticipated usability increase for newbies. See, (assuimg I
> > don't want to maintain my own version,) you reduce my efficiency.
> >...
>
> Why are you assuming that I'm talking about novice users (or `newbies',
> your instinctive way of insulting them)? I'm talking about the greatest
> possible number of users -- which, in most cases, means aiming at the
> average user. Not the expert. Not the novice user. The *average* user.

Should advanced users be unable to use it in
special situations, just because the average
user doesn't need to?

And "newbie" is not an insult. "Clueless newbie"
is, but "newbie" is just slang for novice.


Ben Bucksch

unread,
Jun 4, 2000, 3:00:00 AM6/4/00
to mozill...@mozilla.org
Matthew Thomas wrote:

>
> Ben Bucksch wrote:
> > The human working with the software doesn't have to understand all of
> > its fine details. The user should be able to work with it while only
> > understanding the basics and explore parts of it in more depth it
> > wants.
>
> If your logic was applied to atlases, all maps in atlases would be drawn
> on a 1:1 scale <http://www.bibliomania.com/Fiction/Caroll/CompleteWorks/p6-ch11.html#Marker43>.

Sorry, I don't get you. What I am proposing is *exactly* to have several
levels of detail.

> > Feel free to propose a better strategy.
>
> I already have. Just include the most commonly-used
> features/preferences, up to a point where the greatest possible number
> of users find Mozilla to have a comfortable feature set for them. And
> then ... *stop*. Work on making Mozilla more perfect, rather than more complex.

I said earlier, that I think this strategy is wrong. What I meant was a
better strategy *without* limiting (some) users.

Did I fail to explain why this is the wrong approach for the default
Mozilla?

Let me say it straight: I (and I hope others agree with me) don't want
to remove functionality many people use from Mozilla. This is *hurting*
many people. They will complain loudly. And rightly so.

You can't just adjust Mozilla to a specific narrow target group and not
care about the others (where "others" here are experienced users, a
*large* percentage of Mozilla/Netscape users).

OK, the "most powered" users could edit |prefs.js|, but that is a
workaround, not a solution.

I think, the right approach is to figure out a way to let both newbies
and power users use the same UI.

What I would have liked to hear was another/better/improved appoarch of
achieving this. I would like this discussion to have a productive
outcome.

> The approach you should be taking here is the same as the approach you
> should be taking with :-) smileys. Style the plain text how you want (in
> this case, colorization as is done (to a limited extent) by 4.x and (to
> a greater extent) by Deja.com would be a good choice), but *don't* hide
> the > characters themselves

That's your opinion. Turn it off. The overwhelming response to this bug
was very positive. I think, it is the right thing to do, because
- it hides technical details (msg format) from the user
- makes quotes easier recognizable for the user
- the assumption that a line starting with ">" followed by a space* is a
quote is reasonable safe

*for details see my website.

> Let's
> take Yahoo as the best-known example of a well-designed deep hierarchy,

[...]

I didn't see any argument here, why a deep prefs hierarchy were not
possible. Cross-references are not fortunate, but no killing argument.

Let's take the Yahoo example further. What are the alternatives?
- Portals, i.e. a limited selection of resources (that would be similar
to your approach)
- Search engines
- Hyperlinks (assuming you have a good start) (let's compare this with a
direct manipulation interface)

What would you think, if you had no Yahoo (or Google) at all and just
had exactly one portal to find resources on the Web?

To the other options: You obviously dumped a search function. Direct
manipulation also might not be the end-all solution in all cases (see
previous posts).

[4.x prefs]

I agree with you, that the 4.x prefs organization is not perfect (even
bad in some cases) and especially doesn't scale well. This is obvious (I
think) from the Mozilla "Advanced" pref subtree. That's why I'm talking
here: I don't think, we should release this as is. We need a completely
different strategy.

> And female computer users in particular have told me that
> offering multiple ways to get to a particular feature is one of the
> things which makes computer programs harder (not easier) for them to
> learn and use.

I call it richness and it makes me more productive.

I think, what really hurts is that this is sometimes just a symptom of a
bad overall organization. But I don't think, there is anything wrong
with using two non-conflicting, but complementary approaches in
parallel. I.e. Edit|Prefs|Mail|Servers|ServerA vs.
ServerA|rightclick|Edit.

> But I don't think even you, Ben, would dare to suggest a search function
> in the prefs dialog for finding prefs in your deep prefs hierarchy.
>
> Or would you?

I don't remember, but well possible :). I have feature bug 17199: a
second prefs dialog with a deep prefs hierarchy aimed at power users as
substitution to editing prefs.js; originally intended to coexist with
the current prefs dialog until I realized that this (2 dialogs) propably
wasn't the best solution.

[server type recognition is ambiguous, so doens't remove the need for
the UI.]


> Ideally, those near-AI-complete
> <http://www.tuxedo.org/~esr/jargon/html/entry/AI-complete.html>
> `features' wouldn't be there at all.

They /are/ not there at all.

> > Why would the colorization of smilies be less distracting than the
> > styling of structured phrases?
>

> [...] graphical smiley [...]

Not graphical smilies, but *structured phrases*.

> > > And like viewing attachments in-line or as links. And like viewing
> > > full headers or normal headers.
> >
> > Are you saying that were optimal?
>

> Yes, because [...] they are


> preferences you are likely to want to toggle immediately for one or more messages.

I disagree. In Mozilla, you can get all headers on the fly by clicking
on a header name.

> Ooo, direct manipulation!

I never said, direct manipulation were a bad thing. I fact, it is a very
good approach for many problems. Just not for all, e.g. if it gets in
the way.

> > For the wrap long lines item: I don't see the point of not wrapping,
> > it forces horizontal scrollbars.
>
> <http://cantua.canterbury.ac.nz/~mpt26/art/ascii/faq/#viewing> (second item)

What about resizing the window? Ascii-art doesn't have much point, if
you only see either the left or the right side, no?

[More features = progress?]


> > The difference? To a large part
> > better (easier, higher efficiency of the user, more tasks supported)
> > software, and this "better" needed a *lot* of "bloat".

> I still find it curious that it's acceptable to have to wait more than
> about five seconds for a computer to be ready for your input.

Sure, things could be improved a lot, but are IMO OK in general.

> My
> family used to have an Amiga computer, and (booting from a *floppy*
> drive) it took 50 seconds to boot.

Do you still use them? Why not? I bet, the answer more or less directly
requires the bloat.

> I would regard a loading time, for a computer and for any application on
> that computer, of anything more than five seconds as a usability bug.

Sorry, but this is just not reasonable.

- There are limiting factors that have nothing to do with software.
- I prefer to issue a command and let the computer work rather than
working by myself all the time or longer with the same result.

Examples for both reasons:
- When I click on a http link, an ISDN line to my provider is opened
automatically, the browser requests maybe 10 files with 20k together.
Dialing in (dial, authentification etc.) alone costs currently nearly
10s, >3s costs the loading of the page.
- When I search through a large email archive, this just takes some
time.

> It's the critical factor which determines, for example, whether a member
> of my family looks up something in a dead-tree encyclopedia, or a CD-ROM
> encyclopedia, or a Web encyclopedia. At the moment, they only resort to
> the latter two when the first doesn't have the information they want,
> because the first is faster -- even without the clever searching
> facilities offered by the electronic versions.

Well, *I* perfer online libraries much more, because of
- time
- quality/cost
- accessability (I exclusively work on the computer anyway)
- ...

If you ignore the startup time (which doesn't really matter in my case),
I bet I am faster looking up resources than your family members and
nevertheless get better results. That's what I call progress. And it
needed a lot of "bloat" (my computers spend a large portion of boot time
for bringing up the network [services]).

> > Because some poeple like it
> > - traditional
> > - slim
> > Neither is the market of Mozilla Mailnews.
>
> Why not? Says who?

Would you call HTML capability "traditional"? Depending on one
particular web browser "slim"?

slrn (a newsreader) is <200k in size.

I'll look at it.

> Why are you assuming that I'm talking about novice users (or `newbies',
> your instinctive way of insulting them)?

No insult at all intended. Just shorter. I don't think, novice users are
reading this, so I can hardly insult them.

> I'm talking about the greatest possible number of users

You reach the greatest number, if you target *all* of them, not just one
group. You assume that is impossible, I disagree.

--
<http://www.bucksch.org>


Garth Wallace

unread,
Jun 4, 2000, 3:00:00 AM6/4/00
to
"Ben Bucksch" <mozill...@bucksch.org> wrote in message
news:393A189E...@bucksch.org...

> Matthew Thomas wrote:
> >
> > The approach you should be taking here is the same as the approach you
> > should be taking with :-) smileys. Style the plain text how you want (in
> > this case, colorization as is done (to a limited extent) by 4.x and (to
> > a greater extent) by Deja.com would be a good choice), but *don't* hide
> > the > characters themselves
>
> That's your opinion. Turn it off. The overwhelming response to this bug
> was very positive. I think, it is the right thing to do, because
> - it hides technical details (msg format) from the user

Remember, this isn't *always* a good idea.

> > Let's
> > take Yahoo as the best-known example of a well-designed deep hierarchy,
> [...]
>
> I didn't see any argument here, why a deep prefs hierarchy were not
> possible. Cross-references are not fortunate, but no killing argument.
>
> Let's take the Yahoo example further. What are the alternatives?
> - Portals, i.e. a limited selection of resources (that would be similar
> to your approach)
> - Search engines
> - Hyperlinks (assuming you have a good start) (let's compare this with a
> direct manipulation interface)

I think, if the prefs dialog is kept as is, but allows
hyperlinks into it from a help feature, a lot of the
complexity would disappear for new users.

> > > For the wrap long lines item: I don't see the point of not wrapping,
> > > it forces horizontal scrollbars.
> >
> > <http://cantua.canterbury.ac.nz/~mpt26/art/ascii/faq/#viewing> (second
item)
>
> What about resizing the window? Ascii-art doesn't have much point, if
> you only see either the left or the right side, no?

There's only so much screen real estate you can use. If
the ascii-art piece is wider than the screen, those lines
have to go *somewhere*.


Robert O'Callahan

unread,
Jun 5, 2000, 3:00:00 AM6/5/00
to
Matthew Thomas wrote:
> You get to a point of diminishing returns eventually with prefs, too.
> Eventually the decreased usability from a number of factors (outlined
> below) starts outweighing the extra usefulness you are providing.

I agree with the basic idea here. But there is something missing: the
maximally usable set of preferences is different for different kinds of
users. Most people can only handle a small set of preferences. On the
other hand, I just love programs that give me scrolling lists with
hundreds of checkboxes. So, I would like to have lots of preferences that
are usually concealed.

You sort of address this later:


> Similarly, if you allow users to change too much of how the program
> works, you harm the user population as a whole.
> * The program gets bloated (in both disk space and memory space
> required) from all the options available.

In situations where the program already varies its behaviour, e.g. based
on auto-detection or some clever alternate UI, then adding a preference to
control that behaviour more precisely is very lightweight.

> * The program becomes more unreliable, as a finite quantity of QA gets
> thrown at a geometrically increasing number of pref combinations.

Again, if the program can already vary its behaviour, then those
combinations will already occur. Adding prefs can actually help debugging
since you can use them to narrow down the bug.

> * Development slows, as developers have to take into account expected
> behavior with each possible pref as they maintain their code.

Unless your preferences are controlling truly bizarre features, then
wherever this is a problem, modularity is broken and the varying
preferences are just exposing bugs that would exist, perhaps latent, with
or without the preferences.

> * And of course, users become confused as they are confronted with a
> preferences dialog which starts to resemble a Boeing 747 cockpit.

Some of us are control freaks. We like cockpits.

> If Mozilla programmers worked out an algorithm for detecting when each
> particular setting of one boolean pref was appropriate, and when the
> other was appropriate, then a pref could be removed. I would call that
> an advance, but it would be decreasing the complexity of the product.

I would call that an advance too. But there are always people who want to
override the setting. This is just the sort of case where adding a
preference to override the autodetection will not create any of the
additional issues that you fear.

Then you quote


> In reply to that, I can do no better than to quote Gordon Henriksen's
> message in n.p.m.ui from a month ago:

...


> | And, no, "advanced user" checkboxes do not help. If an option exists,
> | it's almost certain that someone will want to get at it, advanced
> | user or not, and hiding it merely frustrates issues further.

True enough, but this is where Mozilla's status as an open source project
really sets the cat among the pigeons. Speaking for myself, if I want a
feature enough, I'll just implement it to my personal Mozilla tree. I may
even pass around binaries or patches to my friends/family/company/users.
Don't laugh, I am actually doing this (e.g. in my Mozilla, I have a
preference that makes all windows resizable). That required some C++
hacking, but XUL/JS really lowers the bar on what's required to customize
Mozilla in general.

So, I would argue that in many cases (when the code already admits
multiple behaviours), having explicit preference settings in the core code
costs little and should be encouraged. It should be up to each Mozilla
distribution to decide which preferences to provide UI for, and how. I
would certainly agree that distributions aiming for a mainstream audience
should carefully limit the preferences they expose.

Rob
--
[Robert O'Callahan http://www.cs.cmu.edu/~roc 6th year CMU CS PhD student
"Now when Joshua was near Jericho, he looked up and saw a man standing in
front of him with a drawn sword in his hand. Joshua went up to him and
asked, 'Are you for us or for our enemies?' 'Neither,' he replied, 'but
as commander of the army of the LORD I have now come.'" - Joshua 5:13-14]

Jerry Baker

unread,
Jun 29, 2000, 3:00:00 AM6/29/00
to
Matthew Thomas wrote:
>
> So, why do we include prefs at all? The simple answer is: `because a
> pref-less program would be a pain to use'. The generalization of that
> answer is: `to make the program more usable'.
>
> Your logic seems to be that the more prefs we add, the more usable the
> program will be. But that logic is just as flawed as that of the Third
> farmer who thinks `well, if I apply one tonne of fertilizer my harvest
> increases by 20 percent, so if I apply two tonnes of fertilizer my
> harvest will increase by 40 percent'. So he applies two tonnes of
> fertilizer, and then finds that the harvest actually *decreases* because
> the fertilizer concentration in the soil is too high.

This analogy is not even close to valid. You have to realize that prefs
always exist, it is a matter of letting the user get at them or not. For
Mozilla to accomplish task X, it will need parameters Y and Z. Either
these can be built in, or the user can change them around if they want.

>
> You get to a point of diminishing returns eventually with prefs, too.
> Eventually the decreased usability from a number of factors (outlined
> below) starts outweighing the extra usefulness you are providing.

You seem to be operating on the assumption that if there are a lot of
prefs, that users will *have* to look at them or set them. This is not
the case. That's what defaults are for.

> > As our
> > product advances, the prefs *will* grow.


>
> I find it interesting that you assume that any `advance' necessarily
> means an increase in prefs complexity, rather than a decrease.

I do not see how a product can become more advanced as it further
reduces your ability to control it.

>
> If Mozilla programmers worked out an algorithm for detecting when each
> particular setting of one boolean pref was appropriate, and when the
> other was appropriate, then a pref could be removed. I would call that
> an advance, but it would be decreasing the complexity of the product.

It would be, but you have to think more globally as well. Look at IE5
with it's favicon.ico feature. It cannot be turned off. Whether
warranted or not, it irritates some Web server operators that there
error logs are flooded with requests for favicon.ico. In fact, even I
have a redirection set up in Apache that redirects requests to
favicon.ico to Microsoft's Web server.

> For example, if someone implemented the algorithm I suggested in
> <http://bugzilla.mozilla.org/show_bug.cgi?id=17325> for calculating how
> often the layout engine should perform incremental reflows, then Mozilla
> would perform better overall, no matter what your configuration. And a
> pref could be removed from the program (albeit one that's not currently
> shown in the prefs dialog), and that would be a good thing.

Agreed.

> Or an example for Messenger: if Mozilla could automatically detect
> whether a mail server was POP or IMAP, then you could probably remove
> the POP/IMAP popup menu from the account settings, and that would be a
> good thing.

That's not possible. My mail server is both.

> Unless you are an anarchist (and I'm guessing you're not), I assume you
> agree with the general idea of a country having laws. Laws exist to
> restrict people in what they can do, for the benefit of society as a whole.


>
> Similarly, if you allow users to change too much of how the program
> works, you harm the user population as a whole.
> * The program gets bloated (in both disk space and memory space
> required) from all the options available.

> * The program becomes more unreliable, as a finite quantity of QA gets
> thrown at a geometrically increasing number of pref combinations.

> * Development slows, as developers have to take into account expected
> behavior with each possible pref as they maintain their code.

> * And of course, users become confused as they are confronted with a
> preferences dialog which starts to resemble a Boeing 747 cockpit.

See my comments at the top. Prefs always exist, the question is making
them accessible.



> So you do need to have restrictions on how much the user can do -- you
> do need to limit configurability. That sounds unbearably fascist, but
> usability engineering is often like that.
>

Says who?

> But, as I've said before, even a perfectly-designed prefs dialog will


> only get you so far.
>

> > In the long term, I'd like to organize them in a deep hierarchy, with
> > the "frontpage" (the panel you get by clicking an a parent node) of a
> > subtree not being a collection of misc prefs (which didn't well fit in
> > a subpanel), but the most important ones. That way, a user with
> > limited needs wouldn't have to care about the deep hierarchy. If a
> > user misses a pref on the "frontpage", he can explore the hierarchy in
> > more depth.
> >...


>
> In reply to that, I can do no better than to quote Gordon Henriksen's
> message in n.p.m.ui from a month ago:
> |

> | The problem with this is that you generate a very complicated
> | interface with an overwhelming array of options. Hierarchies are
> | grand, but often a particular option will logically belong in two or
> | places in your hierarchy. However, offering multiple, identical (or,
> | worse, non-identical) interfaces to the same bit in the preferences
> | file is demonstrably nothing short of baffling, even to savvy users;
> | instead of exploring an interface by simply crawling into each crevice
> | and back out again in an orderly progression, you have to constantly
> | ask yourself, "Have I been here?" In effect, such a hierarchy becomes
> | a confusing graph. At the same time, not having an option in places
> | where it logically belongs causes as much frustration, perhaps
> | preventing discovery: A shopping site which offers only a hierarchical
> | organization of products will probably lose a large number of sales to
> | potential customers who cannot find what they want. (I've been that
> | customer on more than one occasion.)


> |
> | And, no, "advanced user" checkboxes do not help. If an option exists,
> | it's almost certain that someone will want to get at it, advanced user
> | or not, and hiding it merely frustrates issues further.
> |

> | The right thing to do is select only the best options for preferences
> | and, meanwhile, investigate and implement direct manipulation
> | mechanisms for users to control the bizarre behaviors that you're
> | squirreling away.

That whole situation can be avoided by making sure a pref is located in
only one place.

--
Jerry Baker

PGP Key:
http://pgpkeys.mit.edu:11371/pks/lookup?op=get&search=0xD0AEE429

Jerry Baker

unread,
Jul 5, 2000, 3:00:00 AM7/5/00
to
Matthew Thomas wrote:
>
> > This analogy is not even close to valid. You have to realize that
> > prefs always exist,
>
> Why? Are you too far gone to even question that assumption?

Nope, they are required. Either they are hard coded or they are not.
It's just that simple. How long should Mozilla wait before timing out on
a DNS request? Should the "Next Unread" message button cross folders?
Which thread should have higher priority: netlib or Gecko? How many news
messages should Mozilla's summary file retain? How often should Composer
save a backup of the file your working on? The list can go on and on
forever. There is no other alternative but to either hard code these
values or allow them to be prefs.

>
> Let's take a very arcane and technical program -- the Windows Registry
> Editor (regedit). How many prefs does it have? Last time I checked, it
> had none. Nada. Zero. Zip. Nought.

Regedit does one thing: it edits registry entries. If Mozilla just read
text files, there would need to be no prefs.



> > it is a matter of letting the user get at them or
> > not. For Mozilla to accomplish task X, it will need parameters Y and
> > Z. Either these can be built in, or the user can change them around if
> > they want.
>

> Some examples here would be really really helpful.

See above.

> > You seem to be operating on the assumption that if there are a lot of
> > prefs, that users will *have* to look at them or set them. This is not
> > the case.
>

> Wherever a pref exists, you have to provide an interface for it
> *somewhere*. To some extent, the perceived complexity of the interface
> increases only in /n/th proportion to the square root of the number of
> prefs, so you can apparently get away with a large number of prefs. If
> users will not `*have* to look at them or set' the prefs, that implies a
> simple basic interface, which expands rapidly in complexity as you
> explore its nooks and crannies. On a concrete level, that means a lot of
> `Advanced ...' buttons in various places, which -- when clicked -- bring
> up dialogs for progressively advanced prefs.
>
> But the more you do that, the more mouse clicks (or key presses) are
> required to get at the more advanced prefs, the less convenient it
> becomes to use them, and the more likely it is that even advanced users
> will just not bother. So we have the diminishing returns problem again.

There are more prefs that have no interface in NN4 than prefs that have
one. An interface is not required.



> > I do not see how a product can become more advanced as it further
> > reduces your ability to control it.
>

> Lots of ways.
> * Determining (reliably) what it is you want without you having to tell
> it. (Example: automatically calculating the optimum incremental reflow
> rate for HTML/XML rendering.)
> * Preventing errors on your part. (Example: `You haven't typed anything,
> and there are no attachments. Send anyway?'.)

I would want to turn that off immediately.

> > That whole situation can be avoided by making sure a pref is located
> > in only one place.

> >...
>
> Insufficient comprehension detected. Please try again. Now, if only this
> blasted remote control didn't have so many useless buttons, I could find
> the rewind function ... Ah, there it is.

I don't seem to have that problem with the prefs, and I resent that
someone would want to take away my ability to configure them because of
their bad memory.

Matthew Thomas

unread,
Jul 6, 2000, 3:00:00 AM7/6/00
to mozill...@mozilla.org
First, let's have a look at the map and orient ourselves:

usability vs. number of features/prefs
|
+-bloat
| |
| +-download time
| +-disk requirements
| +-memory requirements
| +-startup time
| +-speed
|
+-usefulness
| |
| +-opportunity cost
| +-diminishing returns
|
+-reliability
| |
| +-code development
| +-code maintenance
| +-quality assurance
| +-geometric growth in combinations
|
+-ease of use
|
+-interface complexity <-- YOU ARE HERE
+-support complexity
+-documentation complexity
+-the twiddle factor

Right, that's that sorted. Now, Jerry Baker wrote:
>
> Matthew Thomas wrote:
>...


> > Your logic seems to be that the more prefs we add, the more usable
> > the program will be. But that logic is just as flawed as that of the
> > Third
>

[World]


>
> > farmer who thinks `well, if I apply one tonne of fertilizer my
> > harvest increases by 20 percent, so if I apply two tonnes of
> > fertilizer my harvest will increase by 40 percent'. So he applies
> > two tonnes of fertilizer, and then finds that the harvest actually
> > *decreases* because the fertilizer concentration in the soil is too
> > high.
>
> This analogy is not even close to valid. You have to realize that
> prefs always exist,

Why? Are you too far gone to even question that assumption?

Let's take a very arcane and technical program -- the Windows Registry


Editor (regedit). How many prefs does it have? Last time I checked, it
had none. Nada. Zero. Zip. Nought.

Or something even more complex -- the Mac OS 9.0 Finder (file manager).
How many prefs does it have? I count 27. Of these, 14 are in two highly
related groups (the Show Columns prefs, and the Labels prefs), so they
can almost be counted as 2 rather than 14 -- giving a grand total of 15 prefs.

> it is a matter of letting the user get at them or
> not. For Mozilla to accomplish task X, it will need parameters Y and
> Z. Either these can be built in, or the user can change them around if
> they want.

Some examples here would be really really helpful.

> > You get to a point of diminishing returns eventually with prefs,


> > too. Eventually the decreased usability from a number of factors
> > (outlined below) starts outweighing the extra usefulness you are
> > providing.
>
> You seem to be operating on the assumption that if there are a lot of
> prefs, that users will *have* to look at them or set them. This is not
> the case.

Wherever a pref exists, you have to provide an interface for it


*somewhere*. To some extent, the perceived complexity of the interface
increases only in /n/th proportion to the square root of the number of
prefs, so you can apparently get away with a large number of prefs. If
users will not `*have* to look at them or set' the prefs, that implies a
simple basic interface, which expands rapidly in complexity as you
explore its nooks and crannies. On a concrete level, that means a lot of
`Advanced ...' buttons in various places, which -- when clicked -- bring
up dialogs for progressively advanced prefs.

But the more you do that, the more mouse clicks (or key presses) are
required to get at the more advanced prefs, the less convenient it
becomes to use them, and the more likely it is that even advanced users
will just not bother. So we have the diminishing returns problem again.

> That's what defaults are for.

So instead of programming intelligently so that the user doesn't need to
use so many prefs, we should set defaults intelligently so that the user
doesn't need to use so many prefs? Hmmm.

Intelligent defaults are good, but they're only a salve.

> > > As
> > > our product advances, the prefs *will* grow.
> >
> > I find it interesting that you assume that any `advance' necessarily
> > means an increase in prefs complexity, rather than a decrease.
>
> I do not see how a product can become more advanced as it further
> reduces your ability to control it.

Lots of ways.


* Determining (reliably) what it is you want without you having to tell
it. (Example: automatically calculating the optimum incremental reflow
rate for HTML/XML rendering.)
* Preventing errors on your part. (Example: `You haven't typed anything,
and there are no attachments. Send anyway?'.)

* Increasing interoperability with other applications and with the
surrounding environment. (Example: just about anything involving drag
and drop.)
* Generally increasing the number of times where you wonder if the
program can do something, you guess the way the feature would be
accessed if it was possible, you try it ... and it Just Works.
Long-time Macintosh users will know exactly what I'm talking about
here. It's the feeling you get when you try pasting a sound into the
Sounds control panel, and it Just Works. Or when you drag a folder
icon into the Sherlock window, and it Just Works.

For more insight, I recommend any of P. G. Wodehouse's books about
Bertie Wooster and his butler Jeeves.

> > If Mozilla programmers worked out an algorithm for detecting when
> > each particular setting of one boolean pref was appropriate, and
> > when the other was appropriate, then a pref could be removed. I
> > would call that an advance, but it would be decreasing the
> > complexity of the product.
>
> It would be, but you have to think more globally as well. Look at IE5
> with it's favicon.ico feature. It cannot be turned off. Whether
> warranted or not, it irritates some Web server operators that there
> error logs are flooded with requests for favicon.ico. In fact, even I
> have a redirection set up in Apache that redirects requests to
> favicon.ico to Microsoft's Web server.

Good for you. But if you think making that icon request a pref on the
client side would solve the problem, you're dreaming. The number of
users who would use such a pref to turn that `feature' off (slightly
decreasing the recognizability of their favorites in the process), out
of altruistic consideration for Web server operators, would be
absolutely miniscule.

The specific problem in the case of favicon.ico is that Microsoft should
have specified an HTTP header (alternatively accessible through a META
HTTP-EQUIV element) for icon access, rather than a compulsory (and
usually unsuccessful) request for an arbitrary resource on the server.
That way, those authors who had icons for their pages could specify it
either in their pages or in their server setup, and the rest of the
Web-serving world wouldn't have to suffer.

The general problem, of course, is that Microsoft didn't take the icon
idea (which is a good one, in theory) to the W3C, where problems such as
this -- and the non-standard file type used for the icon -- could have
been sorted out.

>...


> > Or an example for Messenger: if Mozilla could automatically detect
> > whether a mail server was POP or IMAP, then you could probably
> > remove the POP/IMAP popup menu from the account settings, and that
> > would be a good thing.
>
> That's not possible. My mail server is both.

So is mine. In our case, Mozilla would still have to show the pref. But
in cases where the specified server is only one or the other, the pref
could be set to the correct value and disabled. And a completely
unnecessary opportunity for error on the user's part could thereby be eliminated.

>...


> > So you do need to have restrictions on how much the user can do --
> > you do need to limit configurability. That sounds unbearably
> > fascist, but usability engineering is often like that.
>
> Says who?

Me. Also David Every <http://mackido.com/Software/FreeFeatures.html>,
who (for what it's worth) happens to be a libertarian.

>...

Insufficient comprehension detected. Please try again. Now, if only this
blasted remote control didn't have so many useless buttons, I could find
the rewind function ... Ah, there it is.

<...


> > | Hierarchies are grand, but often a particular option will
> > | logically belong in two or places in your hierarchy.

See also the first half of
<http://deja.com/=dnc/getdoc.xp?AN=630813160>.

Paul McGarry

unread,
Jul 6, 2000, 3:00:00 AM7/6/00
to
In article <39640FE1...@weirdness.com>, Jerry Baker
<jbake...@yahoo.com> wrote:

> I don't seem to have that problem with the prefs, and I resent that
> someone would want to take away my ability to configure them because of
> their bad memory.

For what it's worth I'm with you. This is the main reason I use Opera
as my main web browser.

Mozilla should be preferenced to the hilt. If Netscape or anyone else
basing their product on Mozilla wants to change that for their
target audience then they should feel free, but I don't think Mozilla
should be in the business of limiting possibilities.

Paul.

Josh Harding

unread,
Jul 6, 2000, 3:00:00 AM7/6/00
to mozill...@mozilla.org, mozilla-...@mozilla.org
Matthew Thomas wrote:

> * Determining (reliably) what it is you want without you having to tell
> it. (Example: automatically calculating the optimum incremental reflow
> rate for HTML/XML rendering.)
> * Preventing errors on your part. (Example: `You haven't typed anything,
> and there are no attachments. Send anyway?'.)
> * Increasing interoperability with other applications and with the
> surrounding environment. (Example: just about anything involving drag
> and drop.)
> * Generally increasing the number of times where you wonder if the
> program can do something, you guess the way the feature would be
> accessed if it was possible, you try it ... and it Just Works.
> Long-time Macintosh users will know exactly what I'm talking about
> here. It's the feeling you get when you try pasting a sound into the
> Sounds control panel, and it Just Works. Or when you drag a folder
> icon into the Sherlock window, and it Just Works.

I'm with you on all of your ideas about reducing prefs when they can be determined
automatically. The specifics of which things this can apply to can be a future
topic. I agree that it's a goal to have.

I think the reason you're encountering so much resistance to this is that this forum
is mostly comprised of geeks... the minority who want thousands of checkboxes and
buttons to push (myself included). But we should be thinking about the majority.
Here's a typical example: when I installed NN4 for my parents, I'd setup all their
prefs for them. A year later, my dad commented that he didn't like that netscape put
quoted text in red bold italic. He doesn't wanna go digging through endless prefs
just to see if that's something the user is allowed to set.

The average user (NOT the average reader of this newsgroup) isn't going to live with
most of the defaults because they don't all enjoy looking through the prefs just to
see what they can change.

People don't seem to grasp the concept that Matthew is presenting. The idea is not
to remove functionality. It's to make the prefs a less daunting place to be. If the
same functionality can be achieved by automatically determining the best way to do
it, then don't have a pref for it.

Having more prefs is not the same thing as having more functionality.

When you buy a car, you don't have to spend an hour setting all your prefs up before
you can drive it. There are a few people who may want to pick their gear ratios,
adjust valve timings, and tweak their steering power, but they are not the typical
customer. With automatic transmission, VTEC, variable-assist power steering, climate
control and automatic headlights these things all still happen, but without the need
for the end user to adjust settings... the best setting is chosen automatically.
Wouldn't it be nice if your web browser/email client worked like this too.

The goal is not to remove the features that the prefs adjust... it's to change the
way we think about prefs. Before saying "we need a pref for X", try to think of a
way (or post a message asking for suggestions) on how the best choice could be
selected automatically.

Another suggestion would be to take all the non-essential and infrequently used prefs
out and put them in a separately distributed "geek-pack" plugin. Like what M$ did
with TweakUI. The options in TweakUI are things the average user doesn't want to see
cluttering up the rest of their control panels.

Ok, that was longer than I thought it would be... but I'm done now :)

The Amigo

Robert O'Callahan

unread,
Jul 6, 2000, 3:00:00 AM7/6/00
to
Josh Harding wrote:
> Another suggestion would be to take all the non-essential and
> infrequently used prefs out and put them in a separately distributed
> "geek-pack" plugin. Like what M$ did with TweakUI. The options in
> TweakUI are things the average user doesn't want to see cluttering up
> the rest of their control panels.
>
> Ok, that was longer than I thought it would be... but I'm done now :)

This is absolutely the right way to go.

There is a communication problem here. When some people (me, Jerry) talk
about having "more prefs", we don't much care if there's no interface to
them in the default Mozilla build. We can set the pref in the prefs.js
file, or download some XUL hack pack that provides extra UI for them. What
we care about is that the prefs be used in the code and be settable
through the prefs API.

Of course that means most people won't use them, but that doesn't matter.
The people who care will use them, and the people who don't care won't
complain.

This is really no different from the Mac geeks who used to hack the Finder
with Resedit to change its behaviour in innumerable ways, or the people
who download extensions to change their Mac's behaviour. You can't argue
that Apple should have welded everything shut to make this impossible.

Stuart Ballard

unread,
Jul 6, 2000, 3:00:00 AM7/6/00
to
Matthew Thomas wrote:
>
> But the more you do that, the more mouse clicks (or key presses) are
> required to get at the more advanced prefs, the less convenient it
> becomes to use them, and the more likely it is that even advanced users
> will just not bother. So we have the diminishing returns problem again.

By definition, a pref is something you will want to set exactly once
(modulo experimenting with values until you get what you want). As an
advanced user, I can tell you that the first thing I do when I install a
new piece of software is bring up the prefs window and go through every
single configuration option. I've *never* found a case where I've
thought "damn, I wish this program didn't have so many prefs", or seen a
pref I wish wasn't there (except things like "default to sending in
HTML" in NS4... but that's just a pref to turn on a *feature* I wish
wasn't there). I don't care if it takes quite a long time to go through
all the prefs, and I'm perfectly capable of figuring out that I can skip
some sections that don't need changes on an initial install (eg the
applications/mime-types part of NS4 prefs). I certainly wouldn't want
that section taken *away*, because I know I'll go back to it later when
I want to add a special behavior for the mime-type
audio/x-enqueue-mpegurl (yes, I really did this, and wrote the
server-side app that required it).

> > That's what defaults are for.
>
> So instead of programming intelligently so that the user doesn't need to
> use so many prefs, we should set defaults intelligently so that the user
> doesn't need to use so many prefs? Hmmm.

There's a difference. Jerry's way is to arrange that users don't *need*
to use so many prefs if they don't care, but they still *can* use them
if they do care. Your way is essentially equivalent to having
intelligent defaults and then disabling the pref - "we know what you
want to do".

An example of a good advanced user preferences interface, as much as I
hate to admit it, is the advanced tab in IE4. All the other tabs provide
beginner/intermediate user type interfaces, and then the advanced tab
provides all other available preferences in the form of a scrolling
tree-view. The apparent complexity of the UI is enough to discourage
non-advanced users from touching these prefs, but to an advanced user
it's clear that this is giving you full control over every detail of
operation (although IE still doesn't have every detail of operation in
there, at least last time I looked). This more-or-less negates your
first point of requiring lots of clicks to get to, because it requires
exactly one click (The "advanced" tab) and then tree-view navigation to
the pref you are after. I don't think any advanced user would find that
too complex.

Stuart.

Ben Bucksch

unread,
Jul 6, 2000, 3:00:00 AM7/6/00
to mozill...@mozilla.org
Matthew Thomas wrote:
> +-bloat
> | |
> | +-download time
> | +-disk requirements
> | +-memory requirements
> | +-startup time
> | +-speed

The impact of a pref dialog is neglectable.

> +-usefulness
> | |
> | +-opportunity cost
> | +-diminishing returns

"Preference" options:
+ Increase target audience
+ Increase security (in today's reality, you need to trade options
(read: websites) for security)
+ Decrease annoyance ("I know what I'm doing, don't ask me.")
+ Adapt to different circumstances/prefences of the user ("I like red
links better.")

> +-reliability
> | |
> | +-code development
> | +-code maintenance
> | +-quality assurance
> | +-geometric growth in combinations

Technical options:
Maybe of the combinations are there anyway. If you make the app "detect"
them, you dramatically increase development complexity (because the app
will be so "smart" that it is hard to predict the exact behaviour.)

> +-ease of use
> |
> +-interface complexity <-- YOU ARE HERE

Better complex than limiting.
I don't want to live in the former Eastern Germany. Its population
didn't need to worry about which sort of bread to buy or to compare
prices. The government thought for it.
I like the western, free market approach better. I am willing to invest
time to "cope" with more options with the result to propably get a
better (for me) product.

> +-support complexity

Yes, because less people will use the product :).

Seriously, if you don't include a feature enough people want, some of
them will go to the competition and the rest will ask you about it.
(Note that "enough" here is a relatively low barrier.) Watch .mailnews -
FAQs: "How do I query multiple POP servers with 4.x?", "How do I decode
multipart attachments?" etc..

> +-the twiddle factor

Do you count that as downside? I certainly count that as advantage.

> Let's take a very arcane and technical program -- the Windows Registry
> Editor (regedit). How many prefs does it have? Last time I checked, it
> had none. Nada. Zero. Zip. Nought.

You can hardly count regedit.exe as a good example of a user app. It
propably was a one-day hack of a passionate programmer at Microsoft. As
such, it is a nice program, but nothing for the normal user. Since it is
used by so many people, this fact gets forgotten and the program is
bashed for having no undo, memory, whatever.

> Or something even more complex -- the Mac OS 9.0 Finder (file manager).
> How many prefs does it have? I count 27. Of these, 14 are in two highly
> related groups (the Show Columns prefs, and the Labels prefs), so they
> can almost be counted as 2 rather than 14 -- giving a grand total of 15 prefs.

How many time do you spend in the filemanager in comparison to the
browser and mail client?
-> Need for a comfortable interface
-> Willingness to learn a more complex interface

Just the folder and thread panes of Mailnews together are already as
complex in nature as a filemanager: Both manage a hierarchy of folders,
each containing numerous objects, plus the ability to open and search
objects. Mailnews has (and a normal filemanager hasn't) the ability to
view objects, a complete editor and an address book, which has the same
complexity again, but in a smaller scale. Now, add to that all the
network communication (sending msgs, retrieving msgs and folders via
several ways). And that was only Mailnews, we also have a browser and
chat client.
-> Inherent complexity

> > it is a matter of letting the user get at them or
> > not. For Mozilla to accomplish task X, it will need parameters Y and
> > Z. Either these can be built in, or the user can change them around if
> > they want.
>
> Some examples here would be really really helpful.

You have composed a msg in the HTML editor, and it is complete and
correct. You hit "Send". The recipient isn't known to accept HTML.

Should we convert to plaintext (we might loose the look and even
information, OTOH, the recipient might not be able to read HTML)? If we
do so, what is more important: the look or the information? (Just this
paragraph requires a lot of prefs.)

Should we send it immadiately or delay it (maybe until the user opens a
connection and exchanges data)?

Should we save a copy? Where?

> > You seem to be operating on the assumption that if there are a lot of
> > prefs, that users will *have* to look at them or set them. This is not
> > the case.
>
> Wherever a pref exists, you have to provide an interface for it
> *somewhere*.

> If


> users will not `*have* to look at them or set' the prefs, that implies a
> simple basic interface, which expands rapidly in complexity as you
> explore its nooks and crannies. On a concrete level, that means a lot of
> `Advanced ...' buttons in various places, which -- when clicked -- bring
> up dialogs for progressively advanced prefs.

No, you don't need "Advanced" buttons, just a Deep prefs hierarchy (TM).

> > I do not see how a product can become more advanced as it further
> > reduces your ability to control it.
>
> Lots of ways.
> * Determining (reliably) what it is you want without you having to tell
> it. (Example: automatically calculating the optimum incremental reflow
> rate for HTML/XML rendering.)

If we have a reliably way to determine what the user will want, I'm all
for removing the pref. But unfortunately, this is the minority of prefs.

A lot of prefs are technical in nature, but the app has no way to figure
out the right thing, or it is likely to guess wrong, or guessing creates
negative side effects (I might not want a network connection when I am
configuring my mail server options).

And a lot of prefs are really "preferences". There is no way for the
cook to guess the taste of his "clients".

> * Preventing errors on your part. (Example: `You haven't typed anything,
> and there are no attachments. Send anyway?'.)

Yes, and I want a pref to turn the dialog off. Exactly my speak about
"advances".

> * Increasing interoperability with other applications and with the
> surrounding environment. (Example: just about anything involving drag
> and drop.)

Can you explain? Interoperability and adaption to environment in the
network area certainly cost a lot of prefs (see plaintext conversion
above).

> * Generally increasing the number of times where you wonder if the
> program can do something, you guess the way the feature would be
> accessed if it was possible, you try it ... and it Just Works.
> Long-time Macintosh users will know exactly what I'm talking about
> here. It's the feeling you get when you try pasting a sound into the
> Sounds control panel, and it Just Works. Or when you drag a folder
> icon into the Sherlock window, and it Just Works.

How is that relevant?

BTW: Although I don't know much about Macs, I know what you're speaking
about and complete agree that this is desireable.

> > favicon.ico feature.

> > error logs are flooded with requests for favicon.ico.

> But if you think making that icon request a pref on the


> client side would solve the problem, you're dreaming.

Agreed.

> users who would use such a pref to turn that `feature' off (slightly
> decreasing the recognizability of their favorites in the process)

You like the feature and might want to use it. I like the feature, but
don't want to use it for privacy reasons. We need a pref...

> Insufficient comprehension detected. Please try again. Now, if only this
> blasted remote control didn't have so many useless buttons, I could find
> the rewind function ... Ah, there it is.

Would you prefer to crawl in front of your VCR in order to program it
(the equivalent to hand-editing prefs.js)? I don't.

--
<http://www.bucksch.org>


Ben Bucksch

unread,
Jul 6, 2000, 3:00:00 AM7/6/00
to mozill...@mozilla.org
Josh Harding wrote:
> I think the reason you're encountering so much resistance to this is that this forum
> is mostly comprised of geeks... the minority who want thousands of checkboxes and
> buttons to push (myself included).

Please - I don't consider myself being a geek or monkey.

> But we should be thinking about the majority.
> Here's a typical example: when I installed NN4 for my parents, I'd setup all their
> prefs for them. A year later, my dad commented that he didn't like that netscape

If you didn't mess up his prefs, he wouldn't complain. It would have
been better, if you sat the prefs together with him, so he had an inital
setting he liked and he knew where to look, if he changed his mind.

> People don't seem to grasp the concept that Matthew is presenting. The idea is not

> to remove functionality. [...] If the


> same functionality can be achieved by automatically determining the best way to do
> it, then don't have a pref for it.

This is not the point. I think, we all agree that it is a good thing to
remove prefs that can reliably be determined automatically.

But Matthew wants to remove more. He wants to
- remove prefs rarely used by average users
- substitute prefs with *guessing* algorithms.

> Another suggestion would be to take all the non-essential and infrequently used prefs
> out and put them in a separately distributed "geek-pack" plugin.

Where is the border between a geek and the average user?

--
<http://www.bucksch.org>


Robert O'Callahan

unread,
Jul 6, 2000, 3:00:00 AM7/6/00
to
Ben Bucksch wrote:
> Where is the border between a geek and the average user?

A geek bothers to download the "superprefs" extension, the average user
does not.

Robert O'Callahan

unread,
Jul 6, 2000, 3:00:00 AM7/6/00
to
Actually, considering that Mozilla's audience is mostly sophisticated
users, I think it would be fine for a monstrous "All Preferences" tree
panel to be accessible from within Mozilla. Netscape would simply remove,
disable or hide it in their build.

Remember, we're not just talking about one application here, we're talking
about a family of applications addressed to different user groups.

Matthew Thomas

unread,
Jul 8, 2000, 3:00:00 AM7/8/00
to mozill...@mozilla.org
Jerry Baker wrote:
>
> Matthew Thomas wrote:
> >
> > > This analogy is not even close to valid. You have to realize that
> > > prefs always exist,
> >
> > Why? Are you too far gone to even question that assumption?
>
> Nope, they are required. Either they are hard coded or they are not.
> It's just that simple.

Has it occurred to you that if something was hard-coded, it would cease
to be a pref? Then all the problems I listed earlier would collapse into
a singularity.

> How long should Mozilla wait before timing out
> on a DNS request?

One minute. From a test I did a while ago (albeit without a stopwatch)
this seems to be what Internet Explorer uses too; and I don't see a pref
for this anywhere in IE.

I've never ever seen a successful DNS request take longer than about six
seconds, even on a dialup connection, though in the worst-case scenario
(say, a 14.4 kbps modem in Eastern Europe or central Africa) it may take
a bit longer than that.

> Should the "Next Unread" message button cross
> folders?

It should be a dialog (`Advance to next unread message in {name of
folder}?'), as it is in 4.x. (One pleasant side-effect of the
introduction of XPToolkit is that selecting `Ok' in this dialog will be
possible using the space bar -- which you are already using to page
through unread messages -- on all platforms, whereas in 4.x on Mac OS
you have to move from the space bar to Enter and back again.)

> Which thread should have higher priority: netlib or Gecko?

If the layout in the currently visible portion of the content is
incomplete, then Gecko should have priority (subject to the algorithm I
proposed in <http://bugzilla.mozilla.org/show_bug.cgi?id=17325>);
because users load content in order to read it, they don't load content
in order to see how long it takes in total.

Whenever the layout of currently visible content is stable, however,
Netlib should have the higher priority.

> How many news messages should Mozilla's summary file retain?

That should be a pref, but only because Mozilla is running in operating
environments which aren't smart about allocating disk space. In the
perfect operating system, file I/O would be fast enough that each news
header could be its own file -- or, more likely, its own record in a
system database (akin to that originally used in BeOS). Then when the
system needed more space on a disk than was available, it would be able
to delete files flagged as `temporary' (such as news summary files)
based on the `importance' value registered with the file by its creating application.

Mozilla would then be able to calculate (and register) the `importance'
of a news summary file based on how old it was, how often you had
referred to summary files of that age in the past, and how often you had
gone back to that file in particular (if you ever had).

> How often
> should Composer save a backup of the file your working on?

That should be a pref, but only because Mozilla is running on operating
systems where file I/O has a cost (mainly time, but also disk wear). In
the ideal operating environment, that would not be the case, and Mozilla
would be able to save a backup every 30 seconds.

> The list
> can go on and on forever. There is no other alternative but to either
> hard code these values or allow them to be prefs.

As described, a third option is to calculate the value based on previous
behavior -- whether that be behavior of the user, or of the system itself.

>...


> > But the more you do that, the more mouse clicks (or key presses) are
> > required to get at the more advanced prefs, the less convenient it
> > becomes to use them, and the more likely it is that even advanced
> > users will just not bother. So we have the diminishing returns
> > problem again.
>

> There are more prefs that have no interface in NN4 than prefs that
> have one. An interface is not required.

You seem to be misunderstanding the meaning of `pref'. Not all things
stored in prefs.js are prefs. For example, the prefs.js items containing
the paths of recently-opened files in Composer are not prefs. Composer
just uses prefs.js because that's an architecturally convenient place to
put the items.

A preference is something the user can meaningfully change in order to
change the behavior of the program. Prefs are there to be used. If a
pref does not have an interface, it has Missed The Point Entirely
<http://theonion.com/onion3534/missing_the_point.html>.

>...


> > * Preventing errors on your part. (Example: `You haven't typed
> > anything, and there are no attachments. Send anyway?'.)
>

> I would want to turn that off immediately.

Oh, come on. The only time when you're ever remotely likely to come
across this dialog, *other than* when you've chosen `Send' by accident,
is when subscribing to (or unsubscribing from) a mailing list (where you
put `subscribe' or `unsubscribe' respectively in the subject line, and
write nothing in the body).

And in those cases, you've just hit Ctrl+Enter to send the message (if
you're smart enough to think you don't need this warning dialog, you're
smart enough to always be using the keyboard shortcuts, right?), so your
finger is already over the Enter key ready to activate the `Send' button
in the dialog. Total extra time expended: about one second, for
something which is only going to happen about once a month on average
(if that).

> > > That whole situation can be avoided by making sure a pref is
> > > located in only one place.
> > >...
> >
> > Insufficient comprehension detected. Please try again. Now, if only
> > this blasted remote control didn't have so many useless buttons, I
> > could find the rewind function ... Ah, there it is.
>

> I don't seem to have that problem with the prefs, and I resent that
> someone would want to take away my ability to configure them because
> of their bad memory.

>...

What about the rest of the world, which resents that computers are so
difficult to use, where this is in no small part because people like you
want a pref for everything?

Matthew Thomas

unread,
Jul 8, 2000, 3:00:00 AM7/8/00
to mozill...@mozilla.org
Robert O'Callahan wrote:

>
> Josh Harding wrote:
> >
> > Another suggestion would be to take all the non-essential and
> > infrequently used prefs out and put them in a separately distributed
> > "geek-pack" plugin. Like what M$ did with TweakUI. The options in
> > TweakUI are things the average user doesn't want to see cluttering
> > up the rest of their control panels.
>...

> This is absolutely the right way to go.

That would be a nice partial solution, but only a partial solution.
Let's bring out the map again, and see which problems it would solve.
/ = solved
, = partially solved
x = not solved

bloat:
, download time (given that a fair chunk of a pref is its interface)
, disk requirements (ditto)
x memory requirements (because bits of interface are separated anyway)
x startup time
x speed

usefulness:
x opportunity cost
x diminishing returns

reliability:
x code development
x code maintenance
x quality assurance
x geometric growth in combinations

ease of use:
/ interface complexity
, modality (solved, but only if nobody else ever uses your profile)
, support complexity (ditto)
/ documentation complexity (assuming TweakMoz users don't need docs)
/ the twiddle factor

> There is a communication problem here. When some people (me, Jerry)
> talk about having "more prefs", we don't much care if there's no
> interface to them in the default Mozilla build. We can set the pref in
> the prefs.js file, or download some XUL hack pack that provides extra
> UI for them. What we care about is that the prefs be used in the code
> and be settable through the prefs API.

Which still leaves all the problems with `x's listed above.

>...


> This is really no different from the Mac geeks who used to hack the
> Finder with Resedit to change its behaviour in innumerable ways, or
> the people who download extensions to change their Mac's behaviour.
> You can't argue that Apple should have welded everything shut to make
> this impossible.

>...

No, but in that case the configurability isn't coming at the expense of
bloat, usefulness, or reliability -- because it's the same number of
lines of code being used whether or not you're using a hacked version.
Ceteris paribus, the Finder is just as quick when hacked with ResEdit
than when not, because the resources really need to exist in the form
that they do in order for the Finder to work at all. Right?

Matthew Thomas

unread,
Jul 8, 2000, 3:00:00 AM7/8/00
to mozill...@mozilla.org
Paul McGarry wrote:
>...

> Mozilla should be preferenced to the hilt.

Mozilla is woefully under-configurable in some areas (e.g. printing
options and toolbar arrangement), but bewilderingly over-configurabile
in others. Under-configurability is usually because the relevant
features haven't been implemented yet. Over-configurability is a bit
more complex.

In some cases, over-configurability is the result of programmers,
seeking net.fame for their efforts (`see that checkbox? I programmed
that feature!'), including a pref for something just so that the feature
is visible -- even when you'd never want to turn the pref off. This is
probably a worse problem in open-source projects, where for a sizeable
proportion of the programmers, net.fame is the only payment they can get.

In other cases, over-configurability is the result of an argument
between programmers about whether something should be implemented one
way or another. Instead of resolving the argument, the programmers make
it a pref. This ends up being the worst of both worlds: the argument
still rages about what the default for the pref should be, and the issue
is so technical that the poor user is completely incapable of
understanding the pref anyway.

In still other cases, the problem may be Mozilla-specific. This is just
a conspiracy theory, but here goes ... Because (for various reasons) the
Mozilla project initially had fewer non-Netscape contributors than was
expected, Netscape module owners became hesitant about saying `no' to
any contribution, lest they discourage contributors from working on
Mozilla. So externally developed features got included even where they
weren't a good idea, and a preference then had to be included to turn
the features off in order to save the sanity of other users.

> If Netscape or anyone else
> basing their product on Mozilla wants to change that for their
> target audience then they should feel free,

Is this the dirty secret of the open source movement, then -- that
without coercive pressure placed on it by a profit-making enterprise
(whether that be Netscape in the case of Mozilla, or Eazel in the case
of GNOME, or Corel in the case of KDE), it is incapable of producing an
interface which is usable by ordinary humans?

If that's true <http://sendmail.net/?feed=interviewkuniavsky>, then it
is a very great shame indeed. I'd much rather my family used Mozilla
than Netscape 6, Opera, IE, or any other commercial app. But right now,
Mozilla doesn't have a show of reaching dogfood status as far as they
are concerned.

> but I don't think Mozilla
> should be in the business of limiting possibilities.

>...

Just how many megabytes do you want Mozilla to be, exactly?

Jerry Baker

unread,
Jul 8, 2000, 3:00:00 AM7/8/00
to
Matthew Thomas wrote:
>
> > Nope, they are required. Either they are hard coded or they are not.
> > It's just that simple.
>
> Has it occurred to you that if something was hard-coded, it would cease
> to be a pref? Then all the problems I listed earlier would collapse into
> a singularity.

That was my point exactly. No pref = no choice. A programmer made a
choice for me.

>
> > How long should Mozilla wait before timing out
> > on a DNS request?
>
> One minute. From a test I did a while ago (albeit without a stopwatch)
> this seems to be what Internet Explorer uses too; and I don't see a pref
> for this anywhere in IE.

So because IE doesn't have a pref, neither should Mozilla?



> I've never ever seen a successful DNS request take longer than about six
> seconds, even on a dialup connection, though in the worst-case scenario
> (say, a 14.4 kbps modem in Eastern Europe or central Africa) it may take
> a bit longer than that.

So why should it be a minute as you stated above? Maybe because for some
users it takes longer? Cool. Make a pref so users that have a lower
latency connection don't have to wait for a whole 60 seconds.



> > Should the "Next Unread" message button cross
> > folders?
>
> It should be a dialog (`Advance to next unread message in {name of
> folder}?'), as it is in 4.x. (One pleasant side-effect of the
> introduction of XPToolkit is that selecting `Ok' in this dialog will be
> possible using the space bar -- which you are already using to page
> through unread messages -- on all platforms, whereas in 4.x on Mac OS
> you have to move from the space bar to Enter and back again.)

It should not be a dialog, it should be a choice that is permanent. If
your dialog had a checkbox to remember my decision, then it would be
stored as a pref.



> > Which thread should have higher priority: netlib or Gecko?
>
> If the layout in the currently visible portion of the content is
> incomplete, then Gecko should have priority (subject to the algorithm I
> proposed in <http://bugzilla.mozilla.org/show_bug.cgi?id=17325>);
> because users load content in order to read it, they don't load content
> in order to see how long it takes in total.

Speak for yourself.



> Whenever the layout of currently visible content is stable, however,
> Netlib should have the higher priority.
>
> > How many news messages should Mozilla's summary file retain?
>
> That should be a pref, but only because Mozilla is running in operating
> environments which aren't smart about allocating disk space. In the
> perfect operating system, file I/O would be fast enough that each news
> header could be its own file -- or, more likely, its own record in a
> system database (akin to that originally used in BeOS). Then when the
> system needed more space on a disk than was available, it would be able
> to delete files flagged as `temporary' (such as news summary files)
> based on the `importance' value registered with the file by its creating application.

Expand to fill my hard drive? I think not.



> Mozilla would then be able to calculate (and register) the `importance'
> of a news summary file based on how old it was, how often you had
> referred to summary files of that age in the past, and how often you had
> gone back to that file in particular (if you ever had).

Isn't it easier just to let me tell it how important my news articles
are to me? Why do you want to guess what I want instead of letting me
tell you?

>
> > How often
> > should Composer save a backup of the file your working on?
>
> That should be a pref, but only because Mozilla is running on operating
> systems where file I/O has a cost (mainly time, but also disk wear). In
> the ideal operating environment, that would not be the case, and Mozilla
> would be able to save a backup every 30 seconds.
>
> > The list
> > can go on and on forever. There is no other alternative but to either
> > hard code these values or allow them to be prefs.
>
> As described, a third option is to calculate the value based on previous
> behavior -- whether that be behavior of the user, or of the system itself.

That means choosing for me. Not acceptable.


> >...
> > > But the more you do that, the more mouse clicks (or key presses) are
> > > required to get at the more advanced prefs, the less convenient it
> > > becomes to use them, and the more likely it is that even advanced
> > > users will just not bother. So we have the diminishing returns
> > > problem again.
> >
> > There are more prefs that have no interface in NN4 than prefs that
> > have one. An interface is not required.
>
> You seem to be misunderstanding the meaning of `pref'. Not all things
> stored in prefs.js are prefs. For example, the prefs.js items containing
> the paths of recently-opened files in Composer are not prefs. Composer
> just uses prefs.js because that's an architecturally convenient place to
> put the items.
>
> A preference is something the user can meaningfully change in order to
> change the behavior of the program. Prefs are there to be used. If a
> pref does not have an interface, it has Missed The Point Entirely
> <http://theonion.com/onion3534/missing_the_point.html>.

Right. I'll say it again. There are many more prefs that have no UI than
there are ones that do have a UI in NN4.X. See
http://developer.netscape.com/docs/manuals/deploymt/jsprefs.htm



> >...
> > > * Preventing errors on your part. (Example: `You haven't typed
> > > anything, and there are no attachments. Send anyway?'.)
> >
> > I would want to turn that off immediately.
>
> Oh, come on. The only time when you're ever remotely likely to come
> across this dialog, *other than* when you've chosen `Send' by accident,
> is when subscribing to (or unsubscribing from) a mailing list (where you
> put `subscribe' or `unsubscribe' respectively in the subject line, and
> write nothing in the body).

Well, it just so happens that when I want a friend to turn on AIM, I
send a blank email. Already the "blank subject" pop-up annoys the hell
out of me. Why is it so hard to let me do what I want?



> And in those cases, you've just hit Ctrl+Enter to send the message (if
> you're smart enough to think you don't need this warning dialog, you're
> smart enough to always be using the keyboard shortcuts, right?), so your
> finger is already over the Enter key ready to activate the `Send' button
> in the dialog. Total extra time expended: about one second, for
> something which is only going to happen about once a month on average
> (if that).
>
> > > > That whole situation can be avoided by making sure a pref is
> > > > located in only one place.
> > > >...
> > >
> > > Insufficient comprehension detected. Please try again. Now, if only
> > > this blasted remote control didn't have so many useless buttons, I
> > > could find the rewind function ... Ah, there it is.
> >
> > I don't seem to have that problem with the prefs, and I resent that
> > someone would want to take away my ability to configure them because
> > of their bad memory.
> >...
>
> What about the rest of the world, which resents that computers are so
> difficult to use, where this is in no small part because people like you
> want a pref for everything?

This is Mozilla, not AOL or Netscape 6.

Matthew Thomas

unread,
Jul 8, 2000, 3:00:00 AM7/8/00
to mozill...@mozilla.org
Stuart Ballard wrote:
>...

> By definition, a pref is something you will want to set exactly once
> (modulo experimenting with values until you get what you want).

Not true. There are quite a few preferences which you'll want to turn
on/off temporarily for particular Web sites, or e-mail messages, or chat
rooms. See `Preferences Toolbar, for most commonly used prefs'
<http://bugzilla.mozilla.org/show_bug.cgi?id=38521>.

> As an
> advanced user, I can tell you that the first thing I do when I install
> a new piece of software is bring up the prefs window and go through
> every single configuration option.

That's the `twiddle factor' I listed in my map. You *have* to
investigate every single configuration option, for the same reason some
people *have* to climb a mountain -- Because It's There.

> I've *never* found a case where

> I've thought "damn, I wish this program didn't have so many prefs", or


> seen a pref I wish wasn't there (except things like "default to
> sending in HTML" in NS4... but that's just a pref to turn on a
> *feature* I wish wasn't there).

What's the difference? Features of dubious value are often the reason
for prefs.

> I don't care if it takes quite a long
> time to go through all the prefs,

Lucky for you. Some of us just want to get stuff done, and when --
during the course of our work -- we do want to change prefs, the
complexity of the prefs interface makes that difficult for us.

> and I'm perfectly capable of
> figuring out that I can skip some sections that don't need changes on
> an initial install (eg the applications/mime-types part of NS4 prefs).

Lucky for you, again. Most people don't have that technical knowledge.

> I certainly wouldn't want that section taken *away*, because I know
> I'll go back to it later when I want to add a special behavior for the
> mime-type audio/x-enqueue-mpegurl (yes, I really did this, and wrote
> the server-side app that required it).

Well, IE doesn't have that prefs section -- because it uses the global
filetype-recognition prefs provided by Windows, as it should. Similarly,
iCab doesn't have that prefs section -- because it uses the global
Internet Config prefs used by Mac OS, as it should.

Mozilla only needs this prefs section at all, presumably, because
Mozilla exists on some platforms (X in a GNOME-less and KDE-less
environment, in particular) where such global preferences aren't provided.

>...


> An example of a good advanced user preferences interface, as much as I
> hate to admit it, is the advanced tab in IE4. All the other tabs
> provide beginner/intermediate user type interfaces, and then the
> advanced tab provides all other available preferences in the form of a
> scrolling tree-view.

I beg to differ. I find it difficult to imagine how IE's prefs interface
could get much worse. The names of the tabs aren't very informative, the
portrait dialog layout makes it hard to find the pref you want on each
tab, and even novice-level prefs are hidden in separate dialogs (e.g.
default fonts and colors) or buried in a list of dozens upon dozens of
prefs in the `Advanced' tab. And the `Advanced' tab itself has its own
problems. By default (IIRC), it is fully expanded, removing much of the
point of it being a tree in the first place; and tree branches require
double-clicks to open or close, making it harder to get to the part of
the tree you want.

> The apparent complexity of the UI is enough to
> discourage non-advanced users from touching these prefs, but to an
> advanced user it's clear that this is giving you full control over
> every detail of operation (although IE still doesn't have every detail
> of operation in there, at least last time I looked). This more-or-less
> negates your first point of requiring lots of clicks to get to,
> because it requires exactly one click (The "advanced" tab) and then

> tree-view navigation to the pref you are after. I don't think any


> advanced user would find that too complex.

Let's take a simple example of a pref you might want to change
temporarily. You visit a Web page which has pink text on a purple
background, so you want to temporarily turn off the author's colors and
use your defaults. In Internet Explorer's Internet Options, this pref is
hidden in a separate dialog, which is accessible by clicking an
`Accessibility' button on the General tab
<http://microsoft.com/enable/training/IE5/fontcolor.htm>.

So you need six or seven clicks (depending on whether the `General' tab
is the one showing when you open the dialog) to change the pref. And
that's assuming that you're lucky enough to guess that using your
default colors is an `accessibility' issue -- if not, you won't be able
to find the option at all.

A similar situation applies if you want to turn off images -- in the
Internet Options dialog, you will take anywhere from five to dozens of
clicks (depending on how many clicks you apply to the tree scrollbar) to
get at that pref, because it's hidden in the middle of the tree in the
`Advanced' tab. And that's assuming you can be bothered reading through
enough of the list of `advanced' prefs to find that pref in the first place.

To some extent this is just poor UI design, but to some extent it is
also IE trying to be too configurable. If IE didn't have so many useless
options (`Always expand ALT text for images'? ... um, okay), then it
wouldn't be so difficult to find the prefs you *do* want to change. As
it is, you're more likely just to grin and bear it -- to try and read
the pink text, or to click the Back button, or to wait (and wait ... and
wait ...) while all the images load.

Matthew Thomas

unread,
Jul 8, 2000, 3:00:00 AM7/8/00
to mozill...@mozilla.org
Ben Bucksch wrote:
>
> Matthew Thomas wrote:
> > +-bloat
> > | |
> > | +-download time
> > | +-disk requirements
> > | +-memory requirements
> > | +-startup time
> > | +-speed
>
> The impact of a pref dialog is neglectable.

For prefs which aren't directly related to the interface, much of the
bloat comes not from the XUL and JS, but from the C++ code which
implements the pref.

> > +-usefulness
> > | |
> > | +-opportunity cost
> > | +-diminishing returns
>
> "Preference" options:
> + Increase target audience

Sometimes, and sometimes they decrease it by scaring users away.

> + Increase security (in today's reality, you need to trade options
> (read: websites) for security)

Prefs don't intrinsically increase security; they just give you a wider
range of security levels (from very high to very low). In some cases,
this is a good thing.

> + Decrease annoyance ("I know what I'm doing, don't ask me.")

True, but in most cases these particular preferences *can* be squirreled
away in `Advanced' sections -- the initial interface for turning them
off is provided by the `Always warn me about this' checkbox in the
relevant dialog the first time it appears.

> + Adapt to different circumstances/prefences of the user ("I like red
> links better.")

No argument there.

>...


> Technical options:
> Maybe of the combinations are there anyway. If you make the app
> "detect" them, you dramatically increase development complexity
> (because the app will be so "smart" that it is hard to predict the
> exact behaviour.)

To some extent this is true, but not for the reason you describe.
Development complexity can be increased by having to implement the
detection algorithm, but development complexity can simultaneously be
decreased by the resultant knowledge that some combinations of variables
will now never occur.

If an algorithm is `so "smart" that it is hard to predict the
exact behaviour', that (the unpredictability) is probably a usability
bug anyway, in which case you've created more problems than you're
solving by removing the pref.

> > +-ease of use
> > |
> > +-interface complexity <-- YOU ARE HERE
>
> Better complex than limiting.
> I don't want to live in the former Eastern Germany. Its population
> didn't need to worry about which