This is a very general question but regards a common challenge that people face. I think the story behind is very often similar and it is worth to decompose the problem into smaller pieces to understand it correctly within its generality:
- many vs. few vs. unknown number of options to choose from,
- length/size of the options,
- all options visible vs. visible only one,
- preselection (available in both cases, yet different) & encouraging to make a decision,
- available space,
- cognitive load,
- number of clicks/taps.
There are probably more, and a lot of them overlap, but concluding on what is important at every specific of these may lead you to a decision. Let us try to decompose the nature of selection then.
Many vs. few vs. unknown number of options
This requirement/constraint comes from the content, what is available for selection. Why I am a little bit biased towards hiding the high number of options into a dropdown, I believe the decision cannot be made on this dependency only – it requires mixing with the other elements of reasoning. Displaying e.g. 15 radios may be not the best idea out there, but keeping them in a dropdown may result in Users having problems selecting the proper one or needing to scroll through them. So it is still a matter of the specific case.
However, one point here is important. Is the number of options to choose from that are going to be there constant? Sometimes it may depend on a specific case, so depending on some dependencies within the system the number of them may vary. I believe in some cases it could even lead to a point where the selection pattern would depend on this variable number of options, so you would display e.g. radios for up to 3 options or contract it to a dropdown whenever it grows above it. Some decision hard to make behind it would be if you are going to compromise the consistency of the interface for that, however, there are many cases where I believe you would not because of the high level of the incoherence of the screens (e.g. when you have some extended forms in e.g. a loan request).
Length/size of the options
Two things to consider here:
- the length/size of the options,
- the variance of this length.
If the options are very long, then showing them in a dropdown may be ineffective because you would need to either truncate them or break the lines (provided that these are textual options). Should they be non-textual (namely: images or anything else that is defined in two-dimensional space), you may face similar problem, as some of the images may need to be bigger because of needing to show some complexity of what is shown on them.
Combined with the aforementioned number of options to choose from, it forms an interesting design decision task.
All options visible vs. visible only one
Does it make a difference for the Users or for the business? For example, you would display all the products in an e-shop (they are some options to choose from, are they not?) instead of hiding them in a dropdown but in some cases some specific selection (e.g. t-shirt size) could be pushed to a dropdown.
Preselection & encouraging to make a decision
In some cases a preselection is good. This way you can drive your Users towards making some decisions. In these cases, using a pattern that would show the other options on demand may be beneficial for the system regarding e.g. conversion). I believe a drop-down may be a better solution for that.
In other cases, encouraging the Users to make some decision may be a good idea.
Now, both are available with all the options visible (e.g. when using radios) and a dropdown. The difference is, though, that having all the options visible you can just have all of them deselected (so a User needs to click one to make a decision) and when the options are hidden it is good to inform User that they need to click a dropdown to make a decision.
So a case when there is nothing selected would look like this in both cases:
download bmml source – Wireframes created with Balsamiq Mockups
Of course, you can support both of these with an encouraging text e.g. "Select a colour".
It is one of the most obvious limitations, and I think there is not much to describe here, maybe just the fact that when serving multiple breakpoints you may consider a dualism of a pattern. Something displayed as a list of radios on the desktop version of the site (so: being bigger) may need to be contracted to a smaller representation on mobile, and supported by the appropriate selection pattern available for this medium (e.g. UIPickerView on iOS). Displaying a classic dropdown on mobile may be irrelevant due to the screen size, especially when there are a lot of options, though.
This is a hard part here because there are two things that can cause it:
- too many elements displayed (a.k.a. "Information granted but the brain goes bling!" problem).
- options too much hidden so the User needs to search for them (a.k.a. "Where's Wally?" problem.
Sometimes it is balancing between both of them.
Number of clicks/taps
This is, again a quite obvious thing - if you need to select an option from a list that is initially hidden (so you need to expand that dropdown for example) there are more clicks to be made. It does not make much difference if there are two or three lists to choose options from if this is something you do from time to time, but should you do it repeatedly, these three selections may be a problem as it would become an expand-select-expand-select-expand-select-(repeat) madness. An example here would be my beloved icon selection site, where I always look for the same type of icons (monocolor, linear) and need to perform the same selections every time I search for something new (this is, however also a topic of remembering my previous actions and preselecting (also described above) based on these).