126600 - bad pref wording (quicklaunch/performance)

Status: VERIFIED FIXED

(Core Graveyard :: QuickLaunch (AKA turbo mode), enhancement)

Description

[Henrik Gemal]

The current wording in the turbo pref panel is:
"enable features that affect performance"

to me that really really sound like something bad. I've never heard antbody 
say "that really affected my performce" in a positive way.

Why not make it sound like it's really cool:
"enable features that increase performance"
or something...

Comment 1

[Brant Gurganus]

I agree although this is lower severity.  Should be enhancement as it is not a bug.

Comment 2

[Mike Kowalski]

Attachment: patch that needs diff

Comment 3

[Brian 'netdragon' Bober]

Kowalski: Next time, just attach the file without the + or -, that is something
diff does. Also, for future reference, if you just attach a file without
diffing, please say its name. Thanks. :-)

If you are going to start fixing more bugs, it would be helpful if you got a
tree going so you can do the diff yourself. I can help you get started on irc.

Comment 4

[Brian 'netdragon' Bober]

Attachment: diff

pref-advanced.dtd

Comment 5

[Mike Kowalski]

taking...

Comment 6

[Brian Ryner (not reading)]

Comment on attachment 71970 [details] [diff] [review]
diff 

r=bryner

Comment 7

[kinmoz]

Comment on attachment 71970 [details] [diff] [review]
diff 

sr=[e-mail]

As long as it's cleared with whoever owns that pref panel.

Comment 8

[Bill Law]

Comment on attachment 71970 [details] [diff] [review]
diff 

a=law

Of course, we're talking about *Mozilla's* performance and not the *system*
performance :-).

Comment 9

[Christopher Aillon (sabbatical, not receiving bugmail)]

Comment on attachment 71970 [details] [diff] [review]
diff 

Nothing against Law, but I'm unchecking "has-approval" to denote that this
patch still needs approval from drivers before it can be checked in.  His
approval of the patch still stands though.

Comment 10

[Scott Collins]

Comment on attachment 71970 [details] [diff] [review]
diff 

a=scc

Comment 11

[Christopher Aillon (sabbatical, not receiving bugmail)]

Checked into the trunk 03/24/2002 09:39.

Comment 12

[Blake Ross]

Does "increase performance" make sense?  Dictionary.com defines performance as
"The way in which someone or something functions".  I don't think you can
increase that way, but you can improve that way...

Please cc [e-mail] when you're changing wording.  He's the resident
wording expert, and he needs to be notified anyway so that help documentation
can be updated.

Comment 13

[Grace Bush]

verified on build 2002032503

Comment 14

[Mike Kowalski]

I'm reopening because maybe it should be improve. Improve makes sense also. If
we decide on keeping it as it is then I'll mark this fixed again, but if we
decide on improve then a patch that will change the word to improve will be
checked in.

Comment 15

[Jatin Billimoria]

Quick Launch solely affects the speed at which initial start-up occurs. I
suggest the following wording:

"Enable features that improve speed" 

Comment 16

[Henrik Gemal]

do we really need any text trying to capture the highlight of the features?
"Enable features that improve speed"

Who wouldn't have that? I sound like a "[ ] Make Windows more stable" option!

Why not only hav quick launch:

-- QuickLaunch ---------------------
|
| Quick Launch starts Mozilla faster by keeping portions of the program
| in computer memory
|   [ ] Enable Quick Launch (where posible)
|
------------------------------------

isn't there some limitations on where Quick Launch is able to run?

Please see the dialog in the Windows Mozilla Installer.

Comment 17

[Mike Kowalski]

I'm working on a patch that will make it say "Enable feature to improve startup
performance". I may add some text below the checkbox that will tell users what
Quick Launch does.

Comment 18

[Henrik Gemal]

I still think that:
"Enable feature to improve startup performance"
is bad...
who wouldn't have that?

Sounds like:
[ ] Enable feature to improve startup performance"
[ ] Enable feature to crash less

Think it should be something like this:
Quick Launch starts Mozilla faster by keeping portions of the program in
computer memory
[ ] Enable Quick Launch

Comment 19

[Brian 'netdragon' Bober]

How about:
Quick Launch keeps some of the program in memory when no windows are open for
faster loads.
[ ] Enable Quick Launch

Comment 20

[Mike Kowalski]

Attachment: possible pref wording

Comment 21

[Mike Kowalski]

Attachment: 2nd possible pref wording

Comment 22

[Mike Kowalski]

Attachment: 3rd possible pref wording

Comment 23

[Mike Kowalski]

Attachment: 4th possible pref wording

Comment 24

[Mike Kowalski]

Attachment: 5th possible pref wording

Comment 25

[Mike Kowalski]

Attachment: 6th possible pref wording

Comment 26

[Mike Kowalski]

Attachment: 7th possible pref wording

Comment 27

[Mike Kowalski]

Attachment: xul part of the patch that needs diff

Comment 28

[Mike Kowalski]

Attachment: dtd part of the patch

Comment 29

[Mike Kowalski]

Attachment: patch

Comment 30

[Mike Kowalski]

Attachment: patch

I fixed a few mistakes that I found in my patch.

Comment 31

[Mike Kowalski]

Attachment: patch

better patch

Comment 32

[Mike Kowalski]

Attachment: better patch

fixed some problems with indenting. At least I hope it's fixed.

Comment 33

[Mike Kowalski]

Attachment: an even better patch

fixed some problems with the previous patches. please r= and sr=.

Comment 34

[Daniel Brooks [:db48x]]

Comment on attachment 88086 [details] [diff] [review]
an even better patch

r=db48x

Comment 35

[Mike Kowalski]

Attachment: fix

changed pref back to perf.

Comment 36

[Blake Ross]

Jatin, are you ok with the wording proposed in this patch?

Comment 37

[Jatin Billimoria]

This patch is ok with one exception.
My suggested change on the patch:
"If you check this item, part of {short variable} will stay in memory when not
in use, allowing it to start up faster."

Comment 38

[Mike Kowalski]

Attachment: fix

I changed the wording to what Jatin wanted.

Comment 39

[timeless]

Comment on attachment 90828 [details] [diff] [review]
fix

technically this needs work, i explained to kowalski that jatin meant
&brandShortName;

jatin: your message is silly. When I look in preferences, I see this button
labeled "Help" whenever I want to know what something is, means, or will do, I
click it.  And when it turns out that doesn't work, I file a bug.  Can someone
please give me a good reason for putting detailed explanatory text for pref
options into the pref dialog (which will make it *way* too big) instead of
putting readable information into the associated help pages and allowing users
who care to click the button?

Users who don't care shouldn't be forced to read useless text which can't even
clearly explain what we mean.

What we mean is something like: selecting this will cause the app to load at
launch and not remain closed when you close the last window. As a result the
time it takes for you to open a window when there aren't any other
&brandShortName; windows open will not be as bad as if &brandShortName; had to
actually launch before opening a window.</description>

Note that in fact it can still be pretty pitiful if mozilla has been swapped to
disk and the system has very little RAM.

Comment 40

[Jatin Billimoria]

Timeless, my comments are inline:

"jatin: your message is silly. When I look in preferences, I see this button
labeled "Help" whenever I want to know what something is, means, or will do, I
click it.  And when it turns out that doesn't work, I file a bug.  Can someone
please give me a good reason for putting detailed explanatory text for pref
options into the pref dialog (which will make it *way* too big) instead of
putting readable information into the associated help pages and allowing users
who care to click the button?"

The reason we strive to put explanatory text in the UI and preferences is so
that users don't have to take the extra step of going to the online help.
Usability tests show that users only turn to online help when they are forced to
as a last resort. This being the case, users should be given as much information
as possible through tooltips and UI descriptions.

"Users who don't care shouldn't be forced to read useless text which can't even
clearly explain what we mean."

Users are not insulted by extra information. In fact, more users will appreciate
that we take the extra step to address confusion through the UI itself. Not all
users are developers intimately familiar with the product.

Comment 41

[Mike Kowalski]

Attachment: patch

this patch now adds &brandShortName; to it. please r=/sr=.

Comment 42

[Mike Kowalski]

Attachment: patch for brand.dtd

this patch changes the vendorShortName from Mozilla to Mozilla.org.

Comment 43

[Doron Rosenberg (IBM)]

Comment on attachment 91041 [details] [diff] [review]
patch

 <!DOCTYPE window SYSTEM "chrome://communicator/locale/pref/pref-advanced.dtd"
>
+<!ENTITY % brandDTD SYSTEM "chrome://global/locale/brand.dtd" >

see
http://lxr.mozilla.org/mozilla/source/xpfe/components/prefwindow/resources/cont
ent/pref-appearance.xul

+	<hbox class="indent">
+		<description>&perfdescription.label;</description>

please remove the tab.

Comment 44

[Mike Kowalski]

Attachment: final patch

fixed some things.

Comment 45

[timeless]

jatin: that's all fine and dandy, except that you can't fit a clear explanation of what this patch actually does into the pref dialog. I haven't seen someone actually manage to clearly explain what it does at all.<period>

The bigger problem is that I've been trying to use the pref dialog on MacOS. It really doesn't work -- The pref panels don't fit into the space available, instead their content invisibly extends beyond the margins. And these silly explanations (and an explanation that fails to accurately explain itself is silly) are a significant contributor to that problem.

