Swipe Gesture Angle

[polarathene]

I was working with Swipe Gesture for navigation but wanted to limit the angle more then default value, it was a const unlike slop, I had to edit code to support this, maybe would be useful to others to have control over swipe angle?

private static var ANGLE:Number = 40 * GestureUtils.DEGREES_TO_RADIANS;
public function get angle():Number
{
    return ANGLE;
}
public function set angle(value:Number):void
{
    ANGLE = value * GestureUtils.DEGREES_TO_RADIANS;
}

[fljot]

Yea, I guess I could add it as a configuration property.. But anyway, why the default value didn't work for you? Swipe gesture is the most tricky one to set up actually) you see how much conditions there (I was fine-tuning it for quite some time).

[polarathene]

I just needed to implement swiping left/right to navigate screens/pages in the app. Gestouch was a quick solution, the app is mostly vertical scrolled paragraphs, I did not want a vertical swipe with a slant that crossed into horizontal swipe area to trigger the navigation. Reducing the angle seemed like a good way to solve the issue.

If I have horizontal scrolling UI this might still be a problem, I use feathers UI and it handles touch for scrolling natively, I'm not sure how I would decide if the user is swiping over the UI component for scrolling or to navigate to the next screen. I imagine you could differentiate the two from velocity & distance with longer faster swipes being a navigation swipe. Alternatively swiping with two fingers works but is not as comfortable of a movement horizontally, there was also some difficulty detecting two fingers if they were close together sometimes when tested.

Thankyou for the gesture library :)

[fljot]

So you mean some vertical movements were somehow interpreted as horizontal swipes?

But anyway, will tell you immideately — look at the iOS platform (CocoaTouch framework to be specific I guess). All the input thing is solid single system. Gestures have this default behavior when once one is recognized — the others (which are also being processed in the same display list hierarchy) will normally fail, or there will be some other custom conflict resolution (using protected methods and "delagates"(iOS) or callbacks (in my implementation)). So normally you shouldn't have all that headache "whati if.. compare velocity.. " etc. If vertical scroll started — horizontal swipe is aborted. This is a problem of young, sometimes simply lame and inconsistent frameworks on the Flash Platform.

[polarathene]

Oh no the 2nd part I was talking about a horizontal swipe gesture to navigate, or just horizontal swipe for scrolling horizontal UI component. Similar gestures for both, if the UI component takes a large amount of screen space then if it's interaction cancel out navigation swipe or a navigation swipe were triggered accidentally when the user intended to scroll horizontally...it is a conflict?

Vertical movements I don't think were interpreted as horizontal swipes, just a touch from the top swiping down could be recognized as horizontal if the swipe direction angle was in the 40 degree zone for horizontal. Looking for a longer swipe might have been another solution, less likely to swipe with a vertical intention at that angle, a lazy flick gesture could trigger navigation. It might just be that I'm not using your library correctly.

I tried to make a datagrid component with Feathers UI, I wanted to be able to pan all directions on touch/drag, which I got working with PanGesture, but I lost ability to have the effect of momentum. A Feathers UI list component normally will continue moving in angle/direction you let go for a bit. I think I can implement this but need to know the angle/velocity of the gesture, I can't base it off the starting point as you could pan around different directions at different speed until you release touch.

[fljot]

Oh I there's no point to think about techincal solution for the first thing — it's bad interaction design (or UX). If you you have the whole thing pannable horizontally + horizontal swipe for navigation (which is even not a good idea on it's own!) — it's impossible to distinguish them properly in this specified context. So this is a bad solution by design.

If you would have some sort of slider control in there — it would be okay, because it's relatively small, and pan gesture would normally be triggered first (upon first movement).

Buy vertical scrolling and horizontal swipe are quite possible. Again, normally vertical scrolling should be implemented using pan gesture, and, as it would be recognized first, it would abort horizontal swipe.

I have done touch scrolling physics model for that momentum scrolling a while ago. https://github.com/fljot/TouchScrolling/blob/features/decoupled-architecture/src/com/inreflected/ui/touchScroll/TouchScrollModel.as best physics I've seen open-source ;) might be some bugs due to last architecture transition, would be great to check that.

[polarathene]

The app had navigation buttons (prev/next) and a menu that were positioned in a nav bar above content. Client insisted remove nav buttons and introduce swipe navigation, any horizontal component was changed to vertical to work around the conflict. It's mostly a digital text manual with some videos and activity screens in between.

I'll look into the TouchScrollModel for a personal project, see if I can get it controlling my FeathersUI datagrid component, thanks! :)

[fljot]

I'd offer this model for Feathers once it's actually tested by someone.. because physics itself is totally better (momentum thing is, I guess, the same as Apple have — natural decay formulas and everything). All others I have seen — they're just "meh, it should slow down I guess".