87038 - Bad placement for the Quick Launch option [turbo]

Status: VERIFIED FIXED

(SeaMonkey :: Installer, defect)

Description

[Henrik Gemal]

Having the "Quick Launch" option in the "Start Install" screen is really bad. 
The Start Install screen is a screen to summaries what options the user choose 
in the installer. Please dont have any option in this screen.

I still think the best place would be the Component screen:
[ ] Mozilla Quick Launch
Description:
"Quick Launch will enable you to start Mozilla quicker by doing to magic stuff, 
bla bla bla.."

Comment 1

[Christoph]

I second that.  When I installed it this morning I totally passed it by, but
thought I saw something different there.  So I ran the installer again just so I
could really see what it was.  I also think the component screen is the better
place so you can see it right from the start.

Comment 2

[Matthew T (active 1999-2002)]

This checkbox needs more explanatory text anyway. And Hendikins pointed out to 
me that the installer also doesn't have a checkbox for whether you want Mozilla 
to be your default Web browser or e-mail program.

Therefore, I suggest a new page be added to the installer, between the page for 
component selection and the page summarizing your choices. The new page can 
contain both these options.

Comment 3

[Michael Hendy (Hendikins)]

That option is probably the neatest way to do it...

Wherever it goes, definately not the summary screen...

Comment 4

[Syd Logan]

Lame on all claimed need for verbosity. Extra text is for the manual, or a help 
button -- let's not write books directly in the UI.

Comment 5

[Syd Logan]

Got a spec from [e-mail] -- will get to work on it.

Comment 6

[Henrik Gemal]

where is the spec? can you post it, if it's not available on mozilla.org

Comment 7

[Syd Logan]

Attachment: patch that implements a new panel

Comment 8

[Syd Logan]

German, this basically implements your spec. modulo the gifs and incorporating 
the text that docs came up with.

Comment 9

[Syd Logan]

Attachment: what it looks like (I know, needs some vertical spacing work).

Comment 10

[Syd Logan]

Attachment: Oops, config.ini changes (didn't make the diffs)

Comment 11

[german]

The UI spec for the Quick Launch feature is posted at 
http://mozilla.org/projects/ui/communicator/framework/quicklaunch/,
going a bit beyond what's going to go into the next Netscape release.

Comment 12

[Blake Ross]

Missed 0.9.3.

Comment 13

[Matthew T (active 1999-2002)]

German, all the pictures in your spec are missing.

Comment 14

[Daniel Veditz [:dveditz]]

Syd, aren't you working on this one? marking nsBranch for tracking, remove if
I've gotten it wrong.

Comment 15

[Daniel Veditz [:dveditz]]

It'd be better to have ssu review the wizard code changes so I'll limit my
comments to:

- the "config.ini changes" attachment is the whole file, pretty unreviewable.
Please attach a diff of config.it instead. We'll also need to see the commercial
diffs somewhere; since that probably only consists of config.ini changes I think
it's safe to post those to this bug.

- more context in the diffs is better. "cvs diff -u10" for example. some
super-reviewers demand -20 for code in areas outside their expertise.

- We should scratch "When possible, " from the checkbox option, it's lame and
confusing to the user. The main reason for the hedge--inability to work with
multiple profiles--is fixed or nearly fixed.

Comment 16

[Syd Logan]

Attachment: config.it diffs

Comment 17

[Sean Su]

Attachment: patch that has the state of the dialogs working properly (only dialogs.c diff)

Comment 18

[Sean Su]

r=ssu for syd's patches (per our conversation).  The patch I attached contains 
fixes to the dialog state logic given the new Quick Launch dialog (from Syd's 
patches) in the installer.

Syd, don't forget to check in ns's version of config.it as well.

Comment 19

[Blake Ross]

I would appreciate if we could go the extra mile here and fix up the UI a bit,
to more closely resemble German's spec.  We already have an image of the icon in
the system tray similar to the one in his spec.  There's no need to try to fill
the entire panel up if it means adding unsightly vertical spacing.

Comment 20

[Syd Logan]

Blake, the space is there waiting for German to get off his butt and give me the 
artwork I asked for :-)

I figured it would be better to get the code in so we can exercise it; when the 
art comes along (German: hint hint :-) I will land it.

Comment 21

[Scott MacGregor]

sr=mscott

Comment 22

[Asa Dotzler [:asa]]

a=asa on behalf of drivers

Comment 23

[Syd Logan]

Fix is checked in, keeping open however until I get artwork from German

Comment 24

[Syd Logan]

Reassigning to German. German, can you attach a bmp for me? Then reassign back
to me. Thanks.

Comment 25

[Blake Ross]

Why does German need to provide the screenshot of the system tray?  I mean, I
know it says that at the top of the spec, but it can be obtained easily by
running turbo, taking a screenshot, and cropping appropriately.  That's what I
did for the screenshot I used in the alert you get when you close the last
window while running turbo, and in fact, that image is in the tree (well, in the
branch right now, soon to be on the trunk), so you can use it.  Note that it
doesn't use the pretty N icon shown in the spec, but there's another bug on
that.  Also, still, why is there so much space in the current panel?  Per the
spec, all of the space in the panel does not have to be filled.  The checkbox
shouldn't be at the bottom of the panel, but just right under the image.

--> syd

Comment 26

[Syd Logan]

Blake, don't interfere :-)

I had a discussion with German, he wanted to provide specific artwork (not just
a screendump).

Reassigning to german.

Comment 27

[Blake Ross]

It doesn't look like we're getting the image soon if it's already been a month 
and a half, so the image in the tree is the image we're using in the dialog.  So 
I don't understand why we wouldn't go ahead with that image now, since there's 
nothing wrong with it.  Or, I don't understand why we don't just get rid of the 
giant vertical spacing, since I don't see why we have to 'prepare' for an image 
that might not come for this release.

Usually what happens with these types of bugs is that no one does bother to 
interfere, something suboptimal gets checked in, and then the bug to bring it up 
to par with professional quality UI drifts away because 'what we have is good 
enough'.  That's why we get things like oversized pref panels that go through 5 
revisions before its UI that you might find in an application like Microsoft 
Word.

My two cents.

Comment 28

[Suresh Duddi (gone)]

I think we should nsbranch- this. Syd ?

Comment 29

[Jaime Rodriguez, Jr.]

Syd - nsbranch- this one per suresh's and blake's comments. pls give it a plus,
if you disagree.

Comment 30

[Blake Ross]

Per my comments?  No, my comments (since one month ago yesterday) asked that we
use the artwork that is already in the tree, that we are using in the exit
quicklaunch dialog (and that MSN Messenger and AIM), and that we will continue
to use, rather than waiting for airbrushed artwork that is inexplicably better
than an exact screenshot of what users will see on their screen.  Unless you're
referring to my 9/1 comments, where I expressed the opinion that if we didn't
use that art, this bug would lay dormant for at least one release, leaving us
with a suboptimal UI that refers users to `the icon' in the systray, as if they
have just one icon.  I also there noted that the bug to fix the UI would drift
away because `what we have is good enough', and now we're forced to minus this
bug, because what we have is good enough.  The irony is stinging.

Comment 31

[Peter Trudelle]

I feel bad about this too Blake, but triage criteria has to become much more
risk-averse as we approach RTM, or nothing would ever ship due to endless
changes and resulting regressions.  IMO, this bug clearly does not fit the
profile that PDT would approve (crash, data loss, major feature broken). 
nsbranch- to get it off the radar, appeal directly to PDT if you wish.

Comment 32

[Asa Dotzler [:asa]]

unsetting target milestone and reassigning to default owner
(<[e-mail]> email bounces so I'm assuming he's not really owning this
bug)

Comment 33

[Henrik Gemal]

isn't this fixed?

Comment 34

[Blake Ross]

Yeah, fixed. We can file separate bugs on other issues, right?

Comment 35

[Henrik Gemal]

verified fixed