Need better install progress meter for win32 installer

RESOLVED INVALID

Status

defect
P2
minor
RESOLVED INVALID
20 years ago
3 years ago

People

(Reporter: cathleennscp, Unassigned)

Tracking

({helpwanted, polish})

Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [adt3 RTM])

Attachments

(2 attachments)

Blocks: 11020
Summary: install progress window for Windows Wizard → [feature] install progress window for Windows Wizard
Status: NEW → ASSIGNED
Target Milestone: M10
setting target milestone to M10
Summary: [feature] install progress window for Windows Wizard → Need better install progress window for Windows Wizard
Target Milestone: M10 → M15
This is has been added, but it's not the final look/feel that we might want to
give the users for RTM.

I'll leave this unfixed, but will update the Summary and Target Milestone
appropriately.
The main problem I have with the dialog is that the overall progress indicator
and the individual-file progress indicator are confused.

How about this:

+------------------------------------+
|Installing Mozilla :::::::::::::::::|
+------------------------------------+
| Total progress:                    |
| [########::::::::::::::::::::::::] |
|                                    |
| Time remaining: about 40 seconds   |
|                                    |
| Copying file: navigator.xul        |
| [######################::::::::::] |
|                                    |
|             ( Cancel )             |
+------------------------------------+

Note: The progress indicator for an individual file should *only* be shown if it
has been estimated (from current transfer speeds) that the rest of the file will
take at least two seconds to copy. Any shorter than that, and the indicator will
appear and disappear so quickly as to be useless.
adding polish keyword.

I don't think we should hold beta for this, but we had talked about getting the
changes in.  Do we have a chance of making it?


Keywords: polish
there's still a chance.
Status: ASSIGNED → RESOLVED
Closed: 20 years ago
Resolution: --- → FIXED
fixed.  There's no cancel button because the underlying engine does not have 
such a support (yet).  Everything else is there to make it have a better look 
and feel.
Well, that's better than it was before, but there's still some minor glitches.

* The overall progress indicator isn't nearly granular enough. When installing
  both browser and mail/news, the indicator only stops at ~3 points along the
  way. It should update more often, otherwise don't bother including it.

  Not updating it during prepare-file stages would be ok (presumably because you
  don't know how many files there are going to be), but during the copy stage it
  should update as often as the copy-file indicator. (So when installing both
  components, it could jump from 0% to 25% after browser files have been
  prepared, then slide to 50% during the copying of browser files, then jump to
  75% after mail/news files have been prepared, then slide to 100% during the
  copying of mail/news files.)

* The indeterminate-progress indicator, shown during the `prepare-file' stage,
  looks silly IMO, especially since indeterminate progress is already being
  shown by the rapidly-changing filenames. It might be better to hide this
  indicator except when actually copying files.

* In `Currently Installing xyz', the word `Currently' is unnecessary. Put a
  colon after `Installing' instead.

* In `Currently Installing MailNews', the `N' is underlined. Probably a typo,
  where it was meant to be the slash in `Mail/News'.

* When copying files for mail/news, the background of the second indicator goes
  white, whereas the rest of the time it's the UI default color (e.g. gray).

Reopening and downgrading to minor.
Severity: normal → minor
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
I wrote:
>
> * In `Currently Installing MailNews', the `N' is underlined. Probably a typo,
>   where it was meant to be the slash in `Mail/News'.

Actually, this happens in the component selection dialog as well -- click on 
`Mail&News' (why isn't it `Mail & News'?) in the component list, and the 
description shows the N underlined. I think this is where Windows assumes that a 
& character means the next character in the string should be underlined. So, 
before printing them in dialogs, you need to run component names through a 
procedure which escapes out any `&' characters so that they actually appear as 
`&' and not as underlines.
*** Bug 33356 has been marked as a duplicate of this bug. ***
mass change to M16
Target Milestone: M15 → M16
Target Milestone: M16 → M18
fwiw escape of & is &&.  To get it underlined use &&&.
Keywords: helpwanted
Depends on: 52052
Status: REOPENED → ASSIGNED
Priority: P3 → P5
Unsetting missed milestones to aid triage queries.
Target Milestone: M18 → ---
taking this one.
btw: is this only win32 or OS=all ?
I just assumed win32
OS: other → Windows 2000
QA Contact: gbush → gemal
Summary: Need better install progress window for Windows Wizard → Need better install progress meter for win32 installer
No longer depends on: 52052
well in theory for all, but it started out with Win32.  over to Curt.
Assignee: ssu → curt
Status: ASSIGNED → NEW
Target Milestone: --- → Future
*** Bug 137125 has been marked as a duplicate of this bug. ***
*** Bug 138486 has been marked as a duplicate of this bug. ***
*** Bug 138648 has been marked as a duplicate of this bug. ***
*** Bug 139145 has been marked as a duplicate of this bug. ***
nominating nsbeta1.

This ugly bug has been around forever, it needs to be cleaned up for rtm.  The
install progress bar (not the download one) has completely inconsistent behavior.

Sometimes it goes back and forth, sometimes it just goes left to right,
sometimes it is a solid bar from left to right, sometimes it is a smaller bar,
and yet other times the solid bar breaks in half, then comes back together, then
proceeds on.

ADT - please consider strongly for rtm, it makes us look sloppy.  Curt - have
you looked at this yet?
Keywords: nsbeta1
This problem in the installer is more obvious now days because the size of the
.xpi files have changed, thus changing the speed and size of the progress bar(s).

I've been wanting to fix this for the longest time, but its visibility was not
as much as it is now.  It think I know what's causing this.  Taking this.
Assignee: curt → ssu
Cool, thanks Sean.
Sean, Putterman mentioned that you might not be able to fix this because of
other committments.  You mentioned you know what is causing it.  Can you let me
know again if you can do it, or if you can pass it off to someone who can?

I would really like to get this plussed and adt rated asap.

Thanks!
Priority: P5 → P2
Discussed in Mail News bug meeting.  Decided to assign to Syd this bug.
Assignee: ssu → syd
*** Bug 149713 has been marked as a duplicate of this bug. ***
Syd/Dan/Sean/Grace/Henrik - This bug still was never triaged by the install
team.  I would like to suggest this as an ADT2. 

There was additional feedback since the release of 7.0 PR1 that reinforces how
sloppy this looks.  We should *really* fix it for rtm.

Would you agree to assign this bug an [ADT2]?
sure, why not: adt2. Not sure who's really going to do the work, though, nor how
you'd like it to look.
Assignee: syd → curt
Keywords: nsbeta1nsbeta1+
Whiteboard: [adt2 rtm]
Sean mentioned that he thinks he knows where and how to fix it.  My thoughts on
how it should look is that it should be consistent.

For each component, the bottom meter should progress left to right until the
component is finished.

The top meter shows the total progress and appears to be working fine.
A left to right meter is only possible when you know how long something is going
to take. The slopping back and forth is an attempt to show an "indeterminant"
state like the barber pole in modern, that is, we're still doing something,
don't kill us off.

The only left-to-right motion we could do was some random motion over and over
until we're done. Users might think something was supposed to change when the
bar got to the right, but since the top bar shows us unfinished I guess they
won't be expecting too much. I guess that'd be better than the "Oh no! it's lost
it's mind!" reaction we get now.

If we dropped the display of each filename it would probably go somewhat faster,
by the way.
Don't we know how many files are associated with each component?  Couldn't we
make a linear relationship and have each file of the component represent x% of
the total?  Granted it would probably be a little herky jerky because each file
has a different size, but it would probably be much better than it currently is.

I guess I would also be fine with it going back and forth as long as it was
consistent, but as I said in comment #19, right now it does about 4 different
behaviors.

If neither of these options were viable and worse comes to worse, I wouldn't be
opposed to removing the bottom bar altogether and just have the top overall status.
the part that we don't know (the sloshing back and forth) is because we're
uncompressing the files from the .xpi archive.  Right now, libjar does not tell
us how many total files there are.  If we could get that info, we can get rid of
the sloshing back and forth.  But this means a change in the libjar code.  Not
sure if we want this right now or not.
I dont really see the need for a progress on each component. Just have one
progres meter, a total one. Most users dont care about each component. Something
like this would be more helpfull:

Currently installing : XPCOM
Total Progres        : 0% [ooooooooooooo........] 100%
                                     55%
too late to be designing polish-type bugs that are marked future. nsbeta1-/[adt3
RTM] per ADT triage. let's keep our focus on high visibility adt1 bugs for
1.0.1, that will make this a slammin' release. thanks!
Keywords: nsbeta1+nsbeta1-
Whiteboard: [adt2 rtm] → [adt3 rtm]
It was only marked future because it is an extremely old bug and this drop down
box wasn't updated!!!  It was never turned off of future due to oversight!

Jaime - this bug has been around since 6.0, and something needs to be done about
it, even if the problematic bottom progress meter goes away entirely.  Something
needs to be done about it.

Renominating nsbeta1, removing ADT rating to get this back on radar.
Keywords: nsbeta1-nsbeta1
Whiteboard: [adt3 rtm]
Target Milestone: Future → mozilla1.0.1
ADT impact can be changed, from ADT3 to 2 or 3 (and, only after discussion with
the ADT), but NOT removed. Adding [adt3 RTM] back. Its still too late for taking
a polish bug that has not been designed, nor has consensus on how it should
work. --> Buffy

btw - only engineer can change the milestone, so setting that back to future,
less you have curt's buyin to do so.  If you do, pls feel free to change it back
to 1.0.1. thanks!
Whiteboard: [adt3 RTM]
Target Milestone: mozilla1.0.1 → Future
It doesn't need to be designed, just fixed.  There are several ways it can be
fixed which is what the discussion has centered around.

I have had talked about this bug with Curt, Sean, Dan, & Grace.  To avoid
butting more heads, I will follow up with them *again* to try to see the
feasibility.
Target Milestone: Future → ---
Posted patch patch v1.0Splinter Review
fixes the problem shown in the attached image.	this is not a rework of the
dialog at all.	just fixing up the broken progress bar.
marking nsbeta1- again.  
Keywords: nsbeta1nsbeta1-
Comment on attachment 86886 [details] [diff] [review]
patch v1.0

I see that I haven't been paying enough attention to this discussion.  It
appears that, although I really don't care for the sloshing back and forth
behavior, we are stuck with it for this release.  Sean, is it worth opening
another bug against this specific behavior (i.e., getting the progress bar to
always progress to the right), or are you saying it just isn't doable with what
we have to work with?

There also seems to be a need to generally redesign this dialog for some future
release.  How should be track that?  Should we leave this bug open for that
purpose, or open some kind of PRD requirement or what?

So, it looks like Sean's fix very specifically addresses only the odd behavior
wherein the progress indicator would sometimes be broken into multiple pieces. 
And it further appears that this is all we can reasonably address for rtm.  I'm
in agreement with this, have tried the patch out and am satisfied that it fixes
this one particularly egregious bit of behavior.  So...

r=curt
Attachment #86886 - Flags: review+
okay I've filed a new bug (bug 150678) to deal with the choppy/messed up looking
progress bar.


the attachments have been attached to the new bug too
QA Contact: bugzilla → ktrina
What is the current Situation, I still can find this problem in 1.3a???
Yes, the installmeter for 1.3a is still the same ugly one :-/

I think the progress meter is cool. 
Product: Browser → Seamonkey
(In reply to comment #36)
> Created an attachment (id=86886) [edit]
> patch v1.0
> 
> fixes the problem shown in the attached image. this is not a rework of the
> dialog at all. just fixing up the broken progress bar.

is this patch worth anything?

Assignee: curt → general
QA Contact: ktrina → bugzilla
QA Contact: bugzilla → general
against obsolete installer => invalid
Status: NEW → RESOLVED
Closed: 20 years ago12 years ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.