Left edge swipe to reveal launcher is not consistent

[Pat McGowan]

When using the phone with one hand, especially the right hand, the launcher can be very difficult to reveal.
It may have to do with the speed of the swipe, as slowing down seems to improve the reliability.
It also seems that once it gets in a state where the swipe fails, it continues to fail for a number of attempts.
This started to be reported by multiple users when the launcher behavior changed a couple weeks back.

Currently testing latest saucy and flipped images on nexus 4

[Michał Sawicz (saviq)]

Adding ubuntu-ux for design guidance.

[Pat McGowan (pat-mcgowan)]

I would suggest that the edge detection logic be traced and debugged as the symptom would indicate the heuristic on the edge detection may be causing the issues, as opposed to a specific design intent. That is, determine if the swipe is actually detected and if so why it is then ignored.

[Daniel d'Andrada (dandrader)]

By "swipe fails" you mean that the launcher shows up and then immediately hides itself again or it does not show up at all?

[Daniel d'Andrada (dandrader)]

Pat's answer over IRC: "<pmcgowan> does not show at all"

[Daniel d'Andrada (dandrader)]

Pat,

Could you install that package on your device and do the following:
1 - reboot or restart unity8
2 - Perform a gesture to reveal the launcher that you think should be recognized but is not
3 - Attach the file /tmp/EdgeDragInputLog.txt from your device to this bug

This package logs what's happening in a file named /tmp/EdgeDragInputLog.txt
It's crucial that you take note of the gestures performed to reveal the launcher.
e.g.: "gesture 1: correct and worked. gesture 2: correct but didn't work. gesture 3: might have been a bit too slow. didn't work"

With this log we can know exactly which input events the gesture recognizer received and how it interpreted them.

[Pat McGowan (pat-mcgowan)]

The recognized gestures worked as expected, the rejected ones are indicative of the problem. Tired to swipe with thumb holding the phone in my right hand and keeping as straight a drag as possible

[Daniel d'Andrada (dandrader)]

"It also seems that once it gets in a state where the swipe fails, it continues to fail for a number of attempts."

The gesture recognizer doesn't retain any state between gestures. This perception is likely because subsequent swipes are very similar to previous ones and, therefore, yield similar results.

[Daniel d'Andrada (dandrader)]

Basic findings from looking at the log file:

Failure 1 - finger moved too far downwards before finally making way rightwards. When it did, it was already too late (finger was outside the cone-shaped allowed area)

Failure 2 - initial movement was deemed too slow

Failure 3 - Same as 1

Failure 4 - Same as 1

Failure 5 - Same as 2

[Sam Bull (dreamsorcerer)]

I'm finding that it works reliably if I angle my thumb so I'm only touching with my thumbtip, which is not a natural position when holding the phone. Could it be that resting the thumb along the edge causes the tip to touch first, then as you roll the rest of the phalanx onto the screen it registers that as a downward motion?

[Pat McGowan (pat-mcgowan)]

@sam I think that could be related. Thats why I mention holding with one hand, it causes more of the thumb to touch the screen.

@daniel the swipe is definitely not slow, so the heuristic is somehow concluding that incorrectly. In fact, slowing the swipe improves the acceptance. Maybe we can provide a way to easily change the relevant parameters for some repeated testing.

[Daniel d'Andrada (dandrader)]

@Pat

You can tweak the gesture recognition parameters yourself. On device, edit the following file:

/usr/share/unity8/Launcher/Launcher.qml

You want lines 192 to 195:

        maxDeviation: units.gu(1)
        wideningAngle: 30
        distanceThreshold: units.gu(3)
        minSpeed: units.gu(5)

For dealing with the "big thumb moves the touch point downwards" you will want to increase maxDeviation.
Please play around with those properties and tell me if there's a configuration that works well for you. Ie., one that doesn't reject seemingly correct edge-drags but that does reject taps, vertical drags and overly slow drags.

[Daniel d'Andrada (dandrader)]

By the way, those properties are documented here:
http://bazaar.launchpad.net/~unity-team/unity/8.0/view/head:/plugins/Ubuntu/Gestures/DirectionalDragArea.h#L78

And this diagram helps understanding how they work together:
http://bazaar.launchpad.net/~unity-team/unity/8.0/download/head:/directionaldragarea.-20130605215732-2jnp9kzjan5ybxg8-137/DirectionalDragArea.svg

[Pat McGowan (pat-mcgowan)]

Can you provide logging that prints out which thresholds pass and which fail? I am not finding any combination of parameters that work consistently. I am using "restart ubuntu-touch-session" to restart unity8 each time I change the settings but frankly see no differences in behavior.

[Pat McGowan (pat-mcgowan)]

Ignore previous comment, I see the specific rejection messages now.

Increasing the deviation does help:
values 1-3, gesture is rejected as outside area
4 works half of the time
5 works almost every time but rejections due to speed below minimum start to occur, even with the speed set to units.gu(1)

When the speed below minimum is reported the gesture is not slow, so something else is affecting the calculation.

[Oren Horev (oreneeshy)]

@Daniel d'Andrada @vesar is the designer responsible for edge interactions. Please could you discuss with him this bug and other behaviours that emerge from edge detection improvement.

Thanks,
Oren

[Pat McGowan (pat-mcgowan)]

Looking at the diagram and how max deviation works, the setting of 5 GUs seems to make sense. If the part of my thumb that is touching is up to .5 in wide, 5GUs is 90 pixels either side, 180 total and with Nexus 4 screen at 320 ppi, thats just over .5 in. The initial setting at 1GU would never work which is what we see.

I did not notice any incorrect touches in apps with theses settings.

[Daniel d'Andrada (dandrader)]

Had a chat with Vesa. He will try it out and experiment with it and come back with his findings.

[Vesa Rautiainen (vesar)]

Made some experiments with the launcher's DirectionalDragArea parameters. The component itself seems to be working very well but the parameters for edge gesture detection are somewhat strict at the moment. Also I don't see reasoning for minimum speed limit in edge gesture detection at the moment. My suggestion for the parameters would be:

maxDeviation: units.gu(3)
wideningAngle: 50
distanceThreshold: units.gu(1)
minSpeed: units.gu(0)

We would need to re-evaluate these parameters once we have gesture forwarding/canceling scheme in place.

[PS Jenkins bot (ps-jenkins)]

Fix committed into lp:unity8 at revision 63, scheduled for release in unity8, milestone Unknown

[John Lea (johnlea)]

@dreamsorcerer; hi, please do not change the status of bugs in the "ubuntu-ux" project, as we use this project to track design status and final design QA. For example, changing status from Fix Committed → Fix Released in ubuntu-ux means that a designer has tested the implementation of the bug on the phone and has confirmed that implementation matches the change request.

Full details of what status means for ubuntu-ux bugs is available at https://docs.google.com/a/canonical.com/document/d/1PcNRQZFbfmmQEvxu4SZHO3GZ9Zaetg9p2DOmRwOUbS0/edit#heading=h.yt7pgvf4mg7m

Reverting ubuntu-ux status back to Fix Committed so that designers know that the implementation is ready to test.