Closed Bug 89907 Opened 24 years ago Closed 22 years ago

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

Categories

(SeaMonkey :: UI Design, defect)

Product:
SeaMonkey
Component:
UI Design
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
VERIFIED FIXED
Milestone:
mozilla1.0

People

(Reporter: bugzilla, Assigned: law)

References

Details

(Whiteboard: [adt2 rtm])

Attachments

(9 files, 6 obsolete files)

M?$%&&t screenshot
7.96 KB, image/png
Details
Current look of Navigator Preferences panel on trunk (for Blake)
35.68 KB, image/png
Details
two cases of horizontal radiobutton/checkbox arrangement in a popular app (ICQ 2002a)
10.20 KB, image/png
Details
alternate layout for Set Default Browser pref on Nav panel
14.20 KB, image/gif
Details
New Nav pref panel (state 1, button enabled)
37.27 KB, image/jpeg
Details
state 2 ("set default" pending)
37.18 KB, image/jpeg
Details
state 3 (already the default)
36.88 KB, image/jpeg
Details
Documentation for the changes
30.71 KB, text/html
Details
patch, final rev
22.80 KB, patch
law
: review+
law
: superreview+
asa
: approval+
Details | Diff | Splinter Review
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.
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??"
usability/polish, 0.9.4.
Status: NEW → ASSIGNED
OS: other → All
Hardware: PC → All
Target Milestone: --- → mozilla0.9.4
>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.
Target Milestone: mozilla0.9.4 → mozilla0.9.5
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.
Target Milestone: mozilla0.9.5 → mozilla0.9.6
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
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.
Target Milestone: mozilla0.9.6 → mozilla0.9.7
Target Milestone: mozilla0.9.7 → mozilla0.9.9
Target Milestone: mozilla0.9.9 → mozilla1.1
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)
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.
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.
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.
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".
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.
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.
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.
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.
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. :-)
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).
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.
Depends on: 97975, 103339, 112822
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... )
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.
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.
Oh absolutely, the menu items would only be in their own component's Edit menu.
Attached image M?$%&&t screenshot —
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.
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'.
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.
Depends on: 118497
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."
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. :-)
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!"
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.
Depends on: 86913
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.)
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.
Keywords: nsbeta1
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.
nsbeta1+/adt2
Keywords: nsbeta1 → nsbeta1+
Whiteboard: [adt2]
Target Milestone: mozilla1.1alpha → mozilla1.0
-> bill
Assignee: blaker → law
Status: ASSIGNED → NEW
so what are marketing's/UE's recommendations for fixing this?
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?
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.
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?
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.
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 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.
Attachment #83143 - Flags: needs-work+
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.
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?
We need to decide on this quickly, it it is to make RTM.
Whiteboard: [adt2] → [adt2 rtm]
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.
This is what the pref panel looks like immediately after the user clicks the enabled "Set As Default" button shown in the prior attachment.
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).
Attached patch Updated path (complete) (obsolete) — — Splinter Review
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.
Attachment #83143 - Attachment is obsolete: true
I think you should make the description and button invisible when the Mozilla is already the default, rather than showing some unnecessary disabled text.
#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.
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??
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*) ;-)
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.
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.
#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.
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.
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?
Yes, I can. Might not be the best examples, but at least I found something. :-)
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.
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!
Attachment #84988 - Attachment is obsolete: true
Attachment #84990 - Attachment is obsolete: true
Attachment #84991 - Attachment is obsolete: true
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.
Attachment #84992 - Attachment is obsolete: true
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.
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).
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."
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).
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.
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 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!
Attachment #85875 - Flags: review+
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*
Status: NEW → ASSIGNED
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=ben@netscape.com
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.
Attached patch patch, final rev — — Splinter Review
updated with Ben's suggestion
Attachment #85875 - Attachment is obsolete: true
Comment on attachment 86535 [details] [diff] [review] patch, final rev r=sgehani sr=ben (from previous patch)
Attachment #86535 - Flags: superreview+
Attachment #86535 - Flags: review+
Bill, please see comment #69 for my suggested wording, which still applies to your final rev patch in #78.
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."> +
adding adt1.0.0-,
Keywords: adt1.0.0-
After further discussion, changing to adt1.0.1+. Please get drivers approval before checking into the branch.
Keywords: adt1.0.0- → adt1.0.1+, mozilla1.0.1
Approved for UI change from L10N. Please have it check in before 06/10. Thanks.
Comment on attachment 86535 [details] [diff] [review] patch, final rev a=asa (on behalf of drivers) for checkin to the 1.1 trunk.
Attachment #86535 - Flags: approval+
"&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.
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.
Status: ASSIGNED → RESOLVED
Closed: 23 years ago
Resolution: --- → FIXED
Verified win xp trunk build 2002061408
Status: RESOLVED → VERIFIED
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.
Bill, were you able to check the string changes in already? If not, please hold off on checking these in.
String changes went in a week ago. I'll update the code on the branch ASAP.
fixed on branch
Keywords: mozilla1.0.1+ → fixed1.0.1
verified on the branch using 2002.06.27.08 comm bits on win2k.
Keywords: fixed1.0.1 → verified1.0.1
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.
Status: VERIFIED → REOPENED
Resolution: FIXED → ---
Is somebody going to do something with this bug?
QA Contact: sairuh → paw
No longer depends on: 103339
Marking this bug fixed again. See bug 190288 for the issue pointed out by Anatoliy
Status: REOPENED → RESOLVED
Closed: 23 years ago → 22 years ago
Resolution: --- → FIXED
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
Status: RESOLVED → VERIFIED
Product: Core → Mozilla Application Suite
Component: XP Apps: GUI Features → UI Design
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: