3

We are designing a commercial app for Android. Part of the solution has a list of items that has a number of context actions. Initially there were only 3 actions that were put on the action bar. But a number of other actions have come to light with more actions in the future. Some are also multi-select based. In a discussion with (influential) developers their suggestion was to put all actions on the context menu only - i.e. touch and hold and the menu appears. Is there any data that states how familiar users are with the context menu? Should we be using it at all or just use the action bar?

Paul
  • 155
  • 6

5 Answers5

3

The contextual action bar is currently the right pattern for the generic contextual action problem. See the design guidelines of Android.

It supports multiselect and single select and offers room for multiple actions. It also has a higher discoverability than the long-press for pop-up menu. See also this related question.

Community
  • 1
Pesikar
  • 1,048
  • 1
  • 10
  • 24
2

A context menu is standard and something which, from my experience, has not caused any issues with people.

Without specifics of how you think people will use the app, it's difficult to give concrete suggestions. However you shouldn't just put everything into a context menu just because you can. If one or two function are used 90% of the time, then you should probably have them easily available without the need for an additional tap.

One worry with context menus is that the ability to just add more features often results in their being more features than is necessary, and subsequently a poorer UX. Think very carefully about whether a feature is really needed before you add it.

JohnGB
  • 68,376
  • 26
  • 180
  • 294
1

Having more than 5 buttons in the action bar will make it hard to use, it depends on the orientation of the device but I'm talking about portrait view, it will be hard to press the buttons. Is it possible to group the actions some how? What are the actions?

Threadlife has a fly out menu, when you press menu button, menu slides up with 4 icons and explanation of what the icons are making it very easy to use, user doesn't have to double guess what the icons mean. I think you should use this approach especially if there will be more than 5 actions. And with the right indication like a little arrow will not cause any problems to the users.

Igor-G
  • 3,062
  • 16
  • 25
  • 1
    +1 I like this solution, since with touch screens "right clicks" (long clicks) are time consuming and this solution is both faster and easy to hit on a small screen (since the button has a clear outline). – Danny Varod Dec 04 '12 at 15:59
  • This answer troubles me because the "Threadlife" app is only available on iOS and the OP asked about Android. – mawcsco Dec 04 '12 at 16:04
  • @DannyVarod I believe we need to go back to basics not try to re-invent the wheel. – Igor-G Dec 04 '12 at 16:22
  • 1
    @mawcsco What troubles me is that you think iOS and Android apps should have different touch experiences. This would lead to users needing transition time to learn how to operate new devices. – Danny Varod Dec 04 '12 at 16:26
  • 1
    @Igor-G As long as you don't go back to requiring users to type in terminals :-) – Danny Varod Dec 04 '12 at 16:27
  • @mawcsco it doesn't matter what OS you use, the questions was about the navigation problem and how to solve it. Would you suggest to stop using pen and paper just because it's not digital? – Igor-G Dec 04 '12 at 16:28
  • 1
    @Igor-G Regarding basics and pen & paper, I like the handwriting touch inputs (e.g. Gesture Search on Android). – Danny Varod Dec 04 '12 at 16:30
  • @Igor-G I disagree. Android users and iOS users have different sets of conventions and cultures to deal with. Just because navigation works on iOS does not mean it will work on Android. It's like saying that some desktop convention is equally valid on Android. That simply isn't true. Just because they are "touch" doesn't mean they are the same. – mawcsco Dec 04 '12 at 17:07
  • @DannyVarod Why shouldn't they have different touch experiences? Just because it's done on iOS makes it right? The conventions used in iOS are the gold standard and nobody should experiment with other ideas? WebOS was bad because it wasn't iOS? The fact is that they ARE different and we can't expect them to be the same. Perhaps Android users don't use iOS because the experience doesn't work for them and trying to make Android like iOS actually worsens the experience. – mawcsco Dec 04 '12 at 17:12
  • 1
    @mawcsco go to http://play.google.com/intl/en-GB/about/index.html and click 2nd slide, you will see the same method for the menu is used. I'm not saying that there are no difference between iOS and Android. Just because I didn't use Android app as an example doesn't make the example invalid. – Igor-G Dec 04 '12 at 18:08
  • 1
    @mawcsco I am not saying that everyone should copy from iOS. What I am saying is that if it works, it works (no matter where the source was). – Danny Varod Dec 04 '12 at 18:15
  • @Igor-G are you talking about the system menu in the top right? That's the standard Honeycomb+ "action bar" referenced by the OP that he is moving away from. Plus, it is only available on Android 3.0+. Or, are you referencing the grabber below it? That merely switches from cover view to song view; there's no "menu." http://developer.android.com/design/patterns/actionbar.html – mawcsco Dec 04 '12 at 18:28
  • @nawcsco I was refering to "Action overflow" – Igor-G Dec 04 '12 at 18:38
1

As an avid Android user (my wife would call me an "Android Fan") and a UX practitioner, I feel compelled to respond with my personal experience.

I find context menus very frustrating. There are several problems. The first is that press-and-hold is also used to begin a drag action in applications like GMail and as the select text action in the browser. Without "experimenting and remembering" this behavior is not consistent. Press-and-hold is totally broken on Android.

The second problem is that it slows me down. If my repeated actions are locked behind press-and-hold, I find myself using the app less. There has to be quick and easy ways to do common actions. Less common actions can probably survive in a context menu, but not the frequently used ones.

The third problem is that non-expert users are frequently unaware of press-and-hold. My wife has been using Android for over two years. I recently showed her that press-and-hold allows her to select text in the browser... she had no idea. It's not an obvious behavior that enables discoverability.

My recommendation is to make the context menu an alternative path to functionality and not the primary path.

mawcsco
  • 2,998
  • 21
  • 23
0

There are a couple of problems that occur when using the long tab:

  1. The action possibility is invisible: a context menu has no button or other signifier (aka "Affordance"), so people don't know that they can use it.
  2. The Long-Tab is cumbersome to execute: It needs waiting time, which annoys people. In addition, if one is impatient and lifts the finger too early the waiting was in vain.
  3. It easily can be triggered accidentally by resting the finder on the display.

So I don't recommend the long tab. I don't know what your app does specifically, but you could:

  • Divide the Actions on different screens
  • Get rid of options if they are useless in specific cases so you don't need to display them than
  • Use the menu button like already suggested in an answer here.
jan D
  • 111
  • 3