Re: Telco result, resolution

Hi everyone,

Further to my point about needing to defining path-based gestures, I’ve been compiling different examples and their attributes in this spreadsheet:
https://docs.google.com/spreadsheets/d/1NGxqbwbcaG8dwSs5H2eTRy0gDELTdSuAi1ad0le4fDU/edit?usp=sharing


And video examples in this folder:
https://1drv.ms/u/s!AqcLQeCk6CjwiJpy0DUfE49R2LPiYg?e=mRI6w8


The IDs from the spreadsheet map to the videos.

One thing this exercise taught me was how few ‘gesture’ interactions do actually lock down the direction, undermining my previous approach. Things like Mail.app/Gmail gestures do NOT restrict the direction after the start of the movement, making it difficult to differentiate from (open) sliders.

In summary: It is really hard to see how to reasonably scope-out drag and drop (which we’ve agreed) without also scoping out sliders (and sortable lists).

The closest I can see is:
A path-based gesture is an interaction where the user:

  *   Engages a pointer with a defined starting point in the content (down event),
  *   carries out a directional movement or movements before disengaging the pointer (up event),
  *   where the end point is separate from the starting point and not a pre-defined area.


I’m not happy with the last bullet, but I can’t think of another way of putting it. The “separate” bit is to prevent people interpreting that as scoping-out strict sliders where you have to release at a particular point.

An alternative would be a last bullet of something like:

  *   where the end point does not define a value.

That would scope out sliders, drag & drop, sortable lists, and possibly multi-value gestures.

Given the attributes identified in the spreadsheet, can anyone see another option?

-Alastair