Deconstructing Mozilla Add-ons

Standard

So I didn’t sleep that well after reading some of the 3.2 feedback. Even they admit — some of these posts are just ridiculous but in many cases they make a lot of sense. We hear you.

Since the release of AMO 3.2, our team has been working hard to gather up all the feedback to make sure our next dot release will fix major pain points introduced by the reskin.

Jumping through the post-release blog posts, I did realize that most of the posts about AMO 3.2 were positive, and I relate to many in the community who either feel they weren’t heard or we were trying to shamelessly plug our own work. Not the case, but I understand the concern.

Truth is, 3.2 was just too big. This should have been AMO 4.0, and it overwhelmed a lot of people. We will be working on scaling back the amount of drastic changes we put out in our next dot releases. Also, to remind everyone, here are some places to track changes or plans for future releases so they aren’t surprises:

From a UI perspective, not much energy has been spent discussing exactly what we were trying to do, so I’ll try to explain. A primary goal was to make the site simpler for new users. Problem was that we sacrificed some functionality in key spots in order to achieve that simplicity — and this caused some veteran AMO users some headaches. We’re rolling most if not all of these changes back in 3.4.

This brings us to the root of our UI problem — there is an identiy crisis with AMO. The site is many things to many people:

  • A place where new users try to find add-ons to improve their browsing experience
  • A hub for advanced users to pick up on the lateast and greatest add-ons
  • An incubator for new features
  • A place where developrs can get feedback and statistics for their add-on
  • A tool we use to help QA popular extensions and ensure they meet quality and security guidelines

Trick is, and will continue to be, meshing these different identities together effectively without overcomplicating or oversimplifying the site. In our latest attempt, we oversimplified it and it was a mistake. Our next dot release, which will come out before Firefox 3, will sway things back the other way and address many of the concerns brought up by long-time AMO users.

Looking forward, many of our issues are cosmetic and fixable by updating our views. The backend and scalability work done in 3.2 is still there, and despite the obvious imbalance in the UI, our feet rest on a more stable platform.

So lastly — just a quiet and humble thank you to everyone who commented on our blogs, the forums or the wiki — we look forward to honoring your feedback with changes in 3.4 as we ramp up for the biggest Firefox release ever.

18 thoughts on “Deconstructing Mozilla Add-ons

  1. Josh Aas

    That’s a pretty funny picture for this post. Isn’t MIT suing the architect that put that building together for them? Hopefully nobody sues you over AMO 3.2 🙂

  2. Hrm, hopefully. I think some people would if they could! The picture is a metaphor for mismatched expectations. Also something aside from huge blocks of text to look at.

  3. I’m a big fan of the statistics, so thanks for getting that up and running, and for your continued efforts.

    There are a few improvements that I think you could make (to the current revision of AMO, or just in general)… ignore me if they’re already there or are in progress:

    1) Shield users from sandboxed extensions again *or* use different terminology. Users are told that they’d have to register or log in to install an extension, but not why. I think this needs to be made clearer in the UI or reverted back to the old opt-in style.

    2) Display a compatible version of an extension if available. You’re already sniffing Firefox’s version to decide whether you should display an install link or not – please go one better and display the most recent compatible version of an extension. Urge users to upgrade to the latest Firefox and to use the latest version of the extension, but something to work with would be better than nothing.

    3) I still to this day do not know why, but changing the compatibility values on the site only is not sufficient to get extensions to install for everyone. I get several emails per week (ok, it’s not that many, but then how many will bother to contact me?) reporting that New Tab Homepage is incompatible with Firefox 2.0.0.*. The XPI has a maxVersion of 1.4.1, but AMO is set to 2.0.0.*.

    It’d be really awesome if you could generate a new XPI when those values are changed, at the moment I point people to my website where I’ve changed the XPI myself, but that’s far from ideal (I think people should be using AMO rather than third-party sites).

    At the moment, I’m just holding out for 3.0 and planning to upload new versions of everything, far from ideal, considering that someone’s going to have to review “updates” for no real reason!

    FWIW, this really does look like a Firefox bug, but I haven’t ever been able to reproduce it or get enough useful information from people who have experienced it.

    4) “Developer Comments” are now hidden in “Advanced Details”. All I’ve ever really used this for is informing people about compatibility with other extensions (Image Toolbar will only work on sites whitelisted if NoScript is present and enabled), and to ask users to contact me before leaving negative feedback (I prefer to resolve things quickly and get updates out than read feedback a month later).

    If this is indeed for advanced details, is it possible to either have something more prominent where we can insert this kind of information? If not, then please can you get AMO to email us when we get bad reviews or something, and provide a facility for us to reply with?

    5) What’s the difference between a detailed review and a normal review? It looks like one gets a custom title, or am I just missing something? There doesn’t seem to be a very clear distinction.

    Try not to take the harsh comments to heart, people get very upset and passionate about these things for some reason: http://xkcd.com/198/

    – Ben

  4. @Ben – Thanks for a great comment Ben. Some of these have bugs already and are slated for 3.4 (version ranges and hiding stuff in advanced details). We’ll log and follow-up on 1) 3) and 5), which are all great points.

  5. Mike,

    Thanks for following up. Can you please CC me on the bug report for #3 if/when it gets into Bugzilla with the email address used for this comment? Thanks.

    – Ben

  6. VanillaMozilla

    Thanks for posting the feedback and this blog. The careful attention is much appreciated.

    This was mentioned partly in the discussion and the feedback, but similar problems have come up previously. A lot of contributors hang out in the MozillaZine forums, and information posted there is probably the best way to get their attention before problems arise. Without information on what’s happening, people naturally assume the worst. And for people who have contributed heavily, there is very little that’s more infuriating than to feel dissed or ignored.

  7. @Ben – see bug 425539, I think it is relevant, should read some of the discussion there.

    @VanillaMozilla – we will look at starting a thread there _before_ a release as a part of reaching out, think that would help?

  8. Mike,

    Thanks for the CC, I’m definitely interested in bug 425539 and it will certainly help to have that information back (at least users have an indication of what should happen), but the problem is that it doesn’t always work that way.

    I don’t know of any bugs filed for situations where Firefox doesn’t actually retrieve compatibility data when it should, or whatever is happening to cause the install to fail later in the process. I’ll have a quick search later on if I can find time.

    Also, I noticed in that MozillaZine thread that the version sniffing and corresponding disabling/enabling of the install button is done in JavaScript – I can see this causing problems in some edge cases (anyone with JavaScript disabled is going to be able to launch the install process, whether it’s appropriate or not).

    – Ben

  9. awsco

    As one of the more vocal critics (from a users perspective), I would like to say that I appreciate your candor and honesty… It makes me hopeful for the future of this tool that has become a key asset in many folks lives.

    Regards – Art

  10. VanillaMozilla

    @morgamic,
    Yes, I’m certain it would help. People are very willing to help if they are consulted.

  11. Mozillazine increasingly has the reputation of being a nest of forum trolls. The level of complaining and flaming there is waaaay out of line with reality (even using other forums as a yardstick).

  12. I haven’t commented previously, but I think the redesign is a fantastic improvement. I’ve noticed some minor issues here and there, but overall I find it much easier to navigate the site, and it’s easier on the eyes as well (bigger, prettier).

  13. VanillaMozilla

    @Justin Dolske,
    Those “forum trolls” have worked tirelessly and have supported Mozilla and Firefox through thick and thin. I don’t know and don’t want to discuss how the public relations problems over AMO got started, but this simply has to get turned around. Mike Morgan’s post and the published feedback summary are very welcome, and hopefully will set the tone for the future.

  14. @vanillamozilla – sure but Justin has a decent point. Some forum threads are not constructive. It is a lot easier to slam something afterwards than be a part of the process up front and I see a little of that.

    That said, there is more we can do to encourage participation between the different communities who use AMO and my post is a step towards that. I think that over time as mozilla has grown maybe people didnt know how to be heard or participate and I feel like it is our responsibility to make sure that happens (yours AND mine). We’ll get there – just gotta be civil or it falls apart – I think that is what Justin is touching on. 🙂

  15. @myk – thanks Myk – and along those lines I also think we did some great things. There are some pain points around installation and discovery but the overall design is cool. We all put a lot of thought and work into this revision – so this post is not meant to take away from any of that. I wanted to address feedback and recognize that we can do a better job of listening to prevent some of those minor issues before they happen. But as I said – this was also such a large release that it contributed to the confusion and opaqueness of the process. Best we can do is identify it, learn and move on.

Comments are closed.