Swipe UI

Background

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.

Proposal

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" (mark as unread, create a bookmark/favorite, reply to a message, copy to Just Type to 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". Again in the dashboard, he/she swipes right and taps "Copy to Just Type". In Just Type, he/she selects "New Task" from Quick Actions 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.

Implementation

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.

As of Enyo 2.5, swipe support is only in List, not DataList. Support in DataList is supposed to come after 2.6.

Advantages

The key advantages for users are

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

Specific Instances

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.

In Preware 2, the Package Updates list (and others) could use swipe right to install the update. Swipe left could mark an update to be skipped.

In File Manager, swipe left could Remove (with button labelled Remove to reduce accidents), while swipe right could allow New Folder or Move.

Demo

Run this demo on a touchscreen device to get a feel for the ease of use. (Firefox on Android currently works best.)