Closed Bug 522571 Opened 15 years ago Closed 15 years ago

Link from themes manager to personas gallery

Categories

(Toolkit :: Add-ons Manager, defect)

defect
Not set
normal

Tracking

()

VERIFIED FIXED
Tracking Status
status1.9.2 --- beta4-fixed

People

(Reporter: johnath, Assigned: mossop)

References

Details

Attachments

(4 files, 2 obsolete files)

We talked about this in the initial personas planning, listed it as a P2, but never got a bug filed about it.
Component: General → Add-ons Manager
Product: Firefox → Toolkit
QA Contact: general → add-ons.manager
What do we actually want to link to? Given that we've attempted to make personas appear to be like other themes then it may make sense to link to a page on AMO that lists both lightweight themes and normal themes.
(In reply to comment #1)
> What do we actually want to link to? Given that we've attempted to make
> personas appear to be like other themes then it may make sense to link to a
> page on AMO that lists both lightweight themes and normal themes.

Indeed. Without a landing page to point at, it's hard to do much. cc'ng AMO folks.

Having said that, Dave, what do you think about cooking up a patch that prefs the URL, and uses, say:

https://preview.addons.mozilla.org/en-US/firefox/personas/

for testing purposes? That way an official URL is a trivial change. If we are looking at adding this to the string freeze impact (it's one of the bugs beltzner mentioned in today's Eng call discussion with Axel), we could even build things so that we only show the link if the pref is specified, and land the support pre-URL, but I wouldn't blame you much for disliking that idea.
I dislike adding hidden UI as it's gonna be hard to make the addons dialog be rightly sized if at one point another UI thing pops up.

This seems to be in a state where I'd rather make the cut on the "not take it" side. Like, we don't have a mockup, we don't have a page on AMO, etc.

For trunk, we should probably use the url formatter to generate a url that localizes on AMO, but I guess mossop knows that.
As our in-product URLs usually take the form of add-ons.mozilla.com/whatever and just redirect to the appropriate AMO page, it's easy to have this page go to a different page later.

I kinda think the AMO Personas landing page with a promo box in the left sidebar that advertises the old themes section of the site would be sufficient for this link. (We should probably cross-promote on both of those sections regardless)
Attached image screenshot (obsolete) —
My plan is to use the code and string that already exist for basically doing this but is currently hidden. We probably want to move it to somewhere else but this is what it looks like right now.

It currently links to https://%LOCALE%.add-ons.mozilla.com/%LOCALE%/%APP%/%VERSION%/themes/
Blocks: 511104
No longer depends on: 511104
Sorry, using existing strings in new contexts is l10n-impact. In particular in cases when the space constraints for the string change, which I expect to be the case here from the screenshot.
It's not a new context. The string exists exactly for that link.
Well, as the UI element isn't there right now, it is different context, if only graphical.

Differently put, if the existing buttons plus the new link are wider than the default size of the add-ons manager, the localizer may want to fix this one way or the other.
The screenshot is misleading. It's actually only one button, "Override all compatibilty" is from an extension.
Dave, when you get a moment can you hack this into a local build and put up a screenshot to help Axel's nerves? :)
http://mxr.mozilla.org/l10n-mozilla1.9.2/search?string=getThemes.label&find=extensions.dtd shows quite a few locales that have significantly longer translations than "Get Themes", fwiw. I think it's competing with http://mxr.mozilla.org/l10n-mozilla1.9.2/search?string=cmd.checkUpdatesAll.label&find=extensions.dtd for screen estate.

Hardly any locale changed the width of the dialog so far, too, http://mxr.mozilla.org/l10n-mozilla1.9.2/search?string=em.width&find=extensions.dtd.
Sorry this dropped off my radar. So it seems we can either leave the string roughly where it is, though we have the risk that some locales may have strings that are too long for that, or we move the string some other place in the UI which is technically a string change and so it'd be difficult to justify for this non-blocker.
It's a non-blocker, certainly, but if you have cycles available to get a patch together, can you do so? I understand Axel not wanting to break the EM UI for translations with long strings, but the longest ones I see in Axel's list look, to my naive eyes, like they should fit, and in any event we can fix this on trunk.
Attached image screenshot
This is the more realistic screenshot of what it would look like. Here the string is in the same place as it was when last visible in Firefox 2
Attachment #407424 - Attachment is obsolete: true
Attached patch patch rev 1 (obsolete) — Splinter Review
And this is the patch that does it
Assignee: nobody → dtownsend
(In reply to comment #16)
> Created an attachment (id=408733) [details]
> screenshot

Axel - does this screenshot still worry you in terms of string length?
I wouldn't say "worry", but "uneasy".

I'd love to be in shape to say "let's just have a mozmill test validate the dialog sizes throughout", but I'm not.
How many locales are we looking to ship with 3.6 that we didn't ship in 2.0? I would expect all those that shipped in 2.0 to be fine since the string was there then with the same button present.
How do we want to proceed here? This patch is basically ready though I presume we need to update the url with something AMO provides
(In reply to comment #21)
> How do we want to proceed here? This patch is basically ready though I presume
> we need to update the url with something AMO provides

Yeah, on this week's personas call, I'll ask Nick/WebDev what the final landing page should be for this thing.
(In reply to comment #23)
> What's wrong with the existing
> https://%LOCALE%.add-ons.mozilla.com/%LOCALE%/%APP%/%VERSION%/themes/ proxy?

Potentially nothing, but that page right now doesn't, for instance, have any notion of personas exposed. So the resolution might be "keep using that URL, we'll update the page" or it might be "since AMO treats personas and themes as separate categories and merging them is hard, let's use this custom landing URL that combines the two, instead."
I think the plan is to have this AMO url redirect to the getpersonas site in the 3.6 launch timeframe and then remove that redirect if and when personas gets phased out in favor of AMO.
Oh wait, I just looked at the screenshot and I agree with Fligtar- since this link is for both themes and personas, we should point to AMO with cross promo modules for themes <-> personas as well as a link to the personas plus add-on.
So just to confirm, https://%LOCALE%.add-ons.mozilla.com/%LOCALE%/%APP%/%VERSION%/themes/ is the correct url to use?
(In reply to comment #28)
> So just to confirm,
> https://%LOCALE%.add-ons.mozilla.com/%LOCALE%/%APP%/%VERSION%/themes/ is the
> correct url to use?

And should we have an AMO bug to track the construction of the appropriate cross-promo page?
Comment on attachment 408734 [details] [diff] [review]
patch rev 1

Requesting review on the basis that the url is probably right, and we can just change it after the face if not
Attachment #408734 - Flags: review?(robert.bugzilla)
Depends on: 528318
Depends on: 528318
I think we should link to a page that can at least potentially offer all sorts of themes, as the add-ons manager doesn't discriminate between the different kinds. Opening https://addons.mozilla.org/%LOCALE%/%APP%/personasfx directly doesn't seem to satisfy this. So I think we want to keep https://%LOCALE%.add-ons.mozilla.com/%LOCALE%/%APP%/%VERSION%/themes/ as a redirecting service.
Comment on attachment 408734 [details] [diff] [review]
patch rev 1

Code looks fine but please get feedback from UX about the placement of the getMore url on Windows. It is a tad disconcerting to have the Find Updates button move when switching views.
Attachment #408734 - Flags: review?(robert.bugzilla) → review+
I personally think the get more url should be to the left of the Find Updates button.
(In reply to comment #34)
> Created an attachment (id=412153) [details]
> screenshot regarding comment #33
> 
> I personally think the get more url should be to the left of the Find Updates
> button.
btw: this suggestion would only affect platforms that aren't XP_UNIX so it wouldn't change the look of the earlier screenshot.
(In reply to comment #34)
> Created an attachment (id=412153)
>  --> (https://bugzilla.mozilla.org/attachment.cgi?id=412153)
> screenshot regarding comment #33
> 
> I personally think the get more url should be to the left of the Find Updates
> button.

I concur.  It just seems more natural and common to see a button near the right bottom edge of the window.  Having the link inbetween seems a bit off.
Can't the link be always opposite to the button?
Should be fine to put it on the left side but it should be to the right of the install button which is used by non browser apps such as Thunderbird.
I recommend putting the link next to the "Find Updates" button in both cases, away from the corner of the window - so to the left of Find Updates on Windows, and on the right of Find Updates on Mac. 

The reason to put the two buttons together is simply so the user has one place to look for their options rather than two.  It's the reason OK and CANCEL are not on opposite parts of most dialogs.

The reason to not put the link on corner, as in https://bug522571.bugzilla.mozilla.org/attachment.cgi?id=412153 , is to precent displacing a known button - especially when switching to different addons tabs would effectively cause it to jump left and right
(In reply to comment #32)
> I think we should link to a page that can at least potentially offer all sorts
> of themes, as the add-ons manager doesn't discriminate between the different
> kinds. Opening https://addons.mozilla.org/%LOCALE%/%APP%/personasfx directly
> doesn't seem to satisfy this. So I think we want to keep
> https://%LOCALE%.add-ons.mozilla.com/%LOCALE%/%APP%/%VERSION%/themes/ as a
> redirecting service.

It doesn't really make a lot of difference what the specific url is, either way it can redirect or display whatever content we like. One potential benefit of changing URL though is that it can display themes and personas when the old one didn't and maybe shouldn't for older clients (though we are talking ancient here).

However I do need confirmation that https://addons.mozilla.org/%LOCALE%/%APP%/personasfx is the right url since that isn't the url mentioned in the dependent bug 528318, Nick?
(In reply to comment #40)
> (In reply to comment #32)
> > I think we should link to a page that can at least potentially offer all sorts
> > of themes, as the add-ons manager doesn't discriminate between the different
> > kinds. Opening https://addons.mozilla.org/%LOCALE%/%APP%/personasfx directly
> > doesn't seem to satisfy this. So I think we want to keep
> > https://%LOCALE%.add-ons.mozilla.com/%LOCALE%/%APP%/%VERSION%/themes/ as a
> > redirecting service.
> 
> It doesn't really make a lot of difference what the specific url is, either way
> it can redirect or display whatever content we like. One potential benefit of
> changing URL though is that it can display themes and personas when the old one
> didn't and maybe shouldn't for older clients (though we are talking ancient
> here).

The %VERSION% part should handle that.
(In reply to comment #41)
> (In reply to comment #40)
> > (In reply to comment #32)
> > > I think we should link to a page that can at least potentially offer all sorts
> > > of themes, as the add-ons manager doesn't discriminate between the different
> > > kinds. Opening https://addons.mozilla.org/%LOCALE%/%APP%/personasfx directly
> > > doesn't seem to satisfy this. So I think we want to keep
> > > https://%LOCALE%.add-ons.mozilla.com/%LOCALE%/%APP%/%VERSION%/themes/ as a
> > > redirecting service.
> > 
> > It doesn't really make a lot of difference what the specific url is, either way
> > it can redirect or display whatever content we like. One potential benefit of
> > changing URL though is that it can display themes and personas when the old one
> > didn't and maybe shouldn't for older clients (though we are talking ancient
> > here).
> 
> The %VERSION% part should handle that.

Possible yes, but certainly more complex to do smart matching based on the all the different versions we use. Changing the word "themes" to something else makes it simpler I expect.
Attached patch patch rev 2Splinter Review
Reorders based on comment 39. Also keeps a margin on the link since otherwise it looks to squashed on OSX.
Attachment #408734 - Attachment is obsolete: true
Attachment #412631 - Flags: review?(robert.bugzilla)
Attached image screenshot on OSX
Comment on attachment 412631 [details] [diff] [review]
patch rev 2

nit: please put getMore next to the spacer for the windows case... it is just easier to parse that way. Thanks and r=me
Attachment #412631 - Flags: review?(robert.bugzilla) → review+
(In reply to comment #40)
> However I do need confirmation that
> https://addons.mozilla.org/%LOCALE%/%APP%/personasfx is the right url since
> that isn't the url mentioned in the dependent bug 528318, Nick?

Confirmed with Nick that the URL needs to be https://addons.mozilla.org/%LOCALE%/%APP%/getpersonas per bug 528318
Landed on trunk http://hg.mozilla.org/mozilla-central/rev/a6db334c3c84
Status: NEW → RESOLVED
Closed: 15 years ago
Resolution: --- → FIXED
Since clicking on this gives a 404 page anyway at https://addons.mozilla.org/en-US/firefox/getpersonas, maybe it should be more generic like /themesandpersonas.

Since I wouldn't expect to try clicking on get themes and always end up at getpersonas.com when I'm really looking for themes in the add-ons website.
Hi, 
why is it there only a link to the personas gallery? 
Why is there not a link to the other themes? 

Cheers
(In reply to comment #49)
> Hi, 
> why is it there only a link to the personas gallery? 
> Why is there not a link to the other themes? 

The plan is for the link to go to a page offering both kinds of themes, but since that page doesn't exist yet it will just redirect to getpersonas.
(In reply to comment #50)
> (In reply to comment #49)
> > Hi, 
> > why is it there only a link to the personas gallery? 
> > Why is there not a link to the other themes? 
> 
> The plan is for the link to go to a page offering both kinds of themes, but
> since that page doesn't exist yet it will just redirect to getpersonas.
So, if the patch here is incomplete, why has it landed? I propose to just revert it until that page exists.
(In reply to comment #51)
> (In reply to comment #50)
> > (In reply to comment #49)
> > > Hi, 
> > > why is it there only a link to the personas gallery? 
> > > Why is there not a link to the other themes? 
> > 
> > The plan is for the link to go to a page offering both kinds of themes, but
> > since that page doesn't exist yet it will just redirect to getpersonas.
> So, if the patch here is incomplete, why has it landed? I propose to just
> revert it until that page exists.

The patch is complete, it is all the client code. It has landed before the server side work is complete to give us a chance of getting this into 1.9.2.
(In reply to comment #27)
> Oh wait, I just looked at the screenshot and I agree with Fligtar- since this
> link is for both themes and personas, we should point to AMO with cross promo
> modules for themes <-> personas as well as a link to the personas plus add-on.

Is there a bug on file to create this page yet Nick?
(In reply to comment #53)
> (In reply to comment #27)
> > Oh wait, I just looked at the screenshot and I agree with Fligtar- since this
> > link is for both themes and personas, we should point to AMO with cross promo
> > modules for themes <-> personas as well as a link to the personas plus add-on.
> 
> Is there a bug on file to create this page yet Nick?

The bug on file is to make a redirect to getpersonas, bug 528318.  If you want a page listing both themes and personas having /getpersonas in the name doesn't sound right.
(In reply to comment #54)
> (In reply to comment #53)
> > (In reply to comment #27)
> > > Oh wait, I just looked at the screenshot and I agree with Fligtar- since this
> > > link is for both themes and personas, we should point to AMO with cross promo
> > > modules for themes <-> personas as well as a link to the personas plus add-on.
> > 
> > Is there a bug on file to create this page yet Nick?
> 
> The bug on file is to make a redirect to getpersonas, bug 528318.  If you want
> a page listing both themes and personas having /getpersonas in the name doesn't
> sound right.

Nick agreed that we want a page listing both in comment 27, but that is up to you guys to implement however you like. Please let me know what URL you want to change to so I can get it landed in Firefox a.s.a.p.
IT's actually a page that is primarily personas with a link to get to the themese gallery so /getpersonas is fine.
(In reply to comment #56)
> IT's actually a page that is primarily personas with a link to get to the
> themese gallery so /getpersonas is fine.

Hi, 
sorry - can you explain what this should connoted. 
Is it only now a page that is primarily personas and this page should be changed, 
or is it intended to have a page that is primarily personas .. so /getpersonas is fine. 

Cheers
It is intended to have a page that is primarily personas, as you said.
(In reply to comment #58)
> It is intended to have a page that is primarily personas, as you said.

And why?
(In reply to comment #58)
> It is intended to have a page that is primarily personas, as you said.

Hi, again 

Why, please tell me why ;-) 

I think a lot of themer are interested to know, why their stuff should be hidden and why this limited background image change system should be highlighted. Why?

Is it then as well intended to hide the normal extensions, when Jetpack is later a part of the default installation? 

And when you are still on the way to tell some reasons.   
Why works Personas on 3.6 by default only with the default themes. Is it still intended to change it with 3.7 or later. Why works the Personas 1.4 extension still only on Mac OS X only with the default theme and why is there absolutely no progress in the last months to improve the situation.  

By the way, 
i know a lot of themer, who think Mozilla want to kill the old theme system. Some words as well about it would be very nice. It is hard to find an example that something else is intended. This theme page primarily for Personas is then only one example more. 

Cheers
Link exists now on Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.3a1pre) Gecko/20091118 Minefield/3.7a1pre.
Status: RESOLVED → VERIFIED
Comment on attachment 412631 [details] [diff] [review]
patch rev 2

We should take this simple change on 1.9.2. No risk of regression I think, mostly just moves around UI.
Attachment #412631 - Flags: approval1.9.2?
Attachment #412631 - Flags: approval1.9.2? → approval1.9.2+
Dave, might be a good thing to file bugs for Thunderbird, SeaMonkey, and Sunbird regarding removing the prefs in case they want to continue not displaying the get more urls.
(In reply to comment #60)
> By the way, 
> i know a lot of themer, who think Mozilla want to kill the old theme system.
> Some words as well about it would be very nice. It is hard to find an example
> that something else is intended. This theme page primarily for Personas is then
> only one example more. 

As this discussion about integration from Personas in Firefox appeared the first time on the MozillaZine Forum: http://forums.mozillazine.org/viewtopic.php?f=18&t=1086895 , this document caused a little discomfort on the Theme Development Community: https://wiki.mozilla.org/User:Mconnor/PersonasUplift , particularly this: https://wiki.mozilla.org/User:Mconnor/PersonasUplift#Deprecation_of_old-style_themes

But later, it was possible to read some statements that Personas would not substitute third party themes, like in this discussion: http://groups.google.com/group/mozilla.dev.planning/browse_thread/thread/7ea89af8e3e8dc64# and here: https://bugzilla.mozilla.org/show_bug.cgi?id=510909#c4

But the whole process until now shows a tendency to "deprecate" third party themes or clearly discriminate third party themes as "second class citizens" at the whole process.
First will Personas be called "Theme" and be listed at Addons Manager as "Theme" (I should try this: buy a Golf and call it "Ferrari" and tell everybody in the whole world that I've bought a Ferrari and repeat it every day. For the "skeptics" I can argument that both have the same propose - transport people. Maybe at the end I will own a Ferrari at all...)

More than this: it is called "lightweight", "new-style" Themes in opposite to the third-party themes, the "heavyweight", "old-style" Themes (give the words "light" and "new" the impression to be better then "heavy" or "old"?)

After this, Personas as it is now, don't work with third party themes... One more discrimination.

Now we have a link called "get Themes" pointing to a site that primarily offers Personas.

Nothing against promoting Personas, but it is necessary to discriminate third-party themes to do it? Making other products look bad makes my product better?

Strangely this document: https://support.mozilla.com/en-US/kb/Using+themes+with+Firefox doesn't make this discrimination and explain very well the difference between Personas and "full themes". Why is this changing for 3.5 after?

All of this is actually killing the motivation for Themes Authors to be still developing their themes. Too bad... Actually it is a hard work to build a theme for Firefox, believe me...

So, can someone please, transparently and honestly, answer this simple question?:

Are you going to kill third-party themes?
Bugzilla is not a forum. The appropriate place to have discussions and raise concerns about large features is in the newsgroup mozilla.dev.apps.firefox.
(In reply to comment #67)
> Bugzilla is not a forum. The appropriate place to have discussions and raise
> concerns about large features is in the newsgroup mozilla.dev.apps.firefox.

Ok, 
on mozilla.dev.apps.firefox. is now a thread called: 
Link from themes manager to personas gallery  - Theme discrimination

Cheers
(In reply to comment #65)
> Dave, might be a good thing to file bugs for Thunderbird, SeaMonkey, and
> Sunbird regarding removing the prefs in case they want to continue not
> displaying the get more urls.

Filed bug 530099, bug 530101, bug 530102
(In reply to comment #58)
> It is intended to have a page that is primarily personas, as you said.

Hi, 
just a reminder ;-) 

It is still not primarily a Personas site. It is still ONLY a Personas site.

Cheers
Is this another move to force the 'heavythemes' into oblivion?
Authors, like me, of these themes have worked hard to make perfect themes for FF, but now the Themes panel is redirected to the Personas/lwthemes stuff, bypassing the thousands of existing themes for Firefox.
Alfred, surely you saw Aronnax's comment 3 above your own, about having this discussion in newsgroups, instead of resolved bugs? You have been around the project for some time, you know how Mozilla works - advocacy in closed bugs rarely leads to the results you'd want, no?
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: