Sustained or iterated actions. (I.E.: Paging)

[santiagojrodriguez]

Hi all! I confess this is more a logical question than a coding issue. I’m stuck with a little problem and I’m hoping maybe you guys can point me in the right direction.

I’m developing a game based on an ordered list of items (if you’ve played the boardgame “Timeline”, it’s essentially the same idea). I have a table variable in memory than can grown as the player adds items to it. On the screen I have 5 image objects that display the items, and a left and right arrow to “page” the list backwards or forwards. When one of the arrows is tapped, I increase or decrease a variable that points to the “current center” of the list an re-draw the 5 images accordingly.

One of my testers that reviewed the app mentioned this situation: if you built a long list, and you’re near one end of the list and get an item that should be put near the other end, it’s tiresome to tap a lot of times until you get to the desired spot (“awful UX” were the cruel but honest words).

I’ve tried to fix this issue with two different approachs:

• Implement a Swipe movement that allows a quicker navigation of the list.
• Implement a " Tap and Hold" functionality, so the list keeps on paging forwards or backwards while you mantain your finger down the arrow.

Of course, I’m writing this because I’ve failed miserably with both 

With the Swipe approach I couldn’t establish a smooth paging, and with the other approach I wasn’t even able to implement it (the paging action only ocurred once).

I could give you more details and post some code of what I’m trying, but before that I was interested in a more general advice. Which of the two do you think is more suitable for what I’m aiming to? Do you know by chance any sample that implements a similar situation?

Thanks in advance, as always!

Santiago

[nick_sherman]

Another option is to have the list wrap…once you go past the end it starts displaying from item 1 again…

[davebollinger]

if you have to do it via buttons, perhaps at least give them both “>” and “>>” -type buttons? (where “>>” would skip a whole screen of cards, or 10 cards, or to the end - or maybe a third “>|” button?)

otherwise, i think most ppl would expect swipe/flick, a la widget scrollview.  problem with scrollview may be that it doesn’t support detents by default, so if you need it to “land on” a card exactly then you’d have to modify, fe:

-- forward declare so can ref it in the listener (due to e.target problem) local scrollview -- say your "cards" are 100 pixels wide.. local quantX = 100 local function scrollviewListener(e) --local target = e.target -- would rather do this, but may fail, so.. local target = scrollview local vel = target:getVelocity() if (e.phase=="ended" and vel==0) or (e.phase=="stopped") then -- current local cx,cy = target:getContentPosition() -- quantized local qx = target.x + math.floor((cx+quantX-target.x)/quantX) \* quantX + quantX/2 -- revised target:scrollToPosition({x=qx}) end end -- no "local" here scrollview = widget.newScrollView({ listener = scrollviewListener, -- etc, not important here })

that is only very rough pseudo-code, you’d almost certainly have to customize the quantize calc based on how you have things positioned within the scrollview (plus no guarantee i didn’t typo something ottomh).

[santiagojrodriguez]

Hey guys, thanks for your answers.

@Nick: Sadly I can’t wrap the list because it represents a timeline, so it would be confusing.

@Dave: The scrollView widget looks like a good solution, I’ll give it a try. 

Regards.

[nick_sherman]

Another option is to have the list wrap…once you go past the end it starts displaying from item 1 again…

[davebollinger]

if you have to do it via buttons, perhaps at least give them both “>” and “>>” -type buttons? (where “>>” would skip a whole screen of cards, or 10 cards, or to the end - or maybe a third “>|” button?)

otherwise, i think most ppl would expect swipe/flick, a la widget scrollview.  problem with scrollview may be that it doesn’t support detents by default, so if you need it to “land on” a card exactly then you’d have to modify, fe:

-- forward declare so can ref it in the listener (due to e.target problem) local scrollview -- say your "cards" are 100 pixels wide.. local quantX = 100 local function scrollviewListener(e) --local target = e.target -- would rather do this, but may fail, so.. local target = scrollview local vel = target:getVelocity() if (e.phase=="ended" and vel==0) or (e.phase=="stopped") then -- current local cx,cy = target:getContentPosition() -- quantized local qx = target.x + math.floor((cx+quantX-target.x)/quantX) \* quantX + quantX/2 -- revised target:scrollToPosition({x=qx}) end end -- no "local" here scrollview = widget.newScrollView({ listener = scrollviewListener, -- etc, not important here })

that is only very rough pseudo-code, you’d almost certainly have to customize the quantize calc based on how you have things positioned within the scrollview (plus no guarantee i didn’t typo something ottomh).

[santiagojrodriguez]

Hey guys, thanks for your answers.

@Nick: Sadly I can’t wrap the list because it represents a timeline, so it would be confusing.

@Dave: The scrollView widget looks like a good solution, I’ll give it a try. 

Regards.