Previous Entry Share Next Entry
How best to display a "choice"?
jducoeur wrote in querki_project
So one of the more-common requirements for Querki Spaces is a field that is essentially a "choice". (h/t to tpau for suggesting the term.) Technically, it is a Link to a Model; when you edit a field of this Property, it offers you all of the Instances of that Model to choose from. This gets used for at least a couple of different use cases -- sometimes for linking to a real Thing, sometimes just representing a choice from a limited menu of options. (For instance, a Model whose Instances are simply the names "Bell", "Book" and "Candle". Currently, setting up such choices is far more work than it should be -- on my to-do list is a wizard that does the scutwork for building simple Choice Properties like this.)

We deliberately use the same mechanism for both, because the lines can be blurry and shifting. For example, in the Inventory Management Space I'm about to build, there will be a choice of "Where is this Thing located?", which will probably only have four or five options. Initially, that's probably just a simple named choice, and the options are nothing more than names -- but down the road, it wouldn't surprise me if we wind up adding additional fields to each option, describing more about these locations. (Eg, a "directions" field that says where this location actually is.) This sort of evolution is likely to be *very* common in Querki, which is why I err on the side of recommending Links to real Things instead of just using Text.

The issue, though, is that there is no single one-size-fits-all UI for choosing between the options. Currently, you always make the choice via a drop-down list, which is sort of okay as a lowest-common-denominator, but I'm starting to think that it may not be the *best* option in any case. My gut says that, if the list of choices is small and the text to display for each is decently short, we should be showing radio buttons. On the flip side, if the list of choices is large (and in some cases there can be hundreds to choose from), we should instead show a text-input field that you type into, and prompt you with options that match what you are typing. (Just as Tag Sets work today.) At best, I suspect drop-downs are appropriate if the list isn't too large *and* the names are overlong for radio buttons.

In the medium term, we should certainly provide a way for the user to say which way they want to display the input for this Property. (Possibly as a parameter to the _edit function, possibly as a meta-Property on the Property; I'm not sure yet.) But even then, the question is what the default should be.

My gut says that the default should be context-dependent, but I'm of mixed minds about whether I'm being over-clever and inviting confusion. If the number of choices is short (say, <10), and the display text for each choice is short (say, <50 characters), we should clearly display it as radio buttons. If the number of choices is large (say, >20), we should clearly display a prompting input. *Possibly* somewhere in the middle we should use a drop-down, but I have a sneaking suspicion that even two variations is getting dangerous, and three is just unwise.

Opinions? Some of you have much more UX background than I (and most of you are demonstrably opinionated), so I'd love to get some feedback before I make any decisions...

  • 1
I'd suggest making it easy to switch the "flavor" of choice and then either make the user always have to specify what flavor they want (instead of creating a new choice, you create a specific flavor), or pick some arbitrary default (drop-down list). I feel like if you try to be clever about it, you're really violating the principle of least surprise, and you're not going to come up with an algorithm that will "guess the right flavor" consistently.

Possibly true (part of why I asked). This is one of those cases where the DWIM principle isn't tossing out clearly-correct answers for me.

I'm of mixed minds about the "make the user choose a flavor" option -- it might work, but I suspect it is likely to lead users to make incorrect assumptions about what's going on, and what they can do with the resulting structures. Being able to switch "flavors" easily may be correct, although I need to think through the implementation implications...

okay. so.

the issue with a text field is that there is 0 affordance for typign a selection in there. so likely if you do hav ea text field, you need a "show all options" sort of link that will take you to a list of all the options, however many there are.

radio buttons tend to be good for 5 and less options. drop downs for 5-10 or so, unless it is a super set list such as States, and even then opinions are divided on it being ok to use a drop down cause ugh, long.

Now if i were running this zoo, i would do this: let user easily add options. default to say radio buttons. when they have more then X choices give them a warning (orange/yellow, not popup etc) saying that they have morethen X options and perhaps they want to instead have a dropdown? when yo usee that htey have more then Y do the same and suggest your text filed (or an accumulator, my preference btw). Let them shoot themselves in the foot, if they do truly want 50 radio buttons...

plus remember they may want to make that be checkboxes. or multi-select dropdowns? or you know, an accumulator :P

( this site calls it 'list builder')

the issue with a text field is that there is 0 affordance for typign a selection in there. so likely if you do hav ea text field, you need a "show all options" sort of link that will take you to a list of all the options, however many there are.

Yep -- I'd already realized that that's a UX hole in the current Tag Set design. I'm not sure exactly what the resulting look-and-feel should be, and it's not tops on my priority list, but I agree that something of the sort is clearly necessary.

(Good reminder for me to formally enter that as a UX bug, though.)

radio buttons tend to be good for 5 and less options. drop downs for 5-10 or so

Okay -- that matches my intuitions.

Now if i were running this zoo, i would do this

Reasonable suggestion, and may be correct in the long run, but I'm unlikely to get to all of it in the near term. Might be the right directional design to move towards, though -- kihou's suggestion may be an initial partial step towards it.

plus remember they may want to make that be checkboxes

Yep. That one's already somewhat implemented (I use it in our household shopping list), although this conversation is leading me to suspect that I should somewhat change the way it works. (So far, this decision has been a quality of the _edit command, but I think we're driving towards it being a quality of the Property itself. I need to chew on the implications of that.)

this site calls it 'list builder'

Hmm -- plausible. I'm currently calling it "pick list", based on some other instances I've seen, but I'm not especially wedded to that term...

i think the term is not totally relevant because ultimately you will want to show the user what it looks like as they build.

if you do not implement the smart suggestions, then perhaps some sentances sayign that ("if yo uahve <5 optiosn do this, if >5 and <10 do that, if >10 do this other thing. and then give them choice

This is too big, too general. Do you have a specific case or three that we could follow through, to get a feeling for the edges of it?

My instinct is to say, it depends (the UX mantra), and give people options--possibly including the autoconfiguring choice-widget you mention. My analogy is the LJ poll mechanism--the author knows which poll question type to use, and then the interface renders that. But I'd want to understand more about how people _use_ this...

Well, part of the problem is that I'm not at all sure yet - at this point, there isn't nearly as much evidence as I'd like, so I'm extrapolating from very small data.

That said, a few examples I have seen or planned include:

* In the bug-tracking space, I need a pure enumeration to link bugs to feature areas, but it is a fairly large enumeration - 20 values so far, and growing slowly. (And the purity of the enumeration will probably change - eventually, I expect feature area to grow up into a full fledged Thing.)
* OTOH, the same technology underlies the very different case of linking one bug to another for dependencies. In this case, the target space is large - already a hundred-plus, and growing fast.
* In the inventory space, I have the aforementioned "where is this Thing?" case, which I expect will only have three or four major answers. (Although possibly several occasional edge case ones.)

The latter is a good example of the depth of the problem: at design time, I expect that the user frequently won't actually understand their data very well. This seems to suggest that the earlier points are correct, that being able to alter things later is important.

But overall, I'm still feeling my way around the problem at this point...

I largely agree with the other commenters, but have one new observation:

"If the number of choices is short (say, <10), and the display text for each choice is short (say, <50 characters),"

It strikes me as a Bad Idea to make *any* choice for the end user which is based on and-ing together two separate conditions. The user can easily come to an intuitive understanding of one of those conditions, only to become mega-confused when some day they trip the *other* condition.

Sadly, you're probably correct. It does underline how tricky the problem is, though: radio buttons make oodles of sense for small numbers of short names, but are frequently clunky at best for long ones...

  • 1

Log in

No account? Create an account