If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

[Flatfish][homescreen] findout better tablet swipe threadshold

RESOLVED FIXED

Status

Firefox OS
Gaia::Homescreen
RESOLVED FIXED
4 years ago
4 years ago

People

(Reporter: gasolin, Assigned: gasolin)

Tracking

(Blocks: 1 bug)

unspecified
Other
Gonk (Firefox OS)

Firefox Tracking Flags

(blocking-b2g:koi+, b2g-v1.2 fixed)

Details

Attachments

(2 attachments)

(Assignee)

Description

4 years ago
currently swipethreadshold is counted by `windowWidth * options.swipeThreshold`.

in 320 width device, the swipe range is 128px (320x0.4), but in tablet, the swipe range will be 1280x0.4 = 512, which is too long to trigger the swipe.

expect:

use absolute px (128px) instead of percentage (0.4) in swipe threadshold
(Assignee)

Updated

4 years ago
Assignee: nobody → gasolin
(Assignee)

Comment 1

4 years ago
Created attachment 801207 [details]
pull request redirect to github
Attachment #801207 - Flags: review?(crdlc)
I don't have problem with the patch and it looks perfect although I'd like that the decision should be taken from UX people, right?
Flags: needinfo?(jcarpenter)
(Assignee)

Updated

4 years ago
blocking-b2g: --- → koi?
(Assignee)

Updated

4 years ago
Blocks: 903304
(Assignee)

Comment 3

4 years ago
in case josh is busy, needinfo from UX
Flags: needinfo?(firefoxos-ux-bugzilla)

Comment 4

4 years ago
Josh is the correct person to flag on this.
Flags: needinfo?(firefoxos-ux-bugzilla)
Hi Fred, my only concern here is how this will scale to phones with higher resolutions. 128px on a device with a 3.5" 640x960 screen, for example, would be too small. Is there a way for us to be implement a responsive touch target that scales based on the PPI and physical dimensions of the screen?
Flags: needinfo?(jcarpenter)
(Assignee)

Comment 6

4 years ago
Hi josh,

It's not possible to get physical dimensions from JS though. But for 3.5" 640x960 device, 128px(css pixel) will work just like normal 3.5" 320x480 device. (explain below)

Becuase the device's PixelRatio will be 2x. The code still recognize 128 css pixel to change page, but user actually need to swipe over 256 phycical pixel (128x2) on screen to trigger the action.
Flags: needinfo?(jcarpenter)
(Assignee)

Comment 7

4 years ago
The good thing to change swipe threadshold from percentage to absolute px is 
we can make sure user swipe similar length and get the same feedback.
(Assignee)

Comment 8

4 years ago
Note this issue is about swipe from left to right or vice versa to change between home screen pages.
not related to recent 'swipe up to home' gesture
Fred and I discussed this on Skype and he clarified that this issue pertains to the horizontal swiping within Home app pagination. I mistook the issue as relating to the swipe-to-home implementation. I suggested that Neo and Mike make the UX call here, given that they have the devices in hand. It really will come down to what feels right on both tablet and phone.
(Assignee)

Updated

4 years ago
Summary: [homescreen] move swipe threadshold from percentage to absolute px → [Flatfish][homescreen] move swipe threadshold from percentage to absolute px
I guess this should block if we ship flatfish with 1.2. Tim can you figure out the blocking situation here?
Flags: needinfo?(timdream)
Should be a blocking issue. We should at least provide a bandage fix for minimal tablet support.
blocking-b2g: koi? → koi+
Flags: needinfo?(timdream)
Flags: needinfo?(mtsai)
Flags: needinfo?(jcarpenter)
(Assignee)

Updated

4 years ago
Attachment #801207 - Flags: review?(crdlc)
(Assignee)

Comment 12

4 years ago
Have the offline discussion with Mike. He suggest to use 0.25 percentage of homescreen as swipe threadshold in tablet.
So change the Bug title and will provide PR soon.
Summary: [Flatfish][homescreen] move swipe threadshold from percentage to absolute px → [Flatfish][homescreen] findout better tablet swipe threadshold
(Assignee)

Comment 13

4 years ago
Created attachment 813008 [details]
pull_request
Attachment #813008 - Flags: review?(crdlc)
Comment on attachment 813008 [details]
pull_request

Great
Attachment #813008 - Flags: review?(crdlc) → review+
https://github.com/mozilla-b2g/gaia/pull/12008 is legacy right?

Comment 16

4 years ago
Swipe Threashold for Tablet :
Use percentage 0.25 of the length and width of the screen for 10" 1280x800 device.
In this case- Landscape : 320 px , Portrait : 200 px
If the swipe distance is no enough, then the shortcuts go back to original position.
If the swipe distance exceeds, then go to next page.

p.s. I found that there is a serious lag for long-press and drag to change page.
The touchscreen UI performance needs to be well tuned before shipping. 

(In reply to Fred Lin [:gasolin] from comment #0)
> currently swipethreadshold is counted by `windowWidth *
> options.swipeThreshold`.
> 
> in 320 width device, the swipe range is 128px (320x0.4), but in tablet, the
> swipe range will be 1280x0.4 = 512, which is too long to trigger the swipe.
> 
> expect:
> 
> use absolute px (128px) instead of percentage (0.4) in swipe threadshold
Flags: needinfo?(mtsai)
(Assignee)

Comment 17

4 years ago
merged to gaia-master https://github.com/mozilla-b2g/gaia/commit/d46e3842f5056de88061aa95d77ad3eb6221dcd8

thanks!
Status: NEW → RESOLVED
Last Resolved: 4 years ago
status-b2g-v1.2: --- → affected
Resolution: --- → FIXED

Comment 18

4 years ago
All - please do not uplift this (yet). A 25% swipe threshold seems too small, especially since we asked for approximately 60% for swipe to home. I am flagging Rob and Patryk, since they are also working on tablet, but particularly Patryk, who has a device on which he can take a look.
Flags: needinfo?(rmacdonald)
Flags: needinfo?(padamczyk)
25% should work, but the issue is overall performance, its hard to test these thresholds if we don't have all the hardware drivers turned on... Currently there is significant lag between when the user touches on something and the device reacting to it. So these thresholds should be tweaked only when the device is running at 100% peformance of very close to it.

Comment 20

4 years ago
Yes, I also notice the issue and I did told Fred and Evelyn. It's something should be done asap. Once users get our pad, if this significant lag still is there. Then we are in trouble. The condition will give users bad touch performance impression before they even use any other functions. For 25% should be fine, it's not just coming from our pad, the issue you raised(I also raised in my response ) was taken into consideration. We also compare with other competitor products as well. Let's do 25% for now, and once the lag issue got solved, and it should be solved. We can tweak if needed.

Comment 21

4 years ago
Thank you, Mike and Patryk. Appreciate it.
Flags: needinfo?(rmacdonald)
Flags: needinfo?(padamczyk)
I tested it on Gaia Master 25% works well... also I noticed a performance increase in the tablet, making it feel more usable.
Uplifted d46e3842f5056de88061aa95d77ad3eb6221dcd8 to:
v1.2: ec011ee4decd3d271c80de792dfef7289e5e4673
status-b2g-v1.2: affected → fixed
You need to log in before you can comment on or make changes to this bug.