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
Created attachment 801207 [details] pull request redirect to github
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?
in case josh is busy, needinfo from UX
Josh is the correct person to flag on this.
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?
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.
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.
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.
I guess this should block if we ship flatfish with 1.2. Tim can you figure out the blocking situation here?
Should be a blocking issue. We should at least provide a bandage fix for minimal tablet support.
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 on attachment 813008 [details] pull_request Great
https://github.com/mozilla-b2g/gaia/pull/12008 is legacy right?
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
merged to gaia-master https://github.com/mozilla-b2g/gaia/commit/d46e3842f5056de88061aa95d77ad3eb6221dcd8 thanks!
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.
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.
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.
Thank you, Mike and Patryk. Appreciate it.
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