Difference between revisions of "Swipe UI"

From WebOS-Ports
Jump to navigation Jump to search
(Expanded and added scenario)
(Expanded and improved scenario)
Line 1: Line 1:
webOS has a rich repertoire of gestures.
+
webOS has a rich repertoire of gestures, but they are not always used consistently.
One that has entered the mainstream is swiping left or right on a list item.
+
In a Messaging thread, tapping on a message pops up a menu for forwarding or copying the text.
 +
In Email, tapping on a message opens a full display of the message.
 +
 
 +
A gesture that has entered the mainstream is swiping left or right on a list item.
 
In webOS, swiping either way deletes an item, by convention.
 
In webOS, swiping either way deletes an item, by convention.
  
Line 10: Line 13:
 
This allows the user to rapidly process items, and see what has been done with items.
 
This allows the user to rapidly process items, and see what has been done with items.
  
If there is more than one "close" action, swiping left would overlay the item with a set of buttons.
+
If there is more than one "dismiss" action, swiping left would overlay the item with a set of buttons.
Likewise for "open" actions and swiping right.
+
Likewise for "adopt" actions and swiping right.
 
Users should always be able to recover from a mis-entered gesture, so some cases will have a single "confirm" button.
 
Users should always be able to recover from a mis-entered gesture, so some cases will have a single "confirm" button.
Actions such as "archive" that can be recovered from by some other mechanism wouldn't need this confirmation button.
+
Actions such as "archive" (dismiss) or "favorite" (adopt) that can be recovered from by some other mechanism wouldn't need this confirmation button.
 +
The swiped-in buttons could be swiped out to abort.
  
 
Scenario:
 
Scenario:
User reviews his/her email inbox list, taps on an email in the list to read it in full, then in the full message display taps "Reply" to respond with "Yes, let's do this".
+
A text message appears in a dashboard.  User reads message, then swipes right and taps "Reply" to respond with "Yes, let's do this".
Back in the inbox, he/she swipes right and taps "Create to-do" to add an item in the Tasks app.
+
In the dashboard, he/she swipes right and taps "Create to-do" to add an item in the Tasks app with the message text.
Back in the inbox, he/she swipes left to archive the message, as it has now been dealt with.
+
Finally, in the dashboard, he/she swipes left to dismiss the message, as it has now been dealt with.
  
 
+
Enyo 2 supports separate left & right swipes natively; see [http://enyojs.com/sampler/latest/lib/layout/list/samples/ListLanguagesSample.html ListLanguagesSample]
Enyo 2 supports separate left & right swipes natively; see http://enyojs.com/sampler/latest/lib/layout/list/samples/ListLanguagesSample.html  
+
(although that sample is confusing)  Swipe-in buttons can be seen in [http://searchablenotes.hominidsoftware.com/ Serene Notes]
(although that sample is confusing)  Swipe-in buttons can be seen at http://searchablenotes.hominidsoftware.com/
 
 
Note that Enyo 2 Lists swipe in "on top" of the item, allowing the item to be seen through a scrim,
 
Note that Enyo 2 Lists swipe in "on top" of the item, allowing the item to be seen through a scrim,
 
rather than swiping the item out of the viewport and "revealing" controls beneath, as in Enyo 1 and Mojo.
 
rather than swiping the item out of the viewport and "revealing" controls beneath, as in Enyo 1 and Mojo.
 +
 +
The key advantages for users are
 +
* consistent interactions: tap to open, swipe left to dismiss, swipe right to adopt.
 +
* acceleration of common actions
 +
 +
In Contacts, one could "favorite" people from the list view or set a Reminder. 
 +
These don't get synced to back ends, and so should not be mutated in the Edit pane like conventional fields.
 +
 +
The Messaging app doesn't have a concept of "opening" a message, so tapping displays a popup menu.
 +
Here, we'd probably have tap do the same as right swipe: slide in buttons to reply or copy the text.
 +
 +
In Email, the "adopt" actions would be the same as the bottom toolbar in the full display pane.
 +
Here, we get a little acceleration and consistency with other apps.

Revision as of 23:20, 26 February 2015

webOS has a rich repertoire of gestures, but they are not always used consistently. In a Messaging thread, tapping on a message pops up a menu for forwarding or copying the text. In Email, tapping on a message opens a full display of the message.

A gesture that has entered the mainstream is swiping left or right on a list item. In webOS, swiping either way deletes an item, by convention.

It is proposed that we refine this to distinguish between left and right swipes. Left swipes would "dismiss" (delete, archive, close) the item. Depending on context, the item might be removed from the list, moved to the bottom of the list, or greyed-out. Right swipes would "adopt" (create a bookmark or favorite, reply to a message, create a message from, create a Task from, or otherwise "do more with") the item. Favorites might be marked with a star, replied-to messages might have an icon, and items that tasks or messages have been created from might have a different icon. ("opening" an item for full display or editing would still use a single tap.) This allows the user to rapidly process items, and see what has been done with items.

If there is more than one "dismiss" action, swiping left would overlay the item with a set of buttons. Likewise for "adopt" actions and swiping right. Users should always be able to recover from a mis-entered gesture, so some cases will have a single "confirm" button. Actions such as "archive" (dismiss) or "favorite" (adopt) that can be recovered from by some other mechanism wouldn't need this confirmation button. The swiped-in buttons could be swiped out to abort.

Scenario: A text message appears in a dashboard. User reads message, then swipes right and taps "Reply" to respond with "Yes, let's do this". In the dashboard, he/she swipes right and taps "Create to-do" to add an item in the Tasks app with the message text. Finally, in the dashboard, he/she swipes left to dismiss the message, as it has now been dealt with.

Enyo 2 supports separate left & right swipes natively; see ListLanguagesSample (although that sample is confusing) Swipe-in buttons can be seen in Serene Notes Note that Enyo 2 Lists swipe in "on top" of the item, allowing the item to be seen through a scrim, rather than swiping the item out of the viewport and "revealing" controls beneath, as in Enyo 1 and Mojo.

The key advantages for users are

  • consistent interactions: tap to open, swipe left to dismiss, swipe right to adopt.
  • acceleration of common actions

In Contacts, one could "favorite" people from the list view or set a Reminder. These don't get synced to back ends, and so should not be mutated in the Edit pane like conventional fields.

The Messaging app doesn't have a concept of "opening" a message, so tapping displays a popup menu. Here, we'd probably have tap do the same as right swipe: slide in buttons to reply or copy the text.

In Email, the "adopt" actions would be the same as the bottom toolbar in the full display pane. Here, we get a little acceleration and consistency with other apps.