Closed Bug 584905 Opened 15 years ago Closed 13 years ago

Make Mozilla.com mobile friendly

Categories

(mozilla.org Graveyard :: Webdev, task)

Product:
mozilla.org Graveyard
Component:
Webdev
Type:
task
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED INVALID

People

(Reporter: malexis, Assigned: grlicky)

References

Details

Project Summary: With our pending Android availability, a large population will be going to Mozilla desktop pages on their mobile device looking for a way to download Firefox to their device, and get support and information. For many existing desktop users, they may not know to navigate to our specific mobile pages. To ensure a user friendly experience for our users, we recommend a group of major desktop pages be designed to be mobile/touch friendly to allow users to easily download the app, get support information, or easily download add-ons directly from the AMO page. Scope: Redesign of the following pages (or whatever the URLs will be for Mozilla.org): http://www.mozilla.com/en-US/ http://www.mozilla.com/en-US/firefox/upgrade.html http://www.mozilla.com/en-US/mobile/ https://addons.mozilla.org/en-US/mobile/ http://mobile.support.mozilla.com/en-US/kb/ Implementation - considering user agent. (Would like to emulate how wikipedia handles their pages on mobile) L10N: These pages should all be localized Timing: We'd like these pages to be available to our users by Q4 when Firefox for Android/MeeGo launches.
Just so I'm clear, is this bug seeking to create alternate versions of these pages that are optimized for mobile, or is it about changing the current live pages so they're more mobile-friendly? (fwiw, my preference is towards the former)
(In reply to comment #1) > Just so I'm clear, is this bug seeking to create alternate versions of these > pages that are optimized for mobile, or is it about changing the current live > pages so they're more mobile-friendly? > > (fwiw, my preference is towards the former) This was discussed a lot when creating the first versions of the mobile pages (bug 523034). I'd prefer we use CSS to style mobile-friendly pages without creating alternate versions. Alternate versions create duplicate content to maintain, the solution doesn't scale (e.g. if we wanted the whole site to be mobile-friendly, we'd have to duplicate the whole site), and it makes the IA weird (e.g. /mobile/ vs /m/)
(In reply to comment #2) > I'd prefer we use CSS to style mobile-friendly pages without creating alternate > versions. Alternate versions create duplicate content to maintain, the > solution doesn't scale (e.g. if we wanted the whole site to be mobile-friendly, > we'd have to duplicate the whole site), and it makes the IA weird (e.g. > /mobile/ vs /m/) Just so I'm 100% clear, under that scenario we'd have one site that would look right for either desktop or mobile, depending on the device used to view it? If so, I'm definitely on board with that. On a scale of 1-10, how hard it is to do that? (say, for just one page)
I agree with Alex and Slater, fwiw. I don't want to duplicate content and then try to manage both. I think we just want to be clear that the ui/ue will live to our standards.
We should explore creating a handheld CSS file + layout and see if that works better than creating a separate domain. If we can't rely on standards to do this with the CSS media type, we could instead use PHP or another scripting language (even JS) to switch the CSS page dynamically when a particular set of user agents are detected.
(In reply to comment #5) > We should explore creating a handheld CSS file + layout and see if that works > better than creating a separate domain. If we can't rely on standards to do > this with the CSS media type, we could instead use PHP or another scripting > language (even JS) to switch the CSS page dynamically when a particular set of > user agents are detected. Hey Mike. Caitlin and I would definitely like to pursue this option. What's the best way to get it into the queue?
It's in the queue. How does this stack up against your other projects? http://spreadsheets.google.com/ccc?key=0AhiX365xacl1cG5ueHpxaEN5Z3RlTXVBcHJqazFnWUE&hl=en
Most of the items in the mobile section of that list are short-term must haves, so this would come after things like the mobile blog or other promotional pages needed for beta 1. I talked it over with Caitlin and our recommendation is to make it a Q4 goal (shared between the engagement communications team & webdev), but focus on getting it done in the early part of the quarter. The main deadline is that it needs to be complete well in advance of the Android GA. So, first part of Q4 would be great. Thoughts?
This will be a Q4 goal and we have a full-time person scheduled to work on this starting on the 27th.
Assignee: nobody → jgrlicky
Depends on: 601767
I filed bug 601767 for the AMO mobile designs.
Summary: Make Mozilla.org mobile friendly → Make Mozilla.com mobile friendly
We should also cater to those folks who just go to Firefox.com or Mozilla.com on their mobile looking to download. Can we: 1) modify browser detection on the download buttons to point to the right mobile builds for mobile browsers 2) deploy and then redirect to browser friendly pages we can probably do #1 right away, and #2 is waiting on designs (?) but in the meantime, perhaps we can redirect to mobile First Run (Welcome page).
Haven't heard anything on this front. Is this possible?
Jason has been doing research on the best thing to do here and has been working on mocks for the AMO mobile effort. He'll follow-up today.
(In reply to comment #11) > We should also cater to those folks who just go to Firefox.com or Mozilla.com > on their mobile looking to download. Can we: > > 1) modify browser detection on the download buttons to point to the right > mobile builds for mobile browsers > > 2) deploy and then redirect to browser friendly pages > > we can probably do #1 right away, and #2 is waiting on designs (?) but in the > meantime, perhaps we can redirect to mobile First Run (Welcome page). Hey Caitlin! I met with Alex today about this particular issue and went over our options. Regarding Option #1, we agreed that the idea of a place where mobile users can download Mobile Firefox easily is important, but it seems like switching only the download button would not give them the necessary context. An alternative short-term solution we explored was to redirect users on mobile phones to the mobile-friendly page we already have in place (mozilla.com/m), which features the Download Mobile Firefox button prominently. Unfortunately, from talking to Alex it seems like our mobile detection logic right now is error prone and is going to need a lot of work before we could pursue this effectively - so that would make this not actually a short-term solution after all. This leaves our options to either investing more time into detection logic, or just incorporating this change into the mobile versions of Mozilla.com and Firefox.com we are expecting at the end of the quarter. At this point, it seems like the latter might be the best solution. To that end, Alex and I are planning more meetings in the coming weeks, and will be roping more folks in to figure out the most practical way to proceed with a mobile-friendly Mozilla.com.
The short-term solution sounds like a good plan for now. So we're developing mobile version of the Mozilla.com and Firefox.com pages? I just thought we were optimizing for mobile. I'd like to avoid trying to maintain two sets of pages. Additionally, pages that need to be "mobilized" are listed at the beginning of this bug. I identified pages where people would want to install or get help at the top of this bug: http://www.mozilla.com http://www.mozilla.com/firefox/ http://www.mozilla.com/en-US/mobile/ https://addons.mozilla.org/en-US/mobile/ http://mobile.support.mozilla.com/en-US/kb/ Sounds great!
Thanks! These are definitely the pages we'll be making mobile-friendly first. I'd really like to avoid duplicating content too, and we'll only be doing it where necessary.
Also, keep in mind that all those pages are being redesigned between now and the end of the quarter, so the way they look now isn't necessarily the way they'll look in a few weeks. That's another reason to avoid creating separate versions of the pages if we can help it...
Additionally, let's examine the pages that we link to from our about:firefox page. They all link to remote pages, but the only page that's decently readable is Credits.
Depends on: 608415
who owns specs and implementation here? Chris and myself would like to get some quick wins (i.e. in the next week) of some of the low hanging fruit. would like to get an owner so we can have someone drive a few sprints.
We have Jason working on UI and Alex will handle implementation. We have a meeting on Tuesday and will discuss what improvements we can get live within the following week.
Depends on: 630292
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → INVALID
Product: mozilla.org → mozilla.org Graveyard
You need to log in before you can comment on or make changes to this bug.