683760 - [Update /m] -- Optimize how we use or don't use *menu*

Status: VERIFIED FIXED

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

Description

[mcbmoz]

Hey Jason & Anthony,

Not sure which one of you wants this one! We'd like to improve the user experience around the /m site's navigation. This applies to both iOS and Android sites.

Currently, the menu is hidden and not picked up on by users when they land on the page (they see a single page site).

Can you add a slight animation to the menu, so that it is partially expanded upon page load and retracts or glows a little to increase the user's awareness that there are multiple pages on the /m site?

I didn't make this dependent on any of the other tiny updates to the interface, because it requires a little more design trickery.

In 3.10, but ideally anytime before the end of q4.

HUGE thanks!

~cb

Comment 1

[Jason Grlicky [:grlicky]]

Because human brains are finely tuned to focus on movement, moving elements when the page is finished loading in web design is typically seen as the "Nuclear Option" - it's usually advisable to try all other options before making something move, since the moving thing will automatically become the most prominent thing on the page, regardless of what is actually most important. To put it lightly, a little goes a long way on this type of thing. If anyone can think of a way to more prominently present the menu that does not involve movement, it might be worth discussing!

With this in mind, if we do end up having to go with an animated menu tab, my suggestion is for something subtle, like sliding the menu tab down after the page has loaded.

Comment 2

[mcbmoz]

(In reply to Jason Grlicky [:grlicky] from comment #1)
> Because human brains are finely tuned to focus on movement, moving elements
> when the page is finished loading in web design is typically seen as the
> "Nuclear Option" - it's usually advisable to try all other options before
> making something move, since the moving thing will automatically become the
> most prominent thing on the page, regardless of what is actually most
> important. To put it lightly, a little goes a long way on this type of
> thing. If anyone can think of a way to more prominently present the menu
> that does not involve movement, it might be worth discussing!
> 
> With this in mind, if we do end up having to go with an animated menu tab,
> my suggestion is for something subtle, like sliding the menu tab down after
> the page has loaded.

Jason,

SPOT ON! Great feedback. I was thinking we could also go with a menu similar to gilt groupe's app or Huff Post's -- horizontal menu.

The user testing I ran last week showed that users weren't ever noticing the menu. Then, after they do use it it stays expanded, so I thought - why not just keep it expanded at the start of the experience.

What do you think? I wanted to keep it as simple as possible.

Best,
CB

Comment 3

[Anthony Ricaud (:rik)]

IIRC, there was an animation when the user clicked to open the menu and the performance was awful on some devices. James has the details.

Comment 4

[mcbmoz]

(In reply to Anthony Ricaud (:rik) from comment #3)
> IIRC, there was an animation when the user clicked to open the menu and the
> performance was awful on some devices. James has the details.

OK, great point about performance, so maybe we need to split the nav out of the tab, since it's hiding for a lot of users.

Unless, we really just want to focus on the single page experience as a way to increase conversion.

Thoughts?

Comment 5

[Steven Garrity [:sgarrity]]

(In reply to mcbmoz from comment #4)
> (In reply to Anthony Ricaud (:rik) from comment #3)
> > IIRC, there was an animation when the user clicked to open the menu and the
> > performance was awful on some devices. James has the details.
> 
> OK, great point about performance, so maybe we need to split the nav out of
> the tab, since it's hiding for a lot of users.

Can you clarify what you mean by "split the nav out of the tab"?

Comment 6

[Steven Garrity [:sgarrity]]

Looking at this menu a bit more, the links are as follows:

 "Mozilla Firefox"
 "Features"
 "Desktop"
 "Add-ons"
 "Support"
 "Visit Mozilla"

"Mozilla Firefox" is like a "home" link back to the /m/ home page - a duplicate from the "Mozilla Firefox" title shown on all /m/ pages.

"Features" is a link to /m/features/

"Desktop" takes you to the desktop version of the site - duplicated in the "View Full Site" button in the footer.

"Add-ons" is a link to addons.mozilla.org

"Support" is a link to support.mozilla.org

"Visit Mozilla" links to mozilla.org - which, for now, at least, isn't mobile-friendly.

It strikes me that this isn't a particularly cohesive list of links. All but one link (Features) takes you out of the /m/ mobile-friendly site (which is inevitable, and the addons and support sites both have mobile-friendly layotus).

Two of the six links are also duplicated from elsewhere on the page ("Mozilla Firefox" link, and "Desktop" link). Not necessary a problem, but worth considering.

I wonder if it's worth re-thinking this menu and this set of links rather than trying to draw attention to it.

The mobile-friendly addons.mozilla.org and support.mozilla.org sites have an interesting variation of this header menu. There, the "Mozilla Firefox" title is part of a full-width "menu" button. This might be a bit more discoverable.

They also seem to have a nice slide-down animation (when you open the menu), though I think it relies on jQuery Mobile - not something we current have on the /m/ pages. CC'ing potch to confirm.

Comment 7

[mcbmoz]

(In reply to Steven Garrity from comment #6)
> Looking at this menu a bit more, the links are as follows:
> 
>  "Mozilla Firefox"
>  "Features"
>  "Desktop"
>  "Add-ons"
>  "Support"
>  "Visit Mozilla"
> 
> "Mozilla Firefox" is like a "home" link back to the /m/ home page - a
> duplicate from the "Mozilla Firefox" title shown on all /m/ pages.
> 
> "Features" is a link to /m/features/
> 
> "Desktop" takes you to the desktop version of the site - duplicated in the
> "View Full Site" button in the footer.
> 
> "Add-ons" is a link to addons.mozilla.org
> 
> "Support" is a link to support.mozilla.org
> 
> "Visit Mozilla" links to mozilla.org - which, for now, at least, isn't
> mobile-friendly.
> 
> It strikes me that this isn't a particularly cohesive list of links. All but
> one link (Features) takes you out of the /m/ mobile-friendly site (which is
> inevitable, and the addons and support sites both have mobile-friendly
> layotus).
> 
> Two of the six links are also duplicated from elsewhere on the page
> ("Mozilla Firefox" link, and "Desktop" link). Not necessary a problem, but
> worth considering.
> 
> I wonder if it's worth re-thinking this menu and this set of links rather
> than trying to draw attention to it.
> 
> The mobile-friendly addons.mozilla.org and support.mozilla.org sites have an
> interesting variation of this header menu. There, the "Mozilla Firefox"
> title is part of a full-width "menu" button. This might be a bit more
> discoverable.
> 
> They also seem to have a nice slide-down animation (when you open the menu),
> though I think it relies on jQuery Mobile - not something we current have on
> the /m/ pages. CC'ing potch to confirm.

Steven,

You're reading my mind! I was just describing this in an email :-)

What would be great for this phase to stay in scope would be to break the nav out of the tab and make it horizontal. 

Go to gilt groupe or Huff Post's apps to get a sense (I can mock it up in a graffle later today).

Ultimately, I want to put less emphasis on developing /m for phone users (not tablet) users to experience the site with simple information, so that they can go from one-click into the store(s) where the experience needs to be pitch perfect.

This should reduce the amount of work we need from localizers and keep the experience fairly focused.

Sites that do this well (access from your phone):

opentable.com
twitter.com
yelp.com
zappos.com
gowalla.com

What are your thoughts?

Comment 8

[Steven Garrity [:sgarrity]]

Chrissie - can you post some screenshots of the horizontal menu style you're thinking of? I'm not sure I'm seeing anything consistent across these example sites (don't have an iOS device on hand - working from home).

Comment 9

[mcbmoz]

Attachment: mobile landing page wireframe - android

Comment 10

[mcbmoz]

(In reply to Steven Garrity from comment #8)
> Chrissie - can you post some screenshots of the horizontal menu style you're
> thinking of? I'm not sure I'm seeing anything consistent across these
> example sites (don't have an iOS device on hand - working from home).

Hey Steven,

You raised awesome points this morning, and I'd like to propose that we eliminate the menu entirely.

Observations & recommendations:

Mozilla Firefox - This link is redundant as it goes back to the /m homepage
Features - Do we need this? The copy is clunky & is repeated inside of the app stores, where users make the decision to download
Desktop - This link is redundant as it goes back to the /m homepage
Add-ons - This can be a link in the copy (see #1 on attached wireframe)
Support - This can be a link in the copy on the FAQ Page (FAQ should have download button)
Visit Mozilla - This can be a link in the copy on the FAQ page

This would bring the /m experience down to 4 pages:
*landing page
*FAQ
*Privacy Policy
*Channels

We would then turn more emphasis onto curating and focusing more on the in-app-store experience, where our users seem to meet the greatest friction.

Wireframe attached in comment 9

John, Jaclyn, can you weigh in, so Steven can make changes and tighten up the mobile experience for both Android & iOS?

Thanks!

Comment 11

[Jaclyn Fu]

I agree that the menu should be eliminated and keeping the /m experience as tight as possible. Just my 2 cents: 

Mozilla Firefox - remove
Features - I also think mobile users go straight to the Android Market to get their information. Remove as well 
Desktop - Should we link users to desktop features page? If they click on this link, they probably want to know more about desktop (but obviously can't download it) 
Add-Ons - +1 
Support - Support pages are pretty important and should be accessed easily. Let's make them more easily found instead of inside the FAQ - maybe right above "FAQ"? 
Visit Mozilla - +1 

Thanks!

Comment 12

[mcbmoz]

(In reply to Jaclyn Fu from comment #11)
> I agree that the menu should be eliminated and keeping the /m experience as
> tight as possible. Just my 2 cents: 
> 
> Mozilla Firefox - remove
> Features - I also think mobile users go straight to the Android Market to
> get their information. Remove as well 
> Desktop - Should we link users to desktop features page? If they click on
> this link, they probably want to know more about desktop (but obviously
> can't download it) 
> Add-Ons - +1 
> Support - Support pages are pretty important and should be accessed easily.
> Let's make them more easily found instead of inside the FAQ - maybe right
> above "FAQ"? 
> Visit Mozilla - +1 
> 
> Thanks!

Jaclyn,

Desktop - unfortunately because we do device detection the user isn't able to access desktop without going to the full site. However, this was a link that was designed into the experience before device detection, so it makes sense to eliminate it from the /m menu.

Support - The most relevant information about support is actually in the FAQ section, so that's why I believe it's a better user experience for acquisition design, where you want to be tightly focused on download. If a user clicks to sumo, she won't get a download button for mobile. If she clicks to FAQ, she'll see her basic questions answered (this content is already from sumo) and if she digs deeper then she can go to sumo, but that's a user who is taking more than a few minutes to digest and download from the site - likely an edge case.

If we kept it, or added it to the already busy experience, I'd want to know that we were sending significant traffic to sumo and was it worth losing a /m visitor and conversion?

Thoughts?

John, can you also weigh in - see Steven's comment 6.

Comment 13

[mcbmoz]

ping Jaclyn & John :-) see comment 12 and comment 6

would be great to get this into this week's release, steven's working on it.

Comment 14

[Jaclyn Fu]

Makes sense - let's keep your original recommendations for Sumo and desktop! Thanks!

Comment 15

[mcbmoz]

(In reply to Jaclyn Fu from comment #14)
> Makes sense - let's keep your original recommendations for Sumo and desktop!
> Thanks!

Great!

Steven, let's eliminate the menu from the interface and make the following tweaks:

*add a link to the word "Add-ons" see wireframe attached to comment 9
*add a link to support.mozilla.com on the FAQ
*update FAQ where it reads mozilla.com to mozilla.org/firefox
*add download button to FAQ (top of page and link at bottom of page see wireframe attached to comment 9)

Thanks!

Comment 16

[Steven Garrity [:sgarrity]]

(In reply to mcbmoz from comment #15)
> Steven, let's eliminate the menu from the interface and make the following
> tweaks:
I've eliminated the menu for en-US in trunk. You can preview at http://www-trunk.stage.mozilla.com/en-US/m/

Should this be done for other all other locales as well?

> *add a link to the word "Add-ons" see wireframe attached to comment 9
The entire "Customize" area is a link now, as per Bug 683754, so we can't have a single text link inside this.

> *add a link to support.mozilla.com on the FAQ
Do you have a position or wording in mind?

> *update FAQ where it reads mozilla.com to mozilla.org/firefox
I don't see any reference to "mozilla.com" on the FAQ page. Can you clarify?

> *add download button to FAQ (top of page and link at bottom of page see
> wireframe attached to comment 9)
I'll defer this to Bug 683755.

Comment 17

[mcbmoz]

(In reply to Steven Garrity from comment #16)
> (In reply to mcbmoz from comment #15)
> > Steven, let's eliminate the menu from the interface and make the following
> > tweaks:
> I've eliminated the menu for en-US in trunk. You can preview at
> http://www-trunk.stage.mozilla.com/en-US/m/
> 
> Should this be done for other all other locales as well?
> 
> > *add a link to the word "Add-ons" see wireframe attached to comment 9
> The entire "Customize" area is a link now, as per Bug 683754, so we can't
> have a single text link inside this.
> 
> > *add a link to support.mozilla.com on the FAQ
> Do you have a position or wording in mind?

Let's not add the sumo link, because it will have l10n consequences, will open a bug to revisit with an overhaul of copy on the page anyway - it's really too long.

> 
> > *update FAQ where it reads mozilla.com to mozilla.org/firefox
> I don't see any reference to "mozilla.com" on the FAQ page. Can you clarify?

Yep ok, replace all .com with .org :

at top of page: Get Firefox for Mobile Or visit Firefox.com/m on your browser 

under Is Firefox available for my mobile phone?: Download the latest version of Firefox for mobile by visiting Firefox.com/m 

under Will Firefox work with my mobile phone?: Firefox is available for download on Google Android 2.1 and above. Download the latest version of Firefox by visiting Firefox.com/m 
 
> > *add download button to FAQ (top of page and link at bottom of page see
> > wireframe attached to comment 9)
> I'll defer this to Bug 683755.

cool.

Thank YOU!

Comment 18

[Steven Garrity [:sgarrity]]

(In reply to mcbmoz from comment #17)
> Yep ok, replace all .com with .org :
Sure - so we're not promoting Firefox.com/m anymore? We're over to mozilla.org/m ?

Something else that came to mind - should the grey mozilla tab in the top right remain just as a simple link to mozilla.org? It is a strong part of the overall mozilla.org web identity. The key drawbacks I can see are that mozilla.org isn't mobile-friendly (yet) and that people who got used to it as a menu-opening button will have an unexpected result.

Even with these issues, I would still recommend we keep it.

Comment 19

[John Slater]

Two quick thoughts from me:
- URL should be firefox.com/m, not mozilla.org/m
- let's keep the grey tab

There's lots of other great discussion in this thread...if you need input on anything else please let know.

Comment 20

[mcbmoz]

(In reply to John Slater from comment #19)
> Two quick thoughts from me:
> - URL should be firefox.com/m, not mozilla.org/m
> - let's keep the grey tab
> 
> There's lots of other great discussion in this thread...if you need input on
> anything else please let know.

I recommend not keeping the tab. 

1.) Currently, the tab doesn't take the user to mozilla.org, which is a good thing, because there is no mobile support or mobile product information on mozilla.org.

2.) The mobile site is less about content and more about conversion - the meat of the experience being in the app store itself.

Great supporting examples to view from your phone:

http://rockmelt.com
http://opentable.com
http://groupon.com

The reason I wanted to pull out the .com references is that since the merge they already redirect to http://www.mozilla.org/en-US/m/

We'll be able to straighten out that experience with the mozilla.org redesign. But, for now it's misleading to use those urls and it causes the user to go through a redirect anyway, so we can improve the page load time, which is especially important on phones. I filed a separate bug on this just after the merge bug 683938

Ciao!

Comment 21

[Steven Garrity [:sgarrity]]

I need a tie-breaker or arm-wrestle to settle the differences between comment #19 and #20.

Comment 22

[mcbmoz]

(In reply to Steven Garrity from comment #21)
> I need a tie-breaker or arm-wrestle to settle the differences between
> comment #19 and #20.

Yo! Johnny Slates, can you make the final call between comment #19 and comment #20?

Comment 23

[John Slater]

Oops, sorry about the lack of tiebreaking. Let's go with Chrissie's plan (comment #20), but I would like to revisit this once mozilla.org is more mobile-friendly. For now, though, it does make sense to leave out a link that would take you to a poor browsing experience.

Comment 24

[Steven Garrity [:sgarrity]]

Ok, so we'll drop the grey tab in /m/ for now. Should that be in en-US only, or for all locales?

Also, what about the Firefox.org/m URL - is that a keeper?

Comment 25

[John Slater]

(In reply to Steven Garrity from comment #24)
 > Also, what about the Firefox.org/m URL - is that a keeper?

We don't own that URL, so let's be sure to not use it anywhere.

Comment 26

[Steven Garrity [:sgarrity]]

(In reply to John Slater from comment #25)
>  > Also, what about the Firefox.org/m URL - is that a keeper?
> We don't own that URL, so let's be sure to not use it anywhere.

Right - sorry. I meant Firefox.com/m - also see: https://bugzilla.mozilla.org/show_bug.cgi?id=683938#c6

Comment 27

[Steven Garrity [:sgarrity]]

I think we're all set here then. The tab is gone for en-US in trunk. Ready for qa. Please re-open or file a new bug if this should happen in other locales.

Comment 28

[mcbmoz]

(In reply to Steven Garrity from comment #27)
> I think we're all set here then. The tab is gone for en-US in trunk. Ready
> for qa. Please re-open or file a new bug if this should happen in other
> locales.

Yes, this should be applied to all locales. There are no new copy updates, so it's just reducing the interface, l10n not needed.

Comment 29

[Steven Garrity [:sgarrity]]

(In reply to mcbmoz from comment #28)
> Yes, this should be applied to all locales. There are no new copy updates,
> so it's just reducing the interface, l10n not needed.

Ok, done in trunk for all locales now. CC'ing Pascal for a sanity check (pascal, see r95556).

Comment 30

[raymond [:retornam] (inactive)]

qa-verified-trunk http://www-dev.allizom.org/en-US/m/

Comment 31

[James Long (:jlongster)]

pushed to production r95878

Comment 32

[raymond [:retornam] (inactive)]

verified fixed http://www.mozilla.org/en-US/m/