How to indicate that a list view can be swiped to reveal controls?

Question

I would like some advice on any approach which is conventionally used for indicating that swiping sideways will reveal buttons.

I need to answer this design issue both for iOS and Android although the immediate context is an iOS app which is being enhanced after several years.

I am specifically asking in the context of list views, where swiping sideways will reveal two or more buttons, as seen in Apple's Mail in iOS7.

How to indicate specific sections of a page can be swiped addresses a broader question. The suggestions on that page are excellent but they would result in a lot of noise if repeated for many items on a list. They are also more appropriate when swiping part of a page results in a larger change in context.

Apple's HIG refers to the action in the section Users Know the Standard Gestures with the comment With one finger, to return to the previous screen, to reveal the hidden view in a split view (iPad only), or the Delete button in a table-view row but in my experience of talking to and observing users, they do not know the swipe to reveal buttons.

Update 2018-11-16 even after years of use, my wife still forgets the swipe to reveal buttons as a general list action although she has internalised it to delete things in a specific context of Outlook Mail on an iPad. Just an observation from a recent design review. I think it's important as the majority use of swipe as being delete is now a dominant learned behaviour, even when there are multiple buttons the default is if you continue swiping it activates the delete.

We don't want to have permanent markers as the list views already have a small down "vee" indicating they can be tapped to expand.

I have considered:

1. A subtle animation on showing the list, with one or the items bouncing sideways a bit to show the buttons
2. An onboarding variant of the above where this only happens during the first few launches of the app, or during an explicit walk-through of new features.
3. Also triggering the swipe through a long-press, so people see the animated slide to the left if they press for some time on the list item.
4. In one case, where a button used to be that is now one of the hidden buttons, react to a tap in that location so people reacting with muscle memory will see the button revealed as part of the set of buttons underneath.

Note:

There seems to be some hostility to this question, which I don't understand.

Someone else asked this question before and it was (incorrectly) closed as a duplicate.

Another question about a symbol for Swipe Left was closed as off-topic.

Update

Due largely to time concerns, no added affordances were built into the app. This may be updated for v2.1 after we see what features users have discovered, from Flurry logs.

The App store preview video includes a brief demo of one of the slide sideways features but that is only visible to people connecting to the store on a device. Apple don't (yet?) show previews to web browsers or in the desktop iTunes App Store pages.

If it was my preference, I'd go for both 2 (just have it animate a bit the first few times on those screens) and maybe 3, although long-presses on text areas also trigger label-based actions for copying.

Answer 1

Kudos on getting a sound user research done and framing the question well.

The problem here is that Apple assumes that the users know of the affordances. Ideally though, there should be signifiers denoting the said affordance.

You've given some thought to this already and have come up with reasonable solutions, so I'm merely expanding on your solutions here:

1. Motion, however subtle demands significant attention. It should thus be used prudently and only in rare, high-importance scenarios/actions.
2. Better than the first but still to be avoided. Explicit walk-throughs are a big no. There are reasons aplenty for this (a Google search for the same should give various blog posts discussing them). A better alternative would be including step-by-step tutorial i.e. instructions are shown in a non-obtrusive manner only when they are required, not all at one go. However, if this list issue is the main reason for doing a walk-through/tutorial, then avoid it.
3. This is the most suitable option as the long-press for options has been a pretty standard feature in smartphones since some time (Android users are especially more accustomed to this as compared to swiping). Making an assumption here that the users know of this interaction is more applicable, but still doing a thorough user research is the best option.
4. Detailed user research will be needed to know whether there actually is an existence of muscle memory for the particular action. Also, what if users don't want to perform that particular action but some other which is hidden beneath the swipe? Muscle memory does not come into play then. Also, what about new users or those who aren't power users and hence lack the muscle memory. How would they know.

Answer 2

It sounds like you've answer your own question:

How to indicate specific sections of a page can be swiped addresses a broader question. The suggestions on that page are excellent but they would result in a lot of noise if repeated for many items on a list. They are also more appropriate when swiping part of a page results in a larger change in context.

and

in my experience of talking to and observing users, they do not know the swipe to reveal buttons.

So, you either implement the suggestions in the answer you and referring to, or don't implement it at all.