Closed Bug 676020 Opened 13 years ago Closed 13 years ago

[/firefox] Level 1 Navigation Update

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: lmesa, Assigned: sgarrity)

References

Details

(Whiteboard: r96832,96971,97039 b=trunk)

Attachments

(5 files)

Wireframe: Current L1 Navigation
129.08 KB, image/png
Details
Wireframe: Proposed Update (simple fixes)
129.24 KB, image/png
Details
Wireframe: Alternate Proposed Update (a little more aggressive)
81.67 KB, image/png
Details
Proposed Phase 1 Update
128.02 KB, image/png
Details
Final Phase 1 Update
125.34 KB, image/png
Details 
With new products like Apps coming out, I'd like to revisit our strategy for uplifting content in our Mozilla.com navugation header. 

What new products get uplifted to the top line, what doesn't, and where do projects like developer tools fall in the new schema.  I think this is also critical considering the .org and .com merges. 

Beyond Apps, I know we need to address the uplift of "Future Releases". Built In General Dev tools also might need to be uplifted. Anything else I'm missing?
Assignee: nobody → cbrodigan
Thanks Laura! Assigning to Sean, though Tara you might want to weigh in since this is your workflow area.
Assignee: cbrodigan → smartell
Assignee: smartell → nobody
Component: General → www.mozilla.com
Product: Marketing → Websites
QA Contact: general → www-mozilla-com
Updating this to be a mozilla.com bug, since it's more website strategy than design. Also for that reason, reassigning to Chrissie rather than Sean.
Laura Mesa,

If you can add a requirements doc or any information, as well as timelines that accompany the additions requested that would be great.

Thanks,
CB
Assignee: nobody → lmesa
BrowserID in Q4 but I really don't think that we would want a nav bar placement.
nm on comment 4, i was supposed to comment in the etherpad,
Rapid Release: Q3 2011
Developer Tools: Q4 2011 
Apps Beta: Q4 2011 (Not sure if this should be in the header)
Apps:  Q1 2012
Home: Q2 2012

These are major products that are coming in the next few quarters.

The other thing to take into account is that I think our developer resources are buried and it might be good to uplevel those as their own tab.
Assignee: lmesa → cbrodigan
(In reply to Laura Mesa [:lmesa] from comment #6)
> Rapid Release: Q3 2011
> Developer Tools: Q4 2011 
> Apps Beta: Q4 2011 (Not sure if this should be in the header)
> Apps:  Q1 2012
> Home: Q2 2012
> 
> These are major products that are coming in the next few quarters.
> 
> The other thing to take into account is that I think our developer resources
> are buried and it might be good to uplevel those as their own tab.

Agreed Laura! Thank you for this update. I'll talk to Paul Rouget and Rob Hawkes to get their ideas on grouping Dev Tools.

:)CB
OS: Mac OS X → All
Hardware: x86 → All
Hey Laura,

OK, so the full list of items that will need to go into or move around in the nav menu include:

