Swipeable List Interactions

I really like the ability to swipe list items... However, I'd like a slightly different interaction. Instead of the swipe target coming from the side to cover the list item, I'd like the list item to slide over, revealing the swipe panel (as a series of buttons).

I don't mind trying to get this to work on my own... I've tried listening to the onSwipe and onSwipeDrag events without any luck (they don't seem to be firing). Really, I was curious if this behavior is something that belongs with the core swipe code, or if I should create a new "kind" that adds this behavior. My problem with a new kind is that it seems like there could be conflicts with the core swipeable items...

Thanks for responding to me - it's nice to see a helpful community (or at least a helpful guy)

Comments

  • This behavior is pretty hard-coded in the List.js code... your best bet would be to try to trace how the swipe DOM node is created and animated by the mouse move events and make your own enyo.List variation with your custom behavior.
  • FWIW, I can vaguely imagine uses for the current swipe behavior, but they seem like obscure uses. Swipe-to-delete would be useful in many more cases, but implementing it using the existing swipe functionality seems unnatural and unintuitive.
  • I'm not sure what the big difference is between swiping controls in from the side and pulling the item away. The current implementation allows pulling in different controls depending on the direction of the swipe, an internal requirement we had when implementing it.
  • Certainly the framework should allow a swipe-to-the-left to do something different than a swipe-to-the-right (Though it may be a while before users are ready to take advantage of that).

    The problem with the current UI is the user is not dragging the element his finger is on, but instead dragging a element with no visual connection to the location the user is touching.

    Luke Wroblinski's guide to gestures isn't normative, but is a good attempt to capture current implementations, and thus something like user expectations:
    static.lukew.com/TouchGesturGuide.pdf
  • I agree - the swipe model works best when acting on the item on screen. Finger should be dragging the visible thing, not pulling on empty space to bring it into view. Particularly for delete because you are 'throwing it away'.

    There are similar odd interactions with Panels as well - ex. the Sliding app example. You can drag on a fixed first panel, and have it "pull" the second one over - odd. Or you can drag on the second panel directly, but at some point its fully collapsed, and with continued dragging you start moving the third panel instead, which is not under your finger.

  • I completely agree with @ericmartineau @reeder29 and @rwatkins. The current implementation is somewhat unintuitive. It would be great if you could tell the list how to do the swipe action. I can imagine three different scenarios:

    1. The current implementation: The swipeable item slides over the current item.
    2. As described by Eric and the others: The current item slides away and reveals the 'swipeable components' underneath. I think this is the most common behaviour and what most users will expect.
    3. The current item is 'pushed away' by the swipeable components, i.e. The current item slides out, the swipeable components slide in.

    Options 2 and 3 would allow setting up different controls depending on the index and swiping direction, too, so I don't really get @unwiredben's point here.

    It would be amazing if we could have at least two of the options above built into the List kind. Additionally, an option for providing your own 'swiping function' would be great. I can imagine a couple of pretty cool effects you could build with that.

    I'll probably go ahead and implement this functionality by myself, but I'm wondering what the best course is here. Should I create a new kind or make adjustments to the current List kind? Is this something that might find it's way into the List kind via a pull request?

    There is some other odd things I noticed:

    1. The List kind resets the 'persistSwipeableItem' property after each completed swipe. I always thought published properties were something that the user should have control over and that should not be changed by the kind internally. It took me quite a while to realize why my swipeable items did not persist until I checked out this sample.

    Here is how I tried to do it. Something like this is actually supposed to work, right?
    components: [
        {kind: "List", persistSwipeableItem: true, ...} // This doesn't work!
    ]
    2. The swipe and swipeDrag events are never fired. What's up with that?
  • edited September 2013
    I think persistSwipeableItem is more of a temporary flag -- you set it in the handler to indicate that this will persist. However, I didn't design this API, and found it very complex when I was fixing bugs on it before the 2.2 release.

    There are a lot of bugs here still. We've done almost nothing to List since 2.2 since our main internal use case for this new functionality went away. I'd welcome assistance in fixing problems and intelligently redesigning parts of the API.
  • Well I've never seen a published property being used as a temporary flag before and it seems to me that this is not what they were designed for in the first place. Please correct me if I'm wrong. Looking at the source code, the implementation of the swipeable components seems overly complicated to me and I think refactoring this would basically mean rewriting it completely. I'll probably take a shot at it anyway.
  • No, it's not my favorite design. I'd rather there by a public method to set that instead of a property.
Sign In or Register to comment.