As for the patch. r=timeless w/ the tab fixed. (this is of course over my objection for the explanation)

Comment 46

[Mike Kowalski]

Attachment: final final patch :)

got rid of tab.

Comment 47

[Christopher Aillon (sabbatical, not receiving bugmail)]

Comment on attachment 91050 [details] [diff] [review]
final final patch :)

>-<!DOCTYPE window SYSTEM "chrome://communicator/locale/pref/pref-advanced.dtd" >
>+<!DOCTYPE window [
>+<!ENTITY % brandDTD SYSTEM "chrome://global/locale/brand.dtd">
>+%brandDTD;
>+<!ENTITY % prefAdvancedDTD SYSTEM "chrome://communicator/locale/pref/pref-advanced.dtd"> %prefAppearanceDTD;
>+]>

prefAppearance?  Someone was copy/pasting a little too much:-)

Comment 48

[Mike Kowalski]

Attachment: final final final patch :)

fixed. please r=/sr=.

Comment 49

[Mike Kowalski]

Attachment: patch

fixed indenting problems. please r=/sr=.

Comment 50

[Christopher Aillon (sabbatical, not receiving bugmail)]

Ok cool.  You fixed the indentation for the most part (and got rid of the ugly
tab chars!).  Use the 2 space indent that the rest of the file uses and r=caillon.

Comment 51

[Mike Kowalski]

Attachment: patch

uses 2 space indents.

Comment 52

[Mike Kowalski]

Attachment: patch

Comment 53

[[e-mail] (gone - use [e-mail] instead)]

Attachment: Screenshot after the patch, showing cropping.

You're all spammed _to death_ by the n-N iteration of this bug, so I figured,
'Hey, what's one more screenshot'.  Anyways, we need to make sure this text
wraps.

Comment 54

[Mike Kowalski]

Attachment: patch

fixes the text wrapping problem.

Comment 55

[Mike Kowalski]

Attachment: patch

better patch.

Comment 56

[Ben Goodger (use ben at mozilla dot org for email)]

Do we not consider it important enough to mention that this overhead is incurred
at system boot? 

Comment 57

[[e-mail] (gone - use [e-mail] instead)]

Okay, I applied the latest patch, and the cropping text is fixed now - but we
should get an answer to Ben's question before proceeding, shouldn't we?

Comment 58

[Jatin Billimoria]

Overhead is variable and depends on the memory, CPU, and hard drive specs of the
user's computer. Mentioning overhead in a preference that claims to "improve
startup performance" seems contradictory and may confuse some users. Seems this
information is more appropriate in release notes, in my opinion, since it
affects some users more than others.

Comment 59

[Mike Kowalski]

I agree with Jatin. Saying that Quick Launch will startup when the OS boots up
should be placed into Help and/or Release Notes.

Comment 60

[Brian Ryner (not reading)]

Comment on attachment 91477 [details] [diff] [review]
patch

sr=bryner

Comment 61

[Christopher Aillon (sabbatical, not receiving bugmail)]

Comment on attachment 91477 [details] [diff] [review]
patch

>+      <vbox flex="1">
>+        <vbox class="indent">
>+          <description>&perfdescription.label;</description>
>+        </vbox>
>+      </vbox>

Why the two vboxes?  E.g., why can't you just do <vbox flex="1" class="indent">
 ?

>RCS file: /cvsroot/mozilla/xpfe/components/prefwindow/resources/locale/en-US/pref-advanced.dtd,v

>-<!ENTITY advancedTitle.label          "Enable features that help interpret web pages">
>+<!ENTITY advancedTitle.label          "Features that help interpret web pages">
...
>-<!ENTITY enableTurbo.label            "Enable Quick Launch">
>+<!ENTITY perfTitle.label              "Quick Launch">


Have you gotten these changes approved too?  They seem to be extraneous to what
this bug is about.  Correct me if I'm wrong.

I'm close to giving r= but I want these two questions addressed first before I
do so.

Comment 62

[Mike Kowalski]

Attachment: patch

Comment 63

[Christopher Aillon (sabbatical, not receiving bugmail)]

Comment on attachment 91738 [details] [diff] [review]
patch

r=caillon, carrying over bryner's sr=.	I'll check this in for you if you get
driver approval or the trunk is unfrozen ever again.

Comment 64

[Scott Collins]

Comment on attachment 91738 [details] [diff] [review]
patch

a=scc for checkin to the mozilla trunk

Comment 65

[Christopher Aillon (sabbatical, not receiving bugmail)]

Landed on the trunk.  Die bug die!  :)

Comment 66

[Grace Bush]

fixed..yea
trunk 2002071808