UIs w/ swipe event order

vining

It seems that the newer panels that allow swiping often trigger the level event before the push so if you have a bargraph and you use the channel on that bar graph to qualify the level event it will often fail, more often than not.

Normal sequence for older panels and sometimes on newer. I'm testing with a MXT-1000 but I believe I've noticed this on the 9000i but less frequently.

Line      2 (09:03:00)::  SBS AXI DEBUG: UI INDX-[ 6 ], SBS-[ 1 ], PUSH CHNL-[ 100 ] :DEBUG <532>
Line      3 (09:03:00)::  SBS AXI DEBUG: UI INDX-[ 6 ], SBS-[ 1 ], LEVEL CHNL-[ 6 ], VALUE-[ 58 ] :DEBUG <655>
Line      4 (09:03:00)::  SBS MOD-[ 1 ] DEBUG:[L-1], RX LEVEL FOR SCROLL, nSBS_BScroll-[ 6 ], VALUE-[ 58 ] :DEBUG<7728>
Line      5 (09:03:00)::  SBS AXI DEBUG: UI INDX-[ 6 ], SBS-[ 1 ], RELEASE CHNL-[ 100 ] :DEBUG <617>

This is what usually occurs on the newer panels:

Line     33 (09:03:29)::  SBS AXI DEBUG: UI INDX-[ 6 ], SBS-[ 1 ], LEVEL CHNL-[ 6 ], ERR! NO PUSH :DEBUG <659>
Line     34 (09:03:29)::  SBS AXI DEBUG: UI INDX-[ 6 ], SBS-[ 1 ], PUSH CHNL-[ 100 ] :DEBUG <532>
Line     35 (09:03:29)::  SBS AXI DEBUG: UI INDX-[ 6 ], SBS-[ 1 ], RELEASE CHNL-[ 100 ] :DEBUG <617>

The level comes in first so it doesn't work since I require the push to set a virtual channel to on, off in the release.

Fortunately my code also uses an integer array for all the device's UIs to determine when they are actively on that device page and which instance of the device they are on. The UI index in the array is set to 0 when the a UI goes offline and online so I can change the qualification to that. Offline or not onpage then it can't be a valid level event. FYI, my panels flip to the main page when they come online not back to the page they were last on which sucks with iPads using TPC but...

I also notice that on the MXT demo that swipes also result in pushes way to often and I suppose that on an iPad surfing the internet it's not big deal to open a link and then hit the back button cuz that move wasn't intended but on a control system UI there's allot more at risk. systems turn on or off, vol levels change, missles are launched. Not really an ideal situation for an AMX touch panel.

I've only started to play with the X panel but I would think if they want to allow swiping we should be able to limit it to certain areas and we can then highlight those areas to indicate that swiping is permissable. Maybe that's already done but if not it should be implimented. Then I can disable this functinality completely until it's ready for prime time or I ready to give it a try. It ain't there yet and neither am I.

yuri

I think swiping on the Modero X panels isn't allowed on a button.
So, just make a big (transparant) button for the area you don't want a user to swipe

vining

If that were the case then how would you scroll up and down lists? It would be counter intuitive if you had to go outside the list area to scroll and every list entry is a button used for selecting.

John Nagy

While I don't yet have one to play with, I see in TPDesign that gestures remain discrete codes. That means, they can't give different push codes contextually.

Gestures are detected by a touch that moves in a direction soon enough and fast enough that they must not be a push.

So no, you probably can't block a gesture with a button.

If you want to scroll a list with a gesture aw well as doing other things at other times with a gesture, you'll need to set up your own context system to know what the same gesture push means at the moment. Like if the list is exposed, the gesture is used only for it until closed. Or some means of setting a focus so you can derive the meaning of the moment.

The worst part is that discrimination between gestures and touches is still weak. The system waits on a touch to see if it is moving before it takes the push of any button. This slows the perceived responses to all ordinary pushes. And unless the swipe is the right and constant speed and not at all diagonal, you'll not get the gesture and you might get a push on an underlying button. Hence designs with "racetrack" areas where the only possible result is gesture or nothing. Clearly they haven't caught up with the dynamics of gestures like Apple and Android. And to keep compatibility, TPControl uses AMX's gesture rules instead of the superior ones in the pad. Maybe that will change.

I'd love to see buttons with local gesture rules. So if you open a panel area (a gesture button), gestures within it would have specific meaning. You could make each page have a contextual meaning, all in the button. And different meanings (or none!) on other parts of pages.

DHawthorne

I've played with the swiping on a 9000 a bit and found it useless. PUSH and RELEASE events are processed before the swipe, which is completely counter to how everyone is used to swipes on an iOS device ... which is the defacto standard. Any time movement is detected, it should be interpreted as a swipe (which does cause its own issues, but that is what people are used to), not a push or release. It does no good if we are expecting a swipe, and the page flips or the button is processed because the push went through first.

Auser

DHawthorne wrote: »

I've played with the swiping on a 9000 a bit and found it useless. PUSH and RELEASE events are processed before the swipe, which is completely counter to how everyone is used to swipes on an iOS device ... which is the defacto standard. Any time movement is detected, it should be interpreted as a swipe (which does cause its own issues, but that is what people are used to), not a push or release. It does no good if we are expecting a swipe, and the page flips or the button is processed because the push went through first.

This is still a problem in the X series, even in the setup pages.

vining

DHawthorne wrote: »

I've played with the swiping on a 9000 a bit and found it useless. PUSH and RELEASE events are processed before the swipe, which is completely counter to how everyone is used to swipes on an iOS device ... which is the defacto standard. Any time movement is detected, it should be interpreted as a swipe (which does cause its own issues, but that is what people are used to), not a push or release. It does no good if we are expecting a swipe, and the page flips or the button is processed because the push went through first.

Then why is there that annoying delay with the push event if not to allow time to evaluate if a swipe is occuring and to then send out a swipe event in lieu of a push event.

To get back to my original issue, if they're going to delay the push so they can evaluate if a swipe or double tap is the actionable event then they should also delay the level event too and maintain the order we've come to expect. Keep the proper order and delay everything in order. Personally i still want the ability to disable the delay required for swiping especially since i don't want swiping, maybe someday but not now. Now i just want an immediate push to occur and then the level if the button does both.

jjames

Here's what the 9000i manual has to say about this . . . I would assume that all other panels that support gestures work in the same manner, but I've seen crazier things.

vining

According to the table a slider should have no delay so what accounts for the push event lagging behind the level event most of the time?

I think this is more how they want the TPs to react and evaluate different touches but not necassarrily how it actually behaves or what we can expect to see until the bugs are worked out.

DHawthorne

The logic in that chart looks sound, but in practice it doesn't seem to work as stated.

In my experiment, I had a group of text buttons on a media server that displayed track selections, and had an up/down button to scroll through choices ... common enough scenario. Pressing a button selected he track and flipped to the Now Playing page. I enabled gestures and set a top-bottom swipe to send the down button channel event, and vice versa for bottom-top. Unless the gesture started on a blank part of the page, whatever button the gesture started on acted as though it was pressed, the selection made, and the page flipped. Either the delay was not present, or it was not long enough, or something else got in the way of prioritizing it properly, but I could not consistently get the gesture to work unless I left a lot of empty space on the page to make the gesture in. I suspect the .15 sec delay is simply not enough for the hardware itself to register the activity.

Not that I want to increase the delay ... that would cause other issues. I came to the conclusion the best way around it would be to move all my events off the push and on to the release, but that would not deal with any page flips done in the button itself ... which I try not to do anyway, but it can't always be easily avoided. SO what I really settled on was just abandoning the gestures. I only had one panel out of a half dozen on the job that supported it anyway, so it was probably as well.

PHSJason

What about using a background image on your pop-up page with a gesture/scrolling area? In this area, there would be no buttons, so actions here would always be gestures.

DHawthorne

PHSJason wrote: »

What about using a background image on your pop-up page with a gesture/scrolling area? In this area, there would be no buttons, so actions here would always be gestures.

My projects typically have more than one panel type, and I want them to look as much the same as possible, so though that may be workable, I wouldn't want to do it that way, as the non-swipable panels would then need to have that space too to be consistent. And frankly, I can think of a number of workarounds to make them useable ... my beef is that they either don't work as advertised, or they don't work as people expect in a world where almost everyone has an iOS device they are used to. I think they have to work exactly like iOS gestures do, or we are just causing confusion. Apple beat everyone to the punch, so we all have to play by their rules now.