If Firefox 3 was launched today, 89,560 users would be without Microfarmer. _Find out how to update_! With our active user data, we can now tell how many users of an add-on are using Firefox 3, as well as how many have had their extension disabled for compatibility reasons. We can present this data to the developer in the Developer Control Panel (or possibly elsewhere if we're really into scaring them! - "We see you're trying to download an add-on... wouldn't it be nice if your users could use your add-on in Firefox 3? HMMM?" (that was a joke; we won't do that)). Polvi and I came up with the copy above, but maybe we'll talk with the marketing folks to see if it's too scary or aggressive. There are similar variations, like "390 people have already had their Microfarmer disabled because it's not compatible with Firefox 3" This bug isn't for committing us to doing this, just for discussing the idea.
We can work on the exact messaging but I like the general idea. I think if we show a histogram of Firefox versions Firefox Version - Total Pings (# disabled) 1.5 - 289 (53) 2.0.0.* - 45,234 (6,754) 3.0.* - 5,203 (20,001) That would be pretty useful.
An additional idea: On the developer dashboard, put "you rank #X on the Fx3 upgrade leader board". We could generate that list based on: * number of addons * number of addons upgraded to fx3 * number of people using fx3 addons * age of the addon * etc...
Alex, I didn't get how you are able to rank the author leaderboard since the most popular extensions (or the author with the most number) would always lead. I guess you are suggesting some sort of weighted formula?
(In reply to comment #3) > Alex, I didn't get how you are able to rank the author leaderboard since the > most popular extensions (or the author with the most number) would always lead. > I guess you are suggesting some sort of weighted formula? Yeah. The leader, IMHO, should be the person with the most active users running Fx3 compatible extensions. That way it would encourage the addons developers to update, and would also encourage them to encourage their users to run Fx3! Fligtar, what do you think?
I wonder if this could be even simplier... like if we detect a non beta maxVersion... we say something like, "We detected your extension is not compatible with Firefox 3 (potentially affecting XXX users)." linking to devmo. Thoughts?
(In reply to comment #5) > I wonder if this could be even simplier... like if we detect a non beta > maxVersion... we say something like, "We detected your extension is not > compatible with Firefox 3 (potentially affecting XXX users)." linking to devmo. > > Thoughts? > I like it. One complication is that we haven't yet exposed any active user data to developers. So while this would be a neat first preview for them at how many active users they have, this would only show up for add-ons not compatible with Firefox 3. So we would need to put it where everyone can access it, or not include active users. Whereas if we say something like "there are already 45 people trying to use it in Firefox 3", we would only have to show that to those that haven't updated. Regardless, it seems like this is now an appropriate time to launch something like this, so let's figure out what we want to do this week and get it pushed.
The plan is to add a message upon addon upload that suggests Firefox 3 compatibility if it is not there already. Fligtar is on the case.
Created attachment 299886 [details] [diff] [review] patch, v1 I want to look over this some more, but this adds the notice in step 3 when the developer submits a non-beta compatible Firefox version. The URL and Firefox version are set via the Site Config area of the admin cp. I also discovered what seems to be a PHP5 bug with the dev cp, so I need to look into that as well.
Oh, and the SQL patch: INSERT INTO `remora`.`config` (`key` , `value`) VALUES ('firefox_notice_version', ''), ('firefox_notice_url', '');
Comment on attachment 299886 [details] [diff] [review] patch, v1 This is good for now. I'll file a follow up bug for the PHP5 thing.
Checked in and the gettext issues are resolved now I think. We need to run the SQL in comment 9 when we push this.
This is live.