Closed Bug 556605 Opened 15 years ago Closed 15 years ago

Create New Header for IE.html

Categories

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

Product:
www.mozilla.org
Component:
General
Platform:
x86
Windows XP
Type:
defect

Tracking

(Not tracked)

Status:
VERIFIED FIXED

People

(Reporter: bcutler, Assigned: abuchanan)

References

(
URL
)

Details

Attachments

(3 files)

Preview Screenshot
379.63 KB, image/png
Details
Layout issue in IE 7
445.03 KB, image/png
Details
Screenshot of IE 6 PNG transparency issue
138.77 KB, image/png
Details
As a website experiment, we would like to replaced the current ie.html header with the smaller AMO header (http://www.mozilla.com/en-US/firefox/ie.html). If there are performance benefits, please minimize the use of images. Thanks.
A couple of questions: - the AMO header doesn't include any navigational tabs or elements. What was your thought on how we should integrate the mozilla.com tabs into this design? - related to the above, is this an experimental test or an implementable one? Thanks!
Assigning to Steven. Blake, let us know what you think about the questions in #1.
Assignee: nobody → steven
Unless you disagree, let's try a design without the nav elements. Since it's not the Mozilla.com home page, I think we can get away without including the main-nav elements. Thoughts? Do you have any objections to implementing a nav-less design (for this page only)?
Priority: -- → P1
I've set up a copy of the ie-perf.html (from bug 555235) and simplified the header as requested. This variation includes all of the optimizations (some of which are pretty hacky for now) as the original ie-perf.html file. While the original ie-perf.html weighs in at 13 HTTP requests and 115 KB total, this variation is down to 9 HTTP requests and 107 KB total. The simplified header doesn't actually save much in file size, as the header menu was already quite well optimized. The four HTTP requests are a nice improvement though. Also note that this page was setup as a quick copy of ie-perf.html on the assumption that it would be used for testing. If we end up using this more broadly, a much cleaner implementation will be required. Both this and the original ie-perf.html files seem to be including the following image, which is a 404 - does that file exist somewhere? http://www.mozilla.com/img/ss/subfeature-background-ie-perftest.jpg
(In reply to comment #3) > Unless you disagree, let's try a design without the nav elements. Since it's > not the Mozilla.com home page, I think we can get away without including the > main-nav elements. Thoughts? > > Do you have any objections to implementing a nav-less design (for this page > only)? In general, I'm not in love with the idea of having different types of headers across the site...that doesn't make for a very consistent user experience. And, those links have value in terms of directing people to add-ons, support, etc. I'm definitely up for testing this - in particular, the findings will help us make decisions for future site decisions - but I don't want to commit to losing the header from this page just yet. I'm certainly open to discussing it, especially pending the results of the test, though.
This page was setup in trunk in r65338 and can be previewed here: http://www-trunk.stage.mozilla.com/en-US/firefox/ie-test-simpleheader.html
Attached image Preview Screenshot —
Do you know why a few of the background images are missing?
(In reply to comment #7) > Do you know why a few of the background images are missing? Yes, in comment #4 I asked: Both this and the original ie-perf.html files seem to be including the following image, which is a 404 - does that file exist somewhere? http://www.mozilla.com/img/ss/subfeature-background-ie-perftest.jpg
oh, sorry about that. Image is here: http://www.mozilla.com/img/tignish/firefox/subfeature-background-ie.jpg
Missing image fixed in trunk in r65527.
Looks good. Can we push this to production now?
download button is 3.6.2, current FF is 3.6.3
Attached image Layout issue in IE 7 —
See the "Awards" section
I'll cleanup the IE6 and IE7 issues that stephend pointed out in Comments #13 and #14. As for Comment #12, this page is a copy of the one made in bug 555235. It's completely static will all CSS and Javascript moved inline, and doesn't use the site template for header, footer, or variables like version number. I presume this page is only temporary for a test? If so, we can fix this particular issues, but if it's intended for longer term use, this will become more and more of a problem. This page also won't pick up any bug fixes in JS, CSS, or PHP templates made on the rest of the site.
IE issues from comment #13 and comment #14 are fixed in trunk in r65541 (I'm not near my testing machines, but I'm pretty sure they're fixed.
(In reply to comment #16) > IE issues from comment #13 and comment #14 are fixed in trunk in r65541 (I'm > not near my testing machines, but I'm pretty sure they're fixed. Looks great to me; tested in IE 6,7,8; guess we're just now left to answer comment 15 before pushing to prod.
OS: Mac OS X → Windows XP
(In reply to comment #15) > I presume this page is only temporary for a test? If so, we can fix this > particular issues, but if it's intended for longer term use, this will become > more and more of a problem. This page also won't pick up any bug fixes in JS, > CSS, or PHP templates made on the rest of the site. Yes, this is what I understand. This test was meant to find just how much of a gain we can make, but the page is not ready for production as-is. Maybe we should spend some extra time hooking up the download button? Or just manually fix the hard-coded links for each release? There will be at least 1 more release before this test is over.
Ok, as of r65561 in trunk, en-US/firefox/ie-test-simpleheader.html now uses the LATEST_FIREFOX_VERSION variable for the download button.
What else needs to be done here?
I think we're good to go, I've tested: * IE 6, 7, 8 * links * doctype validation However, I did notice that downloads are no longer auto-starting in IE, when loading https://www-trunk.stage.mozilla.com/en-US/products/download.html?product=firefox-3.6.3&os=win&lang=en-US -- Steven, is this something you can quickly fix? I can spin off a separate bug for this, if needed.
It appears that the JS that manages the auto-start of the download in IE was dropped from ie-perf.html - does that version work?
(In reply to comment #22) > It appears that the JS that manages the auto-start of the download in IE was > dropped from ie-perf.html - does that version work? Sadly, no.
Ok, I've figured out what was wrong with the IE downloads and added an explanation in case it has an impact on the test results here: https://bugzilla.mozilla.org/show_bug.cgi?id=555235#c22 I've fixed the download process for this new simple-header page in trunk in r65567 (please confirm).
(In reply to comment #24) > Ok, I've figured out what was wrong with the IE downloads and added an > explanation in case it has an impact on the test results here: > https://bugzilla.mozilla.org/show_bug.cgi?id=555235#c22 > > I've fixed the download process for this new simple-header page in trunk in > r65567 (please confirm). Tested and verified in IE 6, 7, and 8.
Cool, can we push this to production now?
(In reply to comment #26) > Cool, can we push this to production now? I've merged everything to Stage in r65598. Alex, can you push to production?
(In reply to comment #27) > (In reply to comment #26) > > Cool, can we push this to production now? > I've merged everything to Stage in r65598. Alex, can you push to production? Yes. How come we're not marking these bugs as fixed or verified like we usually do? And, we're creating separate QA bugs for these pages, wish is also unusual. Whatever works is fine with me, but consistency would be nice.
Assignee: steven → buchanae
r65608 in production
Status: NEW → RESOLVED
Closed: 15 years ago
Resolution: --- → FIXED
(In reply to comment #28) > How come we're not marking these bugs as fixed or verified like we usually do? > And, we're creating separate QA bugs for these pages, wish is also unusual. > Whatever works is fine with me, but consistency would be nice. I'm a bit unclear on the workflow for these testing bugs, as I presume they have to go through additional steps after I deliver the markup before being completed. Perhaps those steps are in other bugs?
I'd prefer to have one bug per test, if possible.
(In reply to comment #31) > I'd prefer to have one bug per test, if possible. Me too. Could we denote the various steps within the bug, using flags or the whiteboard or something? What are those steps? Here's a few I can think of: 1) implementation 2) QA 3) push to production 4) test finished, remove files? What do you think? Another good question is, when is the proper time to mark the bug resolved and verified? Having one bug per test, and keeping all related info in that bug, would be a good way to track all our tests, as we discussed last week. Also, we should mark all test bugs somehow, either by getting them their own component, or at least putting [metrics-test] (or something) in the whiteboard
Alex, good thoughts. I've added a few comments below- (In reply to comment #32) > Me too. Could we denote the various steps within the bug, using flags or the > whiteboard or something? What are those steps? Here's a few I can think of: > > 1) implementation > 2) QA > 3) push to production > 4) test finished, remove files? We should also have another step for content creation...that would go before the current #1. > Another good question is, when is the proper time to mark the bug resolved and > verified? Stephen D, what's your take on this? > Having one bug per test, and keeping all related info in that bug, would be a > good way to track all our tests, as we discussed last week. 100% agree. > Also, we should mark all test bugs somehow, either by getting them their own > component, or at least putting [metrics-test] (or something) in the whiteboard 100% agree.
This all sounds good to me. I don't have a strong opinion, but, for now, let's put [metrics-test] in the whiteboard.
verified fixed on production http://www.mozilla.com/en-US/firefox/ie-test-simpleheader.html
Status: RESOLVED → VERIFIED
Thanks Raymond! The small header test is now live.
(In reply to comment #32) We already have the following keywords: * push-needed * qawanted Using those, in combination with the right use of Assignee, would make it clear who owns what step of the bug, at least for the testing and pushing phases. I'm not sure about the other steps.
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.

Attachment

General

Creator:
Created:
Updated:
Size: