User:Abuchanan

From MozillaWiki
Jump to navigation Jump to search
The printable version is no longer supported and may have rendering errors. Please update your browser bookmarks and please use the default browser print function instead.

Me

  • Alex Buchanan
  • buchanan on irc.mozilla.org
  • 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.
    • Mozilla.com/m 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. mozilla.com 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.

Madhava


  • 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/