1

I want to offer the user the choice of one of n choices. The natural choice is to use a dropdown list box:

enter image description here

Here, "Album name", "Artist name" and "Track name" should be mutually exclusive; only one dropdown may have each distinct value selected.

Each row is also optional - only "Album name", say, may be set. There is currently a separate affordance to add a new case rule.

In the screenie above, you can see the alternative choices are disabled. Is this the best way to handle this? Should the other options be removed from the list instead?

Alternatively, is it best to allow the selection, but display a warning and disallow the "saving" or "confirmation" of these settings with an error message?

  • +1 Great question, as it relates to attempting to offer flexibility in simplicity. Case filters are difficult because you also could choose to be less strict with your rules. "Must be" can become "Or" – Pdxd Apr 15 '14 at 14:02
1

I'd confirm that it's better to have some options greyed out.

Here's an example from outlook. Note the greyed out regions in the dropdown. It also has indicators for adding or removing the case on the fly which I know you mentioned you had.

example example2

Notice, as choices get exhausted and another case is added, it filters through the secondary choices until nothing is left:

example3

Here's what it looks like with all choices exhausted. There are no error messages that appear, just can keep adding infinite greyed out items but I'd recommend hiding the "+" after the final option.

example4

Not saying it's the better way to do it, just that this is the approach that Microsoft has taken in Outlook and they must have loads of user research on every feature of their products to support this.

  • Yes, this is pretty much what I'm doing now. It just began to feel a bit "icky" as more rows were added. Should adding more rows be disallowed for example? Doesn't appear to be the case in your example. There is also the option of attaching semantics to multiple settings for the same value - e.g. ANDing or ORing the meaning together... – Dan Gravell Apr 15 '14 at 13:55
  • I edited my post just now. Yes I recommend removing or not allowing the "+" after the required choices are exhausted. – Pdxd Apr 15 '14 at 13:56
  • This is a good example. I would also add that when graying out the options consider making clear to the user why the option is grayed out. – Jonathan Strate May 15 '14 at 16:50
0

If possible, it is always better to design a UI so that a user cannot do the "wrong thing", rather than allowing wrong selections / data entry and then displaying a message. This saves the user time and unnecessary frustration.

User shouldn't be able to select items that don't make sense, and for clarity I would say to remove them entirely.

  • Broadly I agree in this case but I'm also interested in the analogy of boiler plate v free form editing. Most IDEs for example allow you to make mistakes and mark those mistakes, rather than not allowing you to make mistakes. Others enforce boiler plate. Personally I prefer the free form approach to the boiler plate approach... but maybe it depends on the skill level of the user. – Dan Gravell Apr 15 '14 at 13:36
  • 1
    @DanGravell Do they though? It depends on how many permutations of possible inputs they have to deal with. So if they have a fixed list of options available, they provide a dropdown instead of free text field where the user can type all kinds of wrong stuff. I think most nice UIs do this kind of limiting where they can. I wouldn't suggest limiting keystrokes in a free text field, or anything irritating like that (I saw someone do that in a UI once, it was painful). – Franchesca Apr 15 '14 at 15:34
0

Don't use n*n complexity , simply make the label and corresponding to that label user have to select the corresponding data

  • Sorry, I wasn't clear so I have edited the question. They cannot be labels because each row is optional. – Dan Gravell Apr 15 '14 at 13:34
  • @DanGravell: that's not a good reason to increase the complexity. Use the labels and simply add a "don't care" (or similar) option to the case combo. – Marjan Venema Apr 15 '14 at 13:47
  • What if there are fifty labels? Five-hundred (potentially changing to an auto complete drop down here)? – Dan Gravell Apr 15 '14 at 13:49
  • See my response to @Andrew Leach 's idea for a development of this... – Dan Gravell Apr 16 '14 at 9:30
0

The second and subsequent drop-downs should be updated to remove invalid choices, based on what has already been chosen.

Once "Album name" has been selected, it cannot appear in any other choice.

In the mockup below, if Track name is chosen here, then only Artist name would be available in the third dropdown.

mockup

download bmml source – Wireframes created with Balsamiq Mockups

This is not particularly difficult to code, either in a native application, or a web page.

  • Your "Select..." made me think - what if the affordance to add a row was a drop down button labelled "Add case rule" (this is a 'case rule') with drop down values being album name, artist name etc. When one is selected, a row is added with the choice as a label as suggested in @user3011961 's post. This reduces the complexity of the UI because it becomes two stage with fewer options at each stage (can't remember what the Design of Everyday Things says about this... but it's in there IIRC). The obvious drawback is you can't change the field name... but would you want to? It can still be deleted – Dan Gravell Apr 16 '14 at 9:11

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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