Closed Bug 619986 Opened 14 years ago Closed 13 years ago

[Fx4Launch] design new universal header/header tab for Firefox sites

Categories

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

Product:
www.mozilla.org
Component:
General
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
VERIFIED FIXED

People

(Reporter: jslater, Assigned: smartell)

References

(
URL
)

Details

Attachments

(4 files)

Universal Mozilla Tab - 3 Scenarios
308.15 KB, image/jpeg
Details
Universal Mozilla Tab - Expanded
132.13 KB, image/jpeg
Details
Screenshot of the new header design in Internet Explorer
146.64 KB, image/jpeg
Details
Screenshot of PNG images in IE6
21.35 KB, image/png
Details 
This is the design bug to follow up on the conversations we had during the work week to create an improved universal header (or header tab) for mozilla.com, AMO and SUMO. 

General goal is to create a header (or types of headers) that will keep the sites unified and the traffic flowing appropriately, but also make sure that it stays out of the way of the key content. For that reason, we were thinking about optimizing the full header bar on mozilla.com, but moving to a "header tab" model (ex. https://addons.mozilla.org/en-US/thunderbird/) for SUMO and AMO that would cause the full header to slide down (with much panache) when you click on or roll over it.

There are more nuances beyond that, of course, but that's the short version. Sean, I'm sure you know what to do, but if anyone else wants me to go into more detail for the record I can.

In terms of timing, we should have the visuals here wrapped up by early January so we can begin implementation (and b/c they will likely have a ripple effect on AMO & SUMO designs in general).
Assignee: smartell → nobody
Component: Design → www.mozilla.com
Product: Marketing → Websites
QA Contact: design → www-mozilla-com
Target Milestone: --- → 1.0
Assignee: nobody → jslater
Target Milestone: 1.0 → 1.1
John can you update status for this?
Target Milestone: 1.1 → 1.0
Sean is working on mockups and is planning on posting those by EOD Friday. At that point (or before), we should figure out the webdev resourcing for this and what release it will go in so we can get it done.

But as far as next steps go, Sean is working on the mockups. Stay tuned!
Target Milestone: 1.0 → 1.1
All creative you see is preliminary investigation and not final. 

Some comments:

- red on dark site / charcoal on light site
- line at top to hint at expandable area above top margin (2px max)
- 3 sizes to allow choice when adding to websites

We'll need to keep accessibility and mobile in mind with this and perhaps have it onClick so mobile can successfully use it.  Might be a mobile variant also if we were to use another stylesheet.
- very early exploration is simply .org footer in the area. We'd need to explore what content would be here and the best layout based on those reqs.
Awesome, thanks Sean.

The main thing here is that we have both short & long term objectives.

Short term (1.1 release on Jan 25): we need to find a header style that works well with the various needs of mozilla.com, AMO & SUMO. That could be switching to a non-header for some pages (like on the Thunderbird AMO page) + breadcrumbs, or it could be something else, but that's technically the scope of this particular bug.

Long term (Q2): as part of the larger goal of unifying our sites, we need to come up with an awesome expando-header in the vein of comment #4. To do that, we'll need a lot of discussion about what actually goes in there, as well as how the interaction will work. 

Anyway, I'm going to set up a meeting early next week so the key stakeholders can talk through the options, particularly what's needed in the short term. Very excited to see this taking shape!
These look great, Sean.  

For the long term goal John mentioned, I added these images to the Universal Tab draft wiki page at

https://wiki.mozilla.org/Websites/Taskforce/Proposals/Universal_tab#Mockups

We can talk through this with people at next Thursday's task force meeting.
Moving this to 1.2 release as details are still being nailed down.
Target Milestone: 1.1 → 1.2
Target Milestone: 1.2 → 1.3
Hoping to get this into 1.2...Sean will be posting new mockups soon.
Assignee: jslater → smartell
Target Milestone: 1.3 → 1.2
Hey all,

New .com style mockups can be found here:
http://mozilla.seanmartell.com/engagement/mocodotcom/header-mocks/

- phase 1 headers added.
- various tweaks to the look n' feel of the current style to compliment the layout without the blue bar.
I like it :)
w00t!

I really like this too...feels like a great next evolution for the site, and sets us up to have common elements across all mozilla sites, which has been a longtime goal.

We'll probably have to make some tweaks in the implementation (for example, it'd be good to include the 'enter address' email signup field & functionality we added to the first run page with the 1.1 release) but nothing big.

Steven, what do you think the dev time on this would be? Is it something we can get into the 1.2 release, or should we wait until 1.3? I'm excited to make it happen, but certainly don't want to cut corners on implementation (or QA) in the process.

Also, I'd be interested to hear what the SUMO team thinks of this, as ultimately this is a solution we want to work on that site too.
I presume from the mockups that clicking the Mozilla tab will slide open the bar along the top. We'll have to take some time to make sure we get this interaction right and do it in a way that doesn't have a performance hit.

Making the actual design changes is something that can be done in a few days - but we'll have to allow some time for finding the edge cases and side-effects of this around this site (pages that have features that overlap with the header bar, etc.).

Short answer: doing this by 1.2 code freeze (Thurs, Feb 3) is possible, but tight. We'll try for it.

Is this design far enough along to begin implementation?

A few quick questions: 
 - This mockup re-introduces the fixed-width/left-aligned arrangement for the header menu (Desktop/Mobile/Add-ons/etc.). This was dropped at some point in the nova redesign for variable-width/center-aligned menu items. Can you confirm that this arrangement should come back?
 - The interaction details of the newsletter form in the collapsed bar could stress the schedule a bit - perhaps we could start with the simple link we have in the mockup and improve it in later iterations? That said, a newsletter sign-up form in that bar seems like an odd choice to me - it's hidden and I can't see anyone expecting it to be in there.
I also noticed that on the Features page mockup [1] there is an in-page element (the Top Features box on the right side) that is updated to match the new menu style. Are there other elements beyond the header that will be similarly affected? How about the footer?


[1] http://mozilla.seanmartell.com/engagement/mocodotcom/header-mocks/features.png
Also wondered if we could have a "close" link in the expanded panel? See http://cognition.happycog.com/ for an example. The nice part of their implementation is that if you click the square/arrow icon in the top right, you can click again in the same cursor location to close the panel.

Either way, should clicking the "mozilla" tab after the panel is open close it again? I'm assuming so.
Great points Steven.

I'll be making a list and highlighting all of the tweaks to make them clear.

Excellent example there from happy cog. Let me have a go at seeing how we could do that too. Their use of an arrow element pointing up at the menu is also interesting.

for the top features box with the new style, changing the style is fairly low priority if it comes down to it.

