Closed Bug 804320 Opened 12 years ago Closed 11 years ago

List scrolling - swiping a small distance has no inertia

Categories

(Firefox OS Graveyard :: General, defect, P3)

All
Other
defect

Tracking

(blocking-basecamp:-, firefox19 wontfix, firefox20 wontfix, firefox21 fixed, b2g18+ fixed, b2g18-v1.0.0 wontfix, b2g18-v1.0.1 fixed)

RESOLVED FIXED
B2G C4 (2jan on)
blocking-basecamp -
Tracking Status
firefox19 --- wontfix
firefox20 --- wontfix
firefox21 --- fixed
b2g18 + fixed
b2g18-v1.0.0 --- wontfix
b2g18-v1.0.1 --- fixed

People

(Reporter: pla, Assigned: vingtetun)

References

Details

(Whiteboard: interaction, UX-P1, BerlinWW)

Attachments

(2 files)

Go into Settings and scroll up and down.  If you use a large enough or fast enough swipe motion, there is inertia in the scrolling.  If you use a small or slow swipe, there is no inertia.  This creates lowers the overall quality of the scrolling experience and makes it feel difficult & clunky.

Solution: Add a small amount of inertia for smaller (ie. for a small displacement) or slower (ie. below the threshold speed where inertia doesn't kick in) swipe motions.

Tested on: otoro_2012-10-22_ics_us
Priority: -- → P3
Component: Gaia → Gaia::Settings
Component: Gaia::Settings → Gaia::System
Rewriting with perf/ux-trust bug template.

--

What makes it feel slow/broken?

When I'm swiping through a list, such as in the Settings app, the scrolling motion will often 'catch' and just stop, instead of moving in the direction of my swipe, with inertia.  I've noticed this only happens when I swipe a small distance (about the distance of one list item ~60 pixels).

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

It slows me down from finding the item I want in the list, and overall just feels broken.  It's a frustrating feeling.

How does this make you feel?

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

Device: Unagi, Nov. 22 Nightly.

Details: (technical factors, FPS, app startup time, ms elapsed, etc)

Bonus: can you attach a video of the problem?
Yes
Summary: [transition] [perf] Index Lists Scrolling - Swiping a Small Distance Has No Inertia → [Gaia::System][ux-trust] Index Lists Scrolling - Swiping a Small Distance Has No Inertia
Priority: P3 → P1
Summary: [Gaia::System][ux-trust] Index Lists Scrolling - Swiping a Small Distance Has No Inertia → [Gaia::System] Index Lists Scrolling - Swiping a Small Distance Has No Inertia
Nominating for basecamp-block+.

This inertia problem makes scrolling through a list feel completely broken.
blocking-basecamp: --- → ?
blocking-basecamp: ? → +
Priority: P1 → P3
from EU/Taipei gaia triage, change it to BB+ and make it P3 with BB+
While not fantastic, I do not think this feels *broken*. Scrolling still works, and this only occurs with very small scroll gestures. Inertia works fine otherwise.

I do not think this is something we'd hold the entire release to fix. Re-nominating for broader input.
blocking-basecamp: + → ?
blocking-basecamp: ? → -
blocking-basecamp: - → ?
Keywords: perf, polish
Whiteboard: visual design → interaction
Renoming for bb+.

Dietrich, you're correct in saying that scrolling technically works.  But it's such a fundamental activity throughout the OS, why would you release something with a noticeable resistence to user interaction?  Scrolling is a top 5 item for me, and this bug, when fixed in conjuntion with bug 804315 and the overall system improvements will significantly improve the experience.  If you don't fix this bug, scrolling will always feel unnecessarily resistant.

It may not be completely broken, but it is broken.  Please don't ignore this.

If I was head chef, I would not let this out of my kitchen.  It's poor quality, plain and simple. :/
Blocks: 814751
No longer blocks: c&c
Whiteboard: interaction → interaction, UX-P1
Agreed. Attention to touch input details like these are essential to creating an impression of quality and enjoyment. Our current implementation is currently well below even early-version Android. Ideally we could improve this system wide.

Chris and Vivien, would we need to fix this app by app? Or is scrolling implemented system-wide?
Chris, Vivien, renominate if needed
blocking-basecamp: ? → -
Flags: needinfo?(jones.chris.g)
Flags: needinfo?(21)
Scrolling is hopefully implemented system wide in http://mxr.mozilla.org/mozilla-central/source/dom/browser-element/BrowserElementScrolling.js
Flags: needinfo?(jones.chris.g)
Flags: needinfo?(21)
Thanks Vivien. So a fix to the issue described here would be inherited system wide. Another reason to address this.
Summary: [Gaia::System] Index Lists Scrolling - Swiping a Small Distance Has No Inertia → List scrolling - swiping a small distance has no inertia
Whiteboard: interaction, UX-P1 → interaction, UX-P1, BerlinWW
Attached patch PatchSplinter Review
I have a small patch I made in the plane. Not perfect but make it much better imo.
Attachment #699659 - Flags: review?(mchen)
(In reply to Vivien Nicolas (:vingtetun) from comment #11)
> Created attachment 699659 [details] [diff] [review]
> Patch
> 
> I have a small patch I made in the plane. Not perfect but make it much
> better imo.

Hi Vivien,

I think you set a wrong reviewer here. I am not a guy for this area.
Comment on attachment 699659 [details] [diff] [review]
Patch

Should be r? jlebar
Attachment #699659 - Flags: review?(mchen) → review?(justin.lebar+bug)
Comment on attachment 699659 [details] [diff] [review]
Patch

Let's change again my reviewer :)
Attachment #699659 - Flags: review?(justin.lebar+bug) → review?(schien)
Comment on attachment 699659 [details] [diff] [review]
Patch

Review of attachment 699659 [details] [diff] [review]:
-----------------------------------------------------------------

Great work on fine tuning KineticPanning! :)
Attachment #699659 - Flags: review?(schien) → review+
Component: Gaia::System → General
Comment on attachment 699659 [details] [diff] [review]
Patch

This is a simple patch that provide more inertia when the user do little gesture. This is a UX-P1 because doing a small and quick pan gesture in all applications results into an scroll followed by an immediate stops right now.
Attachment #699659 - Flags: approval-mozilla-b2g18?
Does this conflict/relate to bug 827715?
This change is not blocking-basecamp:+ or blocking-b2g:tef+, so we'll default to resolving in v1.0.1 first. You can either land on shira already or wait for mozilla-b2g18 to be opened up to v1.0.1 changes.
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 #699659 - Flags: approval-mozilla-b2g18? → approval-mozilla-b2g18+
Great news, thanks for doing this Vivien!
Does this need to land on inbound/b2g18 still? (I'm assuming b2g18_v1_0_0 isn't going to happen at this point). If you want me to take care of landing it, just set the checkin-needed keyword up top.
https://hg.mozilla.org/mozilla-central/rev/fa18864fd67f
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
Yes, we still want this on b2g18.  Thanks!
Keywords: checkin-needed
Assignee: nobody → 21
Batch edit: bugs fixed on b2g18 since 1/25 branch of v1.0 are fixed on v1.0.1
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: