913895 - [Flatfish][homescreen] findout better tablet swipe threadshold

Status: RESOLVED FIXED

(Firefox OS Graveyard :: Gaia::Homescreen, defect)

Description

[[e-mail]]

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

Comment 1

[[e-mail]]

Attachment: pull request redirect to github

Comment 2

[Cristian Rodriguez (: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?

Comment 3

[[e-mail]]

in case josh is busy, needinfo from UX

Comment 4

[Stephany Wilkes]

Josh is the correct person to flag on this.

Comment 5

[Josh Carpenter [:jcarpenter]]

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?

Comment 6

[[e-mail]]

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.

Comment 7

[[e-mail]]

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.

Comment 8

[[e-mail]]

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

Comment 9

[Josh Carpenter [:jcarpenter]]

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.

Comment 10

[Gregor Wagner [:gwagner]]

I guess this should block if we ship flatfish with 1.2. Tim can you figure out the blocking situation here?

Comment 11

[Tim Guan-tin Chien [:timdream] (please needinfo)]

Should be a blocking issue. We should at least provide a bandage fix for minimal tablet support.

Comment 12

[[e-mail]]

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.

Comment 13

[[e-mail]]

Attachment: pull_request

Comment 14

[Cristian Rodriguez (:crdlc)]

Comment on attachment 813008 [details]
pull_request

Great

Comment 15

[Cristian Rodriguez (:crdlc)]

https://github.com/mozilla-b2g/gaia/pull/12008 is legacy right?

Comment 16

[GoodMike]

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

Comment 17

[[e-mail]]

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

thanks!

Comment 18

[Stephany Wilkes]

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.

Comment 19

[Patryk Adamczyk [:patryk] UX]

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

[GoodMike]

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

[Stephany Wilkes]

Thank you, Mike and Patryk. Appreciate it.

Comment 22

[Patryk Adamczyk [:patryk] UX]

I tested it on Gaia Master 25% works well... also I noticed a performance increase in the tablet, making it feel more usable.

Comment 23

[John Ford [:jhford] CET/CEST Berlin Time]

Uplifted d46e3842f5056de88061aa95d77ad3eb6221dcd8 to:
v1.2: ec011ee4decd3d271c80de792dfef7289e5e4673