Closed Bug 86904 Opened 23 years ago Closed 22 years ago

Turbo mode wording doesn't indicate preloading

Categories

(Documentation Graveyard :: Help Viewer, defect)

Product:
Documentation Graveyard
Component:
Help Viewer
Platform:
x86
Windows 2000
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
VERIFIED FIXED

People

(Reporter: bugzilla, Assigned: jatin)

References

Details

(Whiteboard: [adt3]) 

I think we need to indicate to some degree how turbo mode really works.

The current wording is:

Enable QuickLaunch (requires reboot)

If anything, it needs to be somewhat explained in Help.  (Also, why does it 
require a system reboot?)
->paw/jrgm, for turbo qa.
QA Contact: sairuh → paw
That is something for release notes perhaps.

Startup folder items only get started on reboot, that's why the reboot.
Assigning over to tpringle.
Assignee: syd → tpringle
Component: XP Apps: Cmd-line Features → Mozilla Developer
Product: Browser → Documentation
Version: other → unspecified
We could very easily run mozilla -turbo when the installer finishes. but that 
probably belongs in a different bug.
bug 87028 deals with the preferences wording.
Blocks: 75599
Blake already fixed the bug that turbo required a restart (bug 89504).  
The pref text is now:

Enable features that affect performance
 [ ] Enable Quick Launch

Is this bug about text pref text or about documentation?  The summary seems to 
indicate the former but the product/component indicates the latter.
Blocks: 99488
todd - are we gonna do anything about this one?
I thought we already do explain this in Help.  Ccing Jatin.
The original bug is a bit obsolete, since we no longer require a reboot for
Quick Launch changes.

The following passage is from the Netscape online help under "Using Quick
Launch" and makes mention of Quick Launch memory consumption:

"When you installed Netscape, you were given the option of enabling or disabling
Quick Launch. If your computer is low in memory, or if you are have more then
one profile, you can temporarily or permanently disable Quick Launch to conserve
memory."

Is this good enough?
It seems like somewhere we should clearly say that QuickLaunch uses some of your
available memory, even when there are no windows open, in order to start the
browser more quickly when you need it.
--> evelyn
Assignee: tpringle → evelyn
Jatin - how about modifying the rel notes paragraph you mentioned to something 
like:

"When you installed Netscape, you were given the option of enabling or disabling 
 Quick Launch. When enabled, the Quick Launch feature will use some of your 
computer's available memory to be able to launch the browser more quickly. If 
your computer is low on memory, or if you are have more then one browser 
profile, you can temporarily or permanently disable Quick Launch."

I'll also investigate letting users know about the Quick Launch memory usage via 
some other means - e.g. in the product when they enable/disable the feature.

Do we need to mention profiles?  Very few users are aware of them, and there
should be no problems with them in QL, so this might confuse people unnecessarily.
Since we are talking about release notes, I think it isn't a problem to state 
that you cannot access multiple profiles via Quick Launch, but perhaps there's a 
better place to do it.  

Jatin, is there a better place in the rel notes (e.g. a section on profiles) 
where we can mention not being able to use multiple profiles when enabling Quick 
Launch?
If we don't resolve the problem fully in the UI (and I don't think we should or
will), the relnotes aren't the ideal spot for fully documenting the feature. The
online help can capture much of the details discussed here, in the relevant
sections on profiles and QL. And on the Netscape side, we can elaborate in the
printed end-user's guide. CCing jgorham for that.

We can also consider a tech article or even a tutorial on QL, for posting at
help.netscape.com. Our (Netscape) Help and Product Support page (the page that
appears when Help first opens) can direct users there. 
Agree, re: solving the problem in the UI.

1) Let's make brief mention in the rel notes as encapsulated by the paragraph 
below.

2) Let's make sure to include the information in the client-side Help feature.

3) Let's also include the info in the end-user's guide.

