Closed Bug 794109 Opened 12 years ago Closed 12 years ago

[StubInstaller] Create fallback page

Categories

(www.mozilla.org :: Pages & Content, defect, P1)

Product:
www.mozilla.org
Component:
Pages & Content
Platform:
x86
Windows 7
Type:
defect

Tracking

(Not tracked)

Status:
VERIFIED FIXED
Milestone:
Future

People

(Reporter: lforrest, Assigned: craigcook)

References

(
URL
)

Details

(Whiteboard: [stub=] u=user c=downloads p=3) 

User scenario: Jane downloads Firefox from a download button that gives her the new stub-installer but for some reason the new stub-installer fails. Redirect Jane to a page where she can download again from the full installer. 

All other info here:
https://www.easel.io/documents/1643c095b57e543d

Timing: Chris -- it would be great to have this go live within the next couple of days since it's just HTML changes, and maybe tweaks to the download button to make sure it provides the full installer instead of the stub installer. How does that sound? 

en-US only
Let's not worry about doing a visual design for this. Just get us the text, we will build something on -dev, and post it back here. We can iterate on the actual web page before pushing it out. 

Habber can provide some UX feedback on the prototype on -dev.

Can we get the content by today?
(In reply to Chris More [:cmore] from comment #1)
> Let's not worry about doing a visual design for this. Just get us the text,
> we will build something on -dev, and post it back here. We can iterate on
> the actual web page before pushing it out. 

That's fine. See this link for final copy: https://www.easel.io/documents/1643c095b57e543d 
> 
> Habber can provide some UX feedback on the prototype on -dev.
> 
> Can we get the content by today?

The content is here: https://www.easel.io/documents/1643c095b57e543d
Priority: -- → P1
Whiteboard: u=user c=downloads p=3
Target Milestone: --- → Future
(In reply to Chris More [:cmore] from comment #2)
> How about this URL?
> 
> https://www.mozilla.org/firefox/stub-interrupt

I recommend avoiding use of negative works in public facing URLS. Consider something like: https://www.mozilla.org/firefox/installer
negative *words
Assignee: chrismore.bugzilla → craigcook.bugz
I agree on the negative words. I was just trying to come up with something that is more specific because this is the failure page and not the page where you go to install it to start.

What about /firefox/installer-help ?
> What about /firefox/installer-help ?

Sounds good!
The Support link should link to an specific article that explains what did just happen (instead of the home page): "Why did the installer fail" or something similar.

We will need some context about why the Stub installer can fail (poor connection, etc).
For the link to support you might want to say "Need help installing?" and link to http://support.mozilla.org/kb/install-firefox-windows instead of "need help downloading" with a link to http://support.mozilla.org/products/firefox/download-and-install The download & install link is a list of articles. The install firefox for windows is specific steps to install firefox with the normal installer.
Thanks SUMO folk! 

I agree with @Verdi's link change above: ""Need help installing?" and link to http://support.mozilla.org/kb/install-firefox-windows" 

Let's do a additional SUMO page in another bug and focus the scope of this bug on getting a backup page in place on mozilla.org. 

Chris -- Are you blocked at all? What are next steps?
We are currently building out the page now on Mozilla.org.

Open questions:

1) The page will have a download button to the full installer. What is the logic of that button? What is the URL of the full installers? What platforms should be button be aware of? En-US only logic? The logic for download buttons is significant amount of work and QA gets tricky. If we can minimize the size of the initial market that stub installer is pushed out to, this will reduce the scope of this page for a 1.0 release.

2) How soon do you need the final Mozilla.org URL to put in the stub installer fall back?
(In reply to Chris More [:cmore] from comment #11)
> We are currently building out the page now on Mozilla.org.
> 
> Open questions:
> 
> 1) The page will have a download button to the full installer. What is the
> logic of that button? What is the URL of the full installers? What platforms
> should be button be aware of? 

Windows only. I'll get answers to the logic and URL of full installer via email from Rob Strong. 

