From MozillaWiki
Jump to: navigation, search


  • Alex Buchanan
  • buchanan on
  • Webdev

Mobile Product Pages

  • /m/requirements
    • doesn't actually name any requirements, besides supported phones
  • index-later
    • how will locale selection happen for the SMS text functionality?
    • SMS functionality seems unfinished
      • text field not editable? no, just necessary to choose a country first, but not intuitive. text box could say "choose a country" or be hidden or have a more obvious disabled style. hard to tell it's disabled.
    • link should be relative
  • Platforms page
    • title should match the sidebar nav and the link to it
    • e.g. title should be "Other platforms and languages"
    • Where do download links go? Should be replaced with a locales table?
    • Replace desktop platform links with locales table
    • Uses Fennec in content
  • Main download button?
    • e.g. home page
  • Start off keeping release notes on one page?
  • /m/ pages should be as light as possible
    • drop background sprites for page and download button
    • Urchin necessary?
    • Tracking JS necessary? Can we parse logs instead?
      • On the other hand, if it's loaded in the footer, it shouldn't hurt

examples, links, resources

Builds for mobile vs desktop

naming conventions

  • should /m/requirements.html be /m/all.html?

platform detection

locale detection

  • see platform detection

I don't know what these functions are for

  • getDownloadTablesByContinent
  • getDownloadListForContinent
  • getFilteredDownloadTableForBetaBuilds
  • getFilteredDownloadTableForPrimaryBuilds

Feedback from madhava

Caitlin asked me to have a quick look. Looks good to me! Just a couple of points:

- on mobile, we want those "rows" to be 6-7mm tall and defined as such (not in px, etc.) - a button for the "download" links would be good -- doesn't have to be strong visually, but useful to have a big tap target - I suspect the fonts should be bigger for readability without zooming on a mobile device, but we can check that out

- one longer-term thing -- it would be great to avoid a grid for all the OS versions on the mobile version when that becomes necessary. Could we do OS detection and just offer the right version instead? There's a use case on the desktop for wanting another OS version (deploying elsewhere, etc.), but less so on a mobile device, and it adds a lot of page complexity. Anyway, this is not an issue today, so don't let me hold anything up with that.


  • How can we make download options clear and prominent? I'm thinking mostly about desktop visitors here, and thinking about all the times I've heard that a small tweak in a download button can result a change of millions of downloads. Text in a bulleted list can be very clear, but also text itself is easy to skim and skip over, while a good download button is clear and hard to miss. I think most of our early traffic will be desktop users going to /mobile/ who are looking to learn about FF-mobile and how to download it.
  • If a user visits /mobile/ from an N900 (or future supported platform) I think we should detect that, and either have a download button ready, or forward them to /m/