4) Steve - the tech article or tutorial sounds like a great idea and a nice way 
to supplement the Help menu info.  It isn't a top priority, but if your team 
would like to work/coordinate with help.netscape.com on something like that, I 
think it can only be beneficial to the end-user, while at the same time making 
the info available on the server-side.
What is the correct milestone to assign to this bug?  Leaving it as --- seems
wrong.  Shouldn't this also be nominated for nsbeta1?
->rudman
Assignee: evelyn → rudman
Blocks: 108795
Keywords: nsbeta1
-->Jatin. 

Can't set milestone appropriately yet---will ping Asa to adjust.

nsbeta1+.
Assignee: rudman → jatin
Keywords: nsbeta1 → nsbeta1+
--> qa tpreston@netscape.com
QA Contact: paw → tpreston
not much time left, is this going to make mozilla1.0?
As I understand it we're going to fix this in the Help content.  So the r/sr/a
process and tree branchings don't affect this, it's really only the deadline for
help content that matters.
Here is my suggested wording that will revise the Quick Launch section of
commercial online help:

-- REVISED TEXT --
When you installed Netscape, you were given the option of enabling or disabling
Quick Launch. Quick Launch loads part of Netscape into memory when Windows first
starts, and a part of Netscape will stay in memory after you close all Netscape
windows. This lets Netscape quickly start up when you need it, without having to
load all of Netscape. If your computer is low in memory, you can temporarily or
permanently disable Quick Launch to conserve memory.
-- END REVISED TEXT --

For the existing section that this wording revises, copy and paste the following
URL in the commercial build:
chrome://help/locale/nav_help.html#nav_quicklaunch

I think this wording resolves the need for release notes on Quick Launch,
especially given that profiles are less of a problem with Quick Launch now then
previously.
If this is not a UI fix, then I don't think the nsbeta1+ is valid. 

Removing keyword (as "nsbeta1-" is not appropriate, either). 

Leaving bug open for now for tracking. Will mark as resolved when help content
is checked in.
Keywords: nsbeta1+
Steve, I'm not sure I understand your comment. We are using nsbeta1+ for all
work that is needed for MachV, UI or otherwise.  While you may have some
arrangement that makes it unnecessary for help text changes, I don't think it is
invalid.
Peter, if we were tracking every discrete bit of content that really needed to
be added to the help content for Mach V, we'd have a helluva lot of nsbeta1+
bugs that currently don't exist, and I don't think we want them to exist. I
thought I'd be doing you a favor by getting the bug off of the nsbeta1+ radar.
It's only historical accident that the bug evolved into a purely doc bug (seems
like the original bug might have been for UI as well). 

In any case, I'll reinstate nsbeta1+. But if this bug is nsbeta1+, then there
are potentially many other bugs that should (or could) be opened with the same
designation.
Keywords: nsbeta1+
Steve- sorry, I wasn't trying to change your method, and certainly didn't mean
to imply you should be marking doc bugs any differently.  As I said, if you have
some arrangement for doc bugs that obviates use of nsbeta, that's fine with me,
it just sounded to me like you might be calling it invalid for other reasons.  I
guess I was still thinking this involved a UI change.  One more reason why I try
to avoid morphing...
Whiteboard: [adt3]
accepting QA for mozilla developer docs.

some of these bugs have been around for a _long_ time. Reporters, would you
please review the bugs, see if the issues have been resolved, and close bugs
appropriately.

I will do a full review of all bugs not touched in one week (8th April). 

Thanks.

</spam>
QA Contact: tpreston → imajes
Changing component to user.

Trying to get milestones updated for this product. Will update when able to.
Component: Mozilla Developer → User
No longer blocks: 75599
Blocks: 75599
The help now contains more information about how Quick Launch stays in memory.
Copy and paste the following link in commercial trunk builds to see the updated
section:

chrome://help/locale/nav_help.html#nav_quicklaunch

Marking FIXED
Status: NEW → RESOLVED
Closed: 22 years ago
Resolution: --- → FIXED
v
Status: RESOLVED → VERIFIED
No longer blocks: 99488
You need to log in before you can comment on or make changes to this bug.