Closed Bug 616533 Opened 14 years ago Closed 14 years ago

SUMO mobile-friendly landing page

Categories

(www.mozilla.org :: General, defect)

defect
Not set
normal

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: malexis, Unassigned)

References

()

Details

Design is done and we're ready to start on the static page and styles.

Verdi: we'll need a list of articles and names to be listed on the page. Jason can you provide by EOD today?

Jason can do most of the work without the list so it's not a blocker to start on this.
I'll have the new titles by the EOD - working on it now.
Here are the new title:

How do I sync Firefox between my desktop and mobile?
How do I upgrade Firefox?
How do I use the Awesome Screen?
How do I change preferences?
What are the mobile keyboard shortcuts?
How do I manage downloads?
How do I open a new tab?
How do I find and install Add-ons?
How do I remove or disable Add-ons?
How do I surf the web with mobile Firefox?
How do I add a bookmark?
How do I zoom in and out of a website?
Verdi, could you clarify which of these should be in the top 3 section? The first three in the list?

I think Jason needs the URL targets, too. (I tried https://support.mozilla.com/en-US/kb/How%20do%20I%20sync%20Firefox%20between%20myvdesktop%20and%20mobile for example, but it didn't work; and I would recommend that we trim the slugs anyway.)
Where will the resulting page live on mozilla.com? We need to know that in order to set up the proper redirects on the SUMO server(s). If we're still looking at a b3 release on Thursday, we're really starting to run out of time. There's a SUMO push scheduled for that day, fwiw (bug 617072). 

Furthermore, it would make sense to change the in-product links in Fennec to use the established format that we use for in-product links from (desktop) Firefox:

http://support.mozilla.com/1/%PRODUCT%/%VERSION%/%PLATFORM%/%LOCALE%/help-page-slug

In this case, the link to the help start page might be:
http://support.mozilla.com/1/mobile/4.0/android/en-US/firefox-help

This way, we could easily catch these in-product requests and redirect appropriately to this mobile start page (and, long-term, to the small screen templates) if the platform is Android/Maemo/small screen.

Cc'ing Cheng: I believe you helped figure out the product name for Firefox Home -- would using "mobile" like the above cause any conflicts?
Hey David,

You will be able to redirect to http://mozilla.com/m/support. Alex has the landing page files now, so barring any unforeseen complications, they should be integrated into mozilla.com soon. I'm not sure if we have enough time to get everything QA'd before the Thursday release. Fingers crossed.
David, Cheng:

Do you know exactly which destinations we want to redirect? I figure the default in-product URL for mobile devices:

    /1/mobile/%VERSION%/%PLATFORM%/%LOCALE%/

and anything else? I filed bug 617390 so we can track the redirects there.
(In reply to comment #5)

I think we used firefox-home as the product url link for firefox home.  I'm not 100% sure it's respected though in all links.  We'll probably want to audit fully in either case.  (bug 579592 and bug 571128 for those following along at home, pun totally intended)


(In reply to comment #7)
Hmmm... I just realized that we're in a bit of slug conflict trouble here.

If we have the inproduct links in mobile have the same slugs (as in not-product-specific slugs) as desktop, then we'll need htaccess redirects to get those slugs to work.
I wonder if we can instead do:
/1/mobile/%VERSION%/%PLATFORM%/%LOCALE%/slug > /kb/mobile-slug
/1/firefox-home/%VERSION%/%PLATFORM%/%LOCALE%/slug > /kb/fxhome-slug
/1/sync/%VERSION%/%PLATFORM%/%LOCALE%/slug > /kb/sync-slug

And then use explicit product names in slugs.

That minimizes the redirects we'll need and allows us to add inproduct support links and corresponding articles without pushes.
I'm not sure I understand: comment 8 seems well beyond the scope of what we need for this bug and bug 617390.
Landed Jason's page on mozilla.com trunk, r78859

Adding         en-US/m/support
Adding         en-US/m/support/index.html
Adding         img/mobile/support
Adding  (bin)  img/mobile/support/background.png
Adding  (bin)  img/mobile/support/btn.mobilesearch.png
Adding  (bin)  img/mobile/support/disclosure-indicator.png
Adding  (bin)  img/mobile/support/firefox-logo.png
Adding  (bin)  img/mobile/support/firefox-logotype.gif
Adding  (bin)  img/mobile/support/icon.searchloupe.png
Adding         style/mobile
Adding         style/mobile/support.css
Transmitting file data ........
Committed revision 78859.
Thanks a lot to Alex and Jason for stepping up and helping us out with this!

I noticed that if you're on HTTPS, and try to use the search, you get a secure-content warning. Might be best to use a protocol-relative URL for the form action? (e.g. "//support.mozilla.com/search")
(In reply to comment #11)
> Thanks a lot to Alex and Jason for stepping up and helping us out with this!
> 
> I noticed that if you're on HTTPS, and try to use the search, you get a
> secure-content warning. Might be best to use a protocol-relative URL for the
> form action? (e.g. "//support.mozilla.com/search")

Fixed
qa-verified-trunk https://www-trunk.stage.mozilla.com/en-US/m/support/ using Firefox Mobile for Android
looks like nobody thought of pushing the en-US and template files live, I have 27 locales on trunk ready to go to production and waiting for en-US to be on production first.
Keywords: push-needed
not the right component, that's why it didn't get love :)
Assignee: jgrlicky → nobody
Component: Webdev → www.mozilla.com
Product: mozilla.org → Websites
QA Contact: webdev → www-mozilla-com
on production in r80699, marking fixed
Status: NEW → RESOLVED
Closed: 14 years ago
Resolution: --- → FIXED
Keywords: push-needed
Component: www.mozilla.org/firefox → www.mozilla.org
Component: www.mozilla.org → General
Product: Websites → www.mozilla.org
You need to log in before you can comment on or make changes to this bug.