En-US only logic? 
Yes, will localize next phase. 

The logic for download
> buttons is significant amount of work and QA gets tricky. If we can minimize
> the size of the initial market that stub installer is pushed out to, this
> will reduce the scope of this page for a 1.0 release.
> 
> 2) How soon do you need the final Mozilla.org URL to put in the stub
> installer fall back?

Early this week would be great. If the URL is finalized we can pass that on today.
(In reply to Laura Forrest from comment #10) 
> Let's do a additional SUMO page in another bug and focus the scope of this
> bug on getting a backup page in place on mozilla.org. 

I think we can skip an additional sumo page and another bug. This looks like a great plan to me. Also if/when this goes out to more than en-us, the SUMO article is already localized in most locales.
(In reply to Chris More [:cmore] from comment #11)
> We are currently building out the page now on Mozilla.org.
> 
> Open questions:
> 
> 1) The page will have a download button to the full installer. What is the
> logic of that button?
I think this question is answered below.

> What is the URL of the full installers?
http://download.mozilla.org/?product=firefox-latest&os=win&lang=AB_CD
where AB_CD is the locale. Also, I can include this in the url for the page that is opened so it matches the stub's locale.

> What platforms
> should be button be aware of?
Windows only.

> En-US only logic?
For now if that is easiest though we will want other locales.

> The logic for download
> buttons is significant amount of work and QA gets tricky.
I would hope that it is essentially no different than the current install button (with the exception that the url opened will already include the locale so that doesn't need to be detected) on
https://www.mozilla.org/


> If we can minimize
> the size of the initial market that stub installer is pushed out to, this
> will reduce the scope of this page for a 1.0 release.
> 
> 2) How soon do you need the final Mozilla.org URL to put in the stub
> installer fall back?
By Friday would be best.
:rstrong question:

What will be the difference in the d.m.o URL that points to stub installer vs a full installer?

How is the stub installer going to be deployed in a way that we don't have to change anything on Mozilla.org and people are not given the stub when they want the full?
Depends on: 794499
I opened bug 794499 to track the change of logic in our download buttons.

This bug will only track the creation of the fallback page.
OS: Mac OS X → Windows 7
Craig: Please make the download button for this fall back page to be a regular django download button. We are going to handle the logic for now in d.m.o/bouncer. Let us know when it is on a server to test.
Blocks: 796103
No longer blocks: 796103
Blocks: 796103
http://cl.ly/image/2b3o400f3p23 layout is broken in IE6. Craig can you also make sure we don't have mixed content (serve over https only)  since IE throws a mixed dialog when you click on the download button
(In reply to raymond [:retornam] from comment #18)
> http://cl.ly/image/2b3o400f3p23 layout is broken in IE6. Craig can you also
> make sure we don't have mixed content (serve over https only)  since IE
> throws a mixed dialog when you click on the download button

This is the same as bug 795409, which is fixed on stage and prod but dev is behind. I can add the IE fix to dev. The mixed content warnings should get fixed with bug 796057.
No longer depends on: 794499
Can we just get this pushed out to production since it doesn't link anywhere and no one is going to find it from anywhere else? We need to start knocking off items that we can move forward with that do not rely on anything else.
Jakem: Can you add the rule to d.m.o so that if a hit comes from /firefox/installer-help/ that it serves up the full installer instead of stub installer?
(In reply to Chris More [:cmore] from comment #22)
> Jakem: Can you add the rule to d.m.o so that if a hit comes from
> /firefox/installer-help/ that it serves up the full installer instead of
> stub installer?

This is inherent to the logic that will choose when to offer stub installer instead of full installer, so I can't add it until adding the stub installer logic itself. Right now, *everything* goes to full installer. :)
Commit pushed to master at https://github.com/mozilla/bedrock

https://github.com/mozilla/bedrock/commit/e36babe1cdc53677c6bbd23a68837a41874cfa2f
Bug 794109 - stub installer fallback page

Initial commit, work in progress
(In reply to Jake Maul [:jakem] from comment #23)
> (In reply to Chris More [:cmore] from comment #22)
> > Jakem: Can you add the rule to d.m.o so that if a hit comes from
> > /firefox/installer-help/ that it serves up the full installer instead of
> > stub installer?
> 
> This is inherent to the logic that will choose when to offer stub installer
> instead of full installer, so I can't add it until adding the stub installer
> logic itself. Right now, *everything* goes to full installer. :)

Since no one will manually get to the installer-help page, can't you put in the redirect rule to read the refer and serve up the stub installer even if it is not there yet? I know it will 404 for now, but that rule could still be staged with Ben's help on the product name.
Rob: This will be the final URL of the fall back page after it is pushed to production: https://www.mozilla.org/firefox/installer-help/
URL: https://www.mozilla.org/firefox/insta...
What about the different channels?
I'll use that for official and we can add the other channels later. For now, the other channels will just try to download the full installer via the default browser.
(In reply to Chris More [:cmore] from comment #25)
> Since no one will manually get to the installer-help page, can't you put in
> the redirect rule to read the refer and serve up the stub installer even if
> it is not there yet? I know it will 404 for now, but that rule could still
> be staged with Ben's help on the product name.

No, because the fallback page does *not* serve the stub installer. It serves the full installer.

What's happening here is that the fallback page needs to pass through *unchanged*. That means the logic for the stub-installer-redirect logic has to explicitly not redirect for requests from that page. It inherently can't do that until we actually start doing the stub installer redirect in the first place. :)

The fallback page should work right now, because it's supposed to serve the full installer, which already exists. When we implement the stub installer redirect, we just need to make sure we don't break it.
(In reply to Axel Hecht [:Pike] from comment #29)
> https://www.mozilla.org/b/firefox/installer-help/ works for me, but
> https://www.mozilla.org/firefox/installer-help/ doesn't, note the '/b/'.

That should be corrected by bug 798453
I guess we should expose this page to localizers?
(In reply to Axel Hecht [:Pike] from comment #32)
> I guess we should expose this page to localizers?

Eventually we'll need a more long term version of this page which should absolutely be localized. But for this first test we're only doing the stub installer for en-US anyway and I expect the page will be changing a lot in the next iteration.
We can keep this open until we decide what to do about the three buttons.
rstrong: here is the page with the three buttons. We don't think have multiple buttons on a page is ideal, but it was all we could do:

https://www.mozilla.org/firefox/installer-help/

Can you have stub fallback URL be dynamic like https://www.mozilla.org/firefox/installer-help/?channel=[release|beta|aurora|nightly] so that we can read that query string and only show the specific button?

If the channel query string is not passed, we will display all of the buttons as we do now.

Thanks, Robert!
Will do and get this change in by tomorrow
We do have data from a recent survey that suggests some aurora/beta users don't know the actual name of the channel they are on. It would be much safer to dynamically generate the link based on the user's existing channel.
(In reply to Chris More [:cmore] from comment #36)
> If the channel query string is not passed, we will display all of the
> buttons as we do now.
I think it makes more sense to default to release channel rather than showing all channels. Also, that should never happen anyway.

Do we want to add Nightly to this page? Currently, www.mozilla.org has no knowledge of Nightly. This lives on http://nightly.mozilla.org/.
I changed the url that is opened by the stub in bug 799611 which is now landed on mozilla-inbound and will make it to mozilla-central on the next merge from mozilla-inbound to mozilla-central. The urls used are the same as in comment #36.
Whiteboard: u=user c=downloads p=3 → [stub+] u=user c=downloads p=3
btw: if you would like I can add the locale now to the url as well so when the page is localized it is already passed. We'll need this since the user can install an l10n build that is different than the browser's locale used to view the page.
hrm. can we pass a requested locale as param instead, like we do for the channel?

That'd allow us to get the right download buttons independent of having the text on the page localized.
(In reply to Robert Strong [:rstrong] (do not email) from comment #41)
> btw: if you would like I can add the locale now to the url as well so when
> the page is localized it is already passed. We'll need this since the user
> can install an l10n build that is different than the browser's locale used
> to view the page.

What about if we just leave off the locale and let the existing locale detection and redirection figure it out?

Thanks, Rob!
Craig: Can you adjust the logic on the installer-help page so that if the querystring "channel" is defined that it displays the appropriate button only? If channel is not defined, it will display all the buttons like they do now.

values: release, beta, aurora, nightly.
(In reply to Chris More [:cmore] from comment #43)
> (In reply to Robert Strong [:rstrong] (do not email) from comment #41)
> > btw: if you would like I can add the locale now to the url as well so when
> > the page is localized it is already passed. We'll need this since the user
> > can install an l10n build that is different than the browser's locale used
> > to view the page.
> 
> What about if we just leave off the locale and let the existing locale
> detection and redirection figure it out?

The point is whether the installer can ask the page to offer a particular locale to download, and yes, that'd be nice.

I'd prefer to leave the page localization up to the website sniffing logic, yes to that.

Extreme scenario: We're adding a new locale, hardly any website done for it yet, volunteers download the build for all-aurora.html, fail, get to the installer-help page.
Alternative, and more likely: The installer-help opens in IE, and the IE localization is a different one than the downloaded firefox locale.
Good point. If the stub installer can pass an absolute URL that includes the specific locale failed installer, then no redirection to the browser's preferences will be done. That is also assuming that we have locales available installer-help page, which we currently don't. Stub installer locales and fall back pages will need to stay in sync for the best user experience.
having a url with /ab-CD/ should give the right button for the locale (but if the page is not localized, it will be displayed in English). If it doesn't, that's a bug.

Please, don't rely on locale detection, I can be using a Spanish IE to download a Catalan version of Firefox (lots of multilingual countries in the world).

I think that if we already have first hand information regarding the locale in the stub installer, we should transit this information to the page via the url.
Whiteboard: [stub+] u=user c=downloads p=3 → [stub=] u=user c=downloads p=3
Moving to wanted per stub installer meeting discussion.
Robert is going to point the nightly fall back directly to nightly.mozilla.org and all other channels to the existing installer-help fall back page.
(In reply to Chris More [:cmore] from comment #49)
> Robert is going to point the nightly fall back directly to
> nightly.mozilla.org and all other channels to the existing installer-help
> fall back page.
We can't point it to nightly.mozilla.org unless that has the ability to download the full installer which as I understand it it won't. :(
Nightly is a static-generated page with minimal logic. It would take some work to get it to know which "thing" to present to a visitor.

That said, the target audience of nightly.mozilla.org is inherently more technical... for example, we already expect them to know if they need the ARMv6 build for the Android platform... very few general users would know this. It doesn't even try to guess what platform you're on... it presents all 6 (win, osx, lin32, lin64, android armv7, armv6) to everyone, and you're expected to know which one applies to you.

Since we are clearly expecting a more technical audience here, why don't we simply have nightly.mozilla.org link to *both* the full and stub installers? Just put them side-by-side and let the users figure it out, as we already expect them to be capable of doing?
nightly.m.o is only en-US, so that's a problem for scaling to other locales later.
(In reply to Nick Thomas [:nthomas] from comment #52)
> nightly.m.o is only en-US, so that's a problem for scaling to other locales
> later.

Good point. I like :jakem's logic and it make sense except or the locale scaling problem. We would have to have all combinations of platform+locale in a huge table.
I opened bug 800643 for nightly.mozilla.org.

Let's keep this focused on the first iteration which does not include locales.
This page is done and in production so I'd like to resolve this bug. Any future changes or iterations to the fallback page should be tracked in new bugs.
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
This has been pushed to production.
verified fixed https://www.mozilla.org/en-US/firefox/installer-help/
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.