Future Releases (currently under Desktop & Mobile)
Developer Tools (currently Addons locates their's under Developer Hub)
Apps Beta (who will determine if this goes into the main nav?)
Apps (will this be called Apps or App Store or something else?)
Home (should this be located under mobile?)

Am I missing anything? Can you add thoughts on the above, specifically in response to Apps Beta, Apps, and Home - thanks!
(In reply to mcbmoz from comment #8)
> Hey Laura,
> 
> OK, so the full list of items that will need to go into or move around in
> the nav menu include:

This is everything I know of right now. Also, to clarify, I think this is more than just placing things where they best fit in our current mold. I think we need to rethink the mold for the nav bar completely and have some policies in place for future additions and subtractions. 

> 
> Future Releases (currently under Desktop & Mobile)
Correct. 

> Developer Tools (currently Addons locates their's under Developer Hub)
I'm thinking we need a Developer section as a place to house links to the totality of our developer resources across all products.  So, a place for add-ons, developer tools (firefox's built in developer tools--to be renamed but is like Opera Dragonfly), Apps, Jetpack, MDN, Home, Mobile, etc. 

> Apps Beta (who will determine if this goes into the main nav?)
This is a Dan question--he returns the 18th. 


> Apps (will this be called Apps or App Store or something else?)
I don't think we'll have an app store for some time.  For now, I would just go with Apps. Dan can also clarify when he returns. 

> Home (should this be located under mobile?)
I think so--Mayumi or Jacyln, is that correct?

> 
> Am I missing anything? Can you add thoughts on the above, specifically in
> response to Apps Beta, Apps, and Home - thanks!
For Home, there were previous conversations that it should be its standalone product vs being under mobile - not sure if that's still true.
I'd recommend meeting about this rather than trying to hash it all out in a bug (and I'd like to be in on that meeting).

One option would be for Chrissie to put together a first draft proposal and then we can meet review it. Another would be for us to meet in advance, and *then* put together the proposal.

It's also important to remember that we're talking about the Firefox product site here. So, the nav should be oriented around what's going to help end users understand more about Firefox and presumably make them want to download it.
(In reply to John Slater from comment #11)
> I'd recommend meeting about this rather than trying to hash it all out in a
> bug (and I'd like to be in on that meeting).
> 
> One option would be for Chrissie to put together a first draft proposal and
> then we can meet review it. Another would be for us to meet in advance, and
> *then* put together the proposal.

I'm happy with either. 
> 
> It's also important to remember that we're talking about the Firefox product
> site here. So, the nav should be oriented around what's going to help end
> users understand more about Firefox and presumably make them want to
> download it.

True, but I also thought the idea was that the Nav was consistent on all of our pages, not just on the firefox site.  If so, then the goal here isn't just around firefox, its making sure everyone can find what they're looking for when they get to the nav for all our products.
(In reply to Laura Mesa [:lmesa] from comment #12)
> True, but I also thought the idea was that the Nav was consistent on all of
> our pages, not just on the firefox site.  If so, then the goal here isn't
> just around firefox, its making sure everyone can find what they're looking
> for when they get to the nav for all our products.

Nope, the Firefox site will still have it's own unique nav, as will the Thunderbird site, etc. We have some figuring out to do around how it will all be linked together...the universal header tab seems like the best bet, and that's where we need common links across everything.

As this bug is defined, though, it seems like we're talking about the Firefox product site. If you want to talk about Mozilla-wide nav that's another discussion.
(In reply to John Slater from comment #13)
> (In reply to Laura Mesa [:lmesa] from comment #12)
> > True, but I also thought the idea was that the Nav was consistent on all of
> > our pages, not just on the firefox site.  If so, then the goal here isn't
> > just around firefox, its making sure everyone can find what they're looking
> > for when they get to the nav for all our products.
> 
> Nope, the Firefox site will still have it's own unique nav, as will the
> Thunderbird site, etc. We have some figuring out to do around how it will
> all be linked together...the universal header tab seems like the best bet,
> and that's where we need common links across everything.

I'm a bit confused. 
Does this mean that we will have one nav bar for  mobile and firefox and add-ons experiences and a separate one for apps? But apps are Firefox. And home is too, technically.  I guess my question is, how are we defining what gets a unique nav?

If you consider all of the above products to have the same nav bar, then we're on the same page. If not...then maybe we should have this meeting soon ;)


> 
> As this bug is defined, though, it seems like we're talking about the
> Firefox product site. If you want to talk about Mozilla-wide nav that's
> another discussion.
It depends on the website - mobile and desktop are on the same site, so they'll definitely have the same have bar. Apps will have the Apps Store, which is a different site and thus have different nav. 

Also, I'd dispute that apps are Firefox, since the whole point there is that they can work in any browser (so putting their home base in the Firefox product site wouldn't be right).

Agreed that Home is Firefox, although I don't know enough about the future of the product to say that it should be its own top level nav item or fall under the mobile section.

Long story short, we should meet!
Just wanted to clarify-- should I be setting up this meeting?
(In reply to Laura Mesa [:lmesa] from comment #16)
> Just wanted to clarify-- should I be setting up this meeting?

Sounds to me like you're volunteering! (so yes)
Hey Guys

Will wait for the meeting - in the meantime, wanted to supply answers to questions raised:

>> Apps Beta (who will determine if this goes into the main nav?)
> This is a Dan question--he returns the 18th. 

Apps Beta will NOT go in to the main nav. This will happen once we hit 1.0 release (towards the end of Q4). In the meantime, we will need a smaller level of promotion - sitemap and a small banner on the up-to-date page.

>> Apps (will this be called Apps or App Store or something else?)
>I don't think we'll have an app store for some time.  For now, I would just go with Apps. Dan can also clarify when he returns. 

The naming has still not been finalised. However, there is a distinction between the App platform and the App store (whatever they are both then called).

JS> Also, I'd dispute that apps are Firefox, since the whole point there is that they can work in any browser (so putting their home base in the Firefox product site wouldn't be right).

This is 100% correct. The apps offering will be browser and OS neutral - although users will have in-built access to the app-store from Firefox at some point.
See Also: → 680271
Target Milestone: --- → Future
Summary: New Mozilla.com Navigation Bar Strategy → [/firefox] Level 1 Navigation Update
This represents navigation on mozilla.org/firefox as it is today.

Notice:
Desktop uses "Customization" v. Mobile uses "Customize"
Desktop does not have "Download"

and, lots more.

Interaction notes and observations included on right-side of graffle.
This represents a simple update to current L1 navigation. No new content (until the releases are added).

Interaction notes and observations included on right-side of graffle.

Note: the full experience is still represented in the universal footer - we can keep it simple and focus on conversion and the funnel at the top of the page, and rely on user conventions to look to the footer as an index of the site.
This represents a more aggressive update to the navigation.

Interaction notes and observations included on right-side of graffle.

Note: the full experience is still represented in the universal footer - we can keep it simple and focus on conversion and the funnel at the top of the page, and rely on user conventions to look to the footer as an index of the site.

One new page added, FAQ for desktop to mirror FAQ for mobile - scannable single page of value statements.
Assigning to John.

John, can you review the wireframes I've attached in comment 19, comment 20, and comment 21.

I ran through webtrends to make sure that simplifying the nav wouldn't upset traffic patterns. These represent two easily implemented simplifications.

Goal: Increase visibility of rapid release, simplify user experience, increase conversion and content discoverability.

Apps are not in here yet, but can be easily added in the future.
Assignee: cbrodigan → jslater
Thanks Chrissie--

Looking at the main mockups, I'm generally ok with the phases but have a few questions/comments. 

1) Why do we need to wait until phase 3 to add FAQs?
2) I'm fine with removing participate from About. 
3) I really don't like the name "Releases" for the dev channels. We should come up with a better category name because as its currently named I expect to see desktop in that pull down. Not sure what the right name is--this is why we like the name channels--mainly because releases is too broad, although channels on its own is also confusing. Can we ask matej?  Also, Nightly should not initially be included in this pull down either. Lastly, can you explain why we would put releases as the first tab on the left as opposed to at the end, for example? It doesn't quite feel right where it is. 
4) In your email you say this:
I would like to implement a very early and experimental phase of the universal header (Bug 629699)  when we launch Apps that would include the following:

    Mozilla Foundation
    Mozilla Labs
    Mozilla Products
        Firefox
        Firefox for Mobile
        Apps Marketplace
        Add-ons Marketplace
        Thunderbird
    Mozilla Developer Network
        Desktop
        Mobile
        Add-ons
        Demos"

Should I think of this as phase 4 or as purely experimental? In the meantime, where do links to MDN live? Lack of MDN links in our current nav is sorely missing and something (along with the release channels) that really needs to be addressed regardless of the results of the experimental nav.
(In reply to Laura Mesa [:lmesa] from comment #23)
> Thanks Chrissie--
> 
> Looking at the main mockups, I'm generally ok with the phases but have a few
> questions/comments. 
> 
> 1) Why do we need to wait until phase 3 to add FAQs?

I'd like to add FAQ alongside how we trim /features, so that they compliment one another really well. Also, asking users what they would like in an FAQ - the most common questions from input and sumo.

> 2) I'm fine with removing participate from About. 

+1

> 3) I really don't like the name "Releases" for the dev channels. We should
> come up with a better category name because as its currently named I expect
> to see desktop in that pull down. Not sure what the right name is--this is
> why we like the name channels--mainly because releases is too broad,
> although channels on its own is also confusing. Can we ask matej?  

Defn ask Matej. My reasoning: I did a deep dive into keyword research and users are searching for releases, downloads, and versions for Firefox, Safari, Chrome, Opera, and Rockmelt. We have a tremendous amount of value created alongside "releases" because we have release notes, so based on competitive research, user habit, and existing SEO juice built up over 5+ years, I think releases is a fantastic option for us.

Also,
> Nightly should not initially be included in this pull down either. Lastly,
> can you explain why we would put releases as the first tab on the left as
> opposed to at the end, for example? It doesn't quite feel right where it is.

It should be paired with Desktop and Mobile, because it's part of that suite of products, so either in the first or third place.
 
> 4) In your email you say this:
> I would like to implement a very early and experimental phase of the
> universal header (Bug 629699)  when we launch Apps that would include the
> following:
> 
>     Mozilla Foundation
>     Mozilla Labs
>     Mozilla Products
>         Firefox
>         Firefox for Mobile
>         Apps Marketplace
>         Add-ons Marketplace
>         Thunderbird
>     Mozilla Developer Network
>         Desktop
>         Mobile
>         Add-ons
>         Demos"
> 
> Should I think of this as phase 4 or as purely experimental? In the
> meantime, where do links to MDN live? Lack of MDN links in our current nav
> is sorely missing and something (along with the release channels) that
> really needs to be addressed regardless of the results of the experimental
> nav.

Think of that as experimental. But, note that all MDN, etc. are repeated in the footer for now. We do the users a diservice by overloading the main nav and then repeating ourselves in the footer. The footer is the index, but the nav is the main table of contents - if the site were more like a book of information.
(In reply to mcbmoz from comment #24)
> (In reply to Laura Mesa [:lmesa] from comment #23)
> > Thanks Chrissie--
> > 
> > Looking at the main mockups, I'm generally ok with the phases but have a few
> > questions/comments. 
> > 
> > 1) Why do we need to wait until phase 3 to add FAQs?
> 
> I'd like to add FAQ alongside how we trim /features, so that they compliment
> one another really well. Also, asking users what they would like in an FAQ -
> the most common questions from input and sumo.

FAQs are product FAQs owned by PR, which is separate from SUMO.  I don't know if they should be combined, but as for now they are not. Until then, we should keep the FAQs we have now and whatever we do should be parallel for mobile. 
> 

> 
> > 3) I really don't like the name "Releases" for the dev channels. We should
> > come up with a better category name because as its currently named I expect
> > to see desktop in that pull down. Not sure what the right name is--this is
> > why we like the name channels--mainly because releases is too broad,
> > although channels on its own is also confusing. Can we ask matej?  
> 
> Defn ask Matej. My reasoning: I did a deep dive into keyword research and
> users are searching for releases, downloads, and versions for Firefox,
> Safari, Chrome, Opera, and Rockmelt. We have a tremendous amount of value
> created alongside "releases" because we have release notes, so based on
> competitive research, user habit, and existing SEO juice built up over 5+
> years, I think releases is a fantastic option for us.

Ah, I see. Releases still doesn't feel like the right word. I understand the logic and appreciate the research, but what about Future? I think that's a better descriptive term of what is held within the pulldown. I know we want to take advantage of SEO, but not to the point where we confuse users.   

> 
> Also,
> > Nightly should not initially be included in this pull down either. Lastly,
> > can you explain why we would put releases as the first tab on the left as
> > opposed to at the end, for example? It doesn't quite feel right where it is.
> 
> It should be paired with Desktop and Mobile, because it's part of that suite
> of products, so either in the first or third place.
Please remove nightly from the listing. It may be added later, but for now, it should not be added for desktop or mobile. 

>  
> > 4) In your email you say this:
> > I would like to implement a very early and experimental phase of the
> > universal header (Bug 629699)  when we launch Apps that would include the
> > following:
> > 
> >     Mozilla Foundation
> >     Mozilla Labs
> >     Mozilla Products
> >         Firefox
> >         Firefox for Mobile
> >         Apps Marketplace
> >         Add-ons Marketplace
> >         Thunderbird
> >     Mozilla Developer Network
> >         Desktop
> >         Mobile
> >         Add-ons
> >         Demos"
> > 
> > Should I think of this as phase 4 or as purely experimental? In the
> > meantime, where do links to MDN live? Lack of MDN links in our current nav
> > is sorely missing and something (along with the release channels) that
> > really needs to be addressed regardless of the results of the experimental
> > nav.
> 
> Think of that as experimental. But, note that all MDN, etc. are repeated in
> the footer for now. We do the users a diservice by overloading the main nav
> and then repeating ourselves in the footer. The footer is the index, but the
> nav is the main table of contents - if the site were more like a book of
> information.

Ok, that's okay with me. In the experimental nav, what would be in the footer as a complement to the Nav?
(In reply to Laura Mesa [:lmesa] from comment #25)
> (In reply to mcbmoz from comment #24)
> > (In reply to Laura Mesa [:lmesa] from comment #23)
> > > Thanks Chrissie--
> > > 
> > > Looking at the main mockups, I'm generally ok with the phases but have a few
> > > questions/comments. 
> > > 
> > > 1) Why do we need to wait until phase 3 to add FAQs?
> > 
> > I'd like to add FAQ alongside how we trim /features, so that they compliment
> > one another really well. Also, asking users what they would like in an FAQ -
> > the most common questions from input and sumo.
> 
> FAQs are product FAQs owned by PR, which is separate from SUMO.  I don't
> know if they should be combined, but as for now they are not. Until then, we
> should keep the FAQs we have now and whatever we do should be parallel for
> mobile. 
> > 

Currently, there are no FAQs for Desktop. I recommend against adding any until we can do some user research, talk to SUMO team about what the most frequent questions are, and then work with Matej to create an FAQ that can render on mobile devices as well as on desktop (less copy, more bullet points, simple scanning).

> 
> > 
> > > 3) I really don't like the name "Releases" for the dev channels. We should
> > > come up with a better category name because as its currently named I expect
> > > to see desktop in that pull down. Not sure what the right name is--this is
> > > why we like the name channels--mainly because releases is too broad,
> > > although channels on its own is also confusing. Can we ask matej?  
> > 
> > Defn ask Matej. My reasoning: I did a deep dive into keyword research and
> > users are searching for releases, downloads, and versions for Firefox,
> > Safari, Chrome, Opera, and Rockmelt. We have a tremendous amount of value
> > created alongside "releases" because we have release notes, so based on
> > competitive research, user habit, and existing SEO juice built up over 5+
> > years, I think releases is a fantastic option for us.
> 
> Ah, I see. Releases still doesn't feel like the right word. I understand the
> logic and appreciate the research, but what about Future? I think that's a
> better descriptive term of what is held within the pulldown. I know we want
> to take advantage of SEO, but not to the point where we confuse users.   
> 

Totally appreciate this. Without an SEM budget, we're at a huge disadvantage, but using Releases we would not only be doing what the user expects us to do and what we've trained users to look for, we would have a greater liklihood of appearing just below competitor paid results in search. Releases also translates well across the board - while Future is somewhat vague in this context (I checked with l10n).

This is something that can be easily A/B tested.

Future also suggests, not available yet to users, and users are looking for what they can download right now. It's a little like how Toyota and other car companies post "Coming next year" etc. We have a great product that can be downloaded now. Let's make that ridiculously clear.

Lastly, the word future can be added to the copy inside the pages, like the headlines


> > 
> > Also,
> > > Nightly should not initially be included in this pull down either. Lastly,
> > > can you explain why we would put releases as the first tab on the left as
> > > opposed to at the end, for example? It doesn't quite feel right where it is.
> > 
> > It should be paired with Desktop and Mobile, because it's part of that suite
> > of products, so either in the first or third place.
> Please remove nightly from the listing. It may be added later, but for now,
> it should not be added for desktop or mobile. 
> 
> >  
> > > 4) In your email you say this:
> > > I would like to implement a very early and experimental phase of the
> > > universal header (Bug 629699)  when we launch Apps that would include the
> > > following:
> > > 
> > >     Mozilla Foundation
> > >     Mozilla Labs
> > >     Mozilla Products
> > >         Firefox
> > >         Firefox for Mobile
> > >         Apps Marketplace
> > >         Add-ons Marketplace
> > >         Thunderbird
> > >     Mozilla Developer Network
> > >         Desktop
> > >         Mobile
> > >         Add-ons
> > >         Demos"
> > > 
> > > Should I think of this as phase 4 or as purely experimental? In the
> > > meantime, where do links to MDN live? Lack of MDN links in our current nav
> > > is sorely missing and something (along with the release channels) that
> > > really needs to be addressed regardless of the results of the experimental
> > > nav.
> > 
> > Think of that as experimental. But, note that all MDN, etc. are repeated in
> > the footer for now. We do the users a diservice by overloading the main nav
> > and then repeating ourselves in the footer. The footer is the index, but the
> > nav is the main table of contents - if the site were more like a book of
> > information.
> 
> Ok, that's okay with me. In the experimental nav, what would be in the
> footer as a complement to the Nav?

The universal tab is meant to connect our major sites - currently, the Firefox site is doing a lot of heavy lifting advertising things like SUMO for Thunderbird.

The universal tab helps us keep Firefox specific to the user audience and not mix in so many products. Take a look here: https://wiki.mozilla.org/Websites/Taskforce/Proposals/Universal_tab
(In reply to mcbmoz from comment #26)
> (In reply to Laura Mesa [:lmesa] from comment #25)
> > (In reply to mcbmoz from comment #24)
> > > (In reply to Laura Mesa [:lmesa] from comment #23)
> > > > Thanks Chrissie--
> > > > 
> > > > Looking at the main mockups, I'm generally ok with the phases but have a few
> > > > questions/comments. 
> > > > 
> > > > 1) Why do we need to wait until phase 3 to add FAQs?
> > > 
> > > I'd like to add FAQ alongside how we trim /features, so that they compliment
> > > one another really well. Also, asking users what they would like in an FAQ -
> > > the most common questions from input and sumo.
> > 
> > FAQs are product FAQs owned by PR, which is separate from SUMO.  I don't
> > know if they should be combined, but as for now they are not. Until then, we
> > should keep the FAQs we have now and whatever we do should be parallel for
> > mobile. 
> > > 
> 
> Currently, there are no FAQs for Desktop. I recommend against adding any
> until we can do some user research, talk to SUMO team about what the most
> frequent questions are, and then work with Matej to create an FAQ that can
> render on mobile devices as well as on desktop (less copy, more bullet
> points, simple scanning).

These are the desktop FAQs: http://www.mozilla.org/en-US/press/faq/fx/
> 
> > 
> > > 
> > > > 3) I really don't like the name "Releases" for the dev channels. We should
> > > > come up with a better category name because as its currently named I expect
> > > > to see desktop in that pull down. Not sure what the right name is--this is
> > > > why we like the name channels--mainly because releases is too broad,
> > > > although channels on its own is also confusing. Can we ask matej?  
> > > 
> > > Defn ask Matej. My reasoning: I did a deep dive into keyword research and
> > > users are searching for releases, downloads, and versions for Firefox,
> > > Safari, Chrome, Opera, and Rockmelt. We have a tremendous amount of value
> > > created alongside "releases" because we have release notes, so based on
> > > competitive research, user habit, and existing SEO juice built up over 5+
> > > years, I think releases is a fantastic option for us.
> > 
> > Ah, I see. Releases still doesn't feel like the right word. I understand the
> > logic and appreciate the research, but what about Future? I think that's a
> > better descriptive term of what is held within the pulldown. I know we want
> > to take advantage of SEO, but not to the point where we confuse users.   
> > 
> 
> Totally appreciate this. Without an SEM budget, we're at a huge
> disadvantage, but using Releases we would not only be doing what the user
> expects us to do and what we've trained users to look for, we would have a
> greater liklihood of appearing just below competitor paid results in search.
> Releases also translates well across the board - while Future is somewhat
> vague in this context (I checked with l10n).
> 
> This is something that can be easily A/B tested.

I would like to do this. I will also talk to Matej about different naming options. 

Maybe whats bothering me is that releases come before desktop in the order. I think it might be less weird if we moved it to the end, or something like that. 
> 
> Future also suggests, not available yet to users, and users are looking for
> what they can download right now. It's a little like how Toyota and other
> car companies post "Coming next year" etc. We have a great product that can
> be downloaded now. Let's make that ridiculously clear.
> 
> Lastly, the word future can be added to the copy inside the pages, like the
> headlines

True.
> 
> 
> > > 
> > > Also,
> > > > Nightly should not initially be included in this pull down either. Lastly,
> > > > can you explain why we would put releases as the first tab on the left as
> > > > opposed to at the end, for example? It doesn't quite feel right where it is.
> > > 
> > > It should be paired with Desktop and Mobile, because it's part of that suite
> > > of products, so either in the first or third place.
> > Please remove nightly from the listing. It may be added later, but for now,
> > it should not be added for desktop or mobile. 
> > 
> > >  
> > > > 4) In your email you say this:
> > > > I would like to implement a very early and experimental phase of the
> > > > universal header (Bug 629699)  when we launch Apps that would include the
> > > > following:
> > > > 
> > > >     Mozilla Foundation
> > > >     Mozilla Labs
> > > >     Mozilla Products
> > > >         Firefox
> > > >         Firefox for Mobile
> > > >         Apps Marketplace
> > > >         Add-ons Marketplace
> > > >         Thunderbird
> > > >     Mozilla Developer Network
> > > >         Desktop
> > > >         Mobile
> > > >         Add-ons
> > > >         Demos"
> > > > 
> > > > Should I think of this as phase 4 or as purely experimental? In the
> > > > meantime, where do links to MDN live? Lack of MDN links in our current nav
> > > > is sorely missing and something (along with the release channels) that
> > > > really needs to be addressed regardless of the results of the experimental
> > > > nav.
> > > 
> > > Think of that as experimental. But, note that all MDN, etc. are repeated in
> > > the footer for now. We do the users a diservice by overloading the main nav
> > > and then repeating ourselves in the footer. The footer is the index, but the
> > > nav is the main table of contents - if the site were more like a book of
> > > information.
> > 
> > Ok, that's okay with me. In the experimental nav, what would be in the
> > footer as a complement to the Nav?
> 
> The universal tab is meant to connect our major sites - currently, the
> Firefox site is doing a lot of heavy lifting advertising things like SUMO
> for Thunderbird.
> 
> The universal tab helps us keep Firefox specific to the user audience and
> not mix in so many products. Take a look here:
> https://wiki.mozilla.org/Websites/Taskforce/Proposals/Universal_tab

Sorry, maybe my question wasn't clear.  Earlier you mentioned that the footer holds things in a site that a nav bar does not--what will the footer hold when we implement the experimental header?
(In reply to Laura Mesa [:lmesa] from comment #27)
> (In reply to mcbmoz from comment #26)
> > (In reply to Laura Mesa [:lmesa] from comment #25)
> > > (In reply to mcbmoz from comment #24)
> > > > (In reply to Laura Mesa [:lmesa] from comment #23)
> > > > > Thanks Chrissie--
> > > > > 
> > > > > Looking at the main mockups, I'm generally ok with the phases but have a few
> > > > > questions/comments. 
> > > > > 
> > > > > 1) Why do we need to wait until phase 3 to add FAQs?
> > > > 
> > > > I'd like to add FAQ alongside how we trim /features, so that they compliment
> > > > one another really well. Also, asking users what they would like in an FAQ -
> > > > the most common questions from input and sumo.
> > > 
> > > FAQs are product FAQs owned by PR, which is separate from SUMO.  I don't
> > > know if they should be combined, but as for now they are not. Until then, we
> > > should keep the FAQs we have now and whatever we do should be parallel for
> > > mobile. 
> > > > 
> > 
> > Currently, there are no FAQs for Desktop. I recommend against adding any
> > until we can do some user research, talk to SUMO team about what the most
> > frequent questions are, and then work with Matej to create an FAQ that can
> > render on mobile devices as well as on desktop (less copy, more bullet
> > points, simple scanning).
> 
> These are the desktop FAQs: http://www.mozilla.org/en-US/press/faq/fx/

Laura, currently these FAQs are not linked to from the Desktop section and because they are in press, I think we should hold off for now. Let's streamline the FX content and then create a new FAQ that is very specific to research coming out of SUMO and input to best meet the users' needs.

Since we've been cruising along with them, this shouldn't be a blocker to updating the main nav. It will be to our benefit to do a deeper dive.

> > 
> > > 
> > > > 
> > > > > 3) I really don't like the name "Releases" for the dev channels. We should
> > > > > come up with a better category name because as its currently named I expect
> > > > > to see desktop in that pull down. Not sure what the right name is--this is
> > > > > why we like the name channels--mainly because releases is too broad,
> > > > > although channels on its own is also confusing. Can we ask matej?  
> > > > 
> > > > Defn ask Matej. My reasoning: I did a deep dive into keyword research and
> > > > users are searching for releases, downloads, and versions for Firefox,
> > > > Safari, Chrome, Opera, and Rockmelt. We have a tremendous amount of value
> > > > created alongside "releases" because we have release notes, so based on
> > > > competitive research, user habit, and existing SEO juice built up over 5+
> > > > years, I think releases is a fantastic option for us.
> > > 
> > > Ah, I see. Releases still doesn't feel like the right word. I understand the
> > > logic and appreciate the research, but what about Future? I think that's a
> > > better descriptive term of what is held within the pulldown. I know we want
> > > to take advantage of SEO, but not to the point where we confuse users.   
> > > 
> > 
> > Totally appreciate this. Without an SEM budget, we're at a huge
> > disadvantage, but using Releases we would not only be doing what the user
> > expects us to do and what we've trained users to look for, we would have a
> > greater liklihood of appearing just below competitor paid results in search.
> > Releases also translates well across the board - while Future is somewhat
> > vague in this context (I checked with l10n).
> > 
> > This is something that can be easily A/B tested.
> 
> I would like to do this. I will also talk to Matej about different naming
> options. 

Sounds good. I've cc'd Patrick - it would be awesome to get his input on naming Future/Future Releases/Releases as well - going from research intense foundation.

> 
> Maybe whats bothering me is that releases come before desktop in the order.
> I think it might be less weird if we moved it to the end, or something like
> that. 

I think the third place then, so they aren't too far away from the FX product suite.


> > 
> > Future also suggests, not available yet to users, and users are looking for
> > what they can download right now. It's a little like how Toyota and other
> > car companies post "Coming next year" etc. We have a great product that can
> > be downloaded now. Let's make that ridiculously clear.
> > 
> > Lastly, the word future can be added to the copy inside the pages, like the
> > headlines
> 
> True.
> > 
> > 
> > > > 
> > > > Also,
> > > > > Nightly should not initially be included in this pull down either. Lastly,
> > > > > can you explain why we would put releases as the first tab on the left as
> > > > > opposed to at the end, for example? It doesn't quite feel right where it is.
> > > > 

OK

> > > > It should be paired with Desktop and Mobile, because it's part of that suite
> > > > of products, so either in the first or third place.
> > > Please remove nightly from the listing. It may be added later, but for now,
> > > it should not be added for desktop or mobile. 
> > > 
> > > >  
> > > > > 4) In your email you say this:
> > > > > I would like to implement a very early and experimental phase of the
> > > > > universal header (Bug 629699)  when we launch Apps that would include the
> > > > > following:
> > > > > 
> > > > >     Mozilla Foundation
> > > > >     Mozilla Labs
> > > > >     Mozilla Products
> > > > >         Firefox
> > > > >         Firefox for Mobile
> > > > >         Apps Marketplace
> > > > >         Add-ons Marketplace
> > > > >         Thunderbird
> > > > >     Mozilla Developer Network
> > > > >         Desktop
> > > > >         Mobile
> > > > >         Add-ons
> > > > >         Demos"
> > > > > 
> > > > > Should I think of this as phase 4 or as purely experimental? In the
> > > > > meantime, where do links to MDN live? Lack of MDN links in our current nav
> > > > > is sorely missing and something (along with the release channels) that
> > > > > really needs to be addressed regardless of the results of the experimental
> > > > > nav.
> > > > 
> > > > Think of that as experimental. But, note that all MDN, etc. are repeated in
> > > > the footer for now. We do the users a diservice by overloading the main nav
> > > > and then repeating ourselves in the footer. The footer is the index, but the
> > > > nav is the main table of contents - if the site were more like a book of
> > > > information.
> > > 
> > > Ok, that's okay with me. In the experimental nav, what would be in the
> > > footer as a complement to the Nav?
> > 
> > The universal tab is meant to connect our major sites - currently, the
> > Firefox site is doing a lot of heavy lifting advertising things like SUMO
> > for Thunderbird.
> > 
> > The universal tab helps us keep Firefox specific to the user audience and
> > not mix in so many products. Take a look here:
> > https://wiki.mozilla.org/Websites/Taskforce/Proposals/Universal_tab
> 
> Sorry, maybe my question wasn't clear.  Earlier you mentioned that the
> footer holds things in a site that a nav bar does not--what will the footer
> hold when we implement the experimental header?

The universal footer will stay 'as is' for now. In the future we'll likely do an update to streamline. Right now, I'd like to focus on cleaning up the FX product site nav, so we can have room to add new things into it. The Tab is really just an experiment and won't duplicate or remove content from the footer.

Cool yo?!
(In reply to mcbmoz from comment #28)
> (In reply to Laura Mesa [:lmesa] from comment #27)
> > (In reply to mcbmoz from comment #26)
> > > (In reply to Laura Mesa [:lmesa] from comment #25)
> > > > (In reply to mcbmoz from comment #24)
> > > > > (In reply to Laura Mesa [:lmesa] from comment #23)
> > > > > > Thanks Chrissie--
> > > > > > 
> > > > > > Looking at the main mockups, I'm generally ok with the phases but have a few
> > > > > > questions/comments. 
> > > > > > 
> > > > > > 1) Why do we need to wait until phase 3 to add FAQs?
> > > > > 
> > > > > I'd like to add FAQ alongside how we trim /features, so that they compliment
> > > > > one another really well. Also, asking users what they would like in an FAQ -
> > > > > the most common questions from input and sumo.
> > > > 
> > > > FAQs are product FAQs owned by PR, which is separate from SUMO.  I don't
> > > > know if they should be combined, but as for now they are not. Until then, we
> > > > should keep the FAQs we have now and whatever we do should be parallel for
> > > > mobile. 
> > > > > 
> > > 
> > > Currently, there are no FAQs for Desktop. I recommend against adding any
> > > until we can do some user research, talk to SUMO team about what the most
> > > frequent questions are, and then work with Matej to create an FAQ that can
> > > render on mobile devices as well as on desktop (less copy, more bullet
> > > points, simple scanning).
> > 
> > These are the desktop FAQs: http://www.mozilla.org/en-US/press/faq/fx/
> 
> Laura, currently these FAQs are not linked to from the Desktop section and
> because they are in press, I think we should hold off for now. Let's
> streamline the FX content and then create a new FAQ that is very specific to
> research coming out of SUMO and input to best meet the users' needs.
> 
> Since we've been cruising along with them, this shouldn't be a blocker to
> updating the main nav. It will be to our benefit to do a deeper dive.

Ok. 
> 
> > > 
> > > > 
> > > > > 
> > > > > > 3) I really don't like the name "Releases" for the dev channels. We should
> > > > > > come up with a better category name because as its currently named I expect
> > > > > > to see desktop in that pull down. Not sure what the right name is--this is
> > > > > > why we like the name channels--mainly because releases is too broad,
> > > > > > although channels on its own is also confusing. Can we ask matej?  
> > > > > 
> > > > > Defn ask Matej. My reasoning: I did a deep dive into keyword research and
> > > > > users are searching for releases, downloads, and versions for Firefox,
> > > > > Safari, Chrome, Opera, and Rockmelt. We have a tremendous amount of value
> > > > > created alongside "releases" because we have release notes, so based on
> > > > > competitive research, user habit, and existing SEO juice built up over 5+
> > > > > years, I think releases is a fantastic option for us.
> > > > 
> > > > Ah, I see. Releases still doesn't feel like the right word. I understand the
> > > > logic and appreciate the research, but what about Future? I think that's a
> > > > better descriptive term of what is held within the pulldown. I know we want
> > > > to take advantage of SEO, but not to the point where we confuse users.   
> > > > 
> > > 
> > > Totally appreciate this. Without an SEM budget, we're at a huge
> > > disadvantage, but using Releases we would not only be doing what the user
> > > expects us to do and what we've trained users to look for, we would have a
> > > greater liklihood of appearing just below competitor paid results in search.
> > > Releases also translates well across the board - while Future is somewhat
> > > vague in this context (I checked with l10n).
> > > 
> > > This is something that can be easily A/B tested.
> > 
> > I would like to do this. I will also talk to Matej about different naming
> > options. 
> 
> Sounds good. I've cc'd Patrick - it would be awesome to get his input on
> naming Future/Future Releases/Releases as well - going from research intense
> foundation.
> 
> > 
> > Maybe whats bothering me is that releases come before desktop in the order.
> > I think it might be less weird if we moved it to the end, or something like
> > that. 
> 
> I think the third place then, so they aren't too far away from the FX
> product suite.

Ok. 
> 
> 
> > > 
> > > Future also suggests, not available yet to users, and users are looking for
> > > what they can download right now. It's a little like how Toyota and other
> > > car companies post "Coming next year" etc. We have a great product that can
> > > be downloaded now. Let's make that ridiculously clear.
> > > 
> > > Lastly, the word future can be added to the copy inside the pages, like the
> > > headlines
> > 
> > True.
> > > 
> > > 
> > > > > 
> > > > > Also,
> > > > > > Nightly should not initially be included in this pull down either. Lastly,
> > > > > > can you explain why we would put releases as the first tab on the left as
> > > > > > opposed to at the end, for example? It doesn't quite feel right where it is.
> > > > > 
> 
> OK
> 
> > > > > It should be paired with Desktop and Mobile, because it's part of that suite
> > > > > of products, so either in the first or third place.
> > > > Please remove nightly from the listing. It may be added later, but for now,
> > > > it should not be added for desktop or mobile. 
> > > > 
> > > > >  
> > > > > > 4) In your email you say this:
> > > > > > I would like to implement a very early and experimental phase of the
> > > > > > universal header (Bug 629699)  when we launch Apps that would include the
> > > > > > following:
> > > > > > 
> > > > > >     Mozilla Foundation
> > > > > >     Mozilla Labs
> > > > > >     Mozilla Products
> > > > > >         Firefox
> > > > > >         Firefox for Mobile
> > > > > >         Apps Marketplace
> > > > > >         Add-ons Marketplace
> > > > > >         Thunderbird
> > > > > >     Mozilla Developer Network
> > > > > >         Desktop
> > > > > >         Mobile
> > > > > >         Add-ons
> > > > > >         Demos"
> > > > > > 
> > > > > > Should I think of this as phase 4 or as purely experimental? In the
> > > > > > meantime, where do links to MDN live? Lack of MDN links in our current nav
> > > > > > is sorely missing and something (along with the release channels) that
> > > > > > really needs to be addressed regardless of the results of the experimental
> > > > > > nav.
> > > > > 
> > > > > Think of that as experimental. But, note that all MDN, etc. are repeated in
> > > > > the footer for now. We do the users a diservice by overloading the main nav
> > > > > and then repeating ourselves in the footer. The footer is the index, but the
> > > > > nav is the main table of contents - if the site were more like a book of
> > > > > information.
> > > > 
> > > > Ok, that's okay with me. In the experimental nav, what would be in the
> > > > footer as a complement to the Nav?
> > > 
> > > The universal tab is meant to connect our major sites - currently, the
> > > Firefox site is doing a lot of heavy lifting advertising things like SUMO
> > > for Thunderbird.
> > > 
> > > The universal tab helps us keep Firefox specific to the user audience and
> > > not mix in so many products. Take a look here:
> > > https://wiki.mozilla.org/Websites/Taskforce/Proposals/Universal_tab
> > 
> > Sorry, maybe my question wasn't clear.  Earlier you mentioned that the
> > footer holds things in a site that a nav bar does not--what will the footer
> > hold when we implement the experimental header?
> 
> The universal footer will stay 'as is' for now. In the future we'll likely
> do an update to streamline. Right now, I'd like to focus on cleaning up the
> FX product site nav, so we can have room to add new things into it. The Tab
> is really just an experiment and won't duplicate or remove content from the
> footer.

Ok, thanks for clarifying. 
> 
> Cool yo?!
Wow, lots of great thoughts and discussion here. We should plan on meeting about this in person when Chrissie is back next week, b/c I don't think we're going to resolve every last nuance thru Bugzilla (or if we do, it'll take a long time), but here's my quick take:

Phase 2 (comment #20):
- I'm not sure if 'releases' is the right word here. I like Future, but do see your point about why it's not ideal (sounds like something that's coming later vs what's available right now). I also agree with Laura that it would make more sense to put it after desktop and mobile in the order. 
- pulldowns under the desktop and mobile sections generally look good, but those should be determined by PMM priorities. Personally, I think we could cut them down even more.
- add-ons section looks good, but we should confirm with Fligtar and Dan. Also, maybe keep Personas as a separate category?
- in support, why not have sections for desktop and mobile support (and possibly beta and aurora as well) and drop Thunderbird altogether? That doesn't really fit on a Firefox site.
- we should talk to Mary about dropping Participate. Eventually we can potentially move this content over to mozilla.org, but for now I'm pretty sure this is a big driver of community participation.
- we need to figure out a way to add the brand toolkit here as well (I'm open to ideas...not set on any one solution).

Phase 3 (comment #21):
- basically the same comments as above, but at this point we should be looking to integrate as much of the About content as possible into mozilla.org. By this point we should be using the mozilla.org About section as the main place to tell our story, and we could be using this section to be more literally about Firefox (since this is the Firefox site, after all). Of course that page could still include a lot of links like participate, etc but those could mainly point people to .org rather than exist as distinct pages in the pulldown.

Next steps:
- Chrissie, please set up a time for us to discuss in person
- also, please follow up directly with Tenser on the SUMO stuff and Fligtar/Dan H on the AMO stuff...you can reference this bug of course, but it will save them a lot of extra email if you ping them directly and post the results here rather than copying them on this.

Thanks!
Attached image Proposed Phase 1 Update — 
Laura & John,

Here is the revision to our Phase 1 approach, based on our conversation yesterday:

*Releases is moved to the #3 position (how does this flow for you both now?)
*Download is removed from Desktop & Mobile menus, since the buttons are on all the sub-pages
*Brand Toolkit is added to About
*Personas added to Add-ons

Outstanding, is Sync - Laura let us know when you touch base.

Are you both cool with me proceeding with pinging Justin and David for feedback, so we can slide into 4.1 or 4.2 release?

Thanks!
I think Firefox Home should have it's own link under the "Mobile" tab. Since the Features and Customize aspects don't apply to Home, it makes it seem like there's a Firefox for iOS.
(In reply to Jaclyn Fu from comment #32)
> I think Firefox Home should have it's own link under the "Mobile" tab. Since
> the Features and Customize aspects don't apply to Home, it makes it seem
> like there's a Firefox for iOS.

Jaclyn, do we know the future of Firefox Home? I've previously recommended breaking it off, so that it can have it's own page. But, before adding anything into the menu I think we need to understand the future of that product. Would be awesome to hear more.
All we know now is what we've seen from the Pancake demos, but we know it's an entirely different experience than with Firefox for Android.  It's not a Web browser, and will have an app-like experience to help users discover content and access their desktop Firefox data. I'm just worried that users will be disappointed when they find out our iOS product isn't a full browser
(In reply to Jaclyn Fu from comment #34)
> All we know now is what we've seen from the Pancake demos, but we know it's
> an entirely different experience than with Firefox for Android.  It's not a
> Web browser, and will have an app-like experience to help users discover
> content and access their desktop Firefox data. I'm just worried that users
> will be disappointed when they find out our iOS product isn't a full browser

OK, I think that iPhone Home is a little out of scope for this refresh to L1 navigation. We will have a Phase 2 in the coming weeks and we can revisit when there's more clarity. In the meantime, I've recommended inside of the wireframes on bug 667554 splitting iPhone Home out of the landing page experience, so it does have it's own page. This may solve what you're looking for - neither Android nor iOS will be listed in the nav, but will be implied on the landing page for the user to select an experience from (two pages are also better for SEO for the different products).

Jaclyn, Laura M is going to ping you about Sync. Looking forward to hearing back on that conversation for this Phase 1. Thanks!
Hi Chrissie--

Spoke with Jaclyn about Home and Sync. 

1) Home:  Totally fine leaving it out of the navigation for mobile. We want to keep the page for now in case people search for it (since we still offer it in the app store, etc) but no need to include in the navigation. 

2)Sync: Totally ok removing from navigation as long as:
A) we change the copy under the sync feature on the current features page to say something like "click here to learn more about installing sync".
B) When we re-do the mobile feature page we do a better job of explaining installation so we can kill the current sync page and just have it on the one.

Otherwise, I think the planned streamline in comment 31 looks great. 

Thanks!
This all looks really good to me (with the PMM edits noted above). Thanks Chrissie!
David & Justin,

Can you review comment 31 and let us know if you are ok with the changes we're making to:

Add-ons dropdown (streamlining to send users to the AMO home pages for Mobile & Desktop)

SUMO dropdown (eliminating Thunderbird support)
Depends on: 694420
I'm OK with the Add-ons changes. I'm OK with Personas being there because getpersonas.com is still the primary site, but hopefully after Q4 we'll retire it and it will be on AMO, and should probably be removed from the top menu.

And a note about Apps -- by the time Apps is ready for larger promotion, Add-ons and Apps should be combined into a single marketplace, so it can just use the same Add-ons space in the header.
(In reply to Justin Scott [:fligtar] from comment #39)
> I'm OK with the Add-ons changes. I'm OK with Personas being there because
> getpersonas.com is still the primary site, but hopefully after Q4 we'll
> retire it and it will be on AMO, and should probably be removed from the top
> menu.

Makes sense, thank you.
> 
> And a note about Apps -- by the time Apps is ready for larger promotion,
> Add-ons and Apps should be combined into a single marketplace, so it can
> just use the same Add-ons space in the header.

Makes sense, good to know!

David, assigning to you for feedback on comment 38.
Assignee: jslater → djst
(In reply to mcbmoz from comment #38)
> David & Justin,
> 
> Can you review comment 31 and let us know if you are ok with the changes
> we're making to:
> 
> SUMO dropdown (eliminating Thunderbird support)

Looks good to me. Back to Herr Slater.
Assignee: djst → jslater
(In reply to David Tenser [:djst] from comment #41)
> (In reply to mcbmoz from comment #38)
> > David & Justin,
> > 
> > Can you review comment 31 and let us know if you are ok with the changes
> > we're making to:
> > 
> > SUMO dropdown (eliminating Thunderbird support)
> 
> Looks good to me. Back to Herr Slater.

Thanks David! Yo, Johnny Slates! Can I proceed with implementation?
(In reply to mcbmoz from comment #42)
> Thanks David! Yo, Johnny Slates! Can I proceed with implementation?

Yep! Assigning back to you-
Assignee: jslater → cbrodigan
Attached image Final Phase 1 Update — 
Steven, this is the final wireframe for proceeding with navigation.
Steven, assigning to you, instructions in comment 44.
Assignee: cbrodigan → steven
Target Milestone: Future → 4.2
(In reply to mcbmoz from comment #45)
> Steven, assigning to you, instructions in comment 44.

Looks straight-foward. I'll let you know if any questions come up during implementation. We'll probably have to file bugs to get the update mirrored anywhere we have a copy of this navigation on a different code-base (the blog is the only one that comes to mind).

Great to see this getting cleaned up and simplified.
Blocks: 695863
Working on implementing the menu updates from the attachment in comment #44 and I have a few questions:

"Privacy & Security" might better than "Privacy/Security"?

We don't have a Firefox Beta product page yet. What should we do there? (/firefox/beta/ redirects to /firefox/channel for now)

The diagram shows a "Personas" item under ADD-ONS, but the notes on the right say "Personas - redundant info to the /features & customization pages" - should that item stay or go?

Under the "6. About" notes on the right, and Partnerships & Legal both say "works in the footer". However, we currently mirror these menu contents in the header/footer automatically right now (they are built from a shared list). Can we keep them consistent, or should we break them into two separate lists?

Notes on right say "Ideally, we could remove "participate" - should that stay or go?

What about "Contact" under About? It's missing in the diagram, and not mentioned in the notes.

Also, for touch-based browsers, the top level menu item opens the menu rather that taking you to the destination page (since there is no "hover" mode in the land of touch to open the menu). So, we need to generally make sure that the destination link of the top-level menu titles is accessible from one of the sub-items. For Desktop, we cheat by relying on the main "Mozilla Firefox" logo in the header as the fall-back link. For all others except MOBILE, we have the parent link duplicated in the sub-items. That's what the Download link under MOBILE was for.
(In reply to Steven Garrity from comment #47)
> Working on implementing the menu updates from the attachment in comment #44
> and I have a few questions:
> 
> "Privacy & Security" might better than "Privacy/Security"?

Agreed!

> We don't have a Firefox Beta product page yet. What should we do there?
> (/firefox/beta/ redirects to /firefox/channel for now)

Yes, please!

> The diagram shows a "Personas" item under ADD-ONS, but the notes on the
> right say "Personas - redundant info to the /features & customization pages"
> - should that item stay or go?

Stay. (forgot to update the notes on the wireframe)

> Under the "6. About" notes on the right, and Partnerships & Legal both say
> "works in the footer". However, we currently mirror these menu contents in
> the header/footer automatically right now (they are built from a shared
> list). Can we keep them consistent, or should we break them into two
> separate lists?

Let's keep them the same for now - so leave as is. Cool?

> Notes on right say "Ideally, we could remove "participate" - should that
> stay or go?

Stay.

> What about "Contact" under About? It's missing in the diagram, and not
> mentioned in the notes.

I'd like it to be only in the footer, but if you think we should keep it up there, we can leave as is.

> Also, for touch-based browsers, the top level menu item opens the menu
> rather that taking you to the destination page (since there is no "hover"
> mode in the land of touch to open the menu). So, we need to generally make
> sure that the destination link of the top-level menu titles is accessible
> from one of the sub-items. For Desktop, we cheat by relying on the main
> "Mozilla Firefox" logo in the header as the fall-back link. For all others
> except MOBILE, we have the parent link duplicated in the sub-items. That's
> what the Download link under MOBILE was for.

So, for mobile, we should take the user to http://www.mozilla.org/en-US/mobile/features/ as the destination link.
Target Milestone: 4.2 → 4.3
Thanks Chrissie. I've updated the menu accordingly. I did end up dropping Legal from the About menu as there is a duplicate Legal link in the small print down in the footer.
Status: NEW → RESOLVED
Closed: 13 years ago
Keywords: qawanted
Resolution: --- → FIXED
Whiteboard: r96832, b=trunk
I neglected to consider the layout implications of this extra column of links in the footer. I'll try some quick layout adjustments to see if we can fit it in.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
(In reply to Steven Garrity from comment #50)
> I neglected to consider the layout implications of this extra column of
> links in the footer. I'll try some quick layout adjustments to see if we can
> fit it in.

Steven, thank you for taking this on, lmk if you need me to review.
Made some whitespace (bluespace?) adjustments to fit in this new column in the footer. Ready for QA.
Status: REOPENED → RESOLVED
Closed: 13 years ago → 13 years ago
Resolution: --- → FIXED
Whiteboard: r96832, b=trunk → r96832,96971, b=trunk
Target Milestone: 4.3 → 4.4
Wow, nice job all! Looks really clean.
I have to second that--thanks for all your work on this, web team. Looks and feels a ton better!
+1

Woo-hoo!
After talking with Chrissie, I changed the mobile/customize nav link to go to the addons site like it was previously. We're going to look at the /mobile/customize page which seems out-of-date somehow.

done in r97039
Whiteboard: r96832,96971, b=trunk → r96832,96971,97039 b=trunk
pushed to production r97042
verified fixed http://www.mozilla.org/en-US/firefox/fx/
Status: RESOLVED → VERIFIED
The new Releases menu item points /en-US/mobile/. Is this OK?
And, the About menu in the footer is placed at half-mast.
James, did r96971 get from trunk into production? That should have fixed the about menu position in the footer.
Status: VERIFIED → REOPENED
Resolution: FIXED → ---
Blocks: 699378
(In reply to Kohei Yoshino from comment #61)
> The new Releases menu item points /en-US/mobile/. Is this OK?

Filed Bug 699378 for this.
(In reply to Steven Garrity from comment #63)
> James, did r96971 get from trunk into production? That should have fixed the
> about menu position in the footer.

Update: Looks like James did push everything into production correctly, but the CDN is aggressively caching the CSS. I've removed the date tags from the CSS/JS includes in trunk in r97160 that should help this. James, can you push?
pushed comment 65 to production r97162
Status: REOPENED → RESOLVED
Closed: 13 years ago → 13 years ago
Resolution: --- → FIXED
Keywords: qawanted
Depends on: 699443
Depends on: 699444
verified fixed http://www.mozilla.org/en-US/firefox/fx/
Status: RESOLVED → VERIFIED
Keywords: qawanted
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: