89907 - Need to make it easier for users to make us their default browser

Status: VERIFIED FIXED

(SeaMonkey :: UI Design, defect)

Description

[Blake Ross]

Setting default browser
-----------------------

Internet Explorer:

  - Open Internet Options
  - Click the Programs tab.
  - Click the Reset Web Settings... button (the text next to it doesn't even
    indicate that it's going to reset your default web browser).

  To ensure that it remains default:

  - Check "Internet Explorer should check to see whether it is the default
    browser"

Netscape 6.1:

  - Open Preferences
  - Expand Advanced
  - Go to System
  - Check off the file types and protocols Netscape should handle

  To ensure that it remains default:

  - Alert me if other applications change these settings

In exchange for giving a couple power users some advanced options, we're
basically ensuring that users will never manually change their default browser
later on.  Yes, we can keep the advanced settings, but come on -- we can be more
competitive than this.

Adding insult to injury, IE recommends that users reset their web settings "to
protect them" if other browsers change their settings:

"If you installed another Web browser after installing Internet Explorer and
Internet Tools, some of your Internet Explorer settings may have changed. You
can reset your Internet Explorer settings to their original defaults, including
your home page and search pages, and choice of default browser, without changing
your other browser's settings. "

Right, like users could have installed another browser BEFORE "installing" IE. 
In other words, their Help recommends that users reset their web settings when
installing another browser, thus ensuring that IE remains their default.

Comment 1

[Blake Ross]

6.1pr1 user feedback:

"I do not know how to get Netscape 6.1 to be my
default browser.  HELP@!!"

"I have to have a default browser open an offline
program that is pushed by Xitami and I can not
make netscape 6.1 as my default browser.  How can
I do this??"

Comment 2

[Blake Ross]

usability/polish, 0.9.4.

Comment 3

[Dimitrios]

>Yes, we can keep the advanced settings
I like that. For a power user, current implementation is the best I' ve ever seen.  
And where will this "reset" button be positioned? It seems to me that there' s
no option except creating a new preference category where current
Preferences>Advanced->System should be moved.

Comment 4

[Peter Trudelle]

Mass moving lower-priority bugs to 0.9.6 (with Blake's pre-consent) to make room
for remaining 0.9.4/eMojo bugs and MachV planning, performance and feature work.
 If anyone disagrees with the new target, please let me know.

Comment 5

[Gervase Markham [:gerv]]

We could start with a button on that dialog, marked "Make &brandShortName; my
default browser", which was backed with a bit of JS which checked a certain
number of options on the dialog. Then, when the user clicked OK, the Right Thing
would happen. It's not as easy as IE, but it's a start.

Gerv

Comment 6

[Todd Pringle]

Gerv's idea sounds okay, we recently changed the "windows integration" dialog to
be a more straightforward "Would you like to make Netscape/Mozilla your default
browser?", so a pref that mirrors this dialog exactly (and gets checked when you
answer yes to this start-up dialog) would probably be good.  Blake, what do you
think?  I know you're a big fan of more prefs.

Comment 7

[Blake Ross]

I think the problem is that users are not finding the Advanced -> System panel 
at all, or if they are, they're not understanding how to use it. I would much 
prefer to see a checkbox in the Navigator panel, which is highly visible, 
something simple like "Use Mozilla as my default browser," which would check 
off the appropriate file extensions in the System panel. Of course, the 
interaction between these two would be weird (checking the checkbox but leaving 
the boxes in System unchecked, and pressing OK)

Comment 8

[Hixie (not reading bugmail)]

I'm going to assume we really really want to be the default browser. 'We' in
this case being especially one of the Mozilla distributors, namely Netscape.

I think we should add a checkbox to main panels of "Navigator", "Composer" and
"Mail & Newsgroups" which would simply check or uncheck the relevant things
under "Advanced|System" (no weirdness -- they would always be consistent with
each other). (This is basically blake's idea.)

I then think we should add a menu item just before "Preferences" in the edit
menu of each app, something along the lines of "Set As Default Browser", "Set As
Default Mailer" and "Set As Default Editor". This item would *only* be visible
if we were not the default, so for most of our users there would be no
difference, but for users that have not set us as default, you would have the
equivalent of a shareware application's "nag".

These menu items would bring up a dialog like this:

   :: Set As Default ::::::::::::::::::::::::::::::::::::
   :                                                    :
   : ~~+++  Would you like to set Netscape Navigator    :
   : ~~+++  as your default web browser?                :
   : ~~+++                                              :
   :                                                    :
   : To change your default browser settings in more    :
   : detail, use the "System" panel of the "Advanced"   :
   : section of the preferences dialog.                 :
   :                                                    :
   : ( Open Prefs )    (( Set As Default ))  ( Cancel ) :
   :....................................................: 


mpt will kill me for this, I'm sure.

Comment 9

[Blake Ross]

Cc'ing other UI types.  As the app improves, it's likely (hopefully!) that more 
and more people will want to set it as their default.  Would be a shame to let 
this go unfixed another release.

Comment 10

[Blake Ross]

On IRC, I was saying that we should just fix the behavior of our "Do you want 
to make Mozilla the default?" dialog, since it currently gets lots behind the 
other windows (in IE, the browser won't open until you dismiss the dialog.)

But Ian pointed out that many users probably don't want to make the app default 
until they use it and see if they enjoy it, so many will probably check "Don't 
ask me again," so many won't get to see the dialog again, so this remains a 
problem.

Comment 11

[jglick]

Agree with Blake's comment #7. Average users will most likely stay away from the 
Advanced prefs. Even if they somehow manage to get to the Advanced:System panel, 
its probably not apparent that checking All the options will cause the product 
to be your default browser.

Agree a simple, "Use <productname> as the default browser application" at the 
top "Navigator" pref level would be the best. This is probably where users would 
expect to find such a setting. (Maybe an Advanced button associated with this 
setting allows users to further customize which extensions/protocols)

Top level Mail pref panel currently has: "Use <productname> as the default Mail 
application".

Comment 12

[Peter Trudelle]

Don't most users stay out of prefs entirely?  I've heard the 80/20 rule invoked
here, and tend to believe it, especially now that we've got our mail account
info out of prefs.  Much as I personally dislike it, I think we still need to
rely on the Windows Integration dialog to aggressively ensure that users either
enable 'us', or explicitly indicate they don't want to, and also that they don't
want to be asked about it anymore. Those settings should map to simple
check/make prefs.  This is how <dominant product name> works.  

Comment 13

[Blake Ross]

I honestly don't know, do they?  Lots of users reported looking in prefs for
this, for clearing history, and for other things. I agree that the dialog will
be the most important thing here, and we need to improve its behavior, I just
think a simple checkbox in the Navigator panel will be more effective than a
buried Advanced panel for those that do open prefs.

I would be interested in seeing stats on how many users ever open prefs, even if
they don't switch panels.

Comment 14

[Peter Trudelle]

Reports from lots of users is unusual too; my usual rule of thumb is that only
10% of users have any idea what newsgroups are (and most of them lurk >90% of
the time), and that  much less than 1% of even mozilla users ever file a bug.
That would mean we don't really ever hear from 90% of users, unless we make some
effort to reach them.   I don't have any issue with adding a simple, top-level
pref, I just want to make sure it is clear that it is not intended to solve the
typical-case problem.

Comment 15

[Blake Ross]

Yeah, I know, I should have clarified -- "lots" of users in the newsgroup.  As
this is personally my only connection with real end users, I'm constantly
referring to it.

When I say "newsgroups", though, I mean the feedback newsgroups, which consist
of feedback submissions sent by users from the netscape.com form. It's not
really a technical process (Help | Feedback Center), so I wouldn't consider the
reports as being from highly technical users, with the caveat of course that
most users in general don't submit feedback.

Comment 16

[jglick]

Yeah, its true lots of users never touch Prefs (I don't know percentages). And 
even fewer submit feedback. But, if a user was aware products have Prefs and was 
specifically trying to find this setting, they are more likely to find a simple 
top level checkbox than the current implementation. Windows integration stuffs 
is good too. :-)

Comment 17

[Todd Pringle]

I agree with Peter that we need to rely mostly on the Windows Integration dialog
to perform this function, but I am not averse to adding a simpler top level pref
in Navigator, which is the place most users will open up to when they hit
Edit>Preferences (as most do it from the browser I'm guessing).

Comment 18

[Hixie (not reading bugmail)]

Are there any strong objections to my proposal of a menu item in the Edit menu
which we remove once we are the default? (See comment 8 for an explanation.)
I think that (in addition to a single prefs checkbox per component and the
current advanced prefs panel) would be the most effective but non-intrusive way
of publicising this feature.

Comment 19

[Matthew T (active 1999-2002)]

Yes, I object. (1) I think the irritation caused by a `Set as Default Browser' 
menu item staring people in the face whenever they chose `Copy', or 
`Preferences...', or whatever, would be greater than the benefit caused to 
those for whom Mozilla had inadvertently lost its default browser status. 
(Especially while Mozilla, or any distribution thereof, is still in a state 
where most people who use multiple browsers at all will be using Mozilla as an 
alternative browser rather than as their default.) (2) Alerts should be avoided 
if at all possible, and one of the type Hixie drew -- that is, one which asks a 
question -- should only be used if the user is in danger. This is tenuously 
true (danger of confusion) if Mozilla discovers on startup that another app 
took its default browser status, but for it to unfailingly come up in response 
to a particular menu item is pretty rude. (3) An (effectively boolean) menu 
item which is shown or hidden depending on its own state? Naaaah. You know why.
<http://developer.apple.com/techpubs/mac/HIGuidelines/HIGuidelines-25.html>

In the long term, this bug can get fixed by redesigning the Preferences dialog 
to get rid of the `Advanced' branch (and all branches), since Mozilla still has 
the 4.x problem that people don't know there's anything inside collapsed 
categories (hence comment 1). In the short term, I think it makes sense for the 
pref about whether *Navigator* is your default browser to be in the main page 
of the *Navigator* branch -- I'm pretty sure that's where I'd look for it if I 
was a beginner. (Insert disclaimer about losing perspective completely after 
having used Mozilla for too long.)

[/] Use Navigator as the default Web browser  ( File Types... )

Comment 20

[Hixie (not reading bugmail)]

mpt: The problem is that the majority of people don't open preferences, and thus
we can only use prefs for this if you do not assume that market share is a top
priority. Unfortunately, for certain distributors, market share is the only
reason they are in the game.

I don't see that perceived stability is relevant here, since this is a one time
deal, not a regular occurance.

With recent releases, we have reached a point where people seriously DO want to
use Mozilla (or deriatives) as their default browser. They install us, say "no"
to setting us as default, try us out, then want to set us as default but can't
see how. Feedback which blake has summarised for me (from Netscape 6.x feedback)
strongly suggests that users do not consider looking in prefs.

The menu item will no more be in the face of people using the Edit menu than any
other item, and, in addition, will only be in the face of those who have not yet
set us as default. We *want* those people to be reminded that we can be  set as
default. That's the whole point.

Regarding the alert: this _is_ a potentially dangerous (or at least confusing,
which is the same thing in the mind of new computer users) situation. If the
user suddenly finds a UI element (double clicking on an HTML file, clicking on
an internet shortcut, whatever) launches a different application, then he can be
very disorientated. (I've seen extreme examples of that happen with my mum.)
Since menu items can be clicked accidentally, you need some sort of protection.
It's no good saying "undo" should undo it since for most users they won't know
it happened until days later, when they next try to launch the default browser.

I am not against finding another solution to this problem, but that solution
cannot use prefs, because as I said above -- many people don't open the prefs
dialog at all. For most things that's ok, we can just say "tough luck for them,
they should learn". However, here it would be tough luck for us.

Comment 21

[Peter Trudelle]

I guess it could be a good thing, as long as each menu item only appeared in the
corresponding component, and only when it is not set as default.  Using the
browser with some other mail user agent, or without ever using the editor, is
typical case, and should not come with the penalty of an extra pair of menu items.

Comment 22

[Hixie (not reading bugmail)]

Oh absolutely, the menu items would only be in their own component's Edit menu.

Comment 23

[Bernd]

Attachment: M?$%&&t screenshot

Comment 24

[Bernd]

I disagree with hixies proposal even with his problem description. What is this
Microsoft dialog if it is not a preference panel? So the average MS user is able
to handle the preference panel but is not able to handle another prefernces panel?
Hmm maybe she/he will not be able to handle our preference panel because it is
so techie. But then the solution is to reorganize the preferences and not to
spam the  menus. The menu solution will be especially nice for all developers
having more then a single browser on their system, they will have NN and mozilla
fighting for world domination and the menus will change due to changes in the
other program. This will be the ultimate menu-blink implementation. Further I
think our menu's are already too long. 

Comment 25

[Matthew T (active 1999-2002)]

Hixie, I want Mozilla to gain market share as much as anyone does, otherwise I 
wouldn't be here. But I believe the route to that goal is not through annoying 
everyone who is just trying out a Mozilla distro, or who has decided *not* to 
make it their default browser just yet, or who is running >1 Mozilla distro at 
once, by including desperate-looking (and vastly menu-widening) menu items.

> They install us, say "no" to setting us as default, try us out, then want to
> set us as default but can't see how.

I assume(/hope) the current alert about default browser-ness waits until the
*second* launch, rather than the first launch when the user almost certainly 
won't know the answer. If that's not true, please file a depending bug.

As for your alert, its rationale -- it's easy to click the menu item by mistake 
-- is a screaming clue that it shouldn't be a menu item. Unlike some things 
currently in the Preferences dialog (PSM certificates, security devices, etc), 
default browser-ness really *is* a pref. And it's not something (like images or 
Javascript) which even an advanced user would want to change on a page-by-page 
basis. So it really *does* belong in the Preferences dialog and nowhere else.

Yes, the Prefs dialog is scary, but if you spray infrequent preferences around 
the menus as well, you don't make the dialog any less scary; all you do is make 
the whole of Mozilla more scary. If you want more people to go into the Prefs, 
then (1) put candy in there which they want to use (e.g. the Scripts & Windows 
panel, or minimum font size), and (2) ask me for a spec to make the whole 
dialog much simpler. To tweak Orwell: `If there is hope, it lies in the Prefs'.

Comment 26

[Hixie (not reading bugmail)]

Bernd: The average IE user doesn't have to set IE as default because it already
is the default. While that would be even better, we cannot do that.

So IE does not have this problem.


mpt: The number of people running more than one Mozilla distribution at once is
completely negligible. And candy *inside* the prefs window won't help, because
users don't even open it in the first place, if user feedback is anything to go
by. I don't think my proposal is the ideal solution. I'll be the first to admit
that. However there hasn't been any better solution proposed.

Comment 27

[Peter Trudelle]

Bernd has a good point - we really need to put the Prefs dialog on a
prescription diet, wire its teeth shut, and staple its stomach.  It is causing a
host of defects, and usability/performance problems.  Everyone repeat after me
"Hi, my name is _ _ _ _ _, and I'm a pref-aholic."

Comment 28

[Hixie (not reading bugmail)]

trudelle: The prefs dialog is a known bug. See, e.g., bug 61362. However whether
or not our prefs is overcomplicated or consists of just a single panel with a
single checkbox "make this browser the default", it won't help us if people
don't open it in the first place. :-)

Comment 29

[Peter Trudelle]

Hixie: Sure there are bugs on prefs already, I wasn't trying to morph this one,
but they are related in that a common reason why many people don't go there is
that it is so complex as to make the thought of changing anything there
frightening.  If people had to pop the hood on their car, and start
reconfiguring the wiring  to change the radio station, most cars would be tuned
to whatever station the dealer wanted.   As my wife puts it "Its too much crap!"

Comment 30

[Hixie (not reading bugmail)]

The impression I get, though, is that people are not even _trying_ to look in
the prefs. As I said, even if we made our pref panel consist of just a single
checkbox "make this browser the default", I am not convinced people would
suddenly decide to try looking in prefs. I could be wrong of course. It would be
good to do usability testing on this issue.

Comment 31

[rudman]

See also http://bugzilla.mozilla.org/show_bug.cgi?id=86913, which is a bug about
the lack of documentation on the issue (and thanks hixie for the x-ref from that
bug to this one).

The UI could no doubt be improved, but certainly having some documentation on
the issue would help. 

We're all shooting from the hip (or lip), in the absence of usability studies,
regarding what the UI should be. But certainly making the "default mail
application" and "default browser" prefs selections consistent (with regard to
terminology and where the prefs are located) would be a usability win. And
adding documentation would help as well, and reduce the need for a menu option
in addition to a pref panel. (And in case I need to say it: Please, don't
respond with unsubtantiated assertions about whether users read release notes or
online help.) 

Comment 32

[Todd Pringle]

Nominating nsbeta1.  Outbound marketing has a very strong interest in getting
this one fixed.  We need to make it as easy as possible to set Netscape as the
default.

Comment 33

[Peter Trudelle]

Or mozilla, as the case may be. Blake, do you want this bug? It seems to be more
in Bill's or Ben's area.

Comment 34

[Peter Trudelle]

nsbeta1+/adt2

Comment 35

[Blake Ross]

-> bill

Comment 36

[Blake Ross]

so what are marketing's/UE's recommendations for fixing this?

Comment 37

[Peter Trudelle]

I don't know of any spec, but since we now have dialogs that appear on component
startup (at least for Nav and Mail), the main thing left that I've heard
discussed is a top-level (for discoverability) UI pref that will do the same
thing.    Designers are cc'd, perhaps they could comment here?

Comment 38

[jglick]

See my comment #11. I still think a simple, "Use <productname> as the default  
web browser" at the top "Navigator" pref level is the best solution. Along with 
the existing dialog that asks users if they want us to be their default web 
browser on first usage (and if default status was recently removed). This would 
parallel the existing Mail behavior.

I don't think using a menu item to turn a pref on is a good idea. Menu items 
don't just disappear once a user turns them on.

Comment 39

[Peter Trudelle]

So, would 'browser' exclude mail, composer?  Details (such as which panel, and
exactly where on the panel) would help avoid problems.  Also, how does this
interact with the prefs in the advanced panel?

Comment 40

[Bill Law]

Here's is what I'm going to implement:

* Add a checkbox to the Navigator main panel.  The checkbox will
  be labelled "Use <product-name> as the default web browser".

* Checking the checkbox will:
    - Force the "HTML Documents" and "XML Documents" file type settings on,
    - Force the http, https, and ftp internet shortcut settings on
    - Both of these items refer to setting shown on the Advanced/System
      pref panel,
    - All other setting will be left as-is.
    - Pressing OK will then "commit" the current settings to the Win32
      registry.

I'm not sure there's *room* on the Navigator panel, however...  I'm going to 
try to fit this, sans group box, below the "toolbar button" checkbox group.

Comment 41

[sairuh (rarely reading bugmail)]

yeah, the Navigator panel is woefully crowded. there's a chance that it'll cause
the beloved "content won't fit" issue to crop up (again), depending on the
theme, platform and screen resolution...

Comment 42

[Bill Law]

Attachment: Patch to add checkbox to Nav panel

Comment 43

[Bill Law]

Comment on attachment 83143 [details] [diff] [review]
Patch to add checkbox to Nav panel

This is a first draft; it still needs some work.

See follow-up comment.

Comment 44

[Bill Law]

I've added the checkbox and have made it work in a reasonable fashion.  But 
there's still, um, "issues."

First, the checkbox state, on initial display of the Nav panel, only indicates 
whether 6 specific "advanced" checkboxes are checked.  It doesn't indicate 
anything about whether the Win32 registry matches those checkbox settings.  
That is, if you let IE become your default browser, then when you open the Nav 
panel, the checkbox will be checked (presuming you haven't gone into 
Advanced/System and unchecked something).  This might mislead the user into 
pressing Cancel to close Prefs.

Another issue relates to adverse interactions between this panel and the 
Advanced/System panel.  If you open the latter, then it is possible that 
changes applied by the Nav panel are undone when the code on the other panel 
does its thing.

We've hashed out the issues some and have arrived at the following as 
the "ideal" solution:

1. Eliminate the Advanced/System panel (yeah!).
2. Add the checkbox (labelled as suggested here) to the Nav panel.
3. Add an additional pushbutton to the Nav panel, labelled "Advanced..." 
(or, "Default Browser Preferences..." except that's too long).
4. The Advanced... button opens a dialog, entitled "Default Browser 
Preferences" that looks basically like the current Advanced/System pref panel.  
3 & 4 help to tie together the simple "Make me your default browser" setting to 
the detailed/advanced preferences.
5. On initial display, the Nav panel checkbox means "Win32 is configured to 
implement my Default Browser Preferences."
6. Changing the Nav panel checkbox from unchecked to checked means (when the 
user finally presses Ok on the Pref window): "Configure Windows so that it 
implements my Default Browser Prefs."
7. Changing the Nav panel checkbox from checked to unchecked means (on eventual 
Ok): "Restore the Win32 registry settings that you set when you previously 
applied my Default Browser preferences."
8. Neither 6 nor 7 change the "default browser preferences" in any way.

The only thing (off the top of my head) that doesn't make sense is this:  What 
if the user:
a. Opens prefs to the Nav panel.
b. They have certain default browser prefs selected and the Win32 registry 
matches.
c. The checkbox is checked initially (see rule 5, above).
d. The user presses Advanced...
e. They select another item (e.g., "gopher:" that was previously unselected).
f. Win32 is set up to launch wingopher.exe on gopher: URLs (internet shortcuts).

Does the checkbox change state when the user closes the Default Browser 
Preferences dialog?  It seems like it would have to (to indicate to the user 
that they need to take action).  But would that be confusing?

Ditto the converse situation (the user unsets a setting that was previously 
set).  Does the checkbox change state to reflect that?

I'm not sure how we want to deal with this.  Guidance from UE would be helpful 
at this stage.

Comment 45

[Peter Trudelle]

I agree with your last paragraph :-), and I don't think we want to be making
large changes, like removing a pref panel and adding a dialog, at least not in
the current release.

I think we're getting too caught up in edge cases, and the result is a very
complex user model.  Let's all read the summary again.  It seems like a simple
'Make this app default browser' checkbox on the Nav panel would suffice, linked
to several checkboxes on the Advanced/System panel.  Default case would be that
we check them all.  If the user unchecks the Nav panel pref, then we clear the
A/S set, and restore the registry entries to their previous states.  If the user
checks it, we set them all.  In any case, we always keep them internally
consistent, and synched with the registry.  This should handle the vast majority
of cases, where the user goes no deeper than the top level of prefs, and the
only possible results are a)make this app default, or b) restore previous
defaults. (Perhaps we should consider surfacing this in the UI, clearly
indicating we are changing the default back to IE or whatever?)

For those few brave explorers who venture into the wilds of the A/S panel, we
need to have logic to map changes to the pertinent checkboxes there back to the
Nav panel pref.  If, for any reason and at any time, some of the A/S prefs are
checked and some are unchecked, then we could use a tri-state checkbox set to
[-] for the Nav panel pref.  I'm not sure if that is possible, but let's ignore
that for a moment.  If, at any time, the A/S prefs are all unchecked, then we
clear the Nav panel pref.  If they all get set, we set the Nav panel pref.

So, in your examples, the user would never have to take additional action after
changing an A/S checkbox, we would always update Nav panel pref and the registry
to reflect the new setting.

Now, if we can't have a tri-state checkbox, could we instead just add a simple
"Make default" button that sets all the A/S prefs?  I don't see why we'd need to
make it easy to restore the previous default anyway.

Does that cover all possible cases clearly?

Comment 46

[Peter Trudelle]

We need to decide on this quickly, it it is to make RTM.

Comment 47

[Bill Law]

Attachment: Navigator pref panel; state 1 ("Set As Default" button enabled)

This is what the user would see when Mozilla is not currently set up as the
"default browser."

This is the only layout that I could get to fit.  If somebody has a better
solution, please let us know.

Comment 48

[Bill Law]

Attachment: Navigator pref panel; state 2 (after pressing "Set As Default")

This is what the pref panel looks like immediately after the user clicks the
enabled "Set As Default" button shown in the prior attachment.

Comment 49

[Bill Law]

Attachment: Navigator pref panel; state 3 (when Mozilla is already the default browser)

Finally, this is what it looks like when Mozilla is already the default.  The
button is disabled.  Note that the text is different than in "state 2" (after
pressing "Set As Default" but before pressing Ok).  The intent is to not
confuse the user into thinking that pressing "Set As Default" completed that
task (which might happen if we changed the text at that point to what appears
here).

Comment 50

[Bill Law]

Attachment: Updated path (complete)

I think this is everything (there's a bit of code scattered in a few places).

I'll work on an annotated version of this patch file explaining what changed
and why.

Comment 51

[Håkan Waara]

I think you should make the description and button invisible when the Mozilla is
already the default, rather than showing some unnecessary disabled text.

Comment 52

[Sören 'Chucker' Kuklau (gone)]

#47 - #50
The shots are confusing.

The first one is *acceptable* (i.e. I can tolerate it). The groupbox is called
"defaults", and this is about a *default* browser. But how is a home page a
default? It's not the default home page we're talking about in that groupbox,
but instead the *user* home page. So these two simply don't fit together.

The second one shows the same problem... I'm seeing several widgets related to
the Home page, and then the message that Mozilla will soon become my default
browser. You could as well put the message "you've got 3 new e-mail messages"
below there.

The third, and last, one is the worst. "Mozilla is currently set as your default
browser". Ah yeah? And? What does this have to do with the Home Page, or the
Toolbar buttons, or the navigator startup page?

This is a no-go idea. I know space is tight on that panel, and I know we don't
want to add yet another panel. But do *not* put it in the "Home page" groupbox
and then re-name the "Home page" groupbox to "Defaults". The Home page *isn't* a
default, nor is it related to default browser settings.

Comment 53

[Blake Ross]

I agree, a Defaults groupbox doesn't make much sense.  Are you *sure* we don't
have enough space to just add a new groupbox, or perhaps a groupbox-less
checkbox?  In my commercial build, the panel is indeed full, but that's only
because half of the "Select the buttons you want to see in the toolbar" is just
empty space.

	Netscape 7.0 PR1 Suggestion
 
Primary Browser: 	ntsc62  
Language: 		English  
Component: 		General
Suggestion Category: 	Improvements  
Issues Details: 
I want to make Netscape 7.0 my default browser,
but there doesn't appear to be any way to do so
after I declined that option in the initial set
up.  How do I make it my default browser??

Comment 54

[Sören 'Chucker' Kuklau (gone)]

Attachment: Current look of Navigator Preferences panel on trunk (for Blake)

Looks like this on a trunk build of 2002-05-25-13. We could decrease height of
the startup groupbox by putting the boxes beneath of each other, but IIRC, that
would make a mess on Netscape commercial builds since they have more options
there. Just making the toolbar buttons groupbox smaller won't be sufficient, I
guess.

Slightly off-topic, I've recently come across to a bug about decreasing height
of the panel name headers (in this case, the large bold "Navigator" text on top
of the startup newsgroup) by decreasing borders etc. This might help a little.
I still think that these four things just don't have much in common with each
other:

1) startup page
2) home page (okay, 1) and 2) *are* quite similar)
3) default browser (something very, very different)
4) toolbar buttons (even more different - how about creating a new pan... *gets
shot*) ;-)

Comment 55

[Sören 'Chucker' Kuklau (gone)]

Hmm. Does anything really speak against the following proposal: We get rid of
the "put this setting into the Navigator Category" idea entirely and instead put
it in Appearance? I could imagine

+- Let Mozilla handle these by default -+
| [ ] Web (with Navigator)              |
| [ ] E-Mail (with Mail & Newsgroups)   |
+---------------------------------------+

Yeah yeah, let mpt do the ascii art. Anyways, that way, we could also remove the
"Use Mozilla Mail as the default mail application" checkbox from the Mail &
Newsgroups category, because I don't think it really belongs there either.

Plus, Appearance is as empty as a desert at the moment. Plenty of space there.

Comment 56

[Peter Trudelle]

Well, besides the fact that these prefs have nothing to do with Appearance, the
top-level component panes are the default for Edit Prefs in each component, so
they are the places users are most likely to discover them.

Comment 57

[Sören 'Chucker' Kuklau (gone)]

#56
> Well, besides the fact that these prefs have nothing to do with Appearance,

I can agree to that. But the startup groupbox in Appearance doesn't have *that*
much to do with Appearance either. I believe the startup groupbox and a
potential "default app for ..." groupbox would belong together.

> the top-level component panes are the default for Edit Prefs in each component,
> so they are the places users are most likely to discover them.

In that case, the startup groupbox should be split, too, adding a "Start
Navigator when launching Mozilla" checkbox in the Navigator component, a "Start
MailNews when launching Mozilla" checkbox in the Mail & Newsgroup component,
and... you get the idea.

Comment 58

[Bill Law]

It seems nobody is thrilled with the new "Defaults" group (myself included).

But we need something.

There is no way to fit a new group box.  I tried moving the "Clicking on the 
home button takes you to this page." prompt to the groupbox caption but that 
didn't help (I still lose half the "Home" checkbox at the bottom).

Would it help if "Defaults" were instead "General Settings" as on the Mail & 
Newsgroups panel?  Note that Mail/News has a diverse set of things on that 
panel and within that group.

Another alternative might be to squeeze another group box in alongside 
the "When Navigator starts up, display" groupbox (that groupbox's right half is 
empty).

One last idea: rearrange the radio buttons under "When Navigator starts up, 
display" horizontally rather than vertically.

Comment 59

[Peter Trudelle]

If General Settings would make this fit, then why don't we plan to go with that?
I doubt a horizontal group arrangement would be very discoverable, and we don't
have time to test it.  Arranging radio buttons horizontally sounds really
strange, though I considered it too. Can anyone cite examples of popular apps
doing this?

Comment 60

[Sören 'Chucker' Kuklau (gone)]

Attachment: two cases of horizontal radiobutton/checkbox arrangement in a popular app (ICQ 2002a)

Yes, I can. Might not be the best examples, but at least I found something. :-)

Comment 61

[Lori Kaplan]

Attachment: alternate layout for Set Default Browser pref on Nav panel

Here's an alternative proposal for where to put the pref. It puts the section
next to the startup prefs which gives the default pref visibility and
prominence.

Comment 62

[Bill Law]

Attachment: New Nav pref panel (state 1, button enabled)

Screen shot of new pref panel implemented as Lori suggested.  I did change the
wording slightly to match the point-of-view of the other prompts on this panel.
 Please holler (soon) if you have objections!

Comment 63

[Bill Law]

Attachment: state 2 ("set default" pending)

Comment 64

[Bill Law]

Attachment: state 3 (already the default)

Comment 65

[Alex Bishop]

Re: "Mozilla will be made your default browser when you press Ok."

Firstly, "Ok" should be "OK".

Secondly, I think "Mozilla will be set as your default browser when you press
OK." sounds more consistent.

Comment 66

[Bill Law]

Attachment: Patch corresponding to latest screen shots (ready for review)

Comment 67

[Bill Law]

Attachment: Documentation for the changes

This explains all the modifications.  The diffs in there differ (I didn't
update it to reflect the change in the pref panel layout).  The changes to
pref-navigator.xul and platformPrefOverlay.xul are different (as are the .dtd
files, slightly).  Please rely on what's in the patch for the definitive word.

The rationale given in this document still applies.

Comment 68

[Bill Law]

re: comment 65

Thanks, Alex.  I've applied your suggestions to the file in my source tree (I'm
not going to bother updating the patch for that).

Comment 69

[Jatin Billimoria]

My suggested wording for state 1:
"Set Mozilla as your default browser."

For state 2, I like Alex's wording in Comment #65, but with one modification:
"Mozilla will be set as your default browser when you click OK."

Since most users use a mouse, "click" is more appropriate then "press." 

Comment 70

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

Bill, I'm looking at your screenshots and it appears that you've invented a new
kind of UI element, an un-uncheckable checkbox :-) 

Lori's UI example didn't show exactly what was meant to happen when the button
was pressed. Here's a breakdown of possible alternatives:

Features:

Item A: User can set the browser to be the default
Item B: User can choose to leave the default settings in tact
Item C: Number of operations required to perform a default browser change

Item  | Current Patch (1)   | Immediate Change (2)  | Checkbox (3) 
------+---------------------+-----------------------+-----------------------
A     | Yes, click button   | Yes, click button     | Yes, check checkbox 
      | then OK             |                       | then click OK
------+---------------------+-----------------------+-----------------------
B     | Yes, do not click   | No                    | Yes, clear checkbox 
      | button, or, click   |                       | before clicking OK
      | button then click   |                       |
      | Cancel              |                       |
------+---------------------+-----------------------+-----------------------
C     | 2                   | 1                     | 2
------+---------------------+-----------------------+-----------------------

Current Patch (1) - providing a button that indicates a change will be made when
OK is clicked
Immediate Change (2) - providing a button that performs a default change when it
is clicked
Checkbox (3) - providing a checkbox which indicates a change will be made when
OK is clicked

(2) seems to me to be the best approach when a button is used, as buttons imply
immediacy (IMO), and also the Preferences dialog is non-modal, so it is possible
that this setting may have effect while the dialog is still up. 

(3) seems to me to be the best approach to follow if we want to tie the setting
to the OK button, to allow the user to avoid this change after making it, as the
act of unchecking a checkbox is slightly more obvious than clicking "Cancel"
(and perhaps losing other settings which have been changed in this launch) -
which is the "no actually I don't want to do that" path constructed by
implementatino (1).

Comment 71

[Peter Trudelle]

It isn't that simple.  A correct mapping of the pertinent six Advanced prefs to
a single checkbox would require 3 states, which we don't have. Also, we have no
requirement to make it easy to remove our browser as the default - other
browsers are already making that extremely easy.  Given that today is the L10N
freeze, I think we should just go with the current UE/Doc suggestions, which are
already implemented.

Comment 72

[Bill Law]

I've incorporated Jatin's suggestions into my source tree.

re: Ben's concerns (which are warranted)

I'm also a bit leery of this but the current proposal is the best compromise
possible to make it easier for the user to make us their default browser.

The main issue with a checkbox is: What does it mean to uncheck it?  E.g., the
user has 5 of the 6 settings set already and then checks this box, then unchecks
it.  Do we reset all 6 settings, just the one, and does it depend on whether
they've changed these settings at the Advanced/System panel?

By just having the pushbutton we finesse this issue (to some extent, at least),
and users would usually accomplish the equivalent of "unchecking" this by
configuring their alternative browser.

As to making the push button change things immediately: the issue with that is
that there are other push buttons on that panel that don't work that way.

Comment 73

[Samir Gehani]

Comment on attachment 85875 [details] [diff] [review]
Patch corresponding to latest screen shots (ready for review)

>Index: components/prefwindow/resources/locale/en-US/win/platformPrefOverlay.dtd
>===================================================================
  [snip]
>+<!ENTITY defaultPendingText         "&brandShortName; will be made your default browser when you press Ok.">

Make ``Ok'' -> ``OK'' and r=sgehani.  Nice documentation!

Comment 74

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

I wasn't really advocating the checkbox, although my comment didn't make that
clear. I'm actually an advocate of having the button that sets the default
instantly. Anyhow... *looks at patch*

Comment 75

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

Your patch does:

+  <hbox>
+    <!-- navigator starts with -->  
+    <groupbox>
+      <caption label="&navRadio;"/>
+      <radiogroup id="startupPage" prefstring="browser.startup.page">
<snip>
+      </radiogroup>
+  
+    </groupbox>
+    <!-- Platform specific extensions are inserted here -->
+    <vbox id="pref-nav-platform-extensions"/>
+  </hbox>

why not do:

+  <hbox id="foo">
+    <!-- navigator starts with -->  
+    <groupbox>
+      <caption label="&navRadio;"/>
+      <radiogroup id="startupPage" prefstring="browser.startup.page">
<snip>
+      </radiogroup>
+  
+    </groupbox>
+  </hbox>

and just insert the groupbox without adding an extra box? I doubg this area is
going to be receiving a lot of "extensions" as the dialog will overflow
horizontally ;-) 

do that, and sr=[e-mail]

Comment 76

[Bill Law]

OK, that works for me.  Originally, I used that <vbox> to hang the extensions 
off of because it was at the top level in the <page>.  I just left it that way 
as I moved it around so that it would minimize the work of moving it back (the 
current placement is the 4th attempt).

Now that we've settled on putting it here, I'll code it up properly as you 
suggest.  Thanks.

Comment 77

[Bill Law]

Attachment: patch, final rev

updated with Ben's suggestion

Comment 78

[Bill Law]

Comment on attachment 86535 [details] [diff] [review]
patch, final rev

r=sgehani
sr=ben

(from previous patch)

Comment 79

[Jatin Billimoria]

Bill, please see comment #69 for my suggested wording, which still applies to
your final rev patch in #78.

Comment 80

[Bill Law]

Ok, Jatin; you busted me.  I did not re-generate the patch completely (I just
updated the sections for the files I modified per Ben's suggestion).  So my
files *do* have your suggestions applied, despite what's in the most recent patch.

Here's the actual cvs diff output, so everybody can sleep easier:

Index: platformPrefOverlay.dtd
===================================================================
RCS file: /cvsroot/mozilla/xpfe/components/prefwindow/resources/locale/en-US/win
/platformPrefOverlay.dtd,v
retrieving revision 1.5
diff -u -5 -r1.5 platformPrefOverlay.dtd
--- platformPrefOverlay.dtd     26 Apr 2001 11:00:18 -0000      1.5
+++ platformPrefOverlay.dtd     7 Jun 2002 01:04:30 -0000
@@ -1,2 +1,8 @@
 <!ENTITY winhooks.label                   "System">

+<!ENTITY defaultBrowserGroup.label  "Default Browser">
+<!ENTITY defaultBrowserButton.label "Set Default Browser">
+<!ENTITY alreadyDefaultText         "&brandShortName; is already your default b
rowser.">
+<!ENTITY defaultPendingText         "&brandShortName; will be set as your defau
lt browser when you click OK.">
+<!ENTITY makeDefaultText            "Set &brandShortName; as your default brows
er.">
+

Comment 81

[Syd Logan]

adding adt1.0.0-, 

Comment 82

[scottputterman]

After further discussion, changing to adt1.0.1+.  Please get drivers approval
before checking into the branch.

Comment 83

[rchen]

Approved for UI change from L10N. Please have it check in before 06/10. Thanks.

Comment 84

[Asa Dotzler [:asa]]

Comment on attachment 86535 [details] [diff] [review]
patch, final rev

a=asa (on behalf of drivers) for checkin to the 1.1 trunk.

Comment 85

[:deanis74]

"&brandShortName; is already your default browser."

Shouldn't it just say "&brandShortName; is your default browser."  Why is it
saying already?  This sounds like I tried to set it as the default browser when
it already was.  It's a little confusing for it to say "already" when I've just
opened the prefs panel.

Comment 86

[Bill Law]

Fixed, on the trunk.

If it bugs you enough, Dean, you should open a new bug to have the wording
changed.  It isn't that big a deal to me.  I interpret the "already" to simply
be the explanation as to why the button is disabled.  It isn't as good an
explanation without that word, I don't think.

Comment 87

[Terri Preston]

Verified win xp trunk build 2002061408

Comment 88

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Comment on attachment 86535 [details] [diff] [review]
patch, final rev

Please land this on the 1.0.1 branch.  Once there, replace the
"mozilla1.0.1+" keyword with the "fixed1.0.1" keyword.

Comment 89

[scottputterman]

Bill, were you able to check the string changes in already?  If not, please hold
off on checking these in.

Comment 90

[Bill Law]

String changes went in a week ago.  I'll update the code on the branch ASAP.

Comment 91

[Bill Law]

fixed on branch

Comment 92

[sairuh (rarely reading bugmail)]

verified on the branch using 2002.06.27.08 comm bits on win2k.

Comment 93

[Anatoliy Averbukh]

Part of this patch caused problem (file nsPrefWindow.js): it changed order in 
which pref values are extracted and call back functions are executed.

Before, the call back functions are executed first and then the values are 
extracted, the patch changed the order, it leads to serious regressions for 
applications.

Reopenning the bug.

Comment 94

[Anatoliy Averbukh]

Is somebody going to do something with this bug?

Comment 95

[jag (Peter Annema)]

Marking this bug fixed again. See bug 190288 for the issue pointed out by Anatoliy

Comment 96

[sairuh (rarely reading bugmail)]

this has been fixed on the trunk for some time, so marking verified.

side note wrt Mac OS X: http://bugzilla.mozilla.org/show_bug.cgi?id=166878#c7