re: menu items and fixed width - the menu item width should accommodate the longest word in the sub menus and that should dictate their width. For menu items with two or more words, I'll show what a wrapped line item would look like. Another and probably better option would be for the menu item's width to expand across depending on the width needed, if that were possible. (I know that might not be fluid on older browsers sans transitions, but it'd be snazzy)

one thing that I'd like to standardize is the edges on all our rounded elements should be a border-radius of 4px moving forward to reflect the elements within the browser UI. subtle little consistency bits.
(In reply to comment #15)
> re: menu items and fixed width - the menu item width should accommodate the
> longest word in the sub menus and that should dictate their width. For menu
> items with two or more words, I'll show what a wrapped line item would look
> like. Another and probably better option would be for the menu item's width to
> expand across depending on the width needed, if that were possible. (I know
> that might not be fluid on older browsers sans transitions, but it'd be snazzy)

Thanks for the thorough reply. I'm not sure that fixing top-level menu item width to the widest sub-item is workable. The Support menu, for example, would be particularly long to accommodate the "Thunderbird Support" sub-item title. This could end up make the closed top-level menu items have a seemingly random width to visitors who haven't opened any sub-menus yet.

I would propose the following:
 a) Top-level menus are only as wide as their title+padding (as they are on mozilla.com today). They could be changed to have a fixed min-width if the aesthetics of the left-align was preferred.
 b) Sub-menus are either fixed as they are now, or as wide as the widest sub-menu item title, but either way, sub-menu width is independent of top-level item width. We could give sub-menus a min-width to ensure they are never narrower than their parent.
These look great.  

In terms of how this applies to Mozilla sites beyond mozilla.com/AMO/SUMO it would be nice to make some tweaks to this and then start getting feedback.  Some suggestions:

* Show this tab appearing on a site other than mozilla.com/AMO/SUMO.  Any site would work, but to throw out a suggestion maybe nightly.mozilla.org?

* Show the expanded area with some universal content.  Right now the expanded area seems to be for secondary information specific to that particular site.  Some of the ideas for what universal content could fit are at

https://wiki.mozilla.org/Websites/Taskforce/Proposals/Universal_tab#Expanded_Content

BTW, if this is beyond the scope of this bug, I can open a separate bug for applying this universally.
(In reply to comment #16)
> Thanks for the thorough reply. I'm not sure that fixing top-level menu item
> width to the widest sub-item is workable. The Support menu, for example, would
> be particularly long to accommodate the "Thunderbird Support" sub-item title.
> This could end up make the closed top-level menu items have a seemingly random
> width to visitors who haven't opened any sub-menus yet.
> 
> I would propose the following:
>  a) Top-level menus are only as wide as their title+padding (as they are on
> mozilla.com today). They could be changed to have a fixed min-width if the
> aesthetics of the left-align was preferred.
>  b) Sub-menus are either fixed as they are now, or as wide as the widest
> sub-menu item title, but either way, sub-menu width is independent of top-level
> item width. We could give sub-menus a min-width to ensure they are never
> narrower than their parent.

Good point here Steven. For extra reasons why we should avoid fixed-width top-level menus, see these localized SUMO headers:
http://support.mozilla.com/de/home
http://support.mozilla.com/fr/home

Whether sub-menus are same-width as parent or not, they should have a min-width and a max-width set. Again, looking at the two headers above, it seems that min-width should be the parent's width, and max could be an absolute pixel value.

In general, it would be great if the design worked well with all these localization issues (length of menu/submenu items, items spanning multiple lines, left- vs center-aligned text in that context, etc).
(In reply to comment #17)

> * Show the expanded area with some universal content.  

for the headers shown, it is a phase 1 version of the headers for now. universal content will be mocked up for phase 2 in the near future.

also, I'm going to investigate ways of showing the menu + dropdowns that are less static. will update the mockups soon.
Lots of great discussion here, thanks all. It sounds like the details are already being resolved, so I won't get too into that, but here are some quick comments:

(In reply to comment #12)
> Making the actual design changes is something that can be done in a few days -
> but we'll have to allow some time for finding the edge cases and side-effects
> of this around this site (pages that have features that overlap with the header
> bar, etc.).
> 
> Short answer: doing this by 1.2 code freeze (Thurs, Feb 3) is possible, but
> tight. We'll try for it.

Totally understood. This is a pretty big change, and we definitely don't want to break anything in the process. If it slips into 1.3 to cover any extra QA or edge case work that's fine.

>  - The interaction details of the newsletter form in the collapsed bar could
> stress the schedule a bit - perhaps we could start with the simple link we have
> in the mockup and improve it in later iterations? That said, a newsletter
> sign-up form in that bar seems like an odd choice to me - it's hidden and I
> can't see anyone expecting it to be in there.

That's fine - let's start simple with the newsletter and then we can expand on it later. As for the oddness of the newsletter being up there, I think it's ok (it's also not the only place we'll have the newsletter signup)...this is really a first pass at the content for that header. I think we'll refine it much more over time.

(In reply to comment #17)
> * Show this tab appearing on a site other than mozilla.com/AMO/SUMO.  Any site
> would work, but to throw out a suggestion maybe nightly.mozilla.org?

Sounds good to me.
 
> * Show the expanded area with some universal content.  Right now the expanded
> area seems to be for secondary information specific to that particular site. 

Yeah, that's definitely something we want to do but should be covered in a separate bug with a separate discussion. Phase 1 is implementing the basic header with site-specific info; phase 2 will be figuring out how to add another layer of more 'across the universe' content. That's absolutely a project for the task force...I'd guess it will require a lot of discussion to get right.
OK, I opened bug 629699 for the phase 2 part of this.
(In reply to comment #20)
> Totally understood. This is a pretty big change, and we definitely don't want
> to break anything in the process. If it slips into 1.3 to cover any extra QA or
> edge case work that's fine.

Given how we're still working through some of the interaction/layout issues on the menus, I'm thinking 1.3 is more likely.
(In reply to comment #22)
Moving this to 1.3.
Target Milestone: 1.2 → 1.3
Just to clarify - we're waiting on design/interaction updates from Sean before implementation. Just want to make sure we aren't all waiting for each other.
http://mozilla.seanmartell.com/popup/index-dropdown.html

That's my hackery at the animation stylez for the dropdowns. I was tired and there are many redundancies in the CSS most likely. please transmogrify to your liking.

:)

final revision of the style of the header expanded view to follow...
Great stuff, thanks Sean.
So after much thought and layer shifting, we're not going to have an expanded header on Phase 1 for the main site.

We were going back and forth on what to add up there and decided that we don't want to force unnecessary nav before the full universal nav is finalized.

For now, lets keep the tab there and simply have it redirect to mozilla.org on click.

We can still have it expand on AMO as designed.  There, it serves the purpose of revealing the main site nav.
+1 from me on that plan. Steven, do you need anything else from us?
Blocks: 626665
(In reply to comment #28)
> +1 from me on that plan. Steven, do you need anything else from us?

We'll need a PSD of the new tab design.
(In reply to comment #29)
> We'll need a PSD of the new tab design.

Actually, I see the header is included in the PSD for the Security page on Bug 626665 - that should do. That design includes an arrow on the "mozilla" tab, though - should that be dropped if we're not doing an expanded header?

Any concern about having a "mozilla" button on mozilla.com that points to mozilla.org? That's a lot of mozillas.
(In reply to comment #30)
> Actually, I see the header is included in the PSD for the Security page on Bug
> 626665 - that should do. That design includes an arrow on the "mozilla" tab,
> though - should that be dropped if we're not doing an expanded header?

Sean, can you confirm that that PSD will work? And your call on the arrow.

> Any concern about having a "mozilla" button on mozilla.com that points to
> mozilla.org? That's a lot of mozillas.

Nope, it's all part of the overall strategy and will get clearer when we do the .org URL switch in Q2.
First pass at this is implemented in trunk in r82322.

 * Animation behaviour is from the original (blue header) rather than Sean's HTML mockup as animating the height brings in additional Javascript dependencies that we'd like to avoid.

 * No menu flydown in IE6 - though this isn't working in production either - is that intentional? Not as far as I know.

 * Gradients, shadows, etc. as Firefox only so far, still need -webkit equivalents.

 * No gradients/shadows/corners at all in IE. It's pretty bare-looking in IE. We might need some background-image fall-backs.

 * Pages with fancy feature images that overlap or otherwise interact with the blue header bar will need to be updated.

Comments and feedback are appreciated - this is a high-visibility change.
(In reply to comment #32)
> First pass at this is implemented in trunk in r82322.

Thanks Steven. What's the URL to view?
Added -webkit and standard hooks for CSS shadows and gradients in r82328.

In the bottom left of the footer on the live site, the wordmark is "Mozilla Firefox", while in this PSD, it's just "Firefox" - which should it be? (it's broken right now in trunk either way)

(In reply to comment #33)
> Thanks Steven. What's the URL to view?

Any page in trunk: http://www-trunk.stage.mozilla.com/en-US/firefox/
Updated the feature images on the Mobile page (trapeze) and Plugin Check page to work with the new header (r82335).
Summary: design new universal header/header tab for Firefox sites → [Fx4Launch] design new universal header/header tab for Firefox sites
This looks great, thanks Steven. The only thing that feels off to me is the font in the main headers. It looks a little smaller and bolder in Sean's mockups...can you fix?
(In reply to comment #36)
> This looks great, thanks Steven. The only thing that feels off to me is the
> font in the main headers. It looks a little smaller and bolder in Sean's
> mockups...can you fix?

These fonts were based on Sean's HTML/CSS prototype from comment #25 - I've reverted them to the previous font size/family, which is closer to the PSD mockups (r82392).

John, can you address the footer logo question from comment #34? Thanks.
Thanks Steven. The fonts look good to me now. As for the logo, the way it is on the live site is correct - sorry about the confusion.

Anything left to do here or is it ready for QA?
If I can comment on the design here (I know, not cool to comment afterwards), I feel like there is a background image missing. The way the borders are displayed, I kind of expect an image behind.

And on the homepage, without any section highlighted, it is almost invisible.
Thanks Anthony (although yes, the feedback could have been a bit more timely!). I think we're ok for now, but we definitely can continue to iterate on this design to continue perfecting it (after it goes live) if we feel like that's needed (or if data shows we need to).
(In reply to comment #38)
> Anything left to do here or is it ready for QA?

The main outstanding question for me is, how well do we need to handle IE6/7/8 in the menu styles. What we have now is completely functional, but not really pretty. The attached screenshot shows how the menu looks in IE6/7/8.

Fortunately, the IE9 preview renders the header nicely.
the IE menus are fine as long as they are functional.

If they want pretty, they can download Firefox imo. :)
Sean took the words out of my mouth. Obviously it'd be nice if it looked better on IE, and if there are tricks we can use to improve I'd be interested in discussing them, but usually "functional but not pretty" is about as good as it gets for IE users.
Sounds like we're ready for QA then. I added a minor padding fix for IE6 in r82417. I'll merge to stage and update the bug.
Talked to James - we're ok to QA this in trunk. Got for it!
Status: NEW → RESOLVED
Closed: 13 years ago
Keywords: qawanted
Resolution: --- → FIXED
Steven, the logo in the upper left isn't correctly transparent:

https://www-trunk.stage.mozilla.com/en-US/firefox/RC/

You should be able to use full PNGs on most browsers except IE (not sure about newer versions), and I think there's js hacks to get it working in IE.
Perhaps on those pages we should keep the current logo:

http://www.mozilla.com/en-US/firefox/beta/
http://www.mozilla.com/img/template/header-logos.png

The tab in the top right has problems, too.
Even though the beta pages will become *a lot* less relevant very soon, it really seems best to have the header be consistent throughout the site. How hard is it to fix the logo transparency issue?
could we have the logo as pure 24-bit transparent PNGs and sniff for IE... replace with a 8-bit logo with a proper matte for the page?
Sean,

The difficulty is figuring out the correct matte; if we have to maintain separate images with different backgrounds we're losing all the advantages of using PNGs in the first place. Also, some pages have gradients, which require full transparency:

http://www.mozilla.com/en-US/firefox/beta/

There are hacks to getting PNGs working in IE:

http://www.twinhelix.com/css/iepngfix/

But sometimes there can be a small flicker when the page loads and I'm not sure that's acceptable. I personally think it is, especially if those pages with gradients are going away soon.
Not related to this page but FYI, we don't want to use a PNG fix stuff on the homepage. It is very bad performance wise.

For this page, I guess having a PNG24 is ok. It's gonna be ok everywhere and not as beautiful in IE6 so…
Thanks for the feedback on the IE/PNG issue. I've opted to go with full-color alpha-transparent PNGs with no IE6 fallback. There is, however, a bgcolor set int he PNGs that only IE6 will see. This means a bit of a solid block behind the images in IE6 - though it's mitigated a bit by picking a color that is close to the background. The attached screenshot shows the effect.

On the dark-blue-background Beta pages, I've added a custom PNG that's matted against the blue background.

This means no extra JS, and only custom images for the exceptional pages (beta pages).

The footer logo has also been fixed.

Updated in r82582, r82584, and r82585.
Another minor fix in r82588. This should be ready for QA in trunk.
Merged the new header into the firefox4 branch in r83039.
Target Milestone: 1.3 → 1.4
http://www.mmozilla.com/
Status: RESOLVED → VERIFIED
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: