This is an important subject, I've been meaning to write this for a couple of 
weeks, but Richard got here first.

our current app.

(if anyone is interested I can send you the git repo link off line…it is 
public;  I just don't want to post It public)

use click and swipe "everywhere"

the model is simple: group of rows (smaller groups) whole "portal" group is 
scrollable

each row is a "hyper link" to 
a) a dynamic rebuild of the card with differernt rows
b) open another *module.livecode binary stack
c) open a stack that has a browser widget on it the URL to view pass to it 
dynamically.

Seeims simple enough, works great on desk top… so much promise for a highly 
scalable modular app. 

 but are are getting major failures on mobile and I have been wrestling for 
weeks with the the simple problem of just opening and closing stacks without 
crashing or render issuea (mostly on Android) and performance (super slow on 
some android devices) Once any given stack is actually opened and rendering 
correctly, it works great.  

Anyway, the need to respond to a touch/aka/mouseup  OR swipe the group up and 
down.

That's the tricky bit

Currently we are (pseudo code)

 using locals to get the tStartLoc on mousedown and using

if the  abs(the endloc) > 10  # assume swipe
else
assume tap: fire the hyper link

I'm having issue with this. can't quite figure out why, but I have to tap twice 
to fire the touch event… could be the code needs top be optimized there.  and 
standard mouse/widget/icon/image with just a mouseup alone, fires instantly.

This is not exactly focusing on the card metaphor… but the issues are the same. 
(I think)  Because you might want to trap the touch on a card and not actually 
swipe left or right, group up/down/sideways


Suffice it so say we do need improvements here.  I have a lot of design 
requirements that would use this algorithm

all modern apps do this… verycommon now to load (sometimes over load IMHO) a 
single interface with scrolling groups going sideways… all of which are 
basically create a giant TOC/Index to dive into some other screen/list/listen 
to music (Spotify is a very good model)


" While apps are generally built in
    a hierarchical fashion, there are instances where
    horizontal navigation can flatten vertical hierarchies
    and make access to related data items faster and more
    enjoyable."


Anyone else doing the 

touch or swipe  thing?  on a scrolling group/card can you share your code 
methods for this?  I would like to test and improve what we have if possible.



BR



 

On 4/26/17, 8:50 AM, "use-livecode on behalf of Richard Gaskin via 
use-livecode" <use-livecode-boun...@lists.runrev.com on behalf of 
use-livecode@lists.runrev.com> wrote:

    Mike Kerner wrote:
    
    > So you'd like a swipe event instead of using nav buttons.
    
    Button where appropriate, swiping where appropriate.
    
    
    iOS:
        Use touch gestures to create fluidity. Make it easy to move
        through your interface with minimum friction. For example,
        you could let people swipe from the side of the screen to
        return to the previous screen.
    
<https://developer.apple.com/ios/human-interface-guidelines/interaction/navigation/>
    
    
    Android:
        Efficient navigation is one of the cornerstones of a
        well-designed app. While apps are generally built in
        a hierarchical fashion, there are instances where
        horizontal navigation can flatten vertical hierarchies
        and make access to related data items faster and more
        enjoyable. Swipe views allow the user to efficiently
        move from item to item using a simple gesture and
        thereby make browsing and consuming data a more
        fluent experience.
    <https://developer.android.com/design/patterns/swipe-views.html>

_______________________________________________
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Reply via email to