Swipe left - right on the top side of the frame to change zoom?

[manuq]

This is more a question, do we want this behaviour? I have coded it so we can test. Patch attached.

[manuq]

Patch.

[garycmartin]

For the Sugar zoom views (Neighbourhood, Group and Home), both a horizontal swipe or pinch zoom in/out gesture anywhere on the display would work well for moving between them. Ideally we would have a hardware accelerated zoom transition (with a slight left/right motion if a horizontal swipe is being used) but hardware support didn't get there in time to investigate (apparently os28 now has gfx hardware supported to some extent). The Activity zoom view level is more tricky and should probably be left out of the swipe navigation as the activity should have ownership of the canvas swipes, and swiping into the current Activity would be a dead end (the user could not swipe back out to the home view unfortunately)

On the mail list it was raised to use screen edge swipes for activity switching, but we had blocker bugs last time we tested edge swipes (for raising the Frame) over some Activities (bad behaviours and at least one crash bug).

Can we _reliably_ catch two finger swipes? I'm not convinced this would solve the issue either, it's not discoverable and still probably too easy to accidentally trigger if we used it globally to switch between all zoom views/activities.

[sridhar]

Thanks for your input, Manuel and Gary.

For OLPC Australia and One Education deployments, user experience is key. My idea is to reserve the toolbar area for Sugar platform level gestures. We can alternatively use the frame for this, but that adds the extra step of revealing the frame first.

A lot of users struggle with the zooming UI concept, particularly at the beginning. A pinch accompanied by a zoom transition would go a huge way towards alleviating this and building familiarity with Sugar. Preferably the transition would be hardware accelerated, but maybe there's something simpler we can use in the interim?

I don't see a big problem in using gestures to zoom out of the activity, unless we have a good reason for the activity to have gesture (not just tap) control on its toolbars. My belief is that consistency is more important: if you can zoom into an activity by using gestures, you should be able to get out of it in the same way.

Discoverability is an issue, but we have the same problem with other touch actions like long-press/hover. I've even witnessed a lot of users struggling with a right-click.

[sridhar]

Downstream issue: ​https://sugardextrose.org/issues/3030

[erikos]

Views: add a gesture handler that let's you swipe through the views

[erikos]

As Gary pointed out, the gesture should be available in all the view, not only in the upper 'toolbar area'. The patch above does add a gesture handler that does so.

[erikos]

Replying to erikos:

As Gary pointed out, the gesture should be available in all the view, not only in the upper 'toolbar area'. The patch above does add a gesture handler that does so.

The patch has an issue in that it consumes the touch events. Test with Paint for example. You can not draw with the finger anymore.

[sridhar]

Replying to erikos:

As Gary pointed out, the gesture should be available in all the view, not only in the upper 'toolbar area'. The patch above does add a gesture handler that does so.

Understood; that sounds like a good idea. As Gary has pointed out, that does mean that Sugar Shell gestures shouldn't work when inside an activity (leaving the activity to implement its own touch events). On further consideration, I think that's fine for our users.

[erikos]

Replying to sridhar:

Replying to erikos:

As Gary pointed out, the gesture should be available in all the view, not only in the upper 'toolbar area'. The patch above does add a gesture handler that does so.

Understood; that sounds like a good idea. As Gary has pointed out, that does mean that Sugar Shell gestures shouldn't work when inside an activity (leaving the activity to implement its own touch events). On further consideration, I think that's fine for our users.

You need to get out of the activity view as well. The activity view is just another zoom level. Currently the patch would display the current focused activity when swiping to the activity view.

I think Gary meant the case where you switch from one open activity to another open activity (what you would normally do with tab). Handling those two cases cleanly (a) switching the zoom levels and (b) switching between open activities gets even more tricky.

From the technical point of view, the current patch is a global gesture handler. It will listen for all the gestures and change the zoom level accordingly (a). This works fine in activities like Memorize but in Paint, some events do not get through and drawing is laggy. We came across this when implementing #3981 already. We should check the root cause of that issue.

[erikos]

To add some more information, here is what iOS is doing:

(a) you can use a one finger swipe to go through the list of available apps and to get to the search page (inside the Home Screen), you can use a four finger upwards swipe to get to the list of currently 'open' apps (resume) and you can use a four finger zoom to get into the Home Screen from an App

(b) switching between open apps: you can use a four finger horizontal swipe to move from App to App

[garycmartin]

Replying to erikos:

To add some more information, here is what iOS is doing:

(a) you can use a one finger swipe to go through the list of available apps and to get to the search page (inside the Home Screen), you can use a four finger upwards swipe to get to the list of currently 'open' apps (resume) and you can use a four finger zoom to get into the Home Screen from an App

(b) switching between open apps: you can use a four finger horizontal swipe to move from App to App

Also note that under Android there is no support for switching between apps via touch swipe gestures. They implement switching via the system bar using the 'Recent Apps' button that pops up a list of recent app thumbnails. There are some 3rd party apps you can install, though comments suggest they shorten battery life.

[manuq]

Adds swipe gesture in the zoom views (Neighborhood, Group, and Home)

[manuq]

Use zoom gesture for switching zoom views (Neighborhood, Group, Home)

[manuq]

The previous two patches add gestures in the three zoom views, not interfering with activities. The first adds swipe gesture, the other adds zoom gesture.

I can see two issues with them:

• As Gary expected, when the zoom goes to Activity level, the user reaches a dead end.
• There are accidental presses while doing the gesture: activities can be started in home favs view, scroll takes precedence in home list view, palettes can be raised by accident.

[erikos]

Replying to manuq:

The previous two patches add gestures in the three zoom views, not interfering with activities. The first adds swipe gesture, the other adds zoom gesture.

I can see two issues with them:

• As Gary expected, when the zoom goes to Activity level, the user reaches a dead end.

If it is a global gesture it would not, see your first patch, you can cycle in and out of the ZOOM_ACTIVITY level.

In your patch you are including the Activity View:

_ZOOM_LEVELS = [ZOOM_MESH, ZOOM_GROUP, ZOOM_HOME, ZOOM_ACTIVITY] 

If you take 'ZOOM_ACTIVITY' out you can just cycle through the other views.

• There are accidental presses while doing the gesture: activities can be started in home favs view, scroll takes precedence in home list view, palettes can be raised by accident.

Right, especially with the zoom gesture. I say, this is an issue of the code. There could be fine tuning to make that better to nearly perfect. Not too easy I am sure. Easier if you use a multi-finger gesture of course (e.g. two finger swipe).

[dnarvaez]

Doesn't seem to have landed. Manuel, what's the plan?

[manuq]

Replying to dnarvaez:

Doesn't seem to have landed. Manuel, what's the plan?

Many objections to continue. So, closing it.

[dnarvaez]

Milestone 1.0 deleted