Deep prefs hierarchy
Ben Bucksch
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.)
Matthew Thomas
>
> 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
> 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?
Matthew Thomas
>
> Matthew Thomas wrote:
> >
> > I find it interesting that you assume that any `advance' necessarily
> > means an increase in prefs complexity, rather than a decrease.
>
> 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
> 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).
Matthew Thomas
>...
> 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
[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.
Ben Goodger
> 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.
Garth Wallace
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
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
> Garth Wallace wrote:
> > I still can't tell the difference between
> > the graphics that replace :-) and ;-) though.
>
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
> 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
Karl Ove Hufthammer
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:
| > >...
| > 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.
|
| 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
>
> 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
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.
Ben Bucksch
> * Please already do write URLs abbreviated
s/Please/People
Stuart Ballard
>
> 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
> 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.
Stuart Ballard
>
> 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
> 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.
Ben Bucksch
> 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
> 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
>
> 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
> 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
>
> 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.
>
> 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'd be interesed to see the result (really).
>
> <http://critique.net.nz/project/mozilla/about/>
> <http://alphanumerica.com/projects/mozilla/skins/aphrodite/>
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.
Garth Wallace
> 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
> 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
>
> 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
>
> > This analogy is not even close to valid. You have to realize that
> > prefs always exist,
>
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
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
<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
> * 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
> 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
>
> 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
> +-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.
Ben Bucksch
> 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?
Robert O'Callahan
> 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
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
>
> 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?
>
> 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
>
> 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
> > 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
>...
> 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
>
> > 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
>...
> 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
>
> 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 sort of bread to buy or to compare
> prices. The government thought for it.
Conversely, I don't want to live in MSNistan or AOLia, where the
Internet is turned into a nightmarish, marketeered,
non-standards-compliant, parody of itself. And if we don't make Mozilla
dominant over That Other Major Browser, that's what will happen.
I've seen a conspiracy theory on Slashdot that Netscape and Microsoft
are in cahoots, keeping Mozilla just usable enough to suck up the
efforts of contributors who would otherwise work on other open-source
browser/mailer projects, so that a decent mass-market open-source
browser/mailer never arrives. I don't believe that theory for a second,
but I'd rather we didn't go out of our way to *make* it come true.
> 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.
The free market does not dictate that all hammers must be sold with a
choice of shaped heads, a built-in can opener, Optical Thumb Recognition
to warn you if you if you are about to hurt yourself, and the built-in
ability to `skin' the handle in whatever color and texture you like.
So why do you think the free market dictates that Mozilla is similarly
over-complex? Only because the computer age is still in its infancy, and
consumers still accept that computers must be very slow and very
difficult to use. Eventually the market will correct itself, and we
won't accept that any more; all people like me try to do is hurry the
market up.
>...
> 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..
Neither of those features require prefs, except (of course) those which
store the settings for the multiple POP accounts to begin with.
> > +-the twiddle factor
>
> Do you count that as downside? I certainly count that as advantage.
Every time I use MS Word on a new computer, I have to spend a couple of
minutes turning off prefs which shouldn't exist, but which have to exist
because they toggle features which themselves shouldn't exist. I don't
count that as an advantage of Word.
> > 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.
A one-day hack? Possibly. A passionate programmer? Almost certainly not
<http://www.infowar.com/iwftp/risks/Risks-20/20_37.txt>.
> 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.
Undo would not require any prefs.
>...
> How many time do you spend in the filemanager in comparison to the
> browser and mail client?
Ideally Navigator should be a file manager as well as a browser. By that
I'm not following Jakob Nielsen's idiocy in claiming that the browser
should be an integrated part of the operating system; all I'm saying is
that the tasks of browsers and file managers intersect too much for
their separation to make much sense. The Eazel and KDE people have
already worked this out.
>...
> 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.
In Messenger you do not have to:
* rename messages
* duplicate accounts, folders, or messages
* make aliases to accounts, folders or messages
* eject accounts from the account drive
* arrange your icons in a grid.
>...
> 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)?
This wasn't on my earlier hit-list of prefs to be removed. It should be
a pref, just as it is; and the default should be to ask the user, just
as it is.
> If
> we do so, what is more important: the look or the information?
Neither. I can't think of any major conflict that would exist between
the two; and even if there was, it's highly misguided to assume that the
user would be able to make a sensible decision about it. Chances are,
they wouldn't even understand what you were asking.
>...
> Should we send it immadiately or delay it (maybe until the user opens
> a connection and exchanges data)?
Depends whether the user is in offline mode or not. Thanks to the little
online/offline button in the status bar, this does not require a pref.
> Should we save a copy?
Pref.
> Where?
In an ideal system, the user shouldn't have to care where it goes,
because OS file retrieval functions would be good enough not to need a
folder-based system. But unfortunately that's not the case, so we need
to allow the user to specify a folder for saved messages.
>...
> > * 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".
If we have a pref to turn the dialog off, we won't get that GNKSA
(section 16).
> > * 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).
Here's a simple example. Dragging an entry from the address book to an
Explorer/Finder/GNOME/KDE folder window (or to the desktop) should
create a document of type `Person', which contains the address book data
for that person (and which is kept synchronized with the address book
entry in the address book file itself). You could then:
* drag the icon into a message composition window, in order to include
the person as a recipient;
* open the icon, to view the person's address book card;
* bring up a context menu for the icon (on Windows and on Mac OS, and
probably in the X desktop environments too) which included items such
as `New Mail Message', `New Instant Message', `New Phone Call', `Write
Letter' (which would start up Composer with the address of the person
automatically filled out in your preferred letter style), and
`Properties'.
Other examples of system-savviness would include:
* in Mozilla's setup utility (separate from user prefs), allowing users
to put shortcuts for various Mozilla components in various places
<http://bugzilla.mozilla.org/show_bug.cgi?id=28174>;
* adding appropriate items to the file manager's context menus for
Mozilla-related document types (on both Windows and Mac OS);
* synchronizing the Password Manager with the Keychain on Mac OS (so if
I saved a password in iCab I could use the same password in Mozilla
without having to re-enter it);
* allowing a folder icon (or even a shortcut to a folder icon) to be
dragged from the file manager to the bookmarks window/toolbar, so that
the items in the folder became virtual bookmarks.
The number of prefs required by most of these features would be zero.
> > * 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?
I was asked how Mozilla could be advanced in a way which wouldn't
require additional prefs. And that's one of the ways. Making it more
intuitive, rather than more complicated.
>...
> > > favicon.ico feature.
>
> > > error logs are flooded with requests for favicon.ico.
>...
> > 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...
First you need to explain what on earth requesting bookmark icons could
possibly have to do with your privacy.
> > 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.
>...
Hand-editing prefs.js assumes that the prefs exist at all.
Matthew Thomas
>
> Matthew Thomas wrote:
> > 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.
Every line of code a programmer writes is them making a choice for you.
The only difference is in the extent.
> > > 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?
No, I didn't say that. Given the overabundance of prefs in IE, the lack
of a pref for something in IE would tend to *suggest* that such a pref
is not necessary at all, but it's by no means an A-therefore-B argument.
> > 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.
They don't have to wait anyway. In by far the majority of cases where
you make a DNS request, it is to access content you are actively waiting
for (such as a Web page). And in that case, users will press the Stop
button long before a minute is up.
A DNS timeout limit is only necessary at all in two cases. The first is
where a beginning user, not knowing how the Internet works, is under the
false impression that the all parts of the Internet have 100 percent
uptime. In this case, you need to have a timeout to prevent the user
from waiting too long before they finally realize that their impression
was incorrect.
The second is where a DNS request is required for some background
activity. For example, I may click on a link to download and open a very
large PDF file, and then bring another browser window to the front to
browse elsewhere while the PDF is downloading. If the DNS fails for the
PDF request, I would want to be informed reasonably soon that the
request wasn't getting anywhere, so I wouldn't switch back to the other
window ten minutes later and be irritated to discover that Mozilla was
still waiting for the DNS.
> > > 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.
Why? If you could turn the cross-folders option off, you'd need some
sort of feedback anyway -- when you pressed the space bar at the end of
the last message -- to tell you that there were no more unread messages
to go to in that folder. This dialog provides that feedback already,
with the added bonus of allowing you to go to unread messages in other
folders (if such messages exist).
>...
> > > 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.
Ok, now you've got me curious. What do *you* load HTML/XML content for
most of the time? Just for kicks, to see how fast your connection is,
and not to read it, huh?
>...
> > 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.
You only think not because you're used to 20th-century computers, where
mundane technical things (like how full your hard drive is) still matter.
> > 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?
Easier for whom? For the application programmers and OS programmers, certainly.
>...
> > > 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.
So when did you last write to a car manufacturer, complaining that
they'd chosen the size of the {seat, steering wheel, accelerator pedal,
gear stick ...} for you, that you had found it very difficult to refit
(recompile) the car to get your preferred size, and that this was not acceptable?
>...
> > 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
And I'll say it again: if a pref does not have an interface, it has
Missed The Point Entirely. Anyway, most of the prefs listed on that page
are for organization-specific app customization, which is obsolete now
that Mozilla's chrome is so intrinsically customizable.
>...
> 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?
Because that's an incredibly rare edge case. Is it really so hard to
write `AIM' in the subject, and press Enter one extra time when sending
the message? Surely not.
Soon, Mozilla won't let you delete an entire address book without a
dialog popping up first. And the dialog will not be optional. I'm
grieving in advance for the inconvenience this is going to cause you. Not.
>...
> > 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.
>...
So you'd rather the unwashed masses were stuck with AOL or Netscape 6?
Well, I mean, really. Have you no compassion at all? :-)
Ben Bucksch
> In some cases, over-configurability is the result of programmers,
> seeking net.fame for their efforts (`see that checkbox? I programmed
> that feature!')
Examples?
> 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.
If the programmers argued long enough and assuming they thought well
about the problem, and they can still not agree, this is a hint that it
should really be configurable. If they wouldn't care, they wouldn't have
argued. If they care, users are likely to care as well.
> 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.
I guess, you're speaking of me, as you argued about removing some of the
features I implemented.
Please note, that e.g. the smily recognition was *not* invented by
myself, nor initally implemented in Mozilla by myself. I just rewrote
the implementation to be *much* less annoying (read: less error-prone).
Yes, I added structured phrases recognition/conversion. Do you want to
know why? Because it is a lesser evil than HTML msgs. My goal was and
still is to reduce the number of unnecessary HTML msgs (as long as they
represent an interop problem).
> > 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
> , it is incapable of producing an
> interface which is usable by ordinary humans?
No, if you feel that Mozilla's UI is too complex, you can do that same
as those companies can do: Produce your own custom version of Mozilla.
Just don't cripple (that's what you're trying to do from my POV) the
default Mozilla, please.
> > 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?
As said before, preferences don't blow the app.
Ben Bucksch
> 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.
OK, let's plant all mountains. They make transportation harder.
> when [...] we do want to change prefs, the
> complexity of the prefs interface makes that difficult for us.
Then let's make it easier for you without planting everything.
> > I can skip some sections
> Lucky for you, again. Most people don't have that technical knowledge.
What technical knowledge do you need to know that you can skip the
"Appearance" and "Mail and Newsgroups" sections, if you just want to set
the proxy for web browsing, because your admin told you to do so? To
know what "Mail" is? (Let's ignore that the "Advanced" tab is a mess.)
Exactly that philosophy lies behind my Deep Prefs Hierarchy proposal.
Jerry Baker
>
> 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.
But adding code in that is supposed to guess intelligently about these
settings adds no bloat???
> > Should we send it immadiately or delay it (maybe until the user opens
> > a connection and exchanges data)?
>
> Depends whether the user is in offline mode or not. Thanks to the little
> online/offline button in the status bar, this does not require a pref.
So how does that online/offline button "know" when a user is connected
or not? You cannot rely on users to press that every time they hang up
the modem and again when they dial in.
Jerry Baker
>
> Jerry Baker wrote:
> >
> > Matthew Thomas wrote:
> >
> > That was my point exactly. No pref = no choice. A programmer made a
> > choice for me.
>
> Every line of code a programmer writes is them making a choice for you.
> The only difference is in the extent.
This is true, and the more prefs you take away from me the further you
exacerbate this.
> > 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.
>
> They don't have to wait anyway. In by far the majority of cases where
> you make a DNS request, it is to access content you are actively waiting
> for (such as a Web page). And in that case, users will press the Stop
> button long before a minute is up.
If you do this in 4.X, Netscape will cease to function properly. All
subsequent DNS lookups will be on hold until the timeout expires anyway.
While this bug may not currently exist in Mozilla, it is possible.
> > It should not be a dialog, it should be a choice that is permanent.
>
> Why? If you could turn the cross-folders option off, you'd need some
> sort of feedback anyway -- when you pressed the space bar at the end of
> the last message -- to tell you that there were no more unread messages
> to go to in that folder. This dialog provides that feedback already,
> with the added bonus of allowing you to go to unread messages in other
> folders (if such messages exist).
I don't want a dialog telling me that I have reached the last message in
a group either. I can tell that when it says 0 unread messages that
there are no more. Similarly, when "Next Unread" message fails to
advance, I kind of get the idea.
> Ok, now you've got me curious. What do *you* load HTML/XML content for
> most of the time? Just for kicks, to see how fast your connection is,
> and not to read it, huh?
Sometimes that is exactly what I am doing. Just becasue I don't do it
most of the time does not mean I should never be able to do it.
> > Expand to fill my hard drive? I think not.
>
> You only think not because you're used to 20th-century computers, where
> mundane technical things (like how full your hard drive is) still matter.
It will always matter. Until infinite storage is possible anyway.
> > Isn't it easier just to let me tell it how important my news articles
> > are to me?
>
> Easier for whom? For the application programmers and OS programmers, certainly.
Easier for me the user. How do you as a programmer know whether I want
to keep all the articles I read in a particular group, or keep none at
all, etc.?
> > That means choosing for me. Not acceptable.
>
> So when did you last write to a car manufacturer, complaining that
> they'd chosen the size of the {seat, steering wheel, accelerator pedal,
> gear stick ...} for you, that you had found it very difficult to refit
> (recompile) the car to get your preferred size, and that this was not acceptable?
Infact, I contacted Volkswagen of America yesterday because my 2000
Jetta does not have a cigarette lighter. The option to put one in, I was
told, is as easy as buying the little guy to plug into the socket. But,
when I went to do it, I was informed that it would cost me $100+ to have
the little socket cover removed. That made me angry enough to
contemplate driving the car through the plate glass at the dealership -
just as it would in a browser.
> And I'll say it again: if a pref does not have an interface, it has
> Missed The Point Entirely. Anyway, most of the prefs listed on that page
> are for organization-specific app customization, which is obsolete now
> that Mozilla's chrome is so intrinsically customizable.
Most of those prefs have nothing to do with chrome, but cooler things. I
can set how many simultaneous network connections Netscape opens,
whether I want to allow the blink tag to blink or not, turn of referer
headers, whether to thread news messages by subject or reference header
only, etc.
> Because that's an incredibly rare edge case. Is it really so hard to
> write `AIM' in the subject, and press Enter one extra time when sending
> the message? Surely not.
Why go through the extra work to require me to do that? having all these
dialogs pop up here and there, and removing prefs is akin to passing
laws to protect me from myself. It is highly annoying.
>
> Soon, Mozilla won't let you delete an entire address book without a
> dialog popping up first. And the dialog will not be optional. I'm
> grieving in advance for the inconvenience this is going to cause you. Not.
That won't matter because I would just do it from my file manager if
Mozilla was annoying about it.
> So you'd rather the unwashed masses were stuck with AOL or Netscape 6?
> Well, I mean, really. Have you no compassion at all? :-)
That is exactly what I would prefer.
Computers cannot be made asy to use without removing a lot of what makes
them so powerful. People have to be able to learn how to do things. You
have to learn to drive a car, fly a plane, ride a bike, walk, swim, etc.
If you cannot take the time to learn to use a computer, then don't. That
is no less discriminatory than saying if you can't learn to drive a car,
then don't. There is no natural law anywhere that says everybody has to
be able to use a computer. Sure it would be nice, but it shouldn't be
made to happen.
Matthew Thomas
>
> Matthew Thomas wrote:
> >
> > seeking net.fame for their efforts (`see that checkbox? I programmed
> > that feature!')
>
> Examples?
I'm not a mind-reader, so I can't tell which prefs were implemented for
show-off/marketing purposes and which weren't. (The net.fame theory is
one we were taught in CompSci lectures.) However, the following prefs
look like likely candidates.
* Three different settings for default `Character Coding' [sic] -- in
`Navigator' > `Languages', in `Mail and Newsgroups' > `Viewing
Messages', and in `Mail and Newsgroups' > `Composing Messages'. At the
very least, the first two could be merged; it seems as though they
have only been made separate in order to advertise the implementation
of the feature in each component.
* `Enable address auto-completion' -- if implemented properly, there's
no good reason to turn this off.
* `Use Password Manager to remember this password' -- though this is a
wording issue, rather than a pref issue (why should I care what it is
which is remembering the password?).
> > 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.
>
> If the programmers argued long enough and assuming they thought well
> about the problem, and they can still not agree, this is a hint that
> it should really be configurable.
That depends on whether users can understand the pref or not. If not,
the programmers might as well have tossed a coin instead.
> If they wouldn't care, they wouldn't
> have argued. If they care, users are likely to care as well.
I don't think you can't convince me that users are likely to care about
any of the prefs currently in the main `Composer' category (not the `New
Page Settings' category, but the main category). I can't even understand
what they do, let alone want to change them.
> > 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.
>...
> Please note, that e.g. the smily recognition was *not* invented by
> myself, nor initally implemented in Mozilla by myself.
Who wrote the initial implementation? Not a Netscape person, surely.
>...
> Yes, I added structured phrases recognition/conversion. Do you want to
> know why? Because it is a lesser evil than HTML msgs. My goal was and
> still is to reduce the number of unnecessary HTML msgs (as long as
> they represent an interop problem).
For that I applaud you. It's a great feature -- except when you ram that
conversion down non-Mozilla recipients' throats with HTML messages
composed in Mozilla (which is the default, so you can't accuse the user
of agreeing to it).
>...
> > Is this the dirty secret of the open source movement, then -- that
> > without coercive pressure placed on it by a profit-making
> > enterprise, it is incapable of producing an interface which is
> > usable by ordinary humans?
>
> No, if you feel that Mozilla's UI is too complex, you can do that same
> as those companies can do: Produce your own custom version of Mozilla.
As if I have the resources to do that! I'm not a profit-making enterprise.
The UI isn't too complex for me, but then I -- like you -- use computers
a lot, so I have a thick skin when it comes to bad interfaces. But I
just know that many of those organizations producing custom versions of
Mozilla won't be clueful enough to simplify it from the default version.
(Netscape is the obvious example: except for the `Debug' category, how
many prefs are in Mozilla now that aren't slated to be included in
Netscape 6? Not many.)
So if the default version of Mozilla isn't easy to use, millions of
people are going to find their Mozilla-derived browsers unnecessarily
difficult to use. And that thought keeps me awake at night.
> Just don't cripple (that's what you're trying to do from my POV) the
> default Mozilla, please.
>...
By making me wait 55 seconds for Mozilla to start up (twice as long as
4.7), you're crippling the default Mozilla from *my* point of view.
(Yeah, I know, I know, unoptimized alpha code and all that.)
Ben Bucksch wrote:
>
> Matthew Thomas wrote:
> >
> > 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.
>
> OK, let's plant all mountains. They make transportation harder.
Well, at least let's not plan superhighways (which will be used by
millions of people) to be built right over the top of mountains, please.
If you want to visit the mountains, mount an expedition (compile your
own version with all the bells and whistles).
>...
> > > I can skip some sections
> >
> > Lucky for you, again. Most people don't have that technical
> > knowledge.
>
> What technical knowledge do you need to know that you can skip the
> "Appearance" and "Mail and Newsgroups" sections, if you just want to
> set the proxy for web browsing, because your admin told you to do so?
The original comment was about the helper app prefs, not the proxy
prefs. But anyway, what if you just want to set the proxy for Web
browsing and you *don't* have your admin to guide you? (If we all had
admins to guide us, we wouldn't need GUI prefs at all.)
You open the prefs dialog. Nothing looks obviously proxy-related. You
want to set the Web browsing proxy, so you look in the `Navigator'
category (which will likely be expanded already because you've just come
from a Navigator window). You browse through the subcategories, and find
no references to proxies.
The only other possibility which looks promising is the `Advanced'
category. You click on the word `Advanced', and see a bunch of stuff to
do with Java and JavaScript, and assume that that's all `Advanced' is
about -- nothing about proxies or anything like that.
If you're lucky, you eventually work out that clicking the tiny triangle
next to the word `Advanced' does something different from clicking the
word `Advanced' itself (truly bizarre behavior, inherited from 4.x). So
if the contents of the main `Advanced' category doesn't put you off (by
making you think it's just about Web page display), maybe you'll expand
the branch, and see `Proxies' there in the subcategories.
In comparison, let's open the Tardis prefs dialog
<http://critique.net.nz/project/mozilla/prefs/tardis/>. Where are the
proxy settings? Probably either in `General' or in `Navigator'. You
click on the `Navigator' category; the subcategories are displayed, and
none of them are about proxies. Ok, you click on the `General' category;
the `Navigator' subcategories collapse, and the `General' subcategories
expand. And there's a `Connection' subcategory, with the proxy settings
in it. Bingo.
> To know what "Mail" is? (Let's ignore that the "Advanced" tab is a
> mess.)
>...
On the other hand, let's not. What sense does it make to have
preferences for viewing content strewn over four separate sections --
`Appearance', `Navigator', `Mail and Newsgroups', and `Advanced'? Not much.
Ben Bucksch
> net.fame
> * Three different settings for default `Character Coding'
I don't know enough about I18N to comment here. But I do know that
non-western developers/users have to fight hard for usability.
> * `Enable address auto-completion' -- if implemented properly, there's
> no good reason to turn this off.
I guess, there are people who really don't like those "smart" features.
> * `Use Password Manager to remember this password' -- though this is a
> wording issue, rather than a pref issue (why should I care what it is
> which is remembering the password?).
heh. I guess, this is just a hack. The checkbox won't work, if you don't
have the password manager enabled. (Yes, I know, this is a bad solution.
Don't tell me, but tell NS not to ship too early.)
> That depends on whether users can understand the pref or not. If not,
> the programmers might as well have tossed a coin instead.
The user that do care understand and need it. Others please ignore it
:).
> > Please note, that e.g. the smily recognition was *not* invented by
> > myself, nor initally implemented in Mozilla by myself.
>
> Who wrote the initial implementation? Not a Netscape person, surely.
Oh yes, a Netscape employee.
Guess what? Netscape plans to remove the conversion prefs UI entirely
(which is OK with me), and wants to default smily conversion (which
alters content) to on, but structured phrases conversion to off. Reason:
The first one "is cute", while the latter one might confuse users. I
wonder how they are supposed to understand the stars around the words
then, as they are there anyway, the recognition is only there to help
them understand the stars.
BTW: smily recognition is an established feature of IM clients for quite
some time.
> For that I applaud you. It's a great feature
Thanks.
> except when you ram that
> conversion down non-Mozilla recipients' throats with HTML messages
> composed in Mozilla (which is the default, so you can't accuse the user
> of agreeing to it).
I got so enough negative feedback that I have been convinced that this
might not be a good idea to default to "on" and intend to change the
default to "off". Just waiting for approval.
> > No, if you feel that Mozilla's UI is too complex, you can do that same
> > as those companies can do: Produce your own custom version of Mozilla.
>
> As if I have the resources to do that! I'm not a profit-making enterprise.
I think, if you are doing the right thing, others will care as well and
help you.
> I
> just know that many of those organizations producing custom versions of
> Mozilla won't be clueful enough to simplify it from the default version.
I bet that if you created a good alternative to the current packages,
mozilla.org would be happy to include your version into the respository
and let you "advertize" it on www.mozilla.org. So, if a company would
really look for a browser or "internet suite" with a simplified
interface, it could get "your" packages.
> > Just don't cripple (that's what you're trying to do from my POV) the
> > default Mozilla, please.
>
> By making me wait 55 seconds for Mozilla to start up (twice as long as
> 4.7), you're crippling the default Mozilla from *my* point of view.
> (Yeah, I know, I know, unoptimized alpha code and all that.)
Again: Prefs don't blow the app. It's reinventing the wheel which does
this (but that's a dead snake).
No, not even the code for the almost all prefs has substantial influence
on the weight.
> If you want to visit the mountains, mount an expedition (compile your
> own version with all the bells and whistles).
I think, you are *seriously* underestimating the amount of users which
want to control details of their most-used apps. I would guess that at
least 5% of users would complain about each and every pref you remove
(but different groups for different prefs of course). 5% are still
several millons.
> > What technical knowledge do you need to know that you can skip the
> > "Appearance" and "Mail and Newsgroups" sections, if you just want to
> > set the proxy for web browsing, because your admin told you to do so?
I also wrote "(Let's ignore that the "Advanced" tab is a mess.)" (see
below). But OK, maybe we can at least agree on how to improve or remove
that Advanced tab.
[No proxy in Navigator]
> The only other possibility which looks promising is the `Advanced'
> category. You click on the word `Advanced', and see a bunch of stuff to
> do with Java and JavaScript, and assume that that's all `Advanced' is
> about -- nothing about proxies or anything like that.
Flaw 1 of the current prefs dialog: The main panel is some kind of
"Misc" panel. I would summarize the most important prefs of the
subcategories in the main panel and create an extra "Misc" subpanel, if
necessary.
> If you're lucky, you eventually work out that clicking the tiny triangle
> next to the word `Advanced' does something different from clicking the
> word `Advanced' itself (truly bizarre behavior, inherited from 4.x).
It might make sense to automatically expand the subcategories.
But using a tree widget is basic computer knowledge today - I know no
(non-Netscape/Mozilla) tree widgets which automatically expands
subcategories that way.
> Where are the
> proxy settings? Probably either in `General' or in `Navigator'. You
> click on the `Navigator' category; the subcategories are displayed, and
> none of them are about proxies. Ok, you click on the `General' category;
> the `Navigator' subcategories collapse, and the `General' subcategories
> expand. And there's a `Connection' subcategory, with the proxy settings
> in it. Bingo.
Personally, I would create a "Network" panel or so, but this is not that
important right now.
What I consider important is that
- the user ignored irrelevant panels, both on the main level and second
level
- the user understands the concept of a hierarchy (Navigator->Proxies or
General->Connection->Proxies)
So, would there be a problem, if "Proxies" were a subpanel of
"Connections"? I say no. Neither would it have been a problem, if "Smart
Browsing" under "Navigator" had subpanel again.
That's all I mean with the Deep Prefs Hierarchy proposal. I guess, I
should just go ahead and make a concrete proposal.
> > To know what "Mail" is? (Let's ignore that the "Advanced" tab is a
> > mess.)
> >...
>
> On the other hand, let's not. What sense does it make to have
> preferences for viewing content strewn over four separate sections --
> `Appearance', `Navigator', `Mail and Newsgroups', and `Advanced'? Not much.
IMO, there should be a "General" panel, which contains a "Appearance"
subpanel. But there should also be an "Appearance" subpanel under
Mailnews, because Mailnews has additional viewing orefs that just don't
make sense for Navigator. Just make sure that the wording (e.g. both are
named "Appearance") is identical.
Ben Bucksch
> 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.
Even the code doesn't bloat. Note that compiled C++ code usually bloats
much less than XUL or JS "code".
[You pretty much agreed on the necessarily of each pref category I
mentioned. So you just disagree with the amount of prefs?]
> development complexity can simultaneously be
> decreased by the resultant knowledge that some combinations of variables
> will now never occur.
If autodetecting reduces the amount of combinations, then I guess,
anything was or is flawed. Do you have an example?
> 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.
Exactly my point. Most autodetections are not implemented because either
- it is a lot of work or
- it would only guess, in which case you create a "usability bug"
> Conversely, I don't want to live in MSNistan or AOLia, where the
> Internet is turned into a nightmarish, marketeered,
> non-standards-compliant,
privacy-breaking, choice-denying,
> parody of itself. And if we don't make Mozilla
> dominant over That Other Major Browser, that's what will happen.
Point taken. I want to fight that world as well.
> So why do you think the free market dictates that Mozilla is similarly
> over-complex?
Not over-complex. But as complex as the environment it is made for.
There is demand for a internet applications that are very configurable.
This demand has been served by Netscape, now Mozilla. Where do you want
to send these users otherwise? What browser should I use, if I wouldn't
happen to be a Mozilla developer? There are lots of such users.
To come back to your evil world: It gives you "choices". You can go
either to MSN or AOL. But none does what you want.
Open-source is the only bastion that still cares about advanced users.
Everything else is just running after the masses. Any now you want to
take that last option away from us. And no, most advanced users won't
compile the source themselves.
I do see your point about an easy to use browser, but please leave us
ours. If necessary, provide an additional one.
> In Messenger you do not have to:
> * duplicate accounts, folders, or messages
You can copy messages and I do.
> * make aliases to accounts, folders or messages
Why now? I would like to have this feature.
> > If
> > we do so, what is more important: the look or the information?
>
> Neither. I can't think of any major conflict that would exist between
> the two
There are lots. Examples:
<title>: Show or not?
<b>foo</b> -> *foo*
<code>foo</code> -> |foo|
<h4>foo</h4> -> 3.2.1.4. foo
(I don't see a away to unambiguously show the header level with
indention or so. Also, it needs to stand out from indented one-line
paragraphs. Such combinations do appear in reality, at least in my
documents.)
> In an ideal system, the user shouldn't have to care where it goes,
> because OS file retrieval functions would be good enough not to need a
> folder-based system.
(I do like to organize things hierarchical.)
> > > `You haven't typed
> > > anything, and there are no attachments. Send anyway?'
> If we have a pref to turn the dialog off, we won't get that GNKSA
> (section 16).
Why? I argue that requiring to turn a pref off is enough of a warning.
The next sentence says that a UA may allow the user to ignore the
warning.
> First you need to explain what on earth requesting bookmark icons could
> possibly have to do with your privacy.
The content provides knows
- that
- when
- propably also because of which page
I bookmarked the site.
> Hand-editing prefs.js assumes that the prefs exist at all.
We are talking about interfaces. You will not remove the prefs itself.
If you do, you will hear a *loud* cry from nearly all sides and that's
it - Mozilla would be nothing more than a browser for AOL.
Ben Bucksch
> Why? If you could turn the cross-folders option off, you'd need some
> sort of feedback anyway -- when you pressed the space bar at the end of
> the last message -- to tell you that there were no more unread messages
> to go to in that folder. This dialog provides that feedback already,
> with the added bonus of allowing you to go to unread messages in other
> folders (if such messages exist).
What Jerry said: Just do nothing.
This dialog in 4.x annoys me as well. I have unread msgs filed in some
folders, because I might want to read them later, but not now.
> > 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?
>
> Because that's an incredibly rare edge case.
I for one am annoyed about these dialogs during testing.
Another group of people might just chat over mail and agree on that
subjects are unnecessary. And they might be exactly your target group
(novice or average users).
Point being: "You just don't know (how people will use the app). Don't
force something on your users (if you don't need to)."
> Is it really so hard to
> write `AIM' in the subject, and press Enter one extra time when sending
> the message
Yes. He said, it annoys the hell out of him. And I can follow him well.
Ben Bucksch
> Has it occurred to you that if something was hard-coded, it would cease
> to be a pref?
Hard-coding not good.
> Then all the problems I listed earlier would collapse into
> a singularity.
But other, larger ones would appear. It would be very hard to create a
binary with an alternate setting. You didn't even thought, vendors would
be able to create a good custom UI. Do you think, they will hack the
code, then? Or even individuals? That would be the minority. That's the
point of prefs (regardless of UI or not).
[Cutting heavily:]
> > How long should Mozilla wait before timing out on a DNS request?
> One minute.
> > Should the "Next Unread" message button cross folders?
> It should be a dialog as it is in 4.x.
> > How often should Composer save a backup of the file your working on?
> In the ideal operating environment, that would not be the case,
> and Mozilla would be able to save a backup every 30 seconds.
Matthew, please. You are trying to hardcode /your opinion/. There is a
reason why these things are prefs: others disagreed. Please understand
that there are circumstances that you don't even know of and which
require settings that might sound freaky to you unless you understand
the problem.
It is a bit the same as with the average citizen. You can "specify" a
personn that exactly meets the national average in all things you know
of. But try to find this person. It will be very hard, possibly
impossible.
For each pref you remove, you loose customers. If you do that for too
many ones, you end up having no customers anymore (or exactly one -
yourself, depending on how you chose the settings).
There might be a tradeoff between ease of learning (what you call
"usability") and large configurability (what means usability for me).
(But I am not yet convinced that this is true.) Assuming this tradeoff
is necessary, it is fine to provide two versions of Mozilla -
one which trades more configurability, loosing lots of average users,
and
one which trades ease of learning, potentially creating a problem for
novice users.
> 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.
Yes, but with the option to reset it or set it manually - prefs.
> You seem to be misunderstanding the meaning of `pref'. Not all things
> stored in prefs.js are prefs.
> If a
> pref does not have an interface, it has Missed The Point Entirely
The fact if a pref has an UI or not doesn't change anything about its
existance. But let's focus this discussion on prefs UI, please.
> 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?
I don't think, prefs dialogs would change much about that. IMO, the real
problem is that computers are just a completely different world, and
many people have a problem to adapt.
Compare the task of transferring money using a physical or an internet
bank (including driving to the bank / starting the browser etc.). You
might say "But first, you need to learn, how to use a browser" - I
answer: "And you need to learn, how to drive a car, find a place to park
it etc."
IMO, computers really *simplify* things. Despite their shortcommings.
That's no reason not to simplify things further, but not with the cost
of making it harder to use for others.
Robert O'Callahan
> 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
I don't see why pref-checking code should have any significant impact on
memory requirements, startup time or speed.
I'm assuming that pref-checking code is being used to provide explicit
control over some decision that will otherwise be made by other means
("intelligent" choice or user feedback). (In other words, I do not
advocate adding hidden features accessible only through hidden prefs.) In
this case, the cost of checking for an explicit pref will be tiny compared
to the cost of making the decision in the normal way.
> usefulness:
> x opportunity cost
> x diminishing returns
Huh? The only impact on usefulness is that advanced users can now do
things they couldn't do before, if they really care to. Usefulness can
only be improved.
> reliability:
> x code development
> x code maintenance
> x quality assurance
> x geometric growth in combinations
None of these are affected if we follow my assumption above, and only
provide control over decisions that already need to be made in the code.
No new code paths are introduced; we just have the option of bypassing the
"intelligent choice" algorithm or the user feedback device and using some
preset decision instead.
In fact, debugging will be aided because by hardwiring these choices,
testers can determine if a bug is in the intellgent choice/user feedback
code, or in the code that implements the decision.
> 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
Support could well be improved, for the same reasons that debugging would
be easier.
> > 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.
I don't think those problems exist.
> >...
> > 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
You must be joking. The extensions system *crippled* the reliability of
MacOS. And the Mac resource system is slower and more space-hungry than
just hardcoding data into the binary. It also makes life very difficult
when Mac files try to interoperate with other file systems.
(I'm not saying they were bad ideas ... in most ways they were great
ideas, but they had a cost.)
> -- 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?
The Finder (along with MacOS itself) was designed for a degree of
customizability. That was achieved, and in a reasonable way so that
Resedit hacks don't make things run slower. (Adding extensions does make
everything run a little slower, but that's because they aren't implemented
in a particularly smart way.) BUT the Finder could have been designed to
be less customizable, and if it had been, I'm sure it would be faster,
less bloaty, etc.
Paul McGarry
mp...@student.canterbury.ac.nz (Matthew Thomas) wrote:
> 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.
What this actually shows is that there is that 'the one true way' does
not exist. If a group of users (who also happen to be the programmers)
disagree over a feature it is a fair indication that this may be true of users
generally. If this is the case then whichever option is chosen as the
default there will still be a fair number of users who are grateful that
it is an option and that they can change it.
> 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?
What I was really getting at is that any 'target audience' style
decisions which in any way limit functionality should be being
made at the end packager level. If you want to put together
a Mozilla distro that suits your familly then fine, but the core
Mozilla should be about exposing functionality and providing
potential.
If you look at Eazel's homepage they state that:
======
Our goal is to establish Linux as the desktop of choice for millions of
users. And we'll do it in a way that appeals to today's Linux users and
to mere mortals.
======
To me that sounds like a pretty good goal and one that Mozilla could
mimic. Making life easy for less experienced users does not have
to equate to taking functionality away from those who want it.
>> 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?
A good few less than it is ;) But if I couldn't make Mozilla behave
like I want it to then the fact that it fits on a floppy disk wouldn't
mean all that much to me either.
Paul
J. B. Moreno
<mp...@student.canterbury.ac.nz> wrote:
> Ben Bucksch wrote:
> >
> > Matthew Thomas wrote:
> > > * 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".
>
> If we have a pref to turn the dialog off, we won't get that GNKSA
> (section 16).
Not true.
From 4.5 Evaluation:
16) Try to prevent obvious user errors
[N] a) Warns when attempting to post empty articles M
[N] b) Refuses posting empty articles S
M=Must
S=SHOULD
Only need to satisfy all MUST to pass.
--
J. B. Moreno
Pessimist: Half empty Optimist: Half full Engineer: Wrong size glass
Karl Ove Hufthammer
news:090720002116442220%pl...@newsreaders.com...
| 16) Try to prevent obvious user errors
| [N] a) Warns when attempting to post empty articles M
| [N] b) Refuses posting empty articles S
|
| M=Must
| S=SHOULD
|
| Only need to satisfy all MUST to pass.
Though Mozilla *should* satisfy all SHOULDS.
Ben Bucksch
> | 16) Try to prevent obvious user errors
> | [N] a) Warns when attempting to post empty
> articles M
> | [N] b) Refuses posting empty
> articles S
> Though Mozilla *should* satisfy all SHOULDS.
>
IMO, this is a good example for a SHOULD requirement that Mozilla should
ignore. It makes no sense to me, for the reasons given in previous
posts.
Josh Harding
> Matthew Thomas wrote:
> > 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.
>
> If the programmers argued long enough and assuming they thought well
> about the problem, and they can still not agree, this is a hint that it
> should really be configurable. If they wouldn't care, they wouldn't have
> argued. If they care, users are likely to care as well.
So if your car manufacturer couldn't decide on what gear ratio to use for
third gear, they should make it a pref? So you wouldn't mind that every time
you had to go up a hill, you'd have to pull over, pop the hood a move some
gears around? and then change it back when you're driving on flat ground.
All because the designers couldn't agree on a good compromise.
Jerry Baker wrote:
> People have to be able to learn how to do things. You
> have to learn to drive a car, fly a plane, ride a bike, walk, swim, etc.
> If you cannot take the time to learn to use a computer, then don't. That
> is no less discriminatory than saying if you can't learn to drive a car,
> then don't.
I agree. However, all the rest of the activities you described do not include
a special 3 hour session on setting prefs. Even in your car, you only have a
few options (seat position, air temp, radio). Learning to use a web browser
should be as simple as teaching a person what a URL is and how to use the back
button.
The Amigo
Jerry Baker
>
> So if your car manufacturer couldn't decide on what gear ratio to use for
> third gear, they should make it a pref? So you wouldn't mind that every time
> you had to go up a hill, you'd have to pull over, pop the hood a move some
> gears around? and then change it back when you're driving on flat ground.
> All because the designers couldn't agree on a good compromise.
You are free to choose what gear you drive in. Removing prefs would be
more like having an automatic without the ability to manually use 1st,
2nd, 3rd, etc.
Ben Bucksch
> So if your car manufacturer couldn't decide on what gear ratio to use for
> third gear, they should make it a pref?
It *is* possible to adjust such things in cars. There are cars for which
you can adjust the automatic gears (right name?) (from the cab, not
under the hood or so). For some, you can even change it on-the-fly
between "sportive" and "economically".
Actually, in Europe, manual gears are the standard and widely used. Most
drivers just prefer to directly control the gears, because they think
they could be faster or just because it makes more fun.
> Learning to use a web browser should be as simple as teaching
> a person what a URL is and how to use the back button.
Wrong. Driving is not just steering and using the gears. You need to
know how fast your car can break or run through curves. You have to know
the laws and how to drive safely.
Similarly, you need to know the internet technology, current usage
patterns and how to protect yourself (e.g. from privacy-intrusing
companies) and others (e.g. not to send the MSWord files).
Josh Harding
> Matthew Thomas wrote:
> > 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
Note that "x" does not indicate an issue that is worsened, only that TweakMoz
wouldn't do anything to help the situation.
> > 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
>
> I don't see why pref-checking code should have any significant impact on
> memory requirements, startup time or speed.
It's just that if some of the prefs only have a UI in TweakMoz, then the speed
of the product is no faster than it was before... same speed, startup time,
memory. Putting advanced prefs in a separate UI doesn't improve any of those
areas.
> > usefulness:
> > x opportunity cost
> > x diminishing returns
>
> Huh? The only impact on usefulness is that advanced users can now do
> things they couldn't do before, if they really care to. Usefulness can
> only be improved.
Same as above... they aren't worsened, just not improved. For advanced users,
it's just as usable as having all the prefs in one place... we don't mind
having a separate thing to click on to access the advanced prefs.
> > reliability:
> > x code development
> > x code maintenance
> > x quality assurance
> > x geometric growth in combinations
>
> None of these are affected if we follow my assumption above, and only
> provide control over decisions that already need to be made in the code.
Exactly... the "x" means not affected.
The Amigo
Matthew Thomas
>
> Matthew Thomas wrote:
> > 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.
>
> settings adds no bloat???
No, the bloat argument only applies to those cases where no detection
algorithm is necessary.
> > > Should we send it immadiately or delay it (maybe until the user
> > > opens a connection and exchanges data)?
> >
> > Depends whether the user is in offline mode or not. Thanks to the
> > little online/offline button in the status bar, this does not
> > require a pref.
>
> So how does that online/offline button "know" when a user is connected
> or not? You cannot rely on users to press that every time they hang up
> the modem and again when they dial in.
If the user puts Mozilla in online mode, they are indicating either that
their computer is on line, or that they don't mind going on line when
needed. If they don't want to go on line, they put Mozilla into offline
mode. Surely that's what that button is for in the first place.
Josh Harding
> Josh Harding wrote:
> >
> > So if your car manufacturer couldn't decide on what gear ratio to use for
> > third gear, they should make it a pref? So you wouldn't mind that every time
> > you had to go up a hill, you'd have to pull over, pop the hood a move some
> > gears around? and then change it back when you're driving on flat ground.
> > All because the designers couldn't agree on a good compromise.
>
> Gears are made as prefs in a way. There is not one gear, but several.
> You are free to choose what gear you drive in. Removing prefs would be
> more like having an automatic without the ability to manually use 1st,
> 2nd, 3rd, etc.
You missed the point on this. I'll try for a simpler example: Say they can't
decide how fast to make the turn signal blink... one engineer says it should have a
.9 sec interval and another says 1.1 seconds. They can't agree so instead they put
in a knob so that you can adjust it. *You* may actually like this, but most people
don't want the extra clutter on the dashboard... they just want the turn signal to
blink and don't care if it's .9 or 1.1 seconds. The same holds true for things
like how bright should each individual light be, what interval of tick marks should
be on the speedometer, how far apart should the pedals be, etc... if all of these
were prefs, your car would look like an airplane cockpit and that's not what *most
people* want.
The Amigo
Matthew Thomas
>
> Matthew Thomas wrote:
> >
>...
> > > That was my point exactly. No pref = no choice. A programmer made
> > > a choice for me.
> >
> > Every line of code a programmer writes is them making a choice for
> > you. The only difference is in the extent.
>
> This is true, and the more prefs you take away from me the further you
> exacerbate this.
Well hey, that's easily solved. Just rewrite Mozilla in a programming
language which doesn't allow the use of constants.
>...
> > They don't have to wait anyway. In by far the majority of cases
> > where you make a DNS request, it is to access content you are
> > actively waiting for (such as a Web page). And in that case, users
> > will press the Stop button long before a minute is up.
>
> If you do this in 4.X, Netscape will cease to function properly. All
> subsequent DNS lookups will be on hold until the timeout expires
> anyway. While this bug may not currently exist in Mozilla, it is
> possible.
So instead of fixing the bug, we should introduce a pref? Yeah, sure.
> > > It should not be a dialog, it should be a choice that is
> > > permanent.
> >
> > Why? If you could turn the cross-folders option off, you'd need some
> > sort of feedback anyway -- when you pressed the space bar at the end
> > of the last message -- to tell you that there were no more unread
> > messages to go to in that folder. This dialog provides that feedback
> > already, with the added bonus of allowing you to go to unread
> > messages in other folders (if such messages exist).
>
> I don't want a dialog telling me that I have reached the last message
> in a group either. I can tell that when it says 0 unread messages that
> there are no more. Similarly, when "Next Unread" message fails to
> advance, I kind of get the idea.
Well if you can tell that when it says 0 unread messages that there are
no more, then you're never going to click the `Next Unread' button when
there aren't any more unread messages. So whether or not there is a
dialog is none of your concern, since you'll never see it anyway.
[Netlib versus Gecko]
>
> > Ok, now you've got me curious. What do *you* load HTML/XML content
> > for most of the time? Just for kicks, to see how fast your
> > connection is, and not to read it, huh?
>
> Sometimes that is exactly what I am doing. Just becasue I don't do it
> most of the time does not mean I should never be able to do it.
Just because it's possible for you to drive your car entirely in first
gear doesn't mean that your car should have a pref to behave optimally
if you do.
>...
> Most of those prefs have nothing to do with chrome, but cooler things.
> I can set how many simultaneous network connections Netscape opens,
Even for users who would know what that was for, determining the optimum
number would be practically impossible. (Hmm, well it *seems* faster
with this setting, but maybe I've just gone on line at a quiet time ...)
> whether I want to allow the blink tag to blink or not,
Three words: user style sheet.
> turn of referer
> headers,
That reminds me of a discussion I saw where iCab was being criticized
for having a pref for notifying the user for every HTTP result except
(IIRC) 200 OK and 304 Not Modified. Webmasters were receiving complaints
about Web servers returning 301 Moved Permanently and 307 Temporary
Redirect `errors', when these weren't errors at all.
`Load without referring header' would be a useful hypertext link to
include in the `Document Info' window, but to make it a pref is just
asking for trouble.
> whether to thread news messages by subject or reference
> header only,
You only need that when the threading algorithm is broken to start with,
as it is in 4.x <http://www.jwz.org/doc/threading.html>.
>...
> > Because that's an incredibly rare edge case. Is it really so hard to
> > write `AIM' in the subject, and press Enter one extra time when
> > sending the message? Surely not.
>
> Why go through the extra work to require me to do that? having all
> these dialogs pop up here and there, and removing prefs is akin to
> passing laws to protect me from myself. It is highly annoying.
That's the whole point of the GNKSA in the first place, to protect you
from yourself -- or, more precisely, to protect you from others who will
flame you if you do something stupid.
> > Soon, Mozilla won't let you delete an entire address book without a
> > dialog popping up first. And the dialog will not be optional. I'm
> > grieving in advance for the inconvenience this is going to cause
> > you. Not.
>
> That won't matter because I would just do it from my file manager if
> Mozilla was annoying about it.
But it would be quicker to do from Mozilla than from your file manager,
even with a dialog, and you know it.
<...
> Infact, I contacted Volkswagen of America yesterday because my 2000
> Jetta does not have a cigarette lighter. The option to put one in, I
> was told, is as easy as buying the little guy to plug into the socket.
> But, when I went to do it, I was informed that it would cost me $100+
> to have the little socket cover removed. That made me angry enough to
> contemplate driving the car through the plate glass at the dealership
> - just as it would in a browser.
>
>...
>
> > So you'd rather the unwashed masses were stuck with AOL or Netscape
> > 6? Well, I mean, really. Have you no compassion at all? :-)
>
> That is exactly what I would prefer.
Oh, get away with you. You disgust me.
Ben Bucksch
> Well hey, that's easily solved. Just rewrite Mozilla in a programming
> language which doesn't allow the use of constants.
Sorry for my ignorance, but I don't know of such a language, nor do I
know how it could work, as constants are inherent to many expressions.
Anyhow, how would this data be stored then? In a resource file or so?
One that the user can modify?
> So instead of fixing the bug, we should introduce a pref? Yeah, sure.
If we would try to ship a perfect product that removes all theoretically
unnecessary user input, we wouldn't ship before 2005. Sad, but true.
Apart from that, hidden prefs are an elegant way to workaround bugs. It
is not unwise to add hidden prefs where you *suspect* bugs (e.g. for
"smart" algorithms, new features or security-relevant functions). If you
actually discover a bad bug, you can instantly offer a workaround, even
for installed products.
> Well if you can tell that when it says 0 unread messages that there are
> no more, then you're never going to click the `Next Unread' button when
> there aren't any more unread messages.
I might not have clicked the button, but just pressed SPACE, which also
scrolls down, if possible (and goes to next unread, if not, which is a
good idea IMO).
> > turn of referer headers
>
> That reminds me of a discussion I saw where iCab was being criticized
> for having a pref for notifying the user for every HTTP result except
> (IIRC) 200 OK and 304 Not Modified.
Unrelated.
> `Load without referring header' would be a useful hypertext link to
> include in the `Document Info' window, but to make it a pref is just
> asking for trouble.
The referrer header *itself* is just asking for trouble, disabling it is
just the right thing to do.
> That's the whole point of the GNKSA in the first place, to protect you
> from yourself -- or, more precisely, to protect you from others who will
> flame you if you do something stupid.
Yeah, but in this case, he knows exactly what he does. But the stupid
software warns him nevertheless, without giving him the option to tell
it "Shut up. I know.".
Jerry Baker
You do not have to look at the preferences while you "drive" Mozilla, so
the cockpit analogy still doesn't hold water. If all these settings were
in a little compartment marked "settings", I don't think anyone would
mind.
Jerry Baker
>
> > I don't want a dialog telling me that I have reached the last message
> > in a group either. I can tell that when it says 0 unread messages that
> > there are no more. Similarly, when "Next Unread" message fails to
> > advance, I kind of get the idea.
>
> Well if you can tell that when it says 0 unread messages that there are
> no more, then you're never going to click the `Next Unread' button when
> there aren't any more unread messages. So whether or not there is a
> dialog is none of your concern, since you'll never see it anyway.
I frequently use "N" or the space bar. When it gets to the end, these
keys have no effect. I then press "G" if I want to go on, or if I don't,
I do nothing. Answering a dialog each time would be annoying.
> > Sometimes that is exactly what I am doing. Just becasue I don't do it
> > most of the time does not mean I should never be able to do it.
>
> Just because it's possible for you to drive your car entirely in first
> gear doesn't mean that your car should have a pref to behave optimally
> if you do.
That there is a first gear that I can choose to drive in if I wish *is*
a pref. The car does not automatically shift because it knows I must be
mistaken for driving in first.
> Even for users who would know what that was for, determining the optimum
> number would be practically impossible. (Hmm, well it *seems* faster
> with this setting, but maybe I've just gone on line at a quiet time ...)
When the setting has to be there, either coded into the program, or read
as a pref, why not offer it as a pref. It has the potential to speed
things up for people on fast connections. I wouldn't want Mozilla dumbed
down in the speed department just because not everyone has 10Mbps.
> `Load without referring header' would be a useful hypertext link to
> include in the `Document Info' window, but to make it a pref is just
> asking for trouble.
Actually, I think the HTTP 1.1 spec requires it.
> > whether to thread news messages by subject or reference
> > header only,
>
> You only need that when the threading algorithm is broken to start with,
> as it is in 4.x <http://www.jwz.org/doc/threading.html>.
JWZ suggests threading messages with the same subject line, but no
References or In-Reply-To headers. This is my biggest pet-peeve with
NN4's mail and news. If it wasn't threaded by the application that
posted it, then don't thread it for me.
> > That won't matter because I would just do it from my file manager if
> > Mozilla was annoying about it.
>
> But it would be quicker to do from Mozilla than from your file manager,
> even with a dialog, and you know it.
I don't care if it takes a little longer. It won't annoy me about it. If
something is not annoying done with method #1, and it is faster with
method #2 but very annoying, most will probably use method #1.
> > > So you'd rather the unwashed masses were stuck with AOL or Netscape
> > > 6? Well, I mean, really. Have you no compassion at all? :-)
> >
> > That is exactly what I would prefer.
>
> Oh, get away with you. You disgust me.
Why, because I think advanced users deserve a browser that they find
usable just as neophytes do? Why make all the browsers aimed at
"newbies"? Can't advanced users have just one? Is that alright with you?
Jerry Baker
>
> If the user puts Mozilla in online mode, they are indicating either that
> their computer is on line, or that they don't mind going on line when
> needed. If they don't want to go on line, they put Mozilla into offline
> mode. Surely that's what that button is for in the first place.
That's how it works in NN4 now.
John De Hoog
>I frequently use "N" or the space bar. When it gets to the end, these
>keys have no effect. I then press "G" if I want to go on, or if I don't,
>I do nothing. Answering a dialog each time would be annoying.
I do the same, and similarly find the Netscape Communicator 4.x dialog
annoying. I sincerely hope Mozilla will make it simple to
keyboard-navigate through *all* unread messages/articles in all
folders and accounts. Apart from the dialog, this was a good feature
of Communicator mail/news, not shared by many of its rivals. In
particular, the ability to keep spacebar-scrolling even though HTML
messages is one that only Communicator can boast of. (Though as I
recall, it only works from top-to-bottom in the folder tree. It should
go back up to the top looking for more, since "up" and "down" are not
very meaningful in this context.)
"There is no up or down in space (bar navigation)."
--
John De Hoog, Tokyo
http://dehoog.org
Matthew Thomas
>
> Matthew Thomas wrote:
> > * Three different settings for default `Character Coding'
>
> I don't know enough about I18N to comment here. But I do know that
> non-western developers/users have to fight hard for usability.
I'm well aware of that
<http://bugzilla.mozilla.org/show_bug.cgi?id=10999>.
> > * `Enable address auto-completion' -- if implemented properly,
> > there's no good reason to turn this off.
>
> I guess, there are people who really don't like those "smart"
> features.
Only, I would suggest, when they behave badly
<http://bugzilla.mozilla.org/show_bug.cgi?id=42796>.
>...
> > That depends on whether users can understand the pref or not. If
> > not, the programmers might as well have tossed a coin instead.
>
> The user that do care understand and need it. Others please ignore it
> :).
Where a more or less perfect user interface design allows you to say
`please' to a greater or lesser extent. :-)
> > > Please note, that e.g. the smily recognition was *not* invented by
> > > myself, nor initally implemented in Mozilla by myself.
> >
> > Who wrote the initial implementation? Not a Netscape person, surely.
>
> Oh yes, a Netscape employee.
[sobs, bangs head against screen] And to think they could have been
working on LDAP support instead ...
> Guess what? Netscape plans to remove the conversion prefs UI entirely
> (which is OK with me), and wants to default smily conversion (which
> alters content) to on, but structured phrases conversion to off.
> Reason: The first one "is cute", while the latter one might confuse
> users. I wonder how they are supposed to understand the stars around
> the words then, as they are there anyway, the recognition is only
> there to help them understand the stars.
You see? You see? An object lesson of how, if Mozilla has an
overabundance of options, commercial distributors can *not* be relied on
to do a decent job of simplifying it to be used by ordinary humans.
Netscape Messenger, which has traditionally been used heavily by
businesses, will now be used only by those in the 6~15 demographic, and
by those with a moderate-to-high cheesiness threshold.
And I am not looking forward to having to explain this to those in
<news:alt.ascii-art> once I return to update their FAQ, either. It'll
almost be enough to make them go back to Outlook Express (its bogus
conversion of `//' to `file://' notwithstanding).
Them: `Dammit, we trusted you! And now look at these smileys all over
the place!'
Me: `Well, you can turn it off, just change this line in prefs.js ...'
Them: `But it says, "Do Not Edit".'
Me: `Uh, just ignore that.'
Them: `Ok, I tried it, it didn't work.'
Me: `Um ... did you quit Netscape *before* you edited prefs.js?'
Them: `Oh, never mind, I'm sick of this, I'm using Forte Free Agent
instead.'
> BTW: smily recognition is an established feature of IM clients for
> quite some time.
In instant messaging, vertical alignment of plain text (as disrupted by
graphical smileys) is not an issue. And on the flip side, in instant
messaging, expression of emotion is much more of an issue. (The
importance of expression of emotion increases as the immediacy of the
communication increases: smileys are used hardly ever in paper mail, a
fair bit in e-mail, and a lot in instant messaging.)
>...
> > except when you ram that
> > conversion down non-Mozilla recipients' throats with HTML messages
> > composed in Mozilla (which is the default, so you can't accuse the
> > user of agreeing to it).
>
> I got so enough negative feedback that I have been convinced that this
> might not be a good idea to default to "on" and intend to change the
> default to "off". Just waiting for approval.
That's great. By the way, Ben, I've been meaning to file a bug: the
conversion prefs have tooltips, and none of the other prefs do. The
tooltips don't add much anyway (they're less comprehensible than the
text itself), so I suggest you remove them.
>...
> > I just know that many of those organizations producing custom
> > versions of Mozilla won't be clueful enough to simplify it from the
> > default version.
>
> I bet that if you created a good alternative to the current packages,
> mozilla.org would be happy to include your version into the
> respository and let you "advertize" it on www.mozilla.org. So, if a
> company would really look for a browser or "internet suite" with a
> simplified interface, it could get "your" packages.
That's an interesting idea. Maybe that's how Alphanumerica plans to make
money from their implementation of Aphrodite: produce custom versions
for those organizations which want to use Mozilla, but which don't want
to have to employ an in-house support person to answer all the users'
questions about the multitudinous options. :-)
>...
> Again: Prefs don't blow the app. It's reinventing the wheel which does
> this (but that's a dead snake).
>
> No, not even the code for the almost all prefs has substantial
> influence on the weight.
Ok, you're a programmer and I'm not, so I guess I'll have to take your
word for that.
> > If you want to visit the mountains, mount an expedition (compile
> > your own version with all the bells and whistles).
>
> I think, you are *seriously* underestimating the amount of users which
> want to control details of their most-used apps. I would guess that at
> least 5% of users would complain about each and every pref you remove
> (but different groups for different prefs of course). 5% are still
> several millons.
Ok, let's assume that we have the perfect user interface design -- in
prefs, as in everything else. Deep prefs hierarchy, whatever.
Then, with all other factors (marketing, price, ease of distribution,
etc) held constant, we vary the number of prefs. As we add each pref, we
attract some number of additional users, like this:
No. of users attracted
A
| __,----'"""""
| ,-''
| ,'
| /
| /
|/
+-----------------------> No. of prefs
At the same time, every time we add a pref, the increased complexity
(even with the perfect UI design) drives some users away. These are the
people who use MS Works because it's simpler than MS Office, or who use
Mac OS because it's simpler than Windows. This number doesn't rise as
fast as the number of users attracted, because complexity of interface
doesn't increase as fast as the number of options (since an `Advanced
...' button, or a deep prefs hierarchy branch, can each hide more than
one option).
No. of users driven away
A
|
|
| ___,.---
| _,--'"
| _,-'
| _,-'
+'----------------------> No. of prefs
These two graphs aren't necessarily to scale with each other, but that
doesn't matter. It's the general shape which is important -- the second
one starts out climbing slower than the first, but ends up climbing faster.
To get the total number of users of Mozilla, fairly obviously you take
the number of users attracted, and subtract the number of users driven
away. You end up with a graph like this:
Total number of users
A
|
| ,---.
| ,' `.
| / `-..___
| / `""`
|/
+-----------------------> No. of prefs
Now, I'm not good enough at statistics to be able to tell whether that's
a Poisson distribution, or a chi-squared distribution, or what it is.
But the important thing is that there is some optimal number of prefs we
should expose in the interface, and that number is right about ...
Total number of users
A
| |
| ,-|-.
| ,' | `.
| / | `-..___
| / | `""`
|/ |
+-------|---------------> No. of prefs
|
... here.
Any more than that, and you start losing more users than you're gaining.
>...
> > If you're lucky, you eventually work out that clicking the tiny
> > triangle next to the word `Advanced' does something different from
> > clicking the word `Advanced' itself (truly bizarre behavior,
> > inherited from 4.x).
>
> It might make sense to automatically expand the subcategories.
`Clicking on an item with a twisty should select that item AND expand
it's twisty to make it obvious that there is more stuff. So that kind of
helps with the discoverability issue'
<http://mozilla.org/mailnews/specs/prefs/Preferences2.html>.
It's the `kind of' there which makes me think Netscape haven't paid that
much attention to the usability of the prefs dialog.
> But using a tree widget is basic computer knowledge today - I know no
> (non-Netscape/Mozilla) tree widgets which automatically expands
> subcategories that way.
* Internet Explorer's History bar
* Internet Explorer's Bookmarks bar
* iCab's preferences dialog
These are interfaces which are built without the *requirement* that
branches (as well as leaves) contain content, such as happens in file
managers (where folders can contain files as well as other folders).
File managers can't really escape the necessity for that poor UI; but we can.
>...
> What I consider important is that
> - the user ignored irrelevant panels, both on the main level and
> second level
> - the user understands the concept of a hierarchy (Navigator->Proxies
> or General->Connection->Proxies)
The deeper the hierarchy, the greater the number of clicks, the greater
the chance that people won't bother to use a deeply hidden pref, the
lesser the marginal utility (economics-speak) of the pref.
>...
> That's all I mean with the Deep Prefs Hierarchy proposal. I guess, I
> should just go ahead and make a concrete proposal.
I'd be interested to see (a) what the ontology of your proposal would
be, and (b) what sort of prefs you'd fill it up with.
>...
> IMO, there should be a "General" panel, which contains a "Appearance"
> subpanel. But there should also be an "Appearance" subpanel under
> Mailnews, because Mailnews has additional viewing orefs that just
> don't make sense for Navigator. Just make sure that the wording (e.g.
> both are named "Appearance") is identical.
>...
Tardis's `Display' category, in theory, covers display of content in
general -- whether that be text/plain, text/html, text/xml, or
message/rfc-822. But it contains hardly any prefs for viewing messages
(though that's going to change soon), mainly because for most of those
particular prefs, you're likely to want to change them quickly and
temporarily -- so they belong in the app menus, rather than the prefs
dialog. (Examples: view brief/normal/full headers, show attachments
inline/as links, use which style sheet, smiley detection on/off).
Even more fun is what happens once Mozilla gets split into separate
apps. Then we'll probably have one dialog for the `Display' category,
and one dialog for each app, containing the app-specific categories.
That's something I'll be doing in the next rev of the Tardis design.
The other option would be to rely on apps to add and subtract their
prefs from the global prefs dialog when installed/uninstalled, like
KDE's Panel does (IIRC). But that one-size-fits-all approach would tend
to suffer from many of the same usability problems as the Web does:
* too many initial possibilities {URLs | apps}
* consistent global interface {browser chrome | prefs window} leading to
over-expectations about consistent specific interfaces {Web pages |
prefs panels}
* trying to wangle everything into the same interface format {HTML |
fixed-size panel}
* too much distraction from navigation features {other app's prefs |
Back button and bookmarks}.
Ben Bucksch
> > > > So you'd rather the unwashed masses were stuck with AOL or Netscape
> > > > 6? Well, I mean, really. Have you no compassion at all? :-)
> Why, because I think advanced users deserve a browser that they find
> usable just as neophytes do? Why make all the browsers aimed at
> "newbies"? Can't advanced users have just one? Is that alright with you?
*All* users should have a real (i.e. well-done) open-source alternative.
BTW: The topic is far away from .mail-news now. Please remove .mail-news
where appropriate (i.e. nearly everywhere).
Matthew Thomas
>...
> [You pretty much agreed on the necessarily of each pref category I
> mentioned. So you just disagree with the amount of prefs?]
I can explain that in two ways:
(1) You pick the ones which are hard to remove, I pick the ones which
are easy to remove.
(2) Mozilla now has about the right number of prefs now, for its current
sub-optimal prefs interface -- I'm just firing a pre-emptive strike
against those who want more prefs without redesigning the prefs
dialog first. :-)
> > development complexity can simultaneously be
> > decreased by the resultant knowledge that some combinations of
> > variables will now never occur.
>
> If autodetecting reduces the amount of combinations, then I guess,
> anything was or is flawed. Do you have an example?
This is hard for me since I'm not a programmer. But let's take Jerry's
example of the number of simultaneous network connections. For all
previous versions of Netscape, that number has been 4; early versions
exposed it as a pref in the interface, later versions didn't. In IE, on
the other hand, that number is 3, and I don't think it's ever been
exposed in the interface (it's probably a registry value or something).
We could probably replace that with a function which takes two arguments:
* the proportion of time currently open connections have been stalled
in the past /n/ seconds (positive effect on function result)
* the number of currently open connections (negative effect on function
result).
If the result of the function is greater than someConstant, and we need
a new connection for anything, then we open one. If not, we wait.
That would probably eliminate the necessity to provide so much feedback
to entertain the user when nothing was happening, because nothing would
be less likely to ever happen (so to speak).
>...
> > So why do you think the free market dictates that Mozilla is
> > similarly over-complex?
>
> Not over-complex. But as complex as the environment it is made for.
> There is demand for a internet applications that are very
> configurable. This demand has been served by Netscape, now Mozilla.
> Where do you want to send these users otherwise?
To Mozilla Professional Edition?
>...
> To come back to your evil world: It gives you "choices". You can go
> either to MSN or AOL. But none does what you want.
Funnily enough (and I'll probably get flamed to Alpha Centauri and back
for saying this), Internet Explorer does what I want. And it would do so
even if you blew the `Advanced' tab of its preferences dialog away
completely. Standards compliance? I don't care, I'm not on the cutting
edge of Web design, and there are `enough' sites out there already. Size
and speed? Assuming its integration with Windows, IE's problems in both
those areas get hidden. Integration between browsing, e-mail, and IM?
Whatever. I'd actually rather crashing my browser *didn't* bring down my
e-mail program, actually.
But using IE is like hard drugs or unprotected sex: fun for a while, but
eventually the backlash occurs. Eventually I have no choice but to use
Windows. Eventually every business knows who I am, because IE doesn't
give me the gory details about cookies
<http://bugzilla.mozilla.org/show_bug.cgi?id=44581> -- and I am cosseted
into my own little world where every advertisement is just right, my
view of the Web becomes different from everyone else's without my
realizing, and I get disconnected from my fellow travellers on the Web
<http://www.hewett.norfolk.sch.uk/curric/soc/crime/anomie.htm>.
Eventually the number of useful Web sites starts declining, because
producing content which renders acceptably in IE's half-baked CSS
becomes just too difficult. And so on, and so on, and so on.
*They*'re the things that open source is excellent at fixing. The
trouble is that when it comes to configurability versus ease of use,
open source doesn't know when to stop.
>...
> > > If we do so, what is more important: the look or the information?
> >
> > Neither. I can't think of any major conflict that would exist
> > between the two
>
> There are lots. Examples:
>
> <title>: Show or not?
You shouldn't be able to specify a TITLE for an e-mail message anyway.
What use could it possibly be?
See my recent post in n.p.m.editor about using an `Editor Lite' for
Messenger, which has font and paragraph styles, but not the more
Web-site-oriented stuff (like TITLE and META and LINK).
> <b>foo</b> -> *foo*
> <code>foo</code> -> |foo|
Ah, I see. There you would go for content, rather than formatting,
because (a) changing the content could cause much more serious
misunderstandings than changing the formatting (not to mention violating
the GNKSA), and (b) the user would know what to do if confronted with
that option anyway. (How would you word such a pref, if it existed?)
> <h4>foo</h4> -> 3.2.1.4. foo
> (I don't see a away to unambiguously show the header level with
> indention or so. Also, it needs to stand out from indented one-line
> paragraphs. Such combinations do appear in reality, at least in my
> documents.)
That's a quirk of HTML -- that heading levels are (a) limited to 6, (b)
disconnected from lists, and (c) disconnected across pages (so that
using H1 on an index page doesn't automatically mean that I start at H2
on pages `below' it in the site).
> > In an ideal system, the user shouldn't have to care where it goes,
> > because OS file retrieval functions would be good enough not to need
> > a folder-based system.
>
> (I do like to organize things hierarchical.)
Me too. But only because neither of us use an ideal system.
> > > > `You haven't typed
> > > > anything, and there are no attachments. Send anyway?'
> >
> > If we have a pref to turn the dialog off, we won't get that GNKSA
> > (section 16).
>
> Why? I argue that requiring to turn a pref off is enough of a warning.
I've reread the GNKSA, and I see nothing about allowing the user to turn
the warning off. As far as I can tell, if we offered that option, we'd
be in breach.
> The next sentence says that a UA may allow the user to ignore the
> warning.
Yes, ignoring the warning is what you do when you press Enter after the
dialog pops up.
> > First you need to explain what on earth requesting bookmark icons
> > could possibly have to do with your privacy.
>
> The content provides knows
> - that
> - when
> - propably also because of which page
> I bookmarked the site.
>...
Ah. I didn't realize it was only requested during a bookmarking
operation. And I don't see why that should be the case. Why couldn't it
be automatically loaded (and cached) for every page visit, like a style
sheet is? That way we could use it in the Back/Forward/Go menus, as well
as in the bookmarks.
Matthew Thomas
>
> Matthew Thomas wrote:
> >
> > cease to be a pref?
>
> Hard-coding not good.
Why does that sound like a reflexive mantra (`four legs good, two legs
bad'), rather than a considered opinion? Hard-coding not good. Usability
testing is futile. You will be obfuscated.
Would you like a pref for the proportion of the width of the sidebar
which the sidebar's tabs take up (more width == more room for the
sidebar title, but less obviousness about what the tab widget does)?
How about a pref for the image selection highlighting style
<http://bugzilla.mozilla.org/show_bug.cgi?id=14835>?
How about a pref for the exact amount of time which the menu title in
the Mac menu bar flashes when you type the keyboard shortcut for an item
which is in that menu <http://www.quinn.echidna.id.au/Quinn/WWW/HISubtleties/AnarchieMenuFeedback.html>?
Where do you want to stop?
>...
> [Cutting heavily:]
> > > How long should Mozilla wait before timing out on a DNS request?
> > One minute.
> > > Should the "Next Unread" message button cross folders?
> > It should be a dialog as it is in 4.x.
> > > How often should Composer save a backup of the file your working
> > > on?
> > In the ideal operating environment, that would not be the case,
> > and Mozilla would be able to save a backup every 30 seconds.
>
> Matthew, please. You are trying to hardcode /your opinion/. There is a
> reason why these things are prefs: others disagreed.
Let's dispel that myth once and for all. /My opinion/ -- that is, the
settings which would best suit me -- would be this:
* DNS timeout is 10 seconds.
* Next Unread *always* crosses folders, with no dialog.
* Composer saves a backup every five minutes.
Not the same as the behaviors I gave above, are they? Not even close. So
yes, I would be a bit put off by the difference between my preferred
behavior and Mozilla's behavior, because Mozilla would be aiming to the
greatest possible number of users, and I'm far from average.
But I know that where Mozilla is on the wrong side of the curve, as
configurability decreases, the number of users who can understand the
interface will *increase*, and so the number of users of Mozilla will
increase. And no matter how talented anyone thinks I am :-P, I know that
the net benefit to the world from those thousands of extra Mozilla users
will far outweigh the slight loss to the world from the smaller time
*I*'ll spend using the Internet because I don't have the ability to
configure things exactly the way I'd like.
>...
> > 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?
>
> I don't think, prefs dialogs would change much about that. IMO, the
> real problem is that computers are just a completely different world,
> and many people have a problem to adapt.
You seem to take it as a /fait accompli/ that computers are `a
completely different world', which is a shame. We don't accept that
telephones are `a completely different world', or microwave ovens, or
clock radios.
(Just as a side note, /fait accompli/ shows why -- in struct-to-HTML
conversion -- you should convert /abc/ to <i class="whatever">abc</i>,
and not to <em class="whatever">fait accompli</em>: because /abc/
indicates not emphasis, but italics in general. In this case, the
italics are <span lang="something"></span>, but you can never know
whether it will be SPAN or EM or CITE or VAR which is intended in any
given case.)
> Compare the task of transferring money using a physical or an internet
> bank (including driving to the bank / starting the browser etc.). You
> might say "But first, you need to learn, how to use a browser" - I
> answer: "And you need to learn, how to drive a car, find a place to
> park it etc."
>...
I don't know about you, but I think it would be great if I could just
tell the car where I wanted to go, and it would drive there (and park)
for me. I'd be able to do more useful stuff during the journey, instead
of driving ...
Stuff like surfing the Web, for example. :-)
Matthew Thomas
>...
> mp...@student.canterbury.ac.nz (Matthew Thomas) wrote:
> >
> > 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.
>
> not exist. If a group of users (who also happen to be the programmers)
> disagree over a feature it is a fair indication that this may be true
> of users generally.
More likely, it shows that the programmers didn't say `well, ok, let's
test each approach in the usability lab, and find out which works best'
<http://www.asktog.com/columns/037TestOrElse.html>.
I wish I had such a lab at my disposal -- then I could stop saying `I
think' all the time; I could start saying `I know', and give the
relevant numbers.
As it is, the only equivalent to usability testing which open-source
projects tend to get is people whining in the newsgroups `why doesn't
Mozilla do X?'. But because they don't want to appear clueless, people
don't tend to whine that `I don't understand Y', or `I keep clicking Z
by mistake', or whatever.
>...
> If you look at Eazel's homepage they state that:
> ======
> Our goal is to establish Linux as the desktop of choice for millions
> of users. And we'll do it in a way that appeals to today's Linux users
> and to mere mortals.
> ======
> To me that sounds like a pretty good goal and one that Mozilla could
> mimic. Making life easy for less experienced users does not have
> to equate to taking functionality away from those who want it.
>...
Yeah, but you just watch the excrement hit the air-conditioning as Eazel
tries to actually *deliver* on that goal.
Ben Bucksch
> (2) Mozilla now has about the right number of prefs now, for its current
> sub-optimal prefs interface -- I'm just firing a pre-emptive strike
> against those who want more prefs without redesigning the prefs
> dialog first. :-)
I mostly agree with you here. I even think, Mozilla's prefs are already
too bad to be shipped in this state and have to be reorganized one way
or the other (at the very least, the "Advanced" panel has to go).
I just think that it is possible to create a "scalable" pref
infrastructure, one with which we can theoretically add more prefs
without scaring away new users (at least not more than we do today,
better less).
> > If autodetecting reduces the amount of combinations, then I guess,
> > anything was or is flawed. Do you have an example?
>
> This is hard for me since I'm not a programmer. But let's take Jerry's
> example of the number of simultaneous network connections.
You spoke of *combinations". If you can reduce the amount of
combinations (i.e. different setting-scenarios of several prefs), then
you either had too many prefs before (not orthogonal) or your
autodection is flawed in that it never creates valid combinations. Or
are there other possibilities?
> Mozilla Professional Edition?
OK with me (assuming we can't resolve the problems)
> See my recent post in n.p.m.editor about using an `Editor Lite' for
> Messenger, which has font and paragraph styles, but not the more
> Web-site-oriented stuff (like TITLE and META and LINK).
OFFTOPIC: You can propably drop the <head> part entirely for msgs, as
they have their own headers. You do need <link> (in fact, a lot), and
propably everything else (structural) in the <body> section.
> > <b>foo</b> -> *foo*
> There you would go for content, rather than formatting,
I agree, somebody else (actually, not only theoretically) doesn't.
> That's a quirk of HTML -- that heading levels are (a) limited to 6, (b)
> disconnected from lists, and (c) disconnected across pages (so that
> using H1 on an index page doesn't automatically mean that I start at H2
> on pages `below' it in the site).
OFFTOPIC: Completely agreed. This bugs me about HTML as well. I think,
this and the abuse of HTML are the reasons, why all this WAP/WML stuff
has been invented in the first place :-(.
> > (I do like to organize things hierarchical.)
>
> Me too. But only because neither of us use an ideal system.
OFFTOPIC: No. I like to organize things hierarchical independant from
any technology. Just using *only* *one* hierarchy for *everything*
doesn't always work well (but propably better than other primitive
alternatives).
> Why couldn't it
> be automatically loaded (and cached) for every page visit, like a style
> sheet is? That way we could use it in the Back/Forward/Go menus, as well
> as in the bookmarks.
OFFTOPIC: Nice idea. I don't want to support this flawed "protocol", but
after being worked out by a standards gremium, we could use it in this
way.
But preffable :-), as it causes traffic, which might cost money. Good
example for a high-level pref: "I pay per time" - "I pay per traffic" -
"I don't care about traffic".
Ben Bucksch
> Ben Bucksch wrote:
> > Hard-coding not good.
>
> Why does that sound like a reflexive mantra (`four legs good, two legs
> bad'), rather than a considered opinion?
<http://www.tf.hut.fi/cgi-bin/jargon?search=hardcoded>. See also
<http://www.tf.hut.fi/cgi-bin/jargon?search=magic+number>, Usage 1.
> Usability testing is futile. You will be obfuscated.
Please, let's not start about usability testing :-/.
> Would you like a pref for the proportion of the width of the sidebar
> which the sidebar's tabs take up (more width == more room for the
> sidebar title, but less obviousness about what the tab widget does)?
Using XUL/CSS means some kind of configurability (assuming it's defined
there).
> How about a pref for the exact amount of time which the menu title in
> the Mac menu bar flashes when you type the keyboard shortcut for an item
> which is in that menu <http://www.quinn.echidna.id.au/Quinn/WWW/HISubtleties/AnarchieMenuFeedback.html>?
Yes, I would want to have such a pref, if I worked on Mac. I did
complain a lot about Mozilla waiting 500ms before it opened a submenu,
without any option to change it. I am used to 0s, and this half of a
second really annoyed me and actually slowed me down.
> Where do you want to stop?
Where it starts to bloat the code without giving "enough" (yes, I
know...) advantage in return. Extreme exaple: reading a pref every 10
lines of source code. That means that if we could make everything
configurable without bloating the app, I would go for it, I would even
be proud of it and advertize it a lot. Mozilla's packages and themes go
into this direction (while they unfortunately actually do blow the app).
> > Matthew, please. You are trying to hardcode /your opinion/. There is a
> > reason why these things are prefs: others disagreed.
>
> Let's dispel that myth once and for all. /My opinion/ -- that is, the
> settings which would best suit me -- would be this:
[...]
OK, they sorry for accusing you wrongly. But you propably still don't
know why each of these prefs are there and if they could be removed. The
outstanding of this software is that it is used so widely, in so many
different environments. You sometimes don't know that you pissed off
some users with your new feature until they tell you. So, before
removing a pref (even if only from UI), be sure to understand it
completely.
> > IMO, the
> > real problem is that computers are just a completely different world,
> > and many people have a problem to adapt.
>
> You seem to take it as a /fait accompli/ that computers are `a
> completely different world', which is a shame. We don't accept that
> telephones are `a completely different world', or microwave ovens, or
> clock radios.
OFFTOPIC: Would you consider microwaves being their own world? Or
telephones or clocks? Propably no. I do consider computer being their
own world, because they are a telephone and a clock and many other
things.
Define "world" :-).
When you work on a computer, things like mathematics and a bit of
physics matter. Everything else is just software / information. When you
work in the real world, other physics matter a lot, as does chemestry
etc.. You have and reach the same goals, but have completely different
means to achieve them. These different means cause different problems
and often different usage patterns. You need to know a completely
different set of rules to best reach your goals.
Examples:
In the physical world, not even vendor wants to know your address.
Usually, there's nobody following you, and public video cameras
(although just intended to protect citizens) are fighted as privacy
intrusion. On the internet, you have to enter your address for nearly
every &%$&%$ binary, and you are tracked closely and automatically, if
you don't watch out.
Blind people have a hard time in the real world, but have the chance to
communicate completely normally over the internet, as long as some dumb
web designer doesn't work hard to mess things up (which is quite usual
nowadays :-( ).
> (Just as a side note, [...]
> you should convert /abc/ to <i class="whatever">abc</i>,
> and not to <em class="whatever">fait accompli</em>
OFFTOPIC: Agreed. Feel free to comment on bug 39771 :-).
> I don't know about you, but I think it would be great if I could just
> tell the car where I wanted to go, and it would drive there (and park)
> for me. I'd be able to do more useful stuff during the journey, instead
> of driving ...
Completely agree. But only, if I *could* tell it the car to be smart,
with the option to control things manually. Why? Because it is fun. Many
people think so for cars. Why? Because they *can* control them.
Similarly, default prefs are good, if you just want to concentrate on
your work, without bothering to learn about the web. Prefs are good, if
you want to control, adjust, optimize things.
Ben Bucksch
Matthew Thomas wrote:
[programmers discussing -> pref?]
> More likely, it shows that the programmers didn't say `well, ok, let's
> test each approach in the usability lab, and find out which works best'
> I wish I had such a lab at my disposal -- then I could stop saying `I
> think' all the time; I could start saying `I know', and give the
> relevant numbers.
>
> As it is, the only equivalent to usability testing which open-source
> projects tend to get is people whining in the newsgroups `why doesn't
> Mozilla do X?'. But because they don't want to appear clueless, people
> don't tend to whine that `I don't understand Y', or `I keep clicking Z
> by mistake', or whatever.
I just posted "don't start about usability", but here you go:
Usability testing is good and should be used for seeing how easy to
learn an interface is. It brings intuitive UIs, which are good, as long
as they have no other disadvantages.
But even the word "Usability testing" is wrong IMO, because it usually
intentionally only captures the first hours of using the app. New users
might like some dialog popping up and warning them, but the same users
might find it annoying after seeing it 100 times, with no option to turn
it off.
However, "Usability testing" is used as the ultimate UI argument in
large companies (including Netscape :-( ). Result? "Quote-below" in
Mailnews and similar user- and net-unfriendliness (to be honest).
Newsgroups (or similar feedback channels) and the developers' opinions
are IMO *very* important for getting information about the usability for
advanced users. Unfortunately, this kind of feedback seems to be noted,
but mostly ignored. I remember the (still open BTW) discussion about
quote-below ("Set caret initally above quote") in .mailnews.
Jerry Baker
>
> Only, I would suggest, when they behave badly
> <http://bugzilla.mozilla.org/show_bug.cgi?id=42796>.
And what does the first line of that bug report say? "option to disable
it"
All of your assumptions about driving users away is that they will open
prefs in the first place. Most do not. Most do not even know what prefs
are. They have to see the prefs to be daunted by them. Also, if a user
manages to make it into the prefs, they will either conclude that they
do not know enough to change anything (but it still works now), or they
will change things. I do not think someone would ditch an application
because it worked, but they didn't know the meaning of all the settings.
> The deeper the hierarchy, the greater the number of clicks, the greater
> the chance that people won't bother to use a deeply hidden pref, the
> lesser the marginal utility (economics-speak) of the pref.
You're misusing the term marginal utility. In fact, if someone wants to
change that pref enough, they will indeed find more utility in it. You
act as though a pref has to be changed every time you start the
application.
Matthew Thomas
>
> (Leaving .mail-news in here, changing subject)
Adding n.p.m.ui to, and removing n.p.m.prefs from, followups. (For
carrying on that earlier pref-related discussion in n.p.m.mail-news, I
do apologize.)
>...
> Usability testing is good and should be used for seeing how easy to
> learn an interface is. It brings intuitive UIs, which are good, as
> long as they have no other disadvantages.
>
> But even the word "Usability testing" is wrong IMO, because it usually
> intentionally only captures the first hours of using the app. New
> users might like some dialog popping up and warning them, but the same
> users might find it annoying after seeing it 100 times, with no option
> to turn it off.
That's very true. The ideal usability testing is done over months, with
both new users and expert users, at all levels of experience. (That's
partly why I took a job in an Internet cafe: so I can watch the
customers, who represent quite a large variety of users. They're using
IE 5.5, rather than nightly Mozilla builds:-), but I still learn a lot.)
> However, "Usability testing" is used as the ultimate UI argument in
> large companies (including Netscape :-( ).
Usability testing *is* the ultimate UI argument, but only if done
completely. And this is practically impossible: software companies
(Netscape included) have no financial incentive to do testing
completely, and open source efforts don't have the resources (except
where carrying out surveys is involved, and surveys aren't exactly reliable).
Doing usability testing completely doesn't mean doing it for all
possible users. It means doing usability testing for all those affected
by a program -- for all the `stakeholders', in management lingo.
* For a word processor, this means not only those who author documents,
but also:
- those who pay for them to be written (how much time am I
paying for my employees to play with an animated paper clip?)
- those who edit them (how easy is it for me to apply a new house
style to all these documents?)
- those who read them (does the program encourage the production of
easy-to-read documents?).
* For a spreadsheet, this means not only those who create the
spreadsheets, but also
- those who maintain them (what on earth was this formula supposed to
do?)
- those who rely on their results (a frighteningly high proportion of
spreadsheets contain mistakes in formulas).
* For an e-mail program, this means not only those who send the
messages, but also
- those who employ those senders (are my employees wasting time with
HTML formatting in their messages?)
- those who are responsible for transmitting the messages (why are
`ILOVEYOU' messages clogging my server?)
- those who read the messages (why isn't this conversation quoted in
chronological order?).
This is where open-source software generally tries to be better than its
closed-source equivalent: it tries to do the Right Thing for everyone,
not just for those who happen to be using that particular program.
(That's partly why open-source programs tend to trumpet
standards-compliance so heavily: to increase interoperability, even
interoperability with closed-source programs.)
> Result? "Quote-below" in
> Mailnews and similar user- and net-unfriendliness (to be honest).
So, doing the Right Thing for Mozilla on a usability level means
improving the usability of the Internet as a whole, rather than just of
Mozilla in particular. On a basic level, that means full compliance with
HTML 4.01, CSS1 and CSS2, etc etc etc. But on a broader level, it means
avoiding the sort of `tragedy of the commons' effect
<http://cantua.canterbury.ac.nz/~mpt26/art/essays/soci-102-2/> as you
get from, for example, defaulting to reply-above-quote.
* The usability of the Internet is maximized, in the long run, if all
mailers default to replying below the quoted text (rather than all
defaulting to reply above, or a mixture of the two).
* Flaming from respondents aside, any one mailer gains a slight
usability advantage from defaulting to replying above -- for all the
reasons given by German Bauer, Jennifer Glick, and Lakespur Roca (all
Netscape employees) in
<http://bugzilla.mozilla.org/show_bug.cgi?id=20966>.
* If one mailer chooses to default to replying above, other mailers get
into a `race to the bottom' to achieve the same slight advantage,
while at the same time making the Internet as a whole much less
usable.
* The only thing stopping this from happening (making programs such as
Mozilla 5.x, Mozilla 4.x on Unix, Outlook Express 5.0 on Mac, and most
Unix mailers, do the overall usability-maximizing thing) is pressure
from programmers and other Net-savvy users who are taking a broader
view than that of the usability of the individual program.
Robert O'Callahan
> Robert O'Callahan wrote:
> > I don't see why pref-checking code should have any significant impact
> > on memory requirements, startup time or speed.
>
> It's just that if some of the prefs only have a UI in TweakMoz, then
> the speed of the product is no faster than it was before... same speed,
> startup time, memory. Putting advanced prefs in a separate UI doesn't
> improve any of those areas.
Oh. Did someone claim that TweakMoz was going to solve Mozilla's
performance problems? I certainly didn't.
> Exactly... the "x" means not affected.
OK. So therefore there are no remaining objections to TweakMoz. Right?
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]
Robert O'Callahan
> Ben Bucksch wrote:
> > There is demand for a internet applications that are very
> > configurable. This demand has been served by Netscape, now Mozilla.
> > Where do you want to send these users otherwise?
>
> To Mozilla Professional Edition?
So you don't object to the existence of such a thing?
Do you object to it being built using the same basic code as Mozilla but
with a different UI?
Matthew Thomas
>
> Matthew Thomas wrote:
> >
> > programming language which doesn't allow the use of constants.
>
> know how it could work, as constants are inherent to many expressions.
Excuse the stupid question (stupid because I'm a linguistics student,
and I should know this already) ... but does German have sarcasm, or is
it an English-specific thing?
>...
> Apart from that, hidden prefs are an elegant way to workaround bugs.
> It is not unwise to add hidden prefs where you *suspect* bugs (e.g.
> for "smart" algorithms, new features or security-relevant functions).
> If you actually discover a bad bug, you can instantly offer a
> workaround, even for installed products.
If SmartUpdate works as it should, the instant workaround is a tiny
auto-installing download, which (for most users) would actually be
easier than hacking prefs.js. (Sad but true.)
> > Well if you can tell that when it says 0 unread messages that there
> > are no more, then you're never going to click the `Next Unread'
> > button when there aren't any more unread messages.
>
> I might not have clicked the button, but just pressed SPACE, which
> also scrolls down, if possible (and goes to next unread, if not, which
> is a good idea IMO).
Yes, the space bar is what I use too. And yes, I always continue to the
next group. And yes, I always get the dialog. And no, it doesn't annoy
me. Apparently I'm not *nearly* angry enough -- if I was angry enough,
I'd want a pref. :-)
> > > turn of referer headers
> >
> > That reminds me of a discussion I saw where iCab was being
> > criticized for having a pref for notifying the user for every HTTP
> > result except (IIRC) 200 OK and 304 Not Modified.
>
> Unrelated.
Both are technical aspects of HTTP. Both are required, by many sites, to
be processed in the usual manner by browsers in order for the sites to work.
> > `Load without referring header' would be a useful hypertext link to
> > include in the `Document Info' window, but to make it a pref is just
> > asking for trouble.
>
> The referrer header *itself* is just asking for trouble, disabling it
> is just the right thing to do.
>...
Can you tell me why it's so bad? RFC 2616, section 14.36, says:
|
| The Referer request-header allows a server to generate lists of
| back-links to resources for interest, logging, optimized caching, etc.
| It also allows obsolete or mistyped links to be traced for
| maintenance.
Other uses I can think of for it include:
* allowing Webmasters to arrange beneficial (to everybody) arrangements
with other sites (such as notifying them of the new address of a
broken or redirected link, maybe even before the break/redirect is due
to occur);
* allowing users to be presented with navigation appropriate to the
relationship between the page they came from and the page they are at
now (which is especially important if a given page can be approached
as part of more than one navigation scheme);
* maintaining login status in sites that require `friendly' (non-HTTP)
authorization, when the user has cookies disabled;
* giving Webmasters an idea of how useful various search engines or
Web directories are in referring people to their site
<http://www.useit.com/about/searchreferrals.html>;
* allowing Webmasters to trace fraudulent Web site operators who are
illegally `framing' their site (misrepresenting the original site's
content as their own, through framesets).
[mail-news removed from followups]
Ben Bucksch
> All of your assumptions about driving users away is that they will open
> prefs in the first place. Most do not. Most do not even know what prefs
> are.
Yes, but this is a sub-optimal situation, which Matthew wants to change,
and I agree with him here.
I agree with you in that users not interested in *advanced* prefs should
not see *them*.
Matthew Thomas
>
> Matthew Thomas wrote:
> >
> > >
> > > Hard-coding not good.
> >
> > Why does that sound like a reflexive mantra (`four legs good, two
> > legs bad'), rather than a considered opinion?
>
> <http://www.tf.hut.fi/cgi-bin/jargon?search=hardcoded>. See also
> <http://www.tf.hut.fi/cgi-bin/jargon?search=magic+number>, Usage 1.
Yes yes, I know what `hard-coding' *means* (though the subtle
distinction between in-line constants and #defines had eluded me).
/* http://www.tf.hut.fi/cgi-bin/jargon?search=magic+number (usage 4) */
#define HUMAN_SHORT_TERM_MEMORY 7
/* http://www.useit.com/papers/responsetime.html */
#define HUMAN_TIME_INSTANT 0.1
#define HUMAN_TIME_CONTINUOUS 1.0
/* #define HUMAN_TIME_FOCUSED 10.0 -- 1990s measure, obsolete */
#define HUMAN_TIME_FOCUSED 5.0
>...
> > How about a pref for the exact amount of time which the menu title
> > in the Mac menu bar flashes when you type the keyboard shortcut for
> > an item which is in that menu <http://www.quinn.echidna.id.au/Quinn/WWW/HISubtleties/AnarchieMenuFeedback.html>?
>
> Yes, I would want to have such a pref, if I worked on Mac. I did
> complain a lot about Mozilla waiting 500ms before it opened a submenu,
> without any option to change it. I am used to 0s, and this half of a
> second really annoyed me and actually slowed me down.
That's a bug. The correct delay (as far as I can tell from fiddling with
the Mac menus) is 250 ms. Longer than that, and you get annoyed. Shorter
than that, and two things go wrong: (a) the menu is so busy opening and
closing submenus that it doesn't keep up with the user, and (b) you
might have a very wide submenu opening over the top of the main menu,
even where you only spent a very short time over the menu item, so you
might select an item from the submenu by mistake.
See also:
* <http://www.quinn.echidna.id.au/Quinn/WWW/HISubtleties/HierarchicalMenus.html>
* <http://www.asktog.com/readerMail/2000-07ReaderMail.html#Anchor6>.
> > Where do you want to stop?
>
> Where it starts to bloat the code
I thought you said that didn't happen ...
> without giving "enough" (yes, I
> know...) advantage in return.
I thought you said it always gave advantage ... :-)
>...
> OK, they sorry for accusing you wrongly. But you propably still don't
> know why each of these prefs are there and if they could be removed.
> The outstanding of this software is that it is used so widely, in so
> many different environments. You sometimes don't know that you pissed
> off some users with your new feature until they tell you. So, before
> removing a pref (even if only from UI), be sure to understand it
> completely.
Fair enough. What I probably need to do is to go into
comp.infosystems.www.browsers.{platform} and say, `who uses this pref?',
and see what crawls out of the woodwork.
>...
> > You seem to take it as a /fait accompli/ that computers are `a
> > completely different world', which is a shame. We don't accept that
> > telephones are `a completely different world', or microwave ovens,
> > or clock radios.
>
> OFFTOPIC: Would you consider microwaves being their own world? Or
> telephones or clocks? Propably no. I do consider computer being their
> own world, because they are a telephone and a clock and many other
> things.
You know, some customers come into the Internet cafe where I work, and
they don't ask for a `computer'. They don't even ask to `do e-mail'.
... They just ask for a `Hotmail terminal'.
Is a computer a completely different world to those people? No, it's
just a Hotmail terminal. They have found the most useful use for a
computer -- e-mail -- and that's all they use it for.
One day I hope to hear them ask for a `Mozilla terminal' ...
> Define "world" :-).
The place I call home.
>...
> Examples:
> In the physical world, not even vendor wants to know your address.
> Usually, there's nobody following you, and public video cameras
> (although just intended to protect citizens) are fighted as privacy
> intrusion. On the internet, you have to enter your address for nearly
> every &%$&%$ binary, and you are tracked closely and automatically, if
> you don't watch out.
That was going to happen whether the Internet came along or not. The
good thing about the Internet is that citizens, and those wanting to
take away their privacy, are much more even in power than they are in
the physical world. And the Internet provided the communications medium
which the free software and open source movements (and the pro-privacy
movements) needed to coordinate themselves, in order to counteract that
trend. Like I used to say in my .sig: `The Internet was invented just in time'.
> Blind people have a hard time in the real world, but have the chance
> to communicate completely normally over the internet, as long as some
> dumb web designer doesn't work hard to mess things up (which is quite
> usual nowadays :-( ).
>...
You think that's bad? You wait until the blind users start bitching that
they can't use Mozilla because it doesn't use native widgets, and all
their accessibility tools are designed to hook into the native widget
system on Windows or Mac OS. That's really sad, and it makes Mozilla's
efforts to meet the WAI guidelines look a bit silly.
I hope someone implements a utility to pipe XPToolkit interfaces to a
speech output program pretty soon. It shouldn't be too difficult. Then
we can start making aural CSS skins, not just visual ones ...
Tim Hill
> as Mozilla but with a different UI?
I'm not sure I like the idea of a Mozilla for Dummies and a Mozilla Advanced
version. The ideally designed UI allows users to progressively discover
more about the UI without overwhelming them, even offering possibilities
that a user might not have envisioned. Having separate versions means the
novice user can never progress in understanding the UI without switching
over to a completely different program ("Hmm, I wonder if I'm an advanced
user yet..."). It will also no doubt be a good excuse for developers to
clutter the Advanced version with all kinds of useless things -- after all,
there's always the easy-to-use, powerless Beginner version...
Tim
Ben Bucksch
> > Apart from that, hidden prefs are an elegant way to workaround bugs.
> > It is not unwise to add hidden prefs where you *suspect* bugs (e.g.
> > for "smart" algorithms, new features or security-relevant functions).
> > If you actually discover a bad bug, you can instantly offer a
> > workaround, even for installed products.
>
> If SmartUpdate works as it should, the instant workaround is a tiny
> auto-installing download, which (for most users) would actually be
> easier than hacking prefs.js. (Sad but true.)
No, workarounds can be offered with the description of the bug (on
bugtraq or whereever), before engineers even start to fix it.
> > > > turn of referer headers
> > >
> > > That reminds me of a discussion I saw where iCab was being
> > > criticized for having a pref for notifying the user for every HTTP
> > > result except (IIRC) 200 OK and 304 Not Modified.
> >
> > Unrelated.
>
> [...] Both are required, by many sites, to
> be processed in the usual manner by browsers in order for the sites to work.
I know no case hwere a referrer header would be required for technical
reasons. If sites don't work without it, usually the webmaster worked
hard to close these customers out, because he wants to get the
information.
> > The referrer header *itself* is just asking for trouble, disabling it
> > is just the right thing to do.
> * maintaining login status in sites that require `friendly' (non-HTTP)
> authorization, when the user has cookies disabled;
How does referer help here? It is easy to fake, if you don't include
other means (e.g. the hostname). If you include other means, you
propably don't need the referrer anymore.
> * giving Webmasters an idea of how useful various search engines or
> Web directories are in referring people to their site
> <http://www.useit.com/about/searchreferrals.html>;
> * allowing Webmasters to trace fraudulent Web site operators who are
> illegally `framing' their site (misrepresenting the original site's
> content as their own, through framesets).
>
> [mail-news removed from followups]
>
> --
> Matthew `mpt' Thomas, Mozilla user interface QA
> <http://critique.net.nz/project/mozilla/>
Ben Bucksch
Matthew Thomas wrote:
> Ben Bucksch wrote:
> > The referrer header *itself* is just asking for trouble, disabling it
> > is just the right thing to do.
>
> Can you tell me why it's so bad?
Several sites use sessionids in the URL. This together with the referrer
opened many security holes, e.g. in webmail services.
The largest problem is: It is none of the webmasters business what I did
before I went to his site. Maybe I was on a health-care site which
linked to the Netscape Directory. Or whatever.
Also, maybe I created some sort of a local, custom bookmark page (in the
sidebar or however), or get the URL from a mail or was on a completely
unrelated site and used a bookmark. (Not sure if the referrer is sent in
the last case. It certainly would be a large privacy intrusion.)
> * allowing users to be presented with navigation appropriate to the
> relationship between the page
If they want to do that, they usually have a cooperation with the other
site anyway, in which case the other site can include a hint in the URL.
Then, I at least *know* what's going on (as I can see teh URL).
> * allowing Webmasters to trace fraudulent Web site operators who are
> illegally `framing' their site
And "illegal" (hah) deep linking.
Josh Harding
> Matthew Thomas wrote:
> > The deeper the hierarchy, the greater the number of clicks, the greater
> > the chance that people won't bother to use a deeply hidden pref, the
> > lesser the marginal utility (economics-speak) of the pref.
>
> You're misusing the term marginal utility. In fact, if someone wants to
> change that pref enough, they will indeed find more utility in it. You
> act as though a pref has to be changed every time you start the
> application.
Ah... but that does bring up an interesting point. When considering a Deep Prefs
Hierarchy, one factor that should be kept in mind is how often the pref is likely
to change. I agree that for most of the prefs they are one-time things that I
pick how I want them. But some things aren't as obvious as they initially
seem... example: I don't like how many clicks it takes to get to NN4's proxy
settings. I have to change my proxy settings twice a day (when I get to work and
when I get home). I can't use multiple profiles since I need the same
addressbook/bookmarks etc... Although there's probably a better way to fix this
than to make the proxy settings easier to get to...
The Amigo
Josh Harding
> OK. So therefore there are no remaining objections to TweakMoz. Right?
I have none.
The Amigo
Matthew Thomas
>
> Matthew Thomas wrote:
> >
> > Can you tell me why it's so bad?
>
> Several sites use sessionids in the URL. This together with the
> referrer opened many security holes, e.g. in webmail services.
That would be a problem with the implementation, not with the idea
itself, surely.
Someone comes into the Internet cafe, and they want to use their Webmail
account without other people being able to log in to their account
later. So they uncheck the `Remember this login' box on the home page,
and the Webmail service uses sessionid URLs and the referer header instead.
> The largest problem is: It is none of the webmasters business what I
> did before I went to his site. Maybe I was on a health-care site which
> linked to the Netscape Directory. Or whatever.
I don't understand. If you are on page A, and you type the URI for page
B into the location bar, the Referer is not `A', it's `(null)'.
> Also, maybe I created some sort of a local, custom bookmark page (in
> the sidebar or however),
If Mozilla is sending a referer header with a value of file://something,
I don't think that's technically a bug, but if you reported it as a
security bug I think it would probably get fixed.
> or get the URL from a mail
Same there. msg-id: URIs are of no legitimate use to a Web site
operator, so they shouldn't be sent at all.
> or was on a
> completely unrelated site and used a bookmark. (Not sure if the
> referrer is sent in the last case. It certainly would be a large
> privacy intrusion.)
No, it shouldn't be. A bookmark might have a URI on the implementation
level <file://whatever/bookmarks.html>, but it doesn't really have a URI
as far as the user is concerned.
| The Referer field MUST NOT be sent if the Request-URI was obtained
| from a source that does not have its own URI, such as input from the
| user keyboard.
Oh, look at that:
|...
| Because the source of a link might be private information or might
| reveal an otherwise private information source, it is strongly
| recommended that the user be able to select whether or not the Referer
| field is sent. For example, a browser client could have a toggle
| switch for browsing openly/anonymously, which would respectively
| enable/disable the sending of Referer and From information.
Ok, then ... :-)
> > * allowing users to be presented with navigation appropriate to the
> > relationship between the page
>
> If they want to do that, they usually have a cooperation with the
> other site anyway, in which case the other site can include a hint in
> the URL. Then, I at least *know* what's going on (as I can see teh
> URL).
No, what I meant was something like this. Page X is part of a hierarchy
of information (A -> M -> X). It also happens to be part of a
step-by-step tutorial (V -> W -> X -> Y -> Z). Using the Referer header,
the site can tell whether to show navigation for the hierarchy, or for
the tutorial, without having to maintain separate copies of the page.
> > * allowing Webmasters to trace fraudulent Web site operators who are
> > illegally `framing' their site
>
> And "illegal" (hah) deep linking.
>...
Just providing the option to surf without sending the Referer header
isn't going to stop Web site operators from detecting where the deep
links are -- because *someone* who uses the link is still going to have
the Referer header turned on, aren't they?
Akkana Peck
> And I am not looking forward to having to explain this to those in
> <news:alt.ascii-art> once I return to update their FAQ, either. It'll
> almost be enough to make them go back to Outlook Express (its bogus
> conversion of `//' to `file://' notwithstanding).
>
> Them: `Dammit, we trusted you! And now look at these smileys all over
> the place!'
> Me: `Well, you can turn it off, just change this line in prefs.js ...'
> Them: `But it says, "Do Not Edit".'
> Me: `Uh, just ignore that.'
> Them: `Ok, I tried it, it didn't work.'
> Me: `Um ... did you quit Netscape *before* you edited prefs.js?'
> Them: `Oh, never mind, I'm sick of this, I'm using Forte Free Agent
> instead.'
I suggest telling them to put user-written prefs like this in user.js,
not prefs.js. Then they won't have these problems with Netscape
overwriting their work.
...Akkana
Matthew Thomas
>...
> Why, because I think advanced users deserve a browser that they find
> usable just as neophytes do? Why make all the browsers aimed at
> "newbies"? Can't advanced users have just one? Is that alright with
> you?
Can't ordinary users (a decreasing number of which are `neophytes', as
the Internet becomes ubiquitous) have a usable open-source browser too?
Just one? Is that all right with you? There are far more of them than
there are of us, so shouldn't we be aiming for them first?
Right now, there are *no* credible open-source browsers for ordinary
users. Mozilla is too incomplete, slow, and has a poorly designed user
interface. Same applies to Amaya. Lynx has a good user interface, but it
doesn't have in-line graphics and multimedia (duh) -- it's good at what
it does, but what it does is not what ordinary users want. And the
others (Mnemonic, Konqueror, etc) have various critical problems -- such
as not running on Windows, for example.
Why is this important? To answer that, you need to get into a bit of
crystal-ball gazing.
Option 1: Mozilla aims at advanced users.
The increase in the number of non-Netscape contributors to Mozilla
development accelerates (because open source contributors tend to
be advanced users), especially following the release of Netscape 6
(lots of itches to scratch). Mozilla gains a niche following
amongst Web developers (because of its standards compliance), and
amongst Linux users (because it's the only credible option).
But for ordinary users (who, predominantly, are using Windows), IE
is faster (largely loaded on Windows startup), better integrated
(runs in the same window as the file manager), and less confusing
(more novice-friendly UI) than Mozilla is. So ordinary users don't
switch. Reluctantly, Web developers switch back to using IE, because
the disparities between what they are seeing (using Mozilla or a
Mozilla derivative) and what their sites' visitors are seeing (using
IE) have become too great. And eventually, Linux users switch from
Mozilla to the browsers integrated with GNOME or KDE, because they
are both faster (through using a native UI) and better integrated
with the file manager than Mozilla is. Linux users also have
increasing problems with Web pages which only work in IE, and not in
their standards-compliant (and often Gecko-using) browsers.
Then, AOL switches to using Gecko in their browser.
Because of the large market share of AOL, Web developers now
have to support both AOL and IE. The Web starts to become
balkanized into two parts: the part which works best (or
exclusively) in IE, and the part which works best (or
exclusively) in AOL, Netscape, and other standards-compliant
browsers.
A cyberwar erupts between Microsoft and AOL. AOL manages to
mention `standards compliance' in almost every press release
they issue, and the phrase becomes even more clichéd and
meaningless than the phrase `freedom to innovate' was in the
previous decade. Microsoft, on the other hand, milks the
security bugs found in Mozilla (unavoidably present due to its
immature codebase, open source notwithstanding) for maximum PR
value.
The fact that security bugs found in Mozilla get fixed much
faster than those found in IE (because Mozilla is open source)
can't really be used as a marketing factoid, because that would
require mentioning the existence of the security bugs in the
first place. In addition, IE bugfixes begin to have a higher
deployment rate than Mozilla bugfixes -- due to the improved
automation of Windows Update in Windows ME (as compared
with Netscape's SmartUpdate or the Mozilla.org equivalent), and
the existence of multiple distributions of Mozilla
<http://www.wired.com/news/technology/0,1282,10264,00.html>.
On the content side, MSN (which is still part of Microsoft, as
the appeal process grinds on) and AOL both start buying up as
many major Web properties as they possibly can, in order to
convert those properties to be exclusive to their browsers, to
attract users to their respective halves of the Web. Meanwhile
for independent Web developers, the profitability of Web
production goes down. Either they incur higher costs, through
producing code which works in both browser families, or they get
lower revenue from picking one browser family and thereby
limiting their audience.
So the number of Web sites goes down, and those sites which
remain are slower (due to browser-detection bloat) or more bland
and marketized (because they're owned by MSN or AOL). The
usefulness of the Web as a whole goes down -- partly because of
the decreased number of Web sites, and partly because Metcalfe's
Law (the value of a network is proportional to the square of the
size of the network) is happening in reverse
<http://www.useit.com/alertbox/990725.html>.
Or, AOL see the potential for all of the above to happen, and decide
that the most profitable option is to stick with IE's layout engine.
IE becomes the /de facto/ standard for Web developers. After a
few years, the W3C becomes little more than a rubber stamp for
whatever IE does (they don't have any other practical choice).
Eventually, though, Microsoft starts ignoring the W3C process
altogether, because they no longer need the pretence of
following some sort of external `standard'.
Mozilla.org inevitably gets drawn into a WINE-like attempt to
implement bug-for-bug compatibility with IE. This raises the
barriers to entry of non-Netscape Mozilla developers, because
the Mozilla code is even more complicated than it was before.
One or two AOL shareholder meetings later, Netscape discontinues
work on Mozilla, and concentrates on producing servers and site
management tools. Or, more likely, Netscape is sold off to a
company (such as Red Hat or Sun) which is interested in
developing Mozilla only on one platform where IE is not
available (Linux and Solaris respectively).
A bitter debate ensues: Netscape's new owners want Mozilla to be
rewritten specifically for their own platform (native widgets,
hurrah!), to make it faster and more system-savvy. But this is
opposed by those contributors -- both inside and outside
Netscape -- who are using a different OS, those who are using
XPToolkit for other projects, and even those who just put a lot
of effort into XPToolkit's implementation and don't appreciate
seeing their work abandoned. Eventually the XPToolkit supporters
win the day <http://mozilla.org/fear.html>, but it is a
close-run thing. In the meantime, some contributors get fed up
with the arguments and just leave.
The number of developers continues to decrease as Mozilla, which
is having difficulty staying compatible with IE, gradually
becomes less usable for day-to-day browsing. Eventually Mozilla
gets marginalized, and dies -- as much as any open-source
project can be considered to `die': the source is still
available, but CVS, Bugzilla, and Tinderbox are no longer in
action, and paid programmers are no longer working on Mozilla.
Soon afterwards, through .NET, Microsoft start charging a
subscription fee for the use of Windows, and discontinue
development of IE on any other platform.
Option 2: Mozilla aims at the average user.
The number of non-Netscape contributors to Mozilla development
continues its slow but steady increase. While Mozilla is slower and
less integrated than IE is, it is seen by ordinary users as a
serious contender to IE. Encouraged by this, contributors work to
solve the speed and integration problems, to make Mozilla the best
browser in existence.
This catchup effort means that Microsoft has to start competing on
standards compliance as well as on usability. For a while, Microsoft
is compelled to support the non-standard DHTML, CSS, XML namespace,
and XSL behaviors used in earlier versions of IE (for backward
compatibility with existing IE-dependent sites), as well as the
standards-compliant behaviors. This dual approach (like Mozilla's
Quirks mode, but more complicated) bloats the layout engine and
related internals.
At the same time, the mindless-feature-parity mentality of the
software industry means that Microsoft also has to introduce more
extensive skinning capabilities to IE. This bloats the UI.
As a result of the bloating of both the layout engine and the UI, IE
slows to a speed which is comparable to (if still a bit faster than)
Mozilla.
The W3C standards win the day, so the Web developers are happy. The
usefulness of the Web goes up, as Web developers start doing all
sorts of hoopy stuff with XML, CSS, and the W3C DOM.
Linux becomes more credible as a desktop OS, because there is at
least one browser (Mozilla) running on Linux which does all the cool
stuff which browsers on other platforms do.
Microsoft attempt to embrace and extend XPToolkit -- by now renamed
`MozToolkit' -- by producing a Windows-only `M++ Virtual Machine'.
But the Java/J++ debacle is still fresh in the memories of
developers, and they don't fall for the same ploy twice.
Nevertheless, MozToolkit starts becoming a required item for the new
generation of database-accessing Internet apps. For this reason,
some OEMs even include Mozilla as base software when pre-installing
Windows (or Linux, or BeOS, or Mac OS X PC Edition) on their
machines. Microsoft would love to change the Windows contracts so
that OEMs are prohibited from doing this, but thanks to the US DOJ,
that is something which is no longer possible.
And Mozilla survives.
[n.p.m.mail-news removed from followups]
Jerry Baker
>
> Jerry Baker wrote:
> >...
> > Why, because I think advanced users deserve a browser that they find
> > usable just as neophytes do? Why make all the browsers aimed at
> > "newbies"? Can't advanced users have just one? Is that alright with
> > you?
> >...
>
> Can't ordinary users (a decreasing number of which are `neophytes', as
> the Internet becomes ubiquitous) have a usable open-source browser too?
> Just one? Is that all right with you?
Yes, Netscape 6.
Matthew Thomas
>
> Matthew Thomas wrote:
> > Can't ordinary users (a decreasing number of which are `neophytes',
> > as the Internet becomes ubiquitous) have a usable open-source
> > browser too? Just one? Is that all right with you?
>
>...
I said *usable*.
Ben Bucksch
> Option 2
[...]
> Nevertheless, MozToolkit starts becoming a required item for the
> new generation of database-accessing Internet apps.
Is that the optimistic or pessimistic possibilty? For me, that is one of
the worst things that Mozilla could cause.
Option 3:
The crowd on n.p.m.prefs finally, after a long debate about the
usefulness of prefs in general, found a way to design a user interface
that is adequate for both new and advanced users, (1) allowing them to
gracefully enhance their knowledge level and (2) increasing the target
group and thus the user base of Mozilla.
Of course, MS copies the idea, but fails to carry it out in consequent
way.
Mark Anderson
I'm not going to reply to the specifics of this (although I don't see
either of the scenarios as foregone conclusions), but I have to say that
this post had me laughing out loud in several places (the references to
M++, etc.). Great thoughts, Matt. :)
Ben Bucksch
> > I did
> > complain a lot about Mozilla waiting 500ms before it opened a submenu,
> > without any option to change it. I am used to 0s, and this half of a
> > second really annoyed me and actually slowed me down.
>
> That's a bug. The correct delay (as far as I can tell from fiddling with
> the Mac menus) is 250 ms.
OT: Correct for you. Too slow for me.
> What I probably need to do is to go into
> comp.infosystems.www.browsers.{platform} and say, `who uses this pref?',
> and see what crawls out of the woodwork.
Actually ONTOPIC: Yup, and any appropriate mail/news group(s). But
first, go to n.p.mozilla.*.
> > I do consider computer being their
> > own world, because they are a telephone and a clock and many other
> > things.
>
> You know, some customers come into the Internet cafe where I work, and
> they don't ask for a `computer'. They don't even ask to `do e-mail'.
>
> ... They just ask for a `Hotmail terminal'.
OT: Internet cafes *do* rent Internet access, which is an appliance of
computers, just like clocks.
> You wait until the blind users start bitching that
> they can't use Mozilla because it doesn't use native widgets, and all
> their accessibility tools are designed to hook into the native widget
> system on Windows or Mac OS. That's really sad, and it makes Mozilla's
> efforts to meet the WAI guidelines look a bit silly.
Exactly my speak. I don't like XPToolkit in part because of exactly
that.
Josh Soref
Someone decided that people really don't know how to select their gear better than a computer/mechanism.
So many cars offer automatic gear selection,
however some engineers must have argued this point because a bunch of cars are offered by dealers in two configurations: automatic and manual, it's a customer preference.
Someone else decided that cars needed windshield wipers. Someone declared they should either run all the time or never. Another engineer decided that maybe people wanted an intermittent setting. They couldn't agree on this so now cars have multiple settings for windshield wipers. For some reason, people like this.
Henry Ford offered the best example: You can have a model t in any color you like as long as it is Black.
For some reason people decided they liked making a selection. Others even had the gall to paint their cars (a personal preference). Still others customized their cars. Cars are like browsers, they get people where they want to go. And they have bloat too. For some reason many cars have lighters in them, originally this bloat was because many people smoked.
But few cars offer the preference of not having a lighter. Why? well because it's a standard feature!! But you don't smoke? well tough, it doesn't weigh much and you'll hardly notice it (or the ashtrays or...). Interestingly, someone came up w/ a clever abuse that allows converting the lighter into a standard electrical power source for various uses. If cars subscribed to a one way use concept, then they'd be restructured so lighters couldn't be used for this purpose.
About hidden preferences... Saturn (another car co.) cars have quite a few of these, except, they're hidden and happen over the course of driving, the car gets to know the driver's tendencies and adjusts to them. While this is really nifty, occasionally when people have problems with their cars silly repair shops will blame them on the fact that a different driver used them. (afaik Saturn cars only know one user, so when you drive the car for the first few times it feels really strange, but then it adjusts) So should Mozilla act like a saturn? there's a proposition to do that. But that's not going to be a now thing and that actually requires more buttons to click, because if you don't have the buttons acclimation will never show them.
Maybe Mozilla should be like a model T, any color you want as long as it's black. Or maybe we're too silly to have the preference for intermittent windshield wipers. Would you buy a car that didn't come standard with them? And do you go to a dealer and make a preference choice about automatic vs. manual? If you don't express a preference maybe you could teach me to drive.