Closed
Bug 794109
Opened 12 years ago
Closed 12 years ago
[StubInstaller] Create fallback page
Categories
(www.mozilla.org :: Pages & Content, defect, P1)
Tracking
(Not tracked)
VERIFIED
FIXED
Future
People
(Reporter: lforrest, Assigned: craigcook)
References
()
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
Comment 1•12 years ago
|
||
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?
Comment 2•12 years ago
|
||
How about this URL? https://www.mozilla.org/firefox/stub-interrupt
Reporter | ||
Comment 3•12 years ago
|
||
(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
Updated•12 years ago
|
Priority: -- → P1
Whiteboard: u=user c=downloads p=3
Target Milestone: --- → Future
Reporter | ||
Comment 4•12 years ago
|
||
(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
Reporter | ||
Comment 5•12 years ago
|
||
negative *words
Assignee | ||
Updated•12 years ago
|
Assignee: chrismore.bugzilla → craigcook.bugz
Comment 6•12 years ago
|
||
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 ?
Reporter | ||
Comment 7•12 years ago
|
||
> 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).
Comment 9•12 years ago
|
||
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.
Reporter | ||
Comment 10•12 years ago
|
||
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?
Comment 11•12 years ago
|
||
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?
Reporter | ||
Comment 12•12 years ago
|
||
(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.
Comment 13•12 years ago
|
||
(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.
Comment 14•12 years ago
|
||
(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.
Comment 15•12 years ago
|
||
: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?
Comment 16•12 years ago
|
||
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.
Updated•12 years ago
|
OS: Mac OS X → Windows 7
Comment 17•12 years ago
|
||
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.
Comment 18•12 years ago
|
||
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
Comment 19•12 years ago
|
||
This is the page on -dev: https://www-dev.allizom.org/b/en-US/firefox/installer-help/
Assignee | ||
Comment 20•12 years ago
|
||
(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.
Comment 21•12 years ago
|
||
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.
Comment 22•12 years ago
|
||
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?
Comment 23•12 years ago
|
||
(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. :)
Comment 24•12 years ago
|
||
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
Comment 25•12 years ago
|
||
(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.
Comment 26•12 years ago
|
||
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/
Comment 27•12 years ago
|
||
What about the different channels?
Comment 28•12 years ago
|
||
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.
Comment 29•12 years ago
|
||
https://www.mozilla.org/b/firefox/installer-help/ works for me, but https://www.mozilla.org/firefox/installer-help/ doesn't, note the '/b/'.
Comment 30•12 years ago
|
||
(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.
Assignee | ||
Comment 31•12 years ago
|
||
(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
Comment 32•12 years ago
|
||
I guess we should expose this page to localizers?
Assignee | ||
Comment 33•12 years ago
|
||
(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.
Comment 34•12 years ago
|
||
Commit pushed to master at https://github.com/mozilla/bedrock https://github.com/mozilla/bedrock/commit/265c0510cadd950f9bd4f99ce7e7d544bcdd07c3 Bug 794109: Use direct links on fallback page.
Comment 35•12 years ago
|
||
We can keep this open until we decide what to do about the three buttons.
Comment 36•12 years ago
|
||
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!
Comment 37•12 years ago
|
||
Will do and get this change in by tomorrow
Comment 38•12 years ago
|
||
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.
Comment 39•12 years ago
|
||
(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/.
Comment 40•12 years ago
|
||
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.
Updated•12 years ago
|
Whiteboard: u=user c=downloads p=3 → [stub+] u=user c=downloads p=3
Updated•12 years ago
|
Blocks: StubInstaller
Comment 41•12 years ago
|
||
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.
Comment 42•12 years ago
|
||
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.
Comment 43•12 years ago
|
||
(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!
Comment 44•12 years ago
|
||
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.
Comment 45•12 years ago
|
||
(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.
Comment 46•12 years ago
|
||
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.
Comment 47•12 years ago
|
||
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.
Updated•12 years ago
|
Whiteboard: [stub+] u=user c=downloads p=3 → [stub=] u=user c=downloads p=3
Comment 48•12 years ago
|
||
Moving to wanted per stub installer meeting discussion.
Comment 49•12 years ago
|
||
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.
Comment 50•12 years ago
|
||
(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. :(
Comment 51•12 years ago
|
||
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?
Comment 52•12 years ago
|
||
nightly.m.o is only en-US, so that's a problem for scaling to other locales later.
Comment 53•12 years ago
|
||
(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.
Comment 54•12 years ago
|
||
I opened bug 800643 for nightly.mozilla.org. Let's keep this focused on the first iteration which does not include locales.
Assignee | ||
Comment 55•12 years ago
|
||
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
Comment 56•12 years ago
|
||
Commits pushed to master at https://github.com/mozilla/bedrock https://github.com/mozilla/bedrock/commit/0bbad74ec81b48e6ee90df5b62c56b9e51e0f1f8 Bug 794109 - switch to classes for button styling https://github.com/mozilla/bedrock/commit/08ec158129dc2b235652cd8a525c9f96344cf910 Bug 794109 - switch to classes for button styling
Comment 57•12 years ago
|
||
This has been pushed to production.
Comment 58•12 years ago
|
||
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.
Description
•