Say you have a form where the user must specify a number of X. For sake of example, let's say X is flowers.

For 90% of users, the type of X will be the same, let's say roses.

So you have a control for number of roses. But for that extra 10% , you want there to be some way that they can specify that they don't want just roses, they want to buy 3 sunflowers, 2 daffodils, and 1 rose.

What is an elegant, and just as important, an Android-esque, way of doing this?

I have thought about having the one control for roses, with an arrow icon/button underneat it that will push everything below that point in the form downwards and show new controls for daffodils and sunflowers, but don't know how well this meshes with the rest of Android because I have not seen examples or mentions of such a pattern anywhere.

In images, since explaining this has been quite difficult. Before:

This is before

And after clicking the arrow:

This is after


Another possible idea is to have: enter image description here

2 Answers 2


Here are a few options:

  1. An expandable pane with a disclosure affordance, most commonly a triangle. An example of this is the Play Store app:

    Play Store expando

  2. A spinner widget allowing you to choose one or several sub-items (all initially checked), optionally with a 'Customize...' option. A simple example of what a spinner looks like is below:


  3. A navigational 'more' affordance; this isn't really a standard presentation or anything but you can see what the I/O 2012 app does here to show more available sessions for a given time slot:

    Navigational more affordance

    Note this is different from the 'action overflow' affordance, which is a vertically arranged set of 3 dots indicating that there are more actions that can be performed on the object.

  • Could you please elaborate on what a disclosure affordance is?
    – yarian
    Commented Dec 11, 2012 at 19:50
  • +yarian the disclosure affordance in this would just be the arrow. It affords interaction (it looks clickable) and it's related to the process of information disclosure (expanding a block of text). Sorry for the jargon :) Commented Dec 11, 2012 at 20:14
  • 1
    Nah the jargon is great. I knew affordances just not if disclosure had meaning on its own. I am going to try both approaches and see how it looks. Only then will I know if it works or not.
    – yarian
    Commented Dec 11, 2012 at 21:56

Not saying this would be done in the "Android" way. But, this could be done with a hidden panel. This way the UI wouldn't be cluttered. It would still be clean yet provide the extra functionality when needed to the user.

The panel is a simple <div> with the content you want within it. Then using Jquery and doing div.panel {display: none} in the CSS you hide the panel from showing. In Jquery you could use a toggle.

Of course this works for a browser. If building for a native app I would assume the same functionality could be built.

  • We are talking about a native Android application here. Not to detract from your answer, but I am looking for a more UX perspective than implementation. Implementing is not the issue; the issue is determining whether this is the right solution are not. The final solution must mesh well with overall Android look and feel.
    – yarian
    Commented Dec 11, 2012 at 19:29
  • Why stay within the confines of what "native" gives you? Yes, for easy of coding etc, etc.
    – Tony
    Commented Dec 11, 2012 at 20:03
  • You just answered your own question. Simplicity is something to be sought out. On any given project you have a complexity budget and you want to make sure to not blow it on things that don't need it. Also, making an application consistent with the rest of Android makes for a better overall device experience and is part of being a good citizen.
    – yarian
    Commented Dec 11, 2012 at 21:55
  • This makes me think of an old IBM way of thinking. There is simplicity in development and then there is simplicity in the UX/UI. Producing a great UX and UI doesnt always mean that the code that drives it is easy to pull off. Does the UX drive the development or the other way around? What I've found is that when you allow dev to drive. The UX suffers for that "simplicity of dev".
    – Tony
    Commented Dec 12, 2012 at 1:16
  • You're taking this whole argument way too far. It's not about simplicity of code driving quality of UI. It's about not complicating the code by 20 units when the UI gain is 5 units. It's also about not complicating the code by 20 units when you can get the same UI benefit with a different solution that only complicates it by 5 units.
    – yarian
    Commented Dec 12, 2012 at 7:16

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.