Hot answers tagged

18

I suppose the first point to make is that you shouldn't depend on invisible interactions to accomplish anything. The example made in virtualnobi's comment of iOS's swipe-to-delete gesture is a good example; Mail items etc. can be deleted the long way by choosing Edit, then checking the items you wish to delete, then choosing "Trash"/"Archive" at the bottom ...


10

I have been dealing with designing for swipe gestures recently and you raise a very important question, as the main problem with most mobile gestures is discoverability . More and more, swipe is becoming a standard and well known gesture with the rise of Tinder. However, mobile users are still very much used to tapping buttons. Tapping is by far the most ...


8

Conventions for this micro-interaction are weak I haven't seen a study, but from a usability perspective I really don't like this microinteraction. There is no usability cue/affordance. Users need to be trained or they may not know the interaction even exists. Even if they are trained, there's no cue for what direction causes what action, so it's easy for ...


7

Use cut off content. Really simple visual idiom. I believe it could even be used to signify the elusive drag-down-to-refresh by showing a corner of a circle at the top.


7

Although the use of gestures allows ease of use, as mentioned here and I quote: Using a gesture rather than a button allows you to speed up and more efficiently complete the action, without having to take up screen real estate. The issue with gestures is that they are always hidden as mentioned here and I quote: In addition, gestures have the same ...


5

I have seen some apps use a brief animation that slides over, partly revealing the hidden feature, and then slides back to notify the user of the hidden features. This could be done upon first load or when a user taps on one of the list items. Previews like this avoid the interruption of a pop-up while telling the user that there are hidden features. As well,...


4

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 ...


4

An important factor to consider is the audience of the application (or website). It seems that typically, many younger audiences (or those familiar with touch devices) are used to swiping across carousels. If you look core applications of iOS (and I'm assuming Android as well), you'll find that carousels support swiping to switch to the next image. However, ...


4

The gesture goes back at least to 2009, when it was already being used by Apple and Google, and especially Palm (webOS). I Googled ‘swipe to delete’ and restricted the results to pre-2010. I learned that the iPhone had it in Mail, while Gmail’s mobile app had ‘swipe to archive’. But, as far as I can tell, swipe-to-perform-an-action was used most extensively ...


4

In a word, no. There is no consensus on swipe actions in apps. To illustrate the lack of consensus, here's a quick list of some applications of swipe actions: (When I say "swipe right", I mean swiping from left to right.) Google Android notifications: both left and right for dismissing Android recents: both left and right for dismissing Android wear: ...


4

These icons are generally called "chevron" icons. Now, as you must already be aware, there are different kinds of chevron icons based on the context of the event. For example, in the screenshot you've posted, the icon is called Chevron-down. Similarly, there are chevron-up, chevron-left and chevron-right icons for their respective usage. Hope that helps.


4

I think the solution is to understand that although the gesture is the same, the functionality is different. The first is a Swipeable Menu with hidden tabs and the second is a Swipeable List with hidden options. In other words, the first one is a Carousel and the second a list with a swipe functionality. While in the list it's easily deductible for the user ...


3

Let's start by understanding why users are behaving this way: Carousels are a very common interface on mobile devices. They're used in Facebook, Twitter, and iOS, etc. So there are almost 2 billion smartphone and tablet users who are used to this interface, particularly with cards. In a carousel, swiping left and right are symmetrical actions which move ...


3

Research From Nielsen: Desktop websites have a strong guideline to avoid horizontal scrolling. But for touch-screens, horizontal swipes are often fine. Indeed, mobile-device users typically expect to horizontally swipe their way through a carousel. There's also this research from Poynter showing a similar trend: iPad users have an overwhelming ...


3

I think a combination of animating a slide-in for sections together with a small arrow on the side is the most clear way of indicating the content is slide-able. Bullets can indicate how much content is available and the current position of the user. Image taken from sliders.webflow.com


3

Changing chapter is a major operation, which should be handled with care. A swiping motion changing chapter is in a way careless, since users who accidentally makes the swiping action will be completely lost. Therefore I thing your best option is to use a standard hamburger menu containing the chapters and possibly subchapters as well. download bmml source &...


3

Some desktop applications do take left/right handedness into account, for example games often use the WASD keys for directional movement, but also have IJKL set up by default. Equally some applications don't take it into account. When I broke my right wrist and had to hold the mouse with my left hand, I soon realised how the keyboard shortcuts for a lot of ...


3

Using Gmail and Inbox by Gmail as examples we can see a clear difference in ideas regarding this matter. Unless you are in a serious fight for space within the object I would recommend using icons that reflect the action. This would remove any learning curve that results in removing actions from clear view. Gmail: Swipe left: archive Swipe right: archive ...


3

Consider: Mental Models : There's no a massive use of swiping to choose between yes/no - good/bad to take as "common use", so you will not confuse anyone comparatively more if you set the actions one way or the other. Familiarity and flow: It's common in mobile applications to place the option that let you advance in some process (confirm/yes/...


3

You mention the way Tinder handles swiping (right -> good, left -> bad), but in addition, Tinder offers buttons which perform the exact same behavior and are visible to the user at all times. These buttons are placed in the same location as their corresponding swipe directions (i.e.: dislike button on left, swipe left to dislike). Assuming these swipe-able ...


3

The normal User Experience convention would say that the long press is better because (almost) all the other messengers are using the same thing. But, I am always against the long press option, it holds the user for a few seconds for what he/she was trying to achieve. So, the deciding factor should be, If you do not want your users to waste your time (a ...


3

I found an article which was published on February 20, 2012 written by Jason Mick (blogger) "Neonode Patented Swipe-to-Unlock 3 Years Before Apple" Neonode -- a small Swedish phone manufacturer was the first to deploy the technology commercially.  And it also appears to be the first to have patented swipe-to-unlock. U.S. Patent No. 8,095,879. The ...


3

Alright, so since this is a shopping app, I assume there is no arm in jumping to previous items at will? If so, I have the feeling a persitant "history" would work best. This is a little proposition, might be way above your scope. Let me know!


3

A swipe down, aka pull to refresh would be an option if you did not want to use on-screen controls. Could add a small timestamp at the top, and the app auto updates.


2

Basing your apps functionality on what the user tells you they need is considered a wrong approach. In UX it's widely believed best practice to observe your users' behavior and base functionalities on that. Users don't want what they tell you they want, but want what they don't know they want. As for swipe gesture or just buttons, there isn't a clear ...


2

While I don't believe that there is a standard icon out there for swiping left or right, I do know in many cases to slide something left or right with your mouse you would grab a sizing handle. Like this one: Windows: Mac: I'm thinking if you used this at the end of the slidable UI element, it would probably make it clear that the user should slide it.


2

Currently the gesture language is not very well defined, so there is no specific difference between a swipe action for an entire page compared to a swipe action for a section of a page. This means that either we need to extend the gesture language or provide a specific visual cue for that part of the page to indicate a different behaviour. But it would still ...


2

This is an old thread, but it's still a current problem. The best example I've seen of demonstrating that something is swipable is in the search results of the Amazon app (iPad version, not iPhone). After the search results load, one of the results briefly animates the swipe effect to show that something is hidden behind the cell.


2

Because we read from left to right this means the most natural way of swiping would to bring in new content from the right. So the comment above is correct. Swipe to the left. updated by 'we' I mean the West. For other languages will be in accordance with the reading direction.


2

Without knowing anything about your app, the best solution I can think of, is introducing a brief on-boarding that includes instructions on swiping with one finger to use the app (with an accompanying visual example). I'd be interested to know where they're getting the idea that two fingers is for swipe; maybe they're laptop users having a hard time ...


Only top voted, non community-wiki answers of a minimum length are eligible