- Alex Buchanan
- buchanan on irc.mozilla.org
Mobile Product Pages
- what download link should the SMS contain? direct to build? or -> /m/
- format for download links?
- ftp.m.o or download.m.o?
- probably DMO. e.g. http://download.mozilla.org/?product=mobile-1.0&os=maemo&lang=en
- What needs to happen to DMO to handle this?
- doesn't actually name any requirements, besides supported phones
- 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
- developers page
- Should link to desktop downloads
- 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
- For mobile devices
Builds for mobile vs desktop
- should /m/requirements.html be /m/all.html?
- see platform detection
I don't know what these functions are for
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/