1059002 - Reconsider how the mobile navigation works

Status: RESOLVED FIXED

(Marketplace Graveyard :: Consumer Pages, enhancement, P1)

Description

[Christopher Van Wiemeersch [:cvan]]

Instead of separating the anchors by margins, and remove the margins and instead use padding to space the nav items. You'll likely need to wrap the text in another element to get that cool underline effect, but the improved usability (clickability) will make it well worth it.

http://i.imgur.com/6XQjEzC.png

Comment 1

[Chuck Harmston [:chuck]]

There was a moderate consensus in triage that the current navigation on mobile isn't especially intuitive. Assigning to Philip for further consideration.

Comment 3

[Christopher Van Wiemeersch [:cvan]]

This is both an implementation issue and a issue with the interface's ease of discovery.

It's also worth noting that if you resize your browser to 1440px (which is still a desktop width, almost in tablet-width territory), the swipe-based navigation appears on desktop:

    https://www.dropbox.com/s/arpm2t1jkzgk1pq/Screenshot%202014-09-29%2013.40.42.png?dl=0

I know there are some touch-based desktops, but we're relying on viewport, not touch support, to show this swipe-based nav.

In the screenshot above, it looks like there are no other navigation options, because the offset starts right before the "Popular" text.

In the screenshot below, because the slight edge of the "Home" text is visible, it is a bit more obvious that there is more to the navigation:

    https://www.dropbox.com/s/x18yh980vzc6smi/Screenshot%202014-09-29%2013.41.59.png?dl=0

But, even so, it's unclear how to see more of the nav (on desktop). You cannot scroll but you can indeed drag your cursor to emulate a swipe. 

We should both fix this for non-touch users and make it more obvious that swiping is necessary.

Comment 4

[Christopher Van Wiemeersch [:cvan]]

Hey guys. I just tried using this on my Flames on 1.3 and 2.1, and the nav is completely unusable. The swipe just isn't working. I can click individual links only if they're visible. But I can literally not swipe. I have to click "New" to be able to see "Categories." I cannot swipe.

And when trying to swipe, I often scroll in the wrong area and it scrolls the page vertically.

The settings gear also confuses things.

I understand this may be an implementation issue, coupled with Firefox OS' poor touch capabilities (and probably an issue with the device's poor touch sensitivity).

Other people are filing for this issue too, so I'm not alone.

I suggest everyone try this at home on a Firefox OS phone. The design and implementation needed to be readdressed. I'm certain we can get creative here and improve this to be more intuitive and responsive.

Comment 5

[David Durst [:ddurst]]

Yeah, I was using this late last week on my Flame and it was clunky to say the least. Some of the issue appears to be OS-related (the touch sensitivity is certainly finicky), but there's a lot more issues than that.

- I can't swipe the nav without selecting something
- I can sometimes not even select something further away than "New" when on "Home"
- if I'm on "Popular" and I go to "New" or "Home" (using the nav, not the home button), Popular retains a grew underline
- it's hard to swipe back to the left without hitting the gear icon
- when switching between regular navigation and "my account" navigation, the animated transition happens so fast that it's almost not apparent

That's all on the packaged app, not the site. The good news (?) is that the only one of those -- the underline issue -- happens on my Flame when I go to marketplace (production) via the browser.

While I'd love a redesign of the nav in general, none of the issues have to do with the UX model (the UX model just makes the implementation difficult). We need to solve for those issues and only then will we be able to say if the UXD is not feasible given OS/hardware limitations.

Upping the priority on this, because I feel it negatively impacts usability. Also changing the assignment so that anyone could take this (added the most interested parties to the CC List).

Comment 6

[Paul Rouget [:paul]]

(In reply to Christopher Van Wiemeersch [:cvan] from comment #4)
> I understand this may be an implementation issue, coupled with Firefox OS'
> poor touch capabilities (and probably an issue with the device's poor touch
> sensitivity).

"Firefox OS' poor touch capabilities"

What precisely? If there's issues with how B2G handle touch events, we'd like to hear about it.

Comment 7

[Christopher Van Wiemeersch [:cvan]]

(In reply to Paul Rouget [:paul] (slow to respond. Ping me on IRC) from comment #6)
> (In reply to Christopher Van Wiemeersch [:cvan] from comment #4)
> > I understand this may be an implementation issue, coupled with Firefox OS'
> > poor touch capabilities (and probably an issue with the device's poor touch
> > sensitivity).
> 
> "Firefox OS' poor touch capabilities"
> 
> What precisely? If there's issues with how B2G handle touch events, we'd
> like to hear about it.

Quite regularly, there seem to be missed clicks/touches. These could be attributed to the particular device - I'm not sure. I hear the same thing from quite a few folks around the MV office too - a few of whom are regular FxOS users. Again, not sure if it's a B2G issue.

I'm looking into it for another project. I'll have more concrete tests this week, but I've been detecting noticeable lags between when `touchstart` and `touchend` events are getting fired. It could be my/our own wrongdoing; I'll file bugs if I see anything. Thanks!

Comment 8

[Kevin Ngo [:ngoke]]

After months of acknowledgement of pain points without any serious alternative solution raised, I am going to tackle this today as a part of https://bugzilla.mozilla.org/show_bug.cgi?id=1059528

We will remove the fickle swiping behavior (especially since FxOS 2.1 integrates a system-wide swipe gesture for switching processes), and then programmatically calculate offsets. We will try to increase click target padding as well.

Comment 9

[David Durst [:ddurst]]

I think the smoothness (or lack thereof) of the nav swiping is probably one of the biggest issues -- because it implies that it's clunky.

So if it were smooth-swiping and had reasonable hit areas and responsiveness, the existing model may be fine.

Comment 10

[Kevin Ngo [:ngoke]]

If you try to swipe on FxOS 2.1, it'll switch between different processes. That gives a definite no-go.

Here's a screencast of the updated navbar: http://screencast.com/t/LXWawCRn

The main improvement here that the positioning of the navbar is not hard-coded so it should work for an arbitrary number of nav elements, really long strings, and other languages. I will do some testing on my Flame and in other languages.

Comment 11

[David Durst [:ddurst]]

What happens when there's an option further to the right than the rightmost?

Comment 12

[Kevin Ngo [:ngoke]]

Something like: http://screencast.com/t/6ZIl4fynP

Comment 13

[David Durst [:ddurst]]

Word. You are on your way to a cvan-treated beer.

Comment 14

[Kevin Ngo [:ngoke]]

https://github.com/mozilla/fireplace/pull/702 makes the navbar smarter in terms of positioning and fitting.

Follow-up filed https://bugzilla.mozilla.org/show_bug.cgi?id=1080769 for perf/responsiveness.

Will use https://bugzilla.mozilla.org/show_bug.cgi?id=1059528 for QA, keeping this one as a discussion bug.

Comment 15

[Paul Rouget [:paul]]

If I understand this bug correctly, it is not addressing my original issue (duped, bug 1069284).
Looking at the screencast (comment 12), it even looks like the overflow is actually expected.

I hate bike shedding and random UX opinions as much as anyone, but this menu is really difficult to understand.

* the overflow looks like a bug. I really thought it was a viewport issue at first.
* you have to click the last visible item to see the other items, so you don't know there's anything after the visible items, and really, having to select a random menu to reach another is weird.
* menu items slides under the gear, so you end up clicking on the gear way to often

Speaking of the gear, I never understood what clicking on the gear was actually doing, so I took a minute to look at what it does. It brings you to another menu! With its own items, and you have to click on the markertplace icon on the right to go back to the original menu.

I'm sorry, but all of that is very very confusing.

Comment 16

[Kevin Ngo [:ngoke]]

It's an inherent flaw in the original design. There's been a lot of hot talk about it, but no solutions or alternatives have been raised, which leaves me in an awkward position. The patch I pushed out does improves on the implementation but not the design.

I asked UX about it a couple weeks ago, and they mentioned it was not as high of a priority. Phil, may we consider bumping this to a higher priority to re-address the navbar? Developers and users alike are not able to use it, and it's most likely the highest-engaged component of the Marketplace.

Let me know if you have any suggestions, and thanks for letting us know your concerns!

Comment 17

[Kevin Ngo [:ngoke]]

Attachment: Play Store Nav

It's curious this screenshot of the Play Store's nav also has cut-offs off the screen. They must be doing something to let the user know that the nav extends beyond the screen.

Perhaps if we implemented Phil's mock that fades the end of the navbar to let the user know there's more beyond the screen.

Comment 18

[Christopher Van Wiemeersch [:cvan]]

As I mentioned in comment 4, anyone who opens the Marketplace on *any* phone and tries this out will immediately see that the nav needs fixing yesterday. I've CC'd product (David Bialer) who can help assess the severity of this issue.

Kevin, I respect the effort you've been putting into this. Thanks.

As I mentioned in bug 1059528 comment 7, if we're going to stick with this nav, we should just be allowing users to scroll. A good next step for the Fireplace folks would be to reverse engineer how Apple's hamburger nav is so buttery smooth:

https://www.dropbox.com/s/5sru7gfjc69hg3u/Screenshot%202014-10-10%2002.13.07.png?dl=0

However, their click targets are abysmal, and I find myself constantly swiping outside of the nav - so don't imitate those parts ;)

The fix in bug 1059528 – as I addressed in bug 1059528 comment 5 and Paul also addresses in comment 15 of this bug – causes the user to click adjacent nav items in order to see the ones off screen. Not only is this behaviour frustrating, but the user incurs unnecessary requests - something no user could possibly be happy about.

With all that being said, I still firmly believe that any nav that requires my swiping back and forth is not a nav I ever want to use. Either show the user all the nav options or hide everything by default (à la hamburger menus, which I don't like).

Comment 19

[Christopher Van Wiemeersch [:cvan]]

BTW, you should be able to just do `overflow-x: auto` on the nav container. And if memory serves me correctly, there are no visible scrollbars on Firefox OS / Firefox for Android (I know there aren't any on iOS).

I don't think you will, but if you find yourself in the situation where you do see scrollbars, just have some element below the nav layered above the nav to obscure its scrollbars.

Comment 20

[Paul Rouget [:paul]]

(In reply to Christopher Van Wiemeersch [:cvan] from comment #19)
> BTW, you should be able to just do `overflow-x: auto` on the nav container.
> And if memory serves me correctly, there are no visible scrollbars on
> Firefox OS / Firefox for Android (I know there aren't any on iOS).
> 
> I don't think you will, but if you find yourself in the situation where you
> do see scrollbars, just have some element below the nav layered above the
> nav to obscure its scrollbars.

But then you'll trigger the overscroll effect.

Comment 21

[Philip [:pwalm]]

Just a heads up: I'm working on preliminary ideas for a nav that scales from mobile to desktop nicely, and takes into account device performance/usability/etc. Will share when I've got something more tangible and concrete, but just wanted to let you know it is on my mind.

Comment 22

[Kevin Ngo [:ngoke]]

Thanks, Phil. For now, we're trying to carve time to make it slidable (with overflows).

Comment 23

[Philip [:pwalm]]

Yep, keep working on that. I'm thinking whatever I end up proposing will be a bit of an overhaul, prob wouldn't happen until Q2 (maybe Q3) of 2015.

Comment 24

[Christopher Van Wiemeersch [:cvan]]

Relevant, but don't really take it seriously too yet:
https://github.com/mozilla/fireplace/pull/802/files

I'm working on isolating all the tiny fixes into several small commits (I've already filed several bugs and merged them to Fireplace the past week).

Comment 26

[David Durst [:ddurst]]

Hey! We're going to revise the navigation. Huzzah.

Comment 30

[David Durst [:ddurst]]

Closing, as we've reconsidered how it works and are implementing a fix in bug 1141687.