Scrolling through a list triggers button highlights

RESOLVED FIXED

Status

Firefox OS
General
RESOLVED FIXED
6 years ago
6 years ago

People

(Reporter: Peter La, Assigned: vingtetun)

Tracking

unspecified
All
Other

Firefox Tracking Flags

(firefox20 wontfix, firefox21 fixed, b2g18+ fixed)

Details

(Whiteboard: visual design, interaction, UX-P1, BerlinWW)

Attachments

(1 attachment)

(Reporter)

Description

6 years ago
When scrolling up and down through lists using a swipe motion, the blue highlight for a row will appear momentarily and disappear.  This behaviour is distracting and creates a lowered sense of quality.  The blue highlight should not appear on a rapid swipe, but only if the user's finger rests on the screen without moving for a specified amount of time (usually quite short, like < .5 sec as a ballpark).  The exact time will need to be found through trial and error.

This is not 'technically' a performance issue, but it affects the feeling of fluidity.

Tested on: otoro_2012-10-22_ics_us
(Reporter)

Comment 1

6 years ago
Ps. See settings screen for an example of this behaviour.
Keywords: polish
Priority: -- → P2
Whiteboard: visual design → visual design, usability
In "apps/settings/style/lists.css":

    ul li.active,
    ul li:active {
      background-color: #ddf;
      color: #222;
    }

...handles highlighting items in settings. "ul li:active" is causing the highlight. "ul li.active" seems to be unused.

It seems the intent is to map the :active pseudo-selector to tap gestures. I believe the right way to fix this would be to distinguish swipes as distinct from taps at a platform level. Thoughts?

Updated

6 years ago
Component: Gaia → Gaia::Settings

Updated

6 years ago
Component: Gaia::Settings → Gaia::System
(Reporter)

Comment 3

6 years ago
Rewriting with perf/ux-trust bug template.

--

What makes it feel slow/broken?

The blue highlight bar renders when I'm swiping through a list.  It should only render if I have my finger held stationary on a list item for a certain amount of time.

Did it prevent you from doing what you wanted? Why?

No, but it makes list scrolling look broken.

How does this make you feel?

[ ]  :)  I feel happy about it
[X]  :|  Meh
[ ]  :(  I'm upset
[ ] >:O  I'm angry

Device: Unagi, Nov. 22 Nightly.

Details:

There should be a built in delay of approx. 250-400ms where a highlight state will not be rendered if the user scrolls after touching the screen (ie. a swipe).

Bonus: can you attach a video of the problem?
Yes
Keywords: perf → ux-trust
Summary: [transition] [perf] Indexed Lists Scrolling Undesirable Highlight Behaviour During Swipe → [Gaia::System][ux-trust] Indexed Lists Scrolling Undesirable Highlight Behaviour During Swipe
Whiteboard: visual design, usability → visual design, usability, ux-trust
(Reporter)

Updated

6 years ago
Summary: [Gaia::System][ux-trust] Indexed Lists Scrolling Undesirable Highlight Behaviour During Swipe → [Gaia::System] Indexed Lists Scrolling Undesirable Highlight Behaviour During Swipe
Whiteboard: visual design, usability, ux-trust → visual design, usability, ux-trust UX-P2
(In reply to Peter La from comment #3)
> There should be a built in delay of approx. 250-400ms where a highlight
> state will not be rendered if the user scrolls after touching the screen
> (ie. a swipe).

Agreed. Gordon and I chatted about this in Paris and arrived at a similar initial conclusion. 

cc'ing Vivien and Chris Jones. 

Every time I scroll it gives me the impression I'm about to trigger a button press. It pops up even more annoyingly in form-heavy pages, wherein the keyboard opens/closes when I'm trying to scroll a page full of fields (eg: Contacts > New). That is maddening.
Keywords: ux-trust
Priority: P2 → --
Whiteboard: visual design, usability, ux-trust UX-P2 → visual design, interaction, UX-P1
Vivien and Chris, please see above.
Flags: needinfo?(jones.chris.g)
Summary: [Gaia::System] Indexed Lists Scrolling Undesirable Highlight Behaviour During Swipe → Scrolling through a list triggers button highlights
(Reporter)

Updated

6 years ago
Blocks: 814751
No longer blocks: 805267
(Reporter)

Comment 6

6 years ago
Nominating for bb+, as this is a quality issue on a fundamental, pervasive interaction.
blocking-basecamp: --- → ?
Strongly agree with Peter. This is extremely janky and appears to be causing serious usability problems with keyboard, as explained in commen#4.
Status: NEW → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 766066
blocking-basecamp: ? → ---
Whiteboard: visual design, interaction, UX-P1 → visual design, interaction, UX-P1, BerlinWW
This was fixed for content in bug 823619.

It's not fixed for system UI like popups generated by <select> boxes.
Flags: needinfo?(jones.chris.g)
(In reply to Chris Jones [:cjones] [:warhammer] from comment #9)
> This was fixed for content in bug 823619.
> 
> It's not fixed for system UI like popups generated by <select> boxes.

I told you 50ms is too short ;)
No attempt was made to fix this bug for system UI.  It's still receiving non-spec mouse events.
I spoke w/ CJones here in Berlin WW and it sounds like all we need to do here is extend the time out for the touch events so that we're not quite so aggressive about triggering touch events. This is the approach taken by competitor OS' as well.
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---
Created attachment 700098 [details] [diff] [review]
Patch

Hey Chris I told you 50ms was too small ;)

I take this value with Josh sitting next to me so it seems like a good compromise.
Attachment #700098 - Flags: review?(jones.chris.g)
Comment on attachment 700098 [details] [diff] [review]
Patch

This will regress activating tap targets in pannable frames, but josh and discussed having the important ones manually activate themselves (like settings list items).  So ok by me.
Attachment #700098 - Flags: review?(jones.chris.g) → review+
(In reply to Josh Carpenter [:jcarpenter] from comment #12)
> I spoke w/ CJones here in Berlin WW and it sounds like all we need to do
> here is extend the time out for the touch events so that we're not quite so
> aggressive about triggering touch events. This is the approach taken by
> competitor OS' as well.

And just to add, they get away with that by activating the tap target for a "logical" period after it's tapped.

Comment 16

6 years ago
Does this patch need to land?
Assignee: nobody → 21
Comment on attachment 700098 [details] [diff] [review]
Patch

Trivial safe patch for UX-P1 issue encountered when scrolling tappable buttons inside a pannable frame (e.g., in main settings screen).
Attachment #700098 - Flags: approval-mozilla-b2g18?
Component: Gaia::System → General
why not just make the change in b2g.js pref file so that it doesn't change the behavior of any other application?
(In reply to :Margaret Leibovic from comment #16)
> Does this patch need to land?

Yep, oops.

(In reply to Doug Turner (:dougt) from comment #18)
> why not just make the change in b2g.js pref file so that it doesn't change
> the behavior of any other application?

The code that looks at this pref is only used by b2g atm.
This isn't blocking-basecamp:+ or blocking-b2g:tef+, so we'll get this into v1.0.1. Feel free to land to the shira Gecko branch, and mark the status-b2g18:fixed (given the fact that shira will merge to mozilla-b2g18).
tracking-b2g18: --- → 19+
status-b2g18: --- → affected
tracking-b2g18: 19+ → +
Comment on attachment 700098 [details] [diff] [review]
Patch

Given this is a low risk patch and provides a better user experience, we'll take this on the b2g18 branch now so it gets into v1.0.0 - it's not a blocker so if it doesn't land in time, we will wait for it in 1.0.1
Attachment #700098 - Flags: approval-mozilla-b2g18? → approval-mozilla-b2g18+
https://hg.mozilla.org/integration/mozilla-inbound/rev/ff6901f603ec
https://hg.mozilla.org/releases/mozilla-b2g18/rev/d04a8081ae0d
Status: REOPENED → RESOLVED
Last Resolved: 6 years ago6 years ago
status-b2g18: affected → fixed
status-firefox20: --- → wontfix
status-firefox21: --- → fixed
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.