It would be nice to show the compatible app version range for each version of an addon. We never did this before but now we have those smart install buttons...

craig has a temnplate for a version of this based on some mockups of mine: http://mozilla.focalcurve.com/versions-simple.html I think we'd want the compatibility range to be more visually distinct than in that template (darker, or with more space around it)

Here's the earlier mockup - it has compatibility ranges in it. Ignore the "smart" version-detecting box at the top.

This may be nitpicking on my part, but shouldn't the "don't use old versions" warning be below the current version box, i.e. above the old versions in question? Also, minor layout note: The text in the current version box probably shouldn't wrap around before going above the install button. That doesn't need 2 lines there.

(In reply to comment #4) > This may be nitpicking on my part, but shouldn't the "don't use old versions" > warning be below the current version box, i.e. above the old versions in > question? I believe so too, yes. Per comment 2, I suggest the new layout to be implemented at the same time as this fix; setting bug dependencies accordingly.

(In reply to comment #4) > This may be nitpicking on my part, but shouldn't the "don't use old versions" > warning be below the current version box, i.e. above the old versions in > question? Yeah, that's a good point. I wonder if it's worth also making it more explicit that the top version on the page is the current version. Maybe "(Current Version)" after the version number?

This patch introduces one new l10n string. It pretty much follows the mock-ups Craig and Madhava. I didn't have Works with: * Firefox: 2.0 – 3.0pre all on one line because there might be more than one app and also this allowed me to re-use an existing element. Getting the most recent compatible version at the top of the versions page was a headache. I rewrote the code a couple of times. Initially, I was doing UA detection on the server and then I remembered this might cause problems with caching. So now I do it via Javascript. My feeling is that the install button code is becoming more and more of a dark and hacky art. In this case, I modified the addCompatibilityHints function so that it now has a side effect of recording in a global the first time it was called and a button was compatible. Then I have an additional setTimeout function which is called after (because they are fired in sequence given the 0 second delay and it is last in the document) all the others which copies the first compatible add-on info to the top of the page. I think all versions of an add-on for each platform are now listed on the versions page, so Bug 420332 is also probably resolved by this bug. I tested my patch using the production database. PicLens is a useful test case, because it shows that after I copy the most recent compatible to the top I do fix the platform links on showcase version so that only one button is displayed.

(In reply to comment #7) > I didn't have > > Works with: > > * Firefox: 2.0 – 3.0pre > > all on one line because there might be more than one app and also this allowed > me to re-use an existing element. For reference, that's bug 374890, which probably should be revived now.

Comment on attachment 320412 [details] [diff] [review] noticed mock-up had a title above most recent compatible so added that Works for me. Something to think about, re: - 'compatibleApps'=> $compatible_apps, + 'compatible_apps'=> $compatible_apps I'd like to stay consistent with our naming and all other variables in that array are camel-cased. Not sure why you switched it.

checked into r13019. The install button code expects compatible_apps, a couple other places besides my patch call the install button element stuff so I thought it might be risky to change to the camel-case. But I agree it would look better

Verified FIXED; checked with JavaScript disabled, too, and the "most recent version compatible with" section disappears and there's a flat view of all the versions. I checked PicLens using Minefield on https://preview.addons.mozilla.org/en-US/firefox/addons/versions/5579, which didn't show the "Add to Firefox" button nor the "most recent version compatible with" section because it's not compatible with Firefox 3. I also checked Clipmarks using Minefield on https://preview.addons.mozilla.org/en-US/firefox/addons/versions/1407, which DOES show the "most recent version compatible with" section for the converse reason (it _is_ compatible). Finally, I checked Foxytunes using Firefox 2.0.0.14 on https://preview.addons.mozilla.org/en-US/firefox/addons/versions/219.

Hm, isn't there a little too much room between the individual items? That's probably not a reason to reopen this, I am just wondering if somebody else thinks so, too?

A little more than the mockup, yeah, but I wasn't going to hold this bug hostage :-) Spin-off time?

(In reply to comment #14) > Spin-off time? Yes, would you be so kind? (/me just notices he needs a bookmark for "file a new AMO bug").

I don't think we should hold up but Stephend, can you please file another bug for "multi-app" support on this. E.g. if you look at https://preview.addons.mozilla.org/en-US/firefox/addons/versions/71, scroll down to version 0.89.5. You'll notice that there's no differentiation of different apps and the same "Add to Firefox" button is repeated even for Thunderbird.

(In reply to comment #15) > (In reply to comment #14) > > Spin-off time? > > Yes, would you be so kind? (/me just notices he needs a bookmark for "file a > new AMO bug"). Filed bug 433401.

(In reply to comment #16) > I don't think we should hold up but Stephend, can you please file another bug > for > "multi-app" support on this. E.g. if you look at > https://preview.addons.mozilla.org/en-US/firefox/addons/versions/71, scroll > down to version 0.89.5. You'll notice that there's no differentiation of > different apps and the same "Add to Firefox" button is repeated even for > Thunderbird. Basil, isn't that bug 374890 (comment 9)? It's not in the Thunderbird view: https://preview.addons.mozilla.org/en-US/thunderbird/addons/versions/71 ("Download Now", correctly).

(In reply to comment #18) > (In reply to comment #16) > > I don't think we should hold up but Stephend, can you please file another bug > > for > > "multi-app" support on this. E.g. if you look at > > https://preview.addons.mozilla.org/en-US/firefox/addons/versions/71, scroll > > down to version 0.89.5. You'll notice that there's no differentiation of > > different apps and the same "Add to Firefox" button is repeated even for > > Thunderbird. > > Basil, isn't that bug 374890 (comment 9)? > > It's not in the Thunderbird view: > https://preview.addons.mozilla.org/en-US/thunderbird/addons/versions/71 > ("Download Now", correctly). Nevermind; I'm dense and now see what you mean. Filed bug 433409; sorry for spacing out!