From Lukas' email: It's 6 weeks now until we ship FF31 and will need to process two versions of ESR in parallel on the org page. Can we get this triaged & prioritized so Bedrock will be able to serve these pages by then based on product-details (and, presumably, a second ESR value in p-d)?

Mike, We are going to release 31 in two weeks. Are you ready? Thanks

Hi Sylvestre- We will be ready (Mike is on PTO this week and next). Holly is going to provide some UX direction for showing 2 builds at once on the page, and then Pmac/Jgmize will make the updates to the page. -Jen

Attached are wireframes that describe 3 options: 1. Simple table tabs (easiest): Allows user to switch table content between available versions with a selector at the top of the table. 2. Improved filter area (preferred direction, better user experience): Makes it easier for the user to find their language and version in one place. All choices the user has to make (language, version, alternate beta link) are contained in one area, making these choices clear and easy to find. 3. Prioritized download (nice to have, open to discussion): If possible, let's discuss the best way to prioritize the version of the download that is right for the user visiting the page. This is a nice to have, but I'd like to open up a discussion on the best way to detect this. Is locale + system enough? I'd like to move ahead with Option 2 if time allows. See annotations for details. Please let me know if you have any questions. Dropdown/selector examples for option 2: http://harvesthq.github.io/chosen/ http://ivaynberg.github.io/select2/

A few questions: Is there l10n on this page? Option 2 could be implemented without any immediate l10n, but I'd need to revisit the copy to take out a few stings that are not in the current page. ("version" "All languages") We discussed adding a tip on the page to answer why a user may want to download the older version. Can somebody please answer this question for me? I can then find a way to implement this copy into the page and we can implement it for en-us only for now.

+sgarrity -> Hi Steven - do you have time to help us out with some front end work for http://www.mozilla.org/en-US/firefox/organizations/all/ between now and July 22? Thanks so much for providing this, Holly! My main concern at this point is timing - esp around option #3. Sylvestre: Do you have a preference among the 3 proposed mock ups? Pmac: What do you think is possible in the time we have left?

(In reply to Jennifer Bertsch [:jbertsch] from comment #5) > Sylvestre: Do you have a preference among the 3 proposed mock ups? My favorite is the #3 but I will be happy with #2 if we don't have enough time.

(In reply to Holly Habstritt Gaal [:Habber] from comment #3) > 1. Simple table tabs (easiest): Allows user to switch table content between > available versions with a selector at the top of the table. I think I like this best. I'll explain some issues I see with the other two options below. I like that it seems the best at promoting the version we want to make foremost while allowing access to the full breadth of the other options. > 2. Improved filter area (preferred direction, better user experience): Makes > it easier for the user to find their language and version in one place. All > choices the user has to make (language, version, alternate beta link) are > contained in one area, making these choices clear and easy to find. My main concern with this approach is that I'm not sure the choice of version is important enough to be promoted to the search box. I think we want to make the default the version we want to be downloaded, and a user should have to find and select another one if they know that they want the old one. I'm worried that promoting that choice will lead to higher than necessary usage of the older browser. Keep in mind that the older version on the page will be in end-of-life mode at this point. Another issue here is that not all combinations of language and version are necessarily available. We have data per language, OS and version and the download links are displayed only for those languages and operating systems that are available. It's typically fine, but could be different per version. It's possible we could make the widget respect that, but it's something to keep in mind. This will only really be a problem if you select a language, then change version and that language isn't available for that version. Question: If you just switch the version dropdown, does that switch the table below to show only links for that version? i.e. will it be similar to option 1 when switching tabs? > 3. Prioritized download (nice to have, open to discussion): If possible, > let's discuss the best way to prioritize the version of the download that is > right for the user visiting the page. This is a nice to have, but I'd like > to open up a discussion on the best way to detect this. Is locale + system > enough? This seems cool, I'm just not sure how useful it will be for the particular user this page is targeting. Individual users should not download Firefox from this page. So in the hope that they're not, this page is for IT managers at companies to download Firefox for testing and distribution to their users. So I'm just not sure how useful the download for the particular language and OS would be for this person, since they'll likely then have to go find downloads for other platforms and/or languages as well. I'm not saying it wouldn't be useful at all, just that I think it wouldn't be worth the time to make it.

Given that we have the Engagement Offsite this week and won't be able to discuss this more thoroughly, it seems best to move forward with #1 as a quick solution and discuss your feedback regarding #2 and #3 when we return. I assumed #3 would be something we would discuss later since it involves more work and logic. In solution #1, we still have the issue of not all combinations of language and version being available. If a user selects a language from the dropdown at the top of the page, and the language/version combination do not exist, we need to offer a message saying that an ESR build does not exist for their selection. (ie: "No matching version found for this language.") I'd like to consider implementing #2, so that if a user selects a language, only the versions that are available will show up in the dropdown menu. Then all choices are happening in proximity with one another instead of one choice happening in the search area and one as a table filter. I think you have some feedback that warrants a more thorough discussion. Let's discuss this more post work week and implement what you feel is the easiest solution for now. (In reply to Paul McLanahan [:pmac] from comment #7) > (In reply to Holly Habstritt Gaal [:Habber] from comment #3) > > 1. Simple table tabs (easiest): Allows user to switch table content between > > available versions with a selector at the top of the table. > > I think I like this best. I'll explain some issues I see with the other two > options below. I like that it seems the best at promoting the version we > want to make foremost while allowing access to the full breadth of the other > options. > > > 2. Improved filter area (preferred direction, better user experience): Makes > > it easier for the user to find their language and version in one place. All > > choices the user has to make (language, version, alternate beta link) are > > contained in one area, making these choices clear and easy to find. > > My main concern with this approach is that I'm not sure the choice of > version is important enough to be promoted to the search box. I think we > want to make the default the version we want to be downloaded, and a user > should have to find and select another one if they know that they want the > old one. I'm worried that promoting that choice will lead to higher than > necessary usage of the older browser. Keep in mind that the older version on > the page will be in end-of-life mode at this point. > > Another issue here is that not all combinations of language and version are > necessarily available. We have data per language, OS and version and the > download links are displayed only for those languages and operating systems > that are available. It's typically fine, but could be different per version. > It's possible we could make the widget respect that, but it's something to > keep in mind. This will only really be a problem if you select a language, > then change version and that language isn't available for that version. > > Question: If you just switch the version dropdown, does that switch the > table below to show only links for that version? i.e. will it be similar to > option 1 when switching tabs? > > > 3. Prioritized download (nice to have, open to discussion): If possible, > > let's discuss the best way to prioritize the version of the download that is > > right for the user visiting the page. This is a nice to have, but I'd like > > to open up a discussion on the best way to detect this. Is locale + system > > enough? > > This seems cool, I'm just not sure how useful it will be for the particular > user this page is targeting. Individual users should not download Firefox > from this page. So in the hope that they're not, this page is for IT > managers at companies to download Firefox for testing and distribution to > their users. So I'm just not sure how useful the download for the particular > language and OS would be for this person, since they'll likely then have to > go find downloads for other platforms and/or languages as well. I'm not > saying it wouldn't be useful at all, just that I think it wouldn't be worth > the time to make it.

Sounds good :habber. Thanks for your help with this.

We will move forward with #1.

Sylvestre: What is the procedure for updating product-details with the new version number for ESR? From the SVN history it looks like the FIREFOX_ESR key isn't updated to the new major version in firefoxDetails until the 3rd release of the new one (e.g. 24.2.0). Is this typical?

Paul, I would say that we forgot to update it... Sorry.

:sylvestre so are you saying we shouldn't rely on the version of ESR in product-details? I'm not sure how we can know exactly the released version (including point releases) of the current version without it. In order to complete this bug we need to be able to automatically know which version is newest and display the full table of downloads for that version, plus for at least 6 weeks (possibly 12) also display the previous version. The only data we have to go on is product-details. Please let us know on what data in there we can rely for doing this.

AFAIK, we planned to have two ESR declaration in product details for that. Like define('FIREFOX_ESR_NEXT', '31.0.0esr'); Lukas, can you confirm that?

Discussing with pmac on IRC, we discussed on that and I implemented the change here: http://viewvc.svn.mozilla.org/vc?view=revision&revision=130443 In particular http://viewvc.svn.mozilla.org/vc/libs/product-details/firefoxDetails.class.php?r1=130388&r2=130443&pathrev=130443

Perfect. We should have a PR in for bedrock soon that will use this to show 2 download tables when FIREFOX_ESR_NEXT exists.

Excellent, I will be updating p-d with both versions tomorrow: 24.7.0 and 31.0.0

Commits pushed to master at https://github.com/mozilla/bedrock https://github.com/mozilla/bedrock/commit/4ad81ab9664f9c3a7faf49accd573ef6f9131e76 Bug 1022900: Add 2nd table of downloads for ESR when available. https://github.com/mozilla/bedrock/commit/703604ec26869830c9be939da236f5a108f693f9 Bug 1022900: Add front-end stuff to multi-ESR download page. https://github.com/mozilla/bedrock/commit/b0318042d28fa37935140a605041d642c41f3bd2 Merge pull request #2167 from mozilla/multiple-esr-versions-1022900 Bug 1022900: Add 2nd table of downloads for ESR when available.

This is in production. As soon as P-D are updated with the new versions and build infos we should see both on the /organizations/all/ page.

This worked perfectly for ESR 38 & 45!