I don't know if this has been considered yet or not, but most average users will not know to go to Edit-->Preferences and look for the Themes switcher there. I think it should be either added to Go-->Themes Switcher or added as a Themes menu for easy access for the standard user. I just remember when I was a newbie, I didn't know to go to Edit-->Preferences for anything. Since this is one of the cooler features for standard users, I think it should be made as obvious as possible.

Themes are switched *very* seldom. It is not an action that needs a command in the menus. Cluttering the UI is no good. Newbies just need to be told to look in the prefs.

Themes are switched very seldom because there are no themes right now. When N6 launches it's going to be the one feature that makes it WAY COOL for new users. Speaking for myself, I'll change themes as often as possible once they become available, and I would like it to be as easily accessible of a feature as possible, again, with at least a Themes Switcher item in the Go menu, or at the very least in the Tasks menu. That wouldn't clutter the main UI at all.

Exactly, Kovu, speaking for yourself. The fact you're here at all suggests you're an advanced user, in which case you'll be much more interested in theme switching than most other users will be. The vast, vast majority of Mozilla users won't care at all about Mozilla's skinning ability, let alone wanting a main menu item for it. This seems like an obvious INVALID, but I'll reassign to UI/DF, and CC German, for a sanity check.

5 years ago MS introduced Windows desktop themes in MSplus for Windows95. The desktop themes weren't part of all Windows installs untill Win 98 came out 2 years ago. http://www.themeworld.com is a popular site for these types of themes. Over 5000 of them at one site! In the future there will be sites like this for Mozilla themes. In Windows most "power users" tend towards NT/2000 and don't want to be bothered with the quirks a poorly written theme can introduce. The heavest theme switchers are average users. I see no reason to think this pattern will be different with Mozilla. The "power user" will find a skin that meets thier needs and stick with it. It's the more casual user who will want an ever changing look for Mozilla. I think it's an execellent sugestion for the go menu, but not for the menu bar.

The question isn't "Will themes be popular?" The question is "Is theme switching is part of the normal use the app or part of configuring it?" In Windows, you need to go to the Control Panel. Theme switching, AFAIK, is not in the menus.

Themes will be insanely popular, I'm sure, IF we make it easy enough to do. Windows 98 is the only version of Windows that supports schemes (by default) I think (who the Hell really bought Plus?), and yes, it's buried in the Control Panel where standard users wouldn't think to look for it. The question isn't whether themes will be popular but how easy we want to make the themes feature to find and use. I was under the impression that with Mozilla, unlike Windows schemes, would be so easy to switch that you could go to a site, click one hyperlink, and watch your theme change. That means anyone who goes to CNN.com, Disney.com, StarWars.com, etc., will be able to change their theme with one click of a hyperlink (if it's true). Adding -->Theme Switcher to the Go menu would make it just as easy for users to be able to switch BACK if they hate the Wookie's head back button. We don't want to make the user frustrated searching around obscure menu locations to get rid of a theme they hate.

Advanced users can understand a user interface in spite of the fact that it has changed in appearance. Novice and intermediate users, often, can't. If advanced users `don't want to be bothered with the quirks a poorly written theme can introduce', that doesn't automatically mean that novice and intermediate users *do* want to be bothered; that's a bifurcation fallacy. No, Mozilla will not be able to switch themes just by clicking on a hyperlink. That would be a security nightmare. You could do this, at one point (around M13, IIRC), but then the security system was fixed. And no, theme switching does not belong in the Go menu, because it is not navigation. This is just getting silly.

A theme switcher item should be probably go in the Tasks menu. If you really, REALLY want to make it obscure, put it under the Tools directory. Certainly it will see more use by the average user than the JS console.

Matthew, please re-read this press release, and then tell me that Kovu's bug is INVALID. http://www.netscape.com/newsref/pr/newsrelease804.html From this press release, and I quote, "Themes - Customization of the Browser's Look Fully live in Preview Release 2, Netscape 6 Themes will offer consumers the ability to customize the appearance of the browser from a selection of different themes, and offers businesses the opportunity to create and distribute custom versions of the new browser. Netscape's new Themes are made possible by a breakthrough Gecko technology - XUL (pronounced "zool", the XML based User interface Language), an innovative new XML application that makes it easier than ever to develop a cross-platform, cross-device user interface. Web sites and businesses can create custom versions of the browser to best suit different customer needs. Time Warner properties will be among the many businesses that can customize their browsers. For instance, CNN.com will provide a browser theme that will incorporate a CNN co-branded look and persistent access to news-related information in My Sidebar. " So, if you want to blow people static about a feature that is announced on the Netscape Corporate site as a press release, and a feature that seems to be hidden from the average user, then go ahead. What Kovu is suggesting is logical, and good for the new users that will be using PR2 and expecting theme support and skin switching from either a high-level Task or Go menu isn't too much too ask. Can't wait to hear what Netscape thinks about this, or perhaps Jim Martin, who managed the press release, or Chris Saito, Sr. Director of Product Marketing, Netscape Communications.

Adding myself to the CC: list so I can track this.

First of all, Mozilla isn't Netscape. If Netscape wants themes on the menu and Mozilla doesn't, then they can add it. Having said that, I think it would be a good idea to add a link to the themes part of the preferances panel, maybe this could be listed under Edit > Themes or something.

People Love themes, and can probably find their way around regardless of where/how it's enabled/altered. Just describe the procedure in the helpfile and people will find their way. However, there's enhancement bug 38908, requesting a pref to disable skin switching. (Some companies would wish to "lock" their own customized skin.) That should perhaps be considered when deciding how to deal with this bug; where/how is it easyer to disable skin-switching all together? Was thinking of how the "shop" button in Netscape can be disabled, for instance.

An extra menu item that leads directly to the Themes preference panel seems like a sensible solution. I would prefer "Edit > Themes", "Edit > Theme Switcher", or even better, "Edit > Themes..." Of all "preferences", "themes" will certainly be the ones altered with the most regularity. It seems sensible to include a more direct link to that panel in the menubar. IMO, listing all themes in a menu or submenu on the menubar *sounds* like a good idea, but there is a level of complexity to theme switching that would be lost: the fact that themes may skin certain components and not others. The theme switcher at least attempts to get across that fact (although I would prefer that the "components affected" list not be hidden as it currently is). If y'all want, we can argue the merits of the various predictive methodologies used to determine that the "average" user will (or will not) use Mozilla's themes with regularity. But I will state with great conviction that for every extra click needed to get to the "theme switcher", Mozilla/Netscape will lose potential new "theme" users. Making "themes" more easily discoverable will greatly aid in increasing the usage of the theme switcher, which seems like a worthwhile goal, as it is a definite "selling point" of the app.

Pedantic correction: a bug like this is not "invalid"... it may be marked "wontfix" or "later". Another note: doesn't Kaleidoscope add itself to the Apple menu on the Macintosh? Reassigning to hyatt as he expressed interest in doing this.

Matthew, I find it quite unseemly that someone given a position of authority in the bugzilla system would dare call another's good-faith idea "silly". You can continue your disputations of others' logical reasoning, but when you resort to derision it calls into question your ability to function properly in the position you hold. Kovu deserves nothing less than a full apology.

I agree that it would be nice if themes switching was easier. I'm strongly against everyone's argument that "the average user won't want to use themes switching, and thus we shouldn't even try." Of course they're not going to use it if we stuff if in some obscure prefs panel. The ability to switch themes with the click of a button is one of the best advantages of designing the interface entirely in XUL and CSS. Why do we want to hide it? Sure, maybe it won't be the average user's biggest concern, but we may as well give it a shot. I know my own mother, the epitome of the average computer user who (admittedly) doesn't know much about how things work, would love the idea of having a creative skin. I'm not saying we need to throw it in their face, but we may as well take a shot at making it a mainstream function.

Stephen: Netscape Marketing have trumpeted themability not because it would make users' lives any easier, but because it is one of the few obvious `features' Netscape 6 will have which IE 5 -- or even IE 4 -- did not have. (However, IE 4 and 5 on Windows mostly pay attention to your Windows Desktop Theme, whereas Netscape 6 will not.) Luckily, Mozilla is free from such marketing pressure ... or so I would have thought. Ben: a bug is INVALID if, and I quote, `The problem described is not a bug'. A bug is WONTFIX if it `is a bug which will never be fixed'. I am of the firm opinion that this report falls into the former category, not the latter. Chris: I care much more about usability than I do about `selling points'. Yes, I do think this is a silly idea, and no, that is not derision. Derision, in my view, would be attacking the person who made the suggestion, rather than the suggestion itself. There is, of course, the possibility that my own judgement is wildly off-base in this issue, in which case it's likely that it's also wildly off-base in a lot of other UI issues which have come up in Bugzilla. If you think that's the case, then please e-mail Jan Leger <leger@netscape.com> and ask that I be replaced as UI/DF QA contact immediately.

I think everyone just needs to calm down...or at least take your stress/anger out on something more deserving of it (a big blue "e" comes to mind...) Matthew: you're a good UI contact, no need at all to replace you. I just don't think that bugs that seem like "an obvious INVALID" from your POV should be dumped as wrong or worthless right away. You complained that Kovu should speak for himself only, but you, too, were apparently speaking only for yourself when you said this was an invalid bug (and not even a bug at that)...there do seem to be a lot of people who want to consider this. The great thing about open source development is that we can discuss this and decide what we think is best for the user, which, in the end, is really what counts here. My personal opinion is that such a themes-related item shouldn't be on the go menu (navigation) or the edit menu (primarily selection/clipboard operations), and that if such an item were to exist, it should be somewhere in the Tasks menu (either in the top level menu or in a submenu). IMHO, it seems very closeminded and restrictive to assume that the average Joe doesn't want to change his skin, and thus we should hide the ability to do so in a place where he'll never find it. What if, instead, we pushed it to the average enduser (or at the very least, made it easily accessible), and it ended up becoming an extremely popular feature? To use a hyperbole of an analogy, way back when in the times of Mosaic, NS and the NCSA, who thought the web was going to be an every day household item, rather than a select, exclusive group? Netscape has been known to think outside of the box, and we need to continue such thinking. In my opinion, the average user wouldn't mind getting creative with his or her theme, but he or she doesn't want to have to take the time to search for the tools to do so, or consult a manual. By giving the user a noticable and easy way to do it, switching themes could be made quite common among average users.

Just to refute an earlier point: "In Windows, you need to go to the Control Panel. Theme switching, AFAIK, is not in the menus." Not true. If you install the wallpaper-switching utility (made by MS) for IE, the "Change Wallpaper..." (I believe that's what it says) item appears right in the Tools menu as an item in the top level menu, not part of a submenu. However, I do agree that unless "Themes Switcher" doesn't really belong as a main item in the Tasks menu, right up there with Navigator, Net2Phone, Chatzilla, Addressbook, and so forth (all of which are either full apps, or would be used extremely often). The Tools submenu, containing fairly obscure or rarely used windows, doesn't seem like a bad place. However, aside from the fact that the ability to switch themes would be easier to access once its location is learned, it still doesn't help the original problem much (namely that themes switching is hard for the newbie to discover). Criticism welcome.

>Themes will be insanely popular, I'm sure, IF we make it easy enough to do. The pref UI is easy to use and doesn't add clutter to the menus. Themes aren't switched all the time and, thus, don't require a menu item. Please note, that the user has to be skilled enough to acquire themes before switching them. Usually users who can download and install software can also access the prefs. >switching themes could be made quite common among average users But why should it be *made* common if it doesn't become common otherwise? Just because it is so kewl? In my opinion, there are preferences that are far more important and that the users should be educated about eg. the security prefs. Still, those are configuration settings that belong in prefs, and don't deserve menu items that would clutter the UI. The fact that it is attempted to justify the requested feature by using marketing arguments rather than usability arguments casts serious doubts about the validity of the feature. I agree with Matthew. Theme switchng shouldn't go in menus.

Another option not considered: using the sidebar. The "Themes" sidebar panel would list all available themes, and allow users to switch from one to another. Also, it would list new themes and offer them for download, as well as a permanent link to The Official Comprehensive Theme Archive. If necessary, more advanced options, such as choosing one theme for browser and another for mail/ news, would be in Preferences.

"Luckily, Mozilla is free from such marketing pressure ... or so I would have thought." Again, at the VERY least, I don't see why a Theme Switcher item couldn't help fill out the Tools submenu, and yes, even in Mozilla. That "Mozilla isn't Netscape" means nothing if both apps have the same feature. "Ben: a bug is INVALID if, and I quote, `The problem described is not a bug'." This argument would rule ALL "Severity: enhancement" bugs as invalid, which is total gibberish. The whole point in having "Severity: enhancement" is to sort new ideas from bugs, and yet still welcome them, a point which you seem to miss. "I care much more about usability than I do about `selling points'." So how is making what already IS a popular Mozilla feature (even in its handicapped INFANCY) easier to access NOT a usability issue? Maybe the Go menu isn't the place, maybe my idea needs some help from others, THAT's what I was hoping to get here.

"The pref UI is easy to use and doesn't add clutter to the menus." Again, I think the Prefs menu is too obscure for the standard user as the sole place to access this feature. All I'm asking for is a menu shortcut to it, I tend to think it'll be a more-used feature than Newsgroups, and don't see why it couldn't go right next to Newsgroups in second tier of the task menu. "Themes aren't switched all the time and, thus, don't require a menu item." Again, themes aren't even implemented fully yet, and this argument is ridiculous until the feature is done and can be proven to be true. Saying "themes aren't switched all the time" is just nonsense when the only existing theme that is an alternative to Modern isn't even finished yet. Once there ARE themes to be had, they'll be switched all the time -- even in Mozilla, go ask the gaggle over at MZ. "Please note, that the user has to be skilled enough to acquire themes before switching them." NOT if you make it easy enough to do. "Usually users who can download and install software can also access the prefs." This product (and this feature) isn't/shouldn't be targeted only at "those who can download and install software." N6 and other Mozilla-based browsers will start coming as default on Web appliances, desktop machines, and other machines, and those users don't HAVE to download and install N6 and shouldn't have to know how to use themes. When I was a new Netscape user, I looked for the features I wanted in the menus. EVENTUALLY I realized they hid all this stuff in the Prefs, but I don't think we should make standard users make that connection, just because some don't think we should make this feature easy to find. "In my opinion, there are preferences that are far more important and that the users should be educated about eg. the security prefs." I'm not asking for "education" I'm asking for a menu shortcut. "Still, those are configuration settings that belong in prefs, and don't deserve menu items that would clutter the UI." That's funny, Privacy and Security has its own Tasks submenu! This casts doubts on the validity of your argument, I think. Maybe you'd rather we gank that submenu to avoid "cluttering" the UI and making the menu bar useful for what it's supposed to be useful for, i.e. shortcuts to the apps prominent features? I think all this argument is that some people cannot see from the perspective of a standard user any longer, and who evidently have no interest in making this program easier to use for that user. And yes, a Themes switcher in the sidebar is a great idea. It could be a default N6 tab, but I don't know that it should be a default Moz tab.

>Again, I think the Prefs menu is too obscure for the standard user as the >sole place to access this feature. What is obscure about the prefs? >I tend to think it'll be a more-used feature than Newsgroups, Really? Many people read news daily. Do you expect the user to switch the theme every day? >"Themes aren't switched all the time and, thus, don't require a menu item." >Again, themes aren't even implemented fully yet, and this argument is ridiculous It isn't. I think the user will pick a theme and then use it. I really don't think the user wants to switch the theme every time (s)he uses the app. >"Please note, that the user has to be skilled enough to acquire themes >before switching them." >NOT if you make it easy enough to do. So you are saying the user is going to have different themes without acquiring them. Are you suggesting increasing the download size of Mozilla itself by bundling a selection of themes with it? >those users don't HAVE to download and install N6 and shouldn't have to know >how to use themes. Where do the themes come from if they aren't downloaded and installed? >EVENTUALLY I realized they hid all this stuff in the Prefs, Most apps have prefs. Being aware of the existance of prefs is *basic knowledge* that is required to make personal changes to apps. Newbies need to be told there is such a thing as prefs and that it is OK to look in there. >"Still, those are configuration settings that belong in prefs, and don't >deserve menu items that would clutter the UI." >That's funny, Privacy and Security has its own Tasks submenu! This casts doubts >on the validity of your argument, I think. Maybe you'd rather we gank that >submenu to avoid "cluttering" the UI and making the menu bar useful for what >it's supposed to be useful for, i.e. shortcuts to the apps prominent features? As I have written in earlier comments, commands that get frquently used during the normal operation of the app belong in menus. Settings that are changed very seldom belong in the prefs. Detailed policy settings about the overall behavior of the app belong in preferences. However, a command like "Security Policy for This Site..." has its place in the menus. >I think all this argument is that some people cannot see from the perspective >of a standard user any longer, and who evidently have no interest in making >this program easier to use for that user. I for one am interested in making Mozilla easier to use. Adding too many items to menus does not make the app easier to use.

>Again, I think the Prefs menu is too obscure for the standard user as the >sole place to access this feature. What is obscure about the prefs? It doesn't scream "Theme Switcher" >I tend to think it'll be a more-used feature than Newsgroups, "Really? Many people read news daily. Do you expect the user to switch the theme every day?" Yes, Newsgroups are currently used by advanced Net users. I didn't even know what the heck they were until fairly recently, or how to use them. The goal is to take the Net to standard users, too, many of which won't care about newsgroups -- say kids. And yes, a five-year-old might want to use his Disney theme and ten minutes later his mom might want her Martha Stewart theme and then a few minutes later, dad might want his CNN.com theme, and then daughter might want her barbie theme. I see situations like these making it so themes are changed several times a day at least. "I think the user will pick a theme and then use it. I really don't think the user wants to switch the theme every time (s)he uses the app." Nonsense. I for one will switch themes based on the site I'm on. StarWars theme, Lord of the Rings themes, CNN, MZ, Netscape. I would prefer not to have to go Edit-->Preferences, click themes, and all that every time. Why on earth stick with one when there are hundreds, thousands that potentially interest you and are available to help customize your favorite sites? >"Please note, that the user has to be skilled enough to acquire themes >before switching them." >NOT if you make it easy enough to do. "So you are saying the user is going to have different themes without acquiring them. Are you suggesting increasing the download size of Mozilla itself by bundling a selection of themes with it?" They won't be that hard to get hold of and set up. It's my impression that PACKAGES are different than themes. PACKAGES are new browsers, I assumed THEMES were merely a click or two (to confirm) and you see your browser change before your eyes. No "download" no "unzip" no "execute." For PACKAGES like Aphrodite, yes, for themes, no. I assume it would be just a click of a hyperlink and maybe a click of confirmation. Am I wrong? "Where do the themes come from if they aren't downloaded and installed?" Again, I thought they were completely cache-based and thus didn't need to be downloaded, unzipped, etc. "Most apps have prefs. Being aware of the existance of prefs is *basic knowledge* that is required to make personal changes to apps. Newbies need to be told there is such a thing as prefs and that it is OK to look in there." No, most apps have Options. Some have Prefs, but in any case we shouldn't assume the user has to be "told" anything. What do we "tell" them now? To go look at a Help file that really is no help at all? How were you planning on "telling" them? I'm not arguing we shouldn't, but I am arguing that Themes Switching will be an important enough feature to most users that it deserves at least a menu shortcut, especially if Newsgroups or the Java console, a very high-end user feature, does. No one but developers use the Java console, making it a very obscure feature, but it STILL has a menu item even though most users never touch it. So what, we should allow only obscure features in the menus then and hide all the features that may actually be important to a large base of users deep in the prefs? I say no. >"Still, those are configuration settings that belong in prefs, and don't >deserve menu items that would clutter the UI." "As I have written in earlier comments, commands that get frquently used during the normal operation of the app belong in menus. Settings that are changed very seldom belong in the prefs." Yes, and you still have yet to prove how Themes will be less often used than the Java or Javascript consoles and are thus less worthy of a menu item. In fact, it seems the majority of respondents to this list, all save two in fact, think Themes will be very popular. I just don't think your argument that Themes won't be popular holds any water at all. "Detailed policy settings about the overall behavior of the app belong in preferences. However, a command like "Security Policy for This Site..." has its place in the menus." And what about the Themes disabler someone else mentioned above? This is a "policy setting about he overall behavior of the app", no? So why shouldn't it be under Tasks as well? Perhaps even a Tasks-->Themes submenu? "I for one am interested in making Mozilla easier to use. Adding too many items to menus does not make the app easier to use." Then, again, you can start by scrapping the Java Console, which NO ONE outside of developers will ever touch.

First of all, in my opinion it is VERY important that the download size be kept down. Therefore, the default download should only contain 1, 2 or possibly 3 themes(modern, classic, and possibly a one for real newbies). Secondly maybe we should allow web sites to have their own themes for the web site. For example, when you first went to CNN.com, a dialog box would pop up saying "CNN.com would like to use the 'CNN.com' theme. This theme is 197K, and will take approxamately 14 seconds to download. This theme will just be used for CNN.com. Will you allow it to use it" with buttons "Yes," "No," and maybe checkboxes "Don't ask me again (checked by default)" and "Never allow sites to use own skins". This, obviously is just a rough idea, but do you think it will work in principle? Anyway, maybe as a COMPROMISE between the two viewpoints, we have Preferences have submenus for each of the preferences panels. Of course, THEMES would be one of those submenus, along with those for the other panels.

we have Preferences have submenus for each of the preferences panels. Of course, THEMES would be one of those submenus, along with those for the other panels.Actually I think that's a fantastic idea. It would add shortcuts not just to themes but to all of the main Pref panels, give people an idea of what preferences was for before clicking it, and not add a single item to any of the main menu items (it would merely make Preferences a more dynamic option, with a submenu underneath.

...Also, putting the different pref panels in submenus will cause more newbies to use them. Anyway, aren't preferences normally items that you basically want to "set and forget?" Therefore, while advanced option such as "default theme" would reside there, normal theme changing should be in the View menu, right by "Use Stylesheet." If we REALLY need a simplistic UI, we can change that menu item to "Use Stylesheet/Theme." Anyway, does anyone oppose the idea of the sidebar panel? We would need a permanent theme archive somewhere (mozilla.org can host it), but that should exist anyway.

>It doesn't scream "Theme Switcher" It screams "settings of more permanent nature". >later his mom might want her Martha Stewart theme and then a few minutes >later, dad might want his CNN.com theme, If different users of the computer have different preferences, they should consider creating separate profiles for each user. >I for one will switch themes based on the site I'm on. Do you really want to switch the themes manually in that case? Wouldn't it be better to associate themes with sites so that you wouldn't need to switch themes manually in the future? >in any case we shouldn't assume the user has to be "told" anything. Should we assume the user knows what "Save As..." does? The user can find prefs by exploring the UI. If the user is unwilling to explore, (s)he has to get knowledge of basic computer usage by other means. These include reading documentation or getting training from another user. Failing that, the user has little chance to learn *anything*. In that case, trying to teach theme switching is futile. >To go look at a Help file that really is no help at all? There, of course, should be a helpful help file. >How were you planning on "telling" them? When theme switching is hyped, you could also mention how to do it. >Yes, and you still have yet to prove how Themes will be less often used than >the Java or Javascript consoles and are thus less worthy of a menu item. I think JavaScript programmers will want to display the JS console more often than the switch themes. Some users will never access the JS console. That doesn't mean JS programmers don't need the console. >I just don't think your argument that Themes won't >be popular holds any water at all. I haven't, in comments related to this feature request, argued themes won't be popular. >And what about the Themes disabler someone else mentioned above? This is a >"policy setting about he overall behavior of the app", no? "Allow/disallow sites to set the theme" would be a pref (disallow by default). "Security Policy for This Site..." would be a menu item allowing to change the settings for the current site, including but not limited to, themes, cookies, form autofill, Java and scripting. >Then, again, you can start by scrapping the Java Console, which NO ONE outside >of developers will ever touch. If the Java console menu item bothers you, you may want to file a bug about removing the Java console from the menu and displaying it automatically when an applet calls System.out.print() or System.out.println().

>It doesn't scream "Theme Switcher" It screams "settings of more permanent nature". I don't think that's good enough. But I do like the idea of making the Edit-->Preferences item a submenu. That would save time getting to the different panels in addition to allowing easier access to the themes panel. >I for one will switch themes based on the site I'm on. "Do you really want to switch the themes manually in that case? Wouldn't it be better to associate themes with sites so that you wouldn't need to switch themes manually in the future?" That's a great idea, actually, but you would still need something like the cookie manager to deal with themes on a site-by-site basis. Again, I'm tending towards making Edit-->Preferences a submenu at this point. "Should we assume the user knows what "Save As..." does?" No. Most new users I know couldn't tell you the difference between Save and Save As. "The user can find prefs by exploring the UI." The UI to me is the interface you see of the app that you see when it comes up. This doesn't include the Prefs panels, unless, again, they become subitems of the Edit-->Preferences menu. "These include reading documentation or getting training from another user. Failing that, the user has little chance to learn *anything*. In that case, trying to teach theme switching is futile." All of this to avoid adding one lousy menu item to a popular feature? My answer: make the UI easy enough to deal with so the user doesn't HAVE to go searching documentation. >Yes, and you still have yet to prove how Themes will be less often used than >the Java or Javascript consoles and are thus less worthy of a menu item. "I think JavaScript programmers will want to display the JS console more often than the switch themes. Some users will never access the JS console." Correction: MOST users will never see it. I'm not arguing that we destroy the Java console, I'm arguing that Themes, being a more popular feature than the Java console, also deserve a menu item. "I haven't, in comments related to this feature request, argued themes won't be popular." Granted. But arguing that the Java console should stay a menu item and at the same time that Themes doesn't deserve a menu item says to me that you think the Java console is a more popular, or useful, feature than the Themes Switcher. >And what about the Themes disabler someone else mentioned above? This is a >"policy setting about he overall behavior of the app", no? "If the Java console menu item bothers you, you may want to file a bug about removing the Java console from the menu and displaying it automatically when an applet calls System.out.print() or System.out.println()." It doesn't bother me. What bothers me is that some seem to be arguing that obscure developer apps deserve menu items while popular user-level features do not.

Yikes, this is receiving a lot of comments! Anyway, here is my overall proposition: 1.Keep all existing menu items, including Java and JS console. They are useful in finding out why some applet/script did not work. 2.Add a Theme Manager, which will work just like the Cookie Manager. You can choose whether to let a site set its own theme. 3.Add submenus for the preferences. This will cause many more people to use preferences. 4.Add advanced option to the Themes preference panel, such as a check box to start up with the same theme each time. 5.Add a "Use Theme" menu under the "Use Stylesheet" in the View Menu. This will allow you to change themes by selecting their names, which will be in submenus of the "Use Theme" menu. This is the right place as stylesheets are really themes for the actual content of the page (I think). 6.Add a "Themes" sidebar panel. This will have 3 parts: a.A list of all installed themes. Select to switch to that theme. b.A list of new, non-downloaded themes. Select to download and apply c.A link to a comprehensive theme archive, which will be set up. Possibly, links to other theme archives also, but it would be simpler to have just one. 7.The download contains 3 themes:Modern, Classic, and Easy. Easy will be geared for the easied possible experience. When you install, you will be asked if you want to use the Easy theme.

qaz2: your points 1, 2, 3, and 4 I agree with. I think 5. would be unnatural, though. Themes aren't really used, I think in retrospect I'll go with ChrisN's suggestion of Edit-->Theme. 6 and 7 sound like good ideas, but you may want to make new bugs of them(?) as I think they're good ideas that will get ignored here, where I'm arguing specifically for a menu item. Anyone disagree? I could be wrong here.

kovu: The reason I want it in the View menu is because (PLEASE correct me if I am wrong) <i>themes are the same as stylesheets except for the fact that they change different things.</i> Themes change what's outside the webpage, while stylesheets change what's inside the web page. If we put "Use Theme" in Edit, we really should move "Use Stylesheet" too. But view is a logical place for them both. Themes are rarely used, but that is really because there aren't many yet; there is really just modern and classic. But I am sure that, <i>if we place themes in a prominent place</i>, they will be used. This is also why I want the sidebar panel added; it will cause many more people to notice the feature. Maybe we could put an Edit Theme option somewhere; but for this, we need a user- friendly theme editor. This is a good idea anyway, as <b>the success of the idea of themes depends on there being some good themes.</b>

Methinks hyatt is about ready to kill us all (do you want us to reassign to nobody while we argue like children?) But anyways: >But why should it be *made* common if it doesn't become common otherwise? Just >because it is so kewl? In my opinion, there are preferences that are far more >important and that the users should be educated about eg. the security prefs. >Still, those are configuration settings that belong in prefs, and don't >deserve menu items that would clutter the UI. Oh, come on. That's a restrictive attitude. Do you *really* think that everything we have today that's a common appliance was the result of people actively searching for it to make it popular? I'm not at all suggesting that themes switching is going to be something _that_ common, but this great feature is definitely going to go to waste if we don't even try. And security prefs? Are you kidding me? You seem to have a much more rosy picture of the average user who's highly intelligent. Conduct an informal survey: "Would you rather learn about changing your security zones or customizing your app to your liking?" As superficial as it sounds, based on my experience with average people and their interaction with computers, most want a browser that is customized exactly to their liking...they already *expect* that their browser will handle security and will function exactly as they want. That's like the minimum...many would love to go one step further if they could (as self- centered as this sounds, I again resort to my mom because she's just about THE most average user I know...she, for one, is very creative and loves changing her IE wallpaper) >Adding too many items to menus >does not make the app easier to use. >I think JavaScript programmers will want to display the JS console more often >than the switch themes. Some users will never access the JS console. That >doesn't mean JS programmers don't need the console. You're telling me that adding "Themes Switcher" to Tasks | Tools is going to clutter up the app and make it less usable? Adding an item to what is probably the most obscure and less commonly used submenu in the entire app? Then you go on to seemingly argue that it's harder for JS programmers to find their console, which, IMHO, is just ridiculous. All I'm saying is that we have a wonderful opportunity here, and yes, an advantage. Not every application is skinnable down to every last component, widget and dialog, but ours is. If we waste a great feature now by burying it in a subcomponent of a component in the preferences and take the futile risk that most people will discover it via the help file, we're painting ourselves in the corner for future revisions, since we probably won't want to add a menu item later on. Skins and themes could explode, or they could be that little known feature... Anyways, I suggest we take this to the UI newsgroup now.

"<i>themes are the same as stylesheets except for the fact that they change different things.</i> Themes change what's outside the webpage, while stylesheets change what's inside the web page. If we put "Use Theme" in Edit, we really should move "Use Stylesheet" too. " qaz2: The problem with this is that no standard user has even the vaguest concept of what a stylesheet is. I only barely have an idea, and I consider myself a fairly high-end user. My second argument for the Edit menu is that each menu to the right is less and less used, at least, that's been my experience. There seems to be a hierarchy from left to right of importance, and so the further right you put it the less it will be seen. While View-->Change Theme might be an okay solution, I think View-->Use Theme is not, but that's a matter of a word. My point is that we shouldn't associate "Use Stylesheet," an obscure feature at best (I've never touched this myself) with "Edit-->Theme" or "View-->Change Theme" which will, IMO, be anything but obscure. Even if they are related in some way, the fact that one is very high-end and the other is not makes for a compelling argument not to associate one with the other.

kovu:well...the stylesheet thing is disabled right now, and is therefore not used much. Look at whats in the edit menu now:undo, copy/paste, select all,and prefs. This stuff is standard on most applications; edit is a very standard menu, and themes don't belong there. If a theme option was in edit, it should allow you to edit a theme. View, however, _is_ for that kind of stuff; you change how you _view_ what is on the screen. Therefore, "Use Theme" or "Change Theme" or just plain "Theme" should be there. Furthurmore, do most users know what themes are, in respect to a browser, either? Just as we can make themes popular, we can make stylesheets popular, if we make good ones, such as ones that banish all microscopic text. (You can do that, right?) However, I'd like to see what other people think.

/me wonders why henris@clinet.fi complains that it's outrageous to throw this item in an obscure, little-used submenu, but says nothing at "Use Stylesheet" having its own submenu in the View menu...the average user has no idea what a stylesheet is, and even less interest in using it.

This bug looks like a thread on N.P.M.UI, So I started a thread there. That's where most of these comments belong anyway. Sorry for generating more spam.

wow, a lot of stuff has been added since yesterday... mpt writes: > "Ben: a bug is INVALID if, and I quote, `The problem described > is not a bug'. A bug is WONTFIX if it `is a bug which will never > be fixed'. I am of the firm opinion that this report falls > into the former category, not the latter." --- bugzilla is used not only for tracking bugs in the purest sense, but also for tracking feature requests, enhancements and so on. This is one of those. Resummarising to reflect this.

For `the problem described is not a bug', read `the suggestion described is not an enhancement', if you like. Whatever. :-) In Henri's defence, I would suggest that `Use Stylesheet' is an incredibly cool feature that would be used a lot more than `Use Theme', because people are much more likely to be suddenly confronted with a badly-styled page (and want to apply different styles to it immediately) than they are likely to be suddenly confronted with a badly-designed skin (and want to change the skin immediately). A number of people in this discussion seem to be under the impression that a Web site will be able to push its skin on users, with no more warning than a dialog (which, of course, many users will blindly click `Ok' to). But I'm pretty sure this won't be the case -- a skin will be something you have to actively download, and Web sites won't be able to request that you use one skin or another. (Perhaps Dave or Ben could correct me on this.) If theme-switching were to be introduced in the menus, however, the View menu would be the logical place for it, right below the submenu which allows selection of which toolbars are visible -- because, like turning toolbars on/off, it's affecting the chrome rather than the content. This is where, for comparision, the submenus for selecting toolbar color are in both IE 5 and iCab.

All - I printed out this bug to review all comments and it was 18 pages long! I would like to offer suggestions as to how bugs like this can be handled in the future to make clear and maximize productivity for all. 1) The first thing with a suggestion such as this one is to review the planned specification for the area/feature in question. And in this case Netscape 6 vs. Mozilla plans for themes/skins. As with most new features, since this is the first project for mozilla and the first one Netscape is doing open source, many features function the same way. So, first we need to find out HOW the themes will be implemented. 2) If the ultimate plan is to include access to themes via the menu, then this bug is Invalid since it is a planned feature not implelmented yet. It would be a bug if after the feature was implemented, it did not work. But it is always advised to check the planned spec first. (I will do that on this issue later today). And Matthew, if you have an issue like this again, please let me know if you need the specs, and please use them as your justification. 3) If we find that this is indeed NOT a planned feature, then YES this is an enhancement request. No bug, or request if never "silly" (sorry Matthew, I know you were probably just frustrated...believe me, we all have these days :-) All, Matthew is human and doing the best he can. Let's all move on from that comment please). It is simply a suggestion to take to mozilla folks and escalate to Netscape marketing group if you'all think it would be a great win for the current or future developed Netscape commercial product. 4) If it looks like the suggested issue is going to generate a lot of discussion, then please someone, (Matthew, Blake, Henri? - you all know the drill :-) - suggest that the discussion be taken over to the newsgroups. This allows many others to comment, dicuss, come up with consensus for the mozilla enhancement. That is one of the functions the newgroups are set up for to help all. 5) If a bug writer feels (or the QA contact for the component area) that the enhancement would be great for a commercial product, please cc the marketing rep for that company. I am not going to add michaell at this time on this lengthy bug, but I will bring up your suggestion kovu with him and his Netscape marketing group. BOTTOM LINE - Matthew, please feel free to ping Asa or I if you have procedure questions. And especially when a bug seems a little "out of hand". We can assist you and the bug writer to come to a resolution quickly. kovu - thank you for your idea. I will bring it up with marketing and mozilla to see what they have to say, and get back to you. And please do not be disappointed if this is not doable at this time. mozilla, can make their decision and Netscape Marketing goes primarily with Usabability Tests findings. All - we have a lot of bugs to verify, and new bugs to find :-) Keep the train a rockin...this is just one of thousands of things to do! MATTHEW...to the newsgroups please :-)!!

Oops...for "No bug, or request if never "silly"" I meant 'No bug, or request if EVER "silly"

A couple of quick points. (to echo Jan somewhat) 1. if anyone has a problem with how a bug is handled by the owner or qa contact of that bug, please email Jan and me and let's sort it out somewhere other than the bug. 2. it is my position that no RFE should be marked INVALID (ok, no coherent RFE that has anything to do with Mozilla) 3. mozilla.org makes the final decision on what does and does not go into mozilla. (with resources as they are) mozilla and netscape are more likely to consider RFEs if they also come with a patch :) 4. while certain kinds (and a certain amount) of discussion makes sense in a bug report/RFE, this discussion is definitely ready for the newsgroup ( news://news.mozilla.org/3956A5F8.5C96891C%40bellsouth.net ) More volitile (especially UI) issues should probably be raised first in the newsgroups and IRC where we can come to consensus before the bug is filed. 5. everyone here wants mozilla to be the best it can be. please don't lose sight of that when you're commenting to bugs or the newsgroups. the newsgroup discussion has begun on news.mozilla.org in the group netscape.public.mozilla.ui with a post by John Dobbins Sunday 6/25 titled Themes Switcher location. news://news.mozilla.org/3956A5F8.5C96891C%40bellsouth.net

*** Bug 44026 has been marked as a duplicate of this bug. ***

