Building A Better Button

history of AMO's buttonshistory of add-on install buttons

If you’ve ever installed an add-on from Mozilla’s add-ons website, you’ve probably clicked on one of the cute, innocent-looking buttons that stand between you and the add-on you want. They’re really important, but also really complicated little devils.

Originally, the job of this button was just to link to the add-on file, and the only complication occurred if the add-on was platform-specific. Things have gotten quite a bit more complex over the years, and the role of the button changed to be a guide as to what the user should and shouldn’t install with the introduction of “smart install buttons” two years ago. Today, buttons are more complicated than ever, taking into account:

  • which application’s part of the website you’re browsing in
  • which browser you’re using
  • whether the browser add-on is incompatible due to not having compatibility bumped after your browser version’s release
  • whether the browser add-on is incompatible because your browser is outdated and requires a newer version
  • whether the browser add-on is incompatible because it requires an alpha/beta version that has not yet been released
  • whether you have JavaScript enabled
  • what type of add-on it is
  • whether the add-on is compatible with your operating system
  • whether the add-on is featured
  • whether the add-on has been reviewed
  • whether the add-on is self-hosted
  • whether the add-on has a EULA
  • whether the add-on has a contributions roadblock or post-download page
  • whether the button’s context requires it to be large or small
  • whether you’re logged in

…and combining all of those factors on the client side (for caching) to produce the button you see. Wil Clouser made a flowchart a few months ago that takes into account many of the current scenarios. We recently worked with Paul Lloyd of Clearleft to redesign some parts of the site for our Django rewrite currently underway, and as part of that, wanted to address a few issues of current install buttons, namely:

  • buttons should indicate when they don’t go directly to a file, such as when a EULA or contributions roadblock must be displayed first (bug)
  • “recommended” should be changed to “featured” and incompatibility should be moved to avoid confusing wording (bug)
  • incompatible buttons should not be green
  • add-ons that haven’t been reviewed should have visually distinct buttons and require a click-through warning (bug, blog post)
  • make self-hosted add-on buttons and warnings fit more with the current style
  • make it easier for advanced users to override the “smart buttons”
  • improve the style of the message given to non-Firefox users trying to download a Firefox add-on and make it more obvious how to download anyway (bug)
possible states of the new buttonsnew button styles

With our flowchart in hand, Paul went to work coming up with a new way of presenting our buttons that’s more consistent and takes into account all of the cases we wanted to address. One of the first suggestions made was to limit our button styles to just a few, rather than coming up with lots of different colors for different types of buttons, as we had started to do with things like collections. The new button styles have only 4 variations: green for add-ons that are reviewed and can be installed, blue for links and generic buttons, yellow with caution bars for add-ons that haven’t been reviewed, and a faded look for incompatible add-ons or buttons that should probably not be clicked.

Looking at some of most common pain points for button clickers, an annoyance often encountered is that in order for advanced users to ignore the version check for incompatible add-ons, they have to be logged in with an AMO account. We decided that the ability for a button to be clicked should not be dependent on whether the user is logged in, as long as proper warning is given. It will now be possible to ignore the warning and install an add-on anyway in every case except when an add-on has been marked as requiring a newer version of Firefox than you currently have.

Here’s a matrix showing almost all of the possible button scenarios with our new buttons:

Button Matrix

The buttons in the matrix can currently be previewed on the Button Smorgasbord. Craig Cook and Jeff Balogh created the buttons using CSS3 gradients, even for the cautionary stripes, so only browsers that don’t support them will need to download a background image.

I’m very excited for these buttons to start appearing on site as we roll out Zamboni, our Django rewrite, as I think they provide a much better experience for both novice and advanced add-on users.

  • Alexander Limi


    The green and blue buttons look a bit “cheap” though, probably because they’re so busy with the carved look + gradients + round edges. They make me think of cheap e-commerce web sites. Cautionary/Concealed buttons look great.

    Of course, take this feedback for what it’s worth — opinion. 😉

  • Robert Kaiser

    I think what we should do in any case is to allow SeaMonkey or Thunderbrowse users to install Add-ons that are compatible with their products even if they are on the Firefox add-ons site, and the same for Firefox users browsing the SeaMonkey or Thunderbird add-ons sites.
    We should be able to detect that well enough by checking UA strings.

  • Pingback: Traces of a new AMO « Mozilla Add-ons Blog()

  • Paul Lloyd

    Thanks for taking the time to write up the process we went through—it’s really great to see them starting to appear in the wild on the AMO site, and better still to experience the excellent implementation by Craig and Jeff. I’m looking forward to hearing user feedback—hopefully these new buttons will prove to be a change for the better.