During uplift planning, the idea was raised to rename the "Themes" tab within the add-on manager to reflect the the fact that it contains both themes and personas. Opening this bug to discuss the idea further and setting a dependency on uplift tracking bug for tracking purposes.
Or the Lightweight themes should be separated into a separate tab, indicating the difference between these personas/lwthemes and real themes...
(In reply to comment #1) > Or the Lightweight themes should be separated into a separate tab, indicating > the difference between these personas/lwthemes and real themes... That is a 3.7 discussion, really - and depends on work that Mossop is doing on the EM API. I think don't think changing the string here is critical in the way that the undo changes in bug 518468 are, so it may be that the resolution is WONTFIX here (especially if 3.7 changes obviate the need) but I do appreciate Suneel filing the bug so that there's a record of the discussion.
OS: Mac OS X → All
Hardware: x86 → All
Version: unspecified → 1.9.2 Branch
the question is more about what we can do in the 3.6 timeframe to avoid cognitive dissonance in how we're mixing existing themes with personas in the UI in that we're grouping both together in one interface and keeping the existing label of "Themes". a cheap idea was to relabel the tab to "Themes & Personas" (which would require a string change in the client) and/or add a suffix to the persona titles in the JSON to more clearly differentiate them from existing themes, e.g. "Groovy Blue" > "Groovy Blue Persona" (which we can do on the server side) as jonath mentions, this will probably be resolved separately for 3.7 as part of the reworking of the extension manager UI.
"Theme" seems like an appropriate cover term to me. The two are implemented differently, but why would users care? Since we only have one list and all items are treated equally (except that some need a restart and others don't), I don't see how two labels would be beneficial. I rather think it could confuse users, since Personas seems to be a de-facto brand name but not a standard term in software (is it a commonly used word outside of software?). I'm not sure how I would translate this to German or whether you would even expect localizers to do so.
Sorry, but I don't think "Theme" is an appropriate name for Personas. This could be true on the boring Theme System from Chrome, but not for Firefox. I also don't agree our users aren't "smart" enough to distinguish between "Personas" and "Themes". Indeed the talk in the net now is about which themes are playing nice with which "persona", so I guess any user interested on "appearance changes" has the ability to recognize what is a theme and what is a persona.
I assume that talk on the net is between theme authors and/or users of the Personas extension. The former group is irrelevant for this discussion. The latter isn't, but it's a minority in our user base.
I do not think Themes tab need renaming. Neither for Ukrainian l10n, nor for English. Having some mention in theme description about its nature (if it's a real theme, or persona) might be good. It might explain to users why they sometime need to restart the browser, sometime do not.
(In reply to comment #6) > I assume that talk on the net is between theme authors and/or users of the > Personas extension. The former group is irrelevant for this discussion. The > latter isn't, but it's a minority in our user base. I don't really know, but I guess people interested on Firefox appearance changes are anyway the minority. I know a lot of friends of mine, Firefox users, that have absolutely no idea what is a theme or an extension. When I say about talk on the net I'm referring, for example to this review for my theme: "Great Theme, especially with Personas Wow... Recently I've started using only themes compatible with Personas, and this one works perfectly. Thanks!" And many, many other statements and screenshots about how my theme work together with personas... I'm expecting a couple users blaming me because my theme will not work with Personas on FF 3.6. No problem, I know to who I will forward these blames ;-) IMHO, these and other bugs, issues involving Personas integration are the result from the decision to incorporate it on the Extensions Manager as Theme. The best place for Personas IMO is where it actually is: menu On the menu it is much more "discoverable" to end users. It shows clearly it is a "native feature" from Firefox, and doesn't make confusions with third party themes. I really can't see any advantage to have it on the Extensions Manager instead of menu... I can't understand why you are forcing Personas to look like it would be something it is not...
Some themes, like my Nautipolis and LittleFox do actually support the use of Personas. There should be a way to allow the combination of a Personas 'theme' with a normal 'Theme'. When Personas was just an extension this was possible (and still is via the extension), but now that FF3.6 has 'lwtheme' build in, it outcasts existing themes. This outcasting behaviour is not Mozilla like, and one should allow theme extensions. Note, I have been theming Mozilla for 10 years now, ofwhich5 years for FF, and now this is stopped because of this. I have invested time to support Personas in my themes (with great effect), but now Personas is refusing to support me.... I think also therefor that Personas and Themes should have seperate tabs...
I agree. Themes and Personas are different. Personas are only a basic change, mostly for fun, they do not affect many places, do not affect button appearance, etc. Themes, on the contrary, are a result of a very detailed work, with a completely changed appearance.
After installing FF3.6, i am only able to use Persona's with ... the Default(!) theme- wtf? Strata40 works beautifully with Persona's- the buttons & other elements of the theme compliment any/every Persona design...But the ugly green Back/Forward buttons of the Default theme clash horrendously with a number of Persona's- this is totally ridiculous & not well thought out in the least. Regarding the Themes vs Personas issue, the way things are currently being implemented is totally confusing: - After using a Persona (for ex. "Blue") w/ the Default theme (since I had no other choice), I now see a theme(?) called "Blue" (or the name of the Persona used) listed among my other themes in the sidebar... ->So every time we use a Persona, it is listed as a...theme? A theme which can be un-installed? ->But Persona's are still also considered an Add-On? (as it does appear in my Add-Ons list) ->So if I keep switching around Persona's, each one I tried out will then appear listed as a "theme"- in effect, clogging up my Sidebar/Add-Ons manager every single time I switch Persona's, even if they were only in use for a few seconds/minute?! Also confusing was how I kept reading that Firefox 3.6 would be "Introducing Persona's", despite the fact that we'd ALREADY been introduced to Persona's? (Yet the irony is that version 3.6 essentially took Persona's AWAY from us, now that they can only be used w/ Default theme- I know for my own tastes I don't particularly like the default theme, & so without it & am also without Persona's as well). It appears that this whole new direction with Persona's was not well thought out- in fact the Persona's/Firefox team seem to be just as confused as the users are regarding the new changes & what, exactly, Persona's ARE now (Theme? Add-on? Both?).
EDIT- Above^, when I say "-->But Persona's are still also considered an Add-On...", I think it's apparent that by "Add-On", I mean "Extension" :)
One small label change should (and can) be observed right a way. The link "Get Themes" no longer points to the Themes add-ons. It should be relabled as "Get Persona".
IMO, this is being solved separately in the redesign work. Want to keep bugs in the old UI separate from the new UI.
No longer blocks: 550048
Going to finalise the new category names in bug 565300
Assignee: johnath → nobody
Status: NEW → RESOLVED
Last Resolved: 9 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 565300
You need to log in before you can comment on or make changes to this bug.