Putting this on the nsbeta2 nominee list since the dup is a request from johng to get this into the product. Also, seems like a new feature. johng, please see PDT.

Putting on [nsbeta2-] radar. Not critical to beta2.

Ok, this is a preliminary implementation, since i wrote it, I'm assigning this bug to myself. Adjusted keywords, Adding cc's. Considering the history of the bug, I've reassigned the QAContact, if anyone objects they may contact me, brendan and the new qa via email or on irc. Notes about this version: .) I wanted to make it a radio check system but I'm not sure how to force a limit of one checked item in a templated popup menu, for some reason the menu isn't getting the correct border, I'll look into this. .) I use the word skin throughout the files, but maybe i should use the word theme. If you have an opinion and no one else does, please feel free to file a bug that blocks this one or is dependent on this one. .) I think that this collection of three files could be checked in as is.

Happily accepting this bug, I'd really like to see it in the tree by m18, that is the .xul and the .js. I don't care if we apply this diff to the tree or not.

spaetz accidentally overrode my changes w/ midair collision. We need to change the rules on them; I'll file a bug against bugzilla.

timeless: great! I'm on vacation now until tuesday, if you can have ben review and get approval from waterson or brendan, i can check them in when i get back (or one of them can). My personal opinion is that the item should be themes (even though i prefer skins), for compatibility with the prefs pane. in any case, nice job.

I would argue for View-->Theme Manager or View-->Themes (s/b Theme?), either right under "Sidebar" or right above "Use Stylesheets" because A) it's very much a "view-centric" capability and B) I just don't think it fits under Tasks very well, and I think the Tasks menu is kind of obscure for standard users anyway. Okay I'll shut up now, this bug is long enough.

yeah add theme swich in view->... add it in "second mouse botton" --> ... add it in help ->... add it in -->bookmarks then mozilla will be the most funny thing in the world users will have posibility to change theme even if they don't want. about MS desktop theme when i see that thing i have convuslion. imaging what happens whit old Pentium when he have to play musics. play some moving bugs aroud instead mouse pointer... it works soooo slowly this is copyright to MS they will sue us if we copy them:))) and imaging how Mozilla can kill yourself whit this things..

I don't understand what the URL is intended to show, aside from one person (who in no way represents the average user, especially given his background in computers) with a desire to go off on a rant about skins who chose Mozilla as his target. This man also presented only one side of the equation: he showed the inevitable badly designed skins. No mention was made of some of the excellent, elegant skins out there. Nor did he give anything to support his claim, aside from a random babbling of thoughts.

I also have no idea what Bozhan Boiadzhiev was trying to say. It sounded like it was intended to be some devilishly clever rant agaisnt Mozilla, but instead it came out some nonsensical, random mixture of words. If you're going to make fun of Mozilla, at least do it well!

The url field of this bug is reserved for something related to skin switching. If you have an interest in lodging complaints about skins, this is not the bug. A newer version of my diffs will be up shortly. As for humor, I'm using this bug for mozilla development, if you want to include humor in bugzilla please do it elsewhere.

The purpose of my writing this bug was simply to make the Mozilla/Netscape products and what I and MANY others feel are one of its most salable features easier to find and use, NOT to make the themes/skins-haters of the world come crawling out of the woodwork to whine that they don't like the feature. Bottom line: The only reason NOT to make this feature easier to find/use are petty personal issues with themes/skins. News flash: Like it or not, themes ARE a part of both Netscape 6 and the open source Mozilla product and that ISN'T going to change. If you have a problem with themes in general then take your rants to the UI newsgroups where the rest of us can safely ignore them.

The current patch just allows switching one app global theme. I'm considering a new menu hierarchy: Themes>[Package]>[Applicable Themes] While this is more complicated it is also more useful and should alleviate the problem of being unable to decide which theme should be checked. -- From bug 50397 [which should not exist] Comments From johng@netscape.com 2000-08-25 20:35: skin triage team had already approved a nsbeta3+, P1 because theme switching is a top priority for the product. Adding those now. I'm moving the nsbeta3+ status to this bug because it's the one the world is tracking. John in the future please don't file new bugs on old problems to which you are cc'd. I am aware that this bug is messy but it also has a following. Since I am the owner I object to this additional mess. Jan: blake and kerz were consulted and agreed w/ the entirety of this bug comment. CC's were copied over from the other bug. I'm trading QA and Assignee places w/ Blake since he and ben ended up repeating the work i had already done and has patches. The patches will be attached to this bug.

just making a couple of changes to my patches suggested by ben, and will then check it in...

fix checked in. please file a separate RFE bug for the implementation of the more complex, hierarchical menu (if you want) because I don't know if we'll get to that for this release.

verified theme switching is under the view menu 2000092810/linux