Early Bird Registration for DrupalCon Portland 2024 is open! Register by 23:59 PST on 31 March 2024, to get $100 off your ticket.
example:
http://jsfiddle.net/3quCy/
Yes. a contri modules doing similar stuff:
http://drupal.org/project/select_or_other
Most of select list in CORE are predefined list. what if you want to show more than 30 post in front page or other conf ? Yes. you can build a module or set it through "variables". But it's not user friendly for common users.
adding this into CORE, we can expose all options with custom values. more freedom :)
Comment | File | Size | Author |
---|---|---|---|
#7 | Screen Shot 2013-01-16 at 20.01.45 .png | 11.65 KB | Xano |
#7 | Screen Shot 2013-01-16 at 20.02.00 .png | 11.78 KB | Xano |
Comments
Comment #1
catchIf we add this we could use it for #680546: Add a custom 'number of values' for 'multiple / multi-value' field. (e.g. nodereference, imagefield), there's also a similar pattern with the date selector according to Xano in that issue.
Comment #2
k.skarlatos CreditAttribution: k.skarlatos commentedSelect or other in core will be super useful in order to be able to allow a user to add items to a select list without having to give him access to the field settings
Comment #3
sunTBH, I find the Select + Other... option interface pattern pretty weak.
It performs very poorly when the list of options is larger than "a few".
For example, enable the Language module, and add a language. I bet that >90% of all users will entirely miss the "Other"/"Custom" option that happens to be at the end of the option list.
It's also cumbersome to use when you already know that you need/want to enter a custom option. (i.e., repetitively executed tasks)
I'm absolutely confident that there are better interface patterns for solving this problem space. Actually, I'm sure that I've seen and used many different approaches already, but off-hand, I can't remember where I've seen them.
Comment #4
yoroy CreditAttribution: yoroy commentedWell, long lists are long. And 90+ % of people wouldnt need it because the language is already in the list. 'a few options + other' is exactly what this is for.
Comment #5
sunCan we explore options before preemptively hopping onto conclusions? :)
(wow, Reverse World Order™ - isn't it you who normally asks for that? :P ;))
Comment #6
yoroy CreditAttribution: yoroy commentedSure we can. I was saying that your argument for why this pattern is weak was itself pretty weak ;-p
Comment #7
XanoI added something similar to Currency earlier this week in the form of the
currency_sign
element. It starts out as a basic select element, but it has a- Custom -
option. After selecting that, a textfield appears.That is why I made the "custom" option look similar to and positioned it below the "none"/"select" options that we already have in FAPI.
Comment #8
tsvenson CreditAttribution: tsvenson commentedI was pointed to this issue from #680546: Add a custom 'number of values' for 'multiple / multi-value' field. (e.g. nodereference, imagefield) and would like to add my view on this.
While I understand @sun's point about it being a bit cumbersome when custom is at the bottom of list, I also think the benefits outweighs it. Particularly that users quickly will learn it is there they always will find it. If its not found there, the dropdown simply does not offer a custom option.
"Other" can be used for long alphabetic lists to just present the most obvious/used options using a shorter list. When selecting "Other" the user will be prompted with the full list.
Then there are the two options:
Sometimes only one is used and sometimes both.
I consider them static values and also often the default value and are logical to have at the top of the list.
Since Drupal already used "- Select -" (dashed) in dropdowns to tell the user they must select a value, the same should not be used for these as they are real values. Better is to then use "<None>" and "<Any>", which is a common way to present these two values in many applications.
These three, and other, should also be centered in the list.
Delimiter
To further improve the visual guides for the user, a delimiter can be used after None/Any and before Custom when they are present. Particularly in word lists, the delimiter will be useful to make a clear separation between the static choices and the custom option.
Using the above rules a number dropdown would be looking like this:
Number dropdowns:
Alphabetic lists:
Even if there are some, very few, cases where the above is not perfect, following the standard is better since everyone then know exactly what to expect and how it works. Learn it once an never get surprised again so to speak.
Edit: Changed the meaning of "Other". No idea how I got it wrong in the first place.
Comment #9
XanoMy first response is: why separate "custom" from the other special options? If we already have some special options at the top, to me it doesn't make sense to put others at the bottom.
Comment #10
tsvenson CreditAttribution: tsvenson commentedYes, I agree that Any and None are special too. But, they are also very different from the Other/Custom at the bottom.
They are both static values in the same as the numeric and alphabetic. At the same time they are neither a number, nor a alphabetic choice.
Both Other and Custom are not static values that affect the functionality of the field, they are choices that triggers a second step in the field configuration. For Other that extra step is to make all static choices visible to select from and for Custom it means revealing an input field to enter a value in.
The main reason for having Other/Custom at the bottom is so that users at least will have to scan the choices between top and bottom. If they are at the top, then some will sometimes wrongly assume the value they need isn't available without even looking. It is also to separate them from the other due to that they have a different special meaning.
From an UX perspective it is important to have well defined standards like this. Sometimes they aren't designed to allow you to make the fastest possible configuration selection. They are designed to guide you to make the correct configuration selection. That's why you need to separate what on the surface might look at similar options, but in reality have very different underlying meanings. Like in this case.
Comment #11
webchickI'm not really sure why we are hypothesizing about this? Let's just go find other examples on the web and do what 90% of other people are already doing.
Comment #12
tsvenson CreditAttribution: tsvenson commentedJust looking on the web would be wrong. We also need to look at how things are done in desktop applications. Personally I firstly turn to the Microsoft's Windows UI standards as guidelines. Not only because Windows is the most spread/used OS, but especially because they have spent 35+ years, and billions of USD, researching, testing and tuning their UI standards to perfection.
Look at their Drop-Down Lists and Combo Boxes page gives detailed information about this, and you can see that I have followed their principles in my examples.
Specifically in the Usage patterns you see that the triggers for the second step are at the bottom, like the Other/Custom, and in further down you see them using the equivalent of Any (look for "All Windows products") as well as their use of (None) at the top of the list.
These design patters haven't been made randomly. They are there so that users will be able to quickly learn the expected behaviour, while at the same time avoid the choices to be mixed up (if for example "special" choices are grouped together just because they are special). Then they will be able to instinctively know where to look for a certain kind of selectable option. This is very important to understand to be able to create a successful UX.
With no UX design patter, then users will first have to spend time analysing and trying to figure out what order the options are, as well as identifying the meaning of the word choices by different developers for the same functionality. That only results in a steeper learning curve.
Comment #13
User Advocate CreditAttribution: User Advocate commentedArguably, ‘www’ could stand for ‘Wild West Web’ from a UX standards point of view. I’m not convinced ‘the web’ has found a solution on this and many other interaction patterns yet. I’m encouraged to see this discussion because it means we are finally at a point where we can consider strong UX strategies.
I think @tsvenson’s logic is sound and needs some serious consideration. I agree that the MS Windows UI principles are well thought through and make a good reference point for issues such as this. One minor point, as I recall the Windows UI guidelines use the term ‘separators’ rather than ‘delimiters’ for the divisions on menus. From my experience as a user and a UI designer I find these menu separators to be of value for helping the user see related groups of options.
A more important point is that the Windows UI guidelines identify the use of such signifiers to set up a rigorous system of visual cues that users come to rely on. This is no doubt a contributing factor to the historic success of Windows – all personal preferences aside. Another good example is the practice of using ‘…’ to indicate that more user actions are required via a dialog, if the user were to select that menu option.
All too often we lack standards like this in the web – where user guidance is often left up to: the imagination of graphic designers; random marketing decisions; technical limitations; other...
I think, by considering issues like this one, we are helping to define much needed standards. So, as with any UI design, I think the best we can do is form a strong rationale (also known as a design hypothesis) and go with it until proven wrong.
Comment #14
tsvenson CreditAttribution: tsvenson commentedThanks for the correction @User Advocate, separator is of course the correct term. I blame being Swedish for my slip :)
I would also like to add that UI/UX standards like this is not limited to just benefits for users of the configuration UI or live sites. It goes much further than that and is a major win for everyone involved our touched by the Drupal.
By defining UI standards like this we will then be able to develop a more mature and reusable UI library in core. The ASCII designs I posted in #8 can easily be defined in that library. When developer then need this functionality they just need to enable those "special" properties (Select, Any, None, Unlimited, Other, Custom, etc...) and not worry about where in the drop-down list they will appear.
Nor do they have to worry about what to call them as that is defined in the UI standard. That in turn means that the string will only exist in one place in the code, namely the UI library.
Translators will then only need to translate those strings one time no matter how many core features or contrib projects that uses it.
The code base will also win by this as it will get smaller. And since the logic only exists in one place, it will be easier to maintain as well as minimizing the risk of bugs too.
Developers needing a drop-down will then be able to focus on the actual values then want to include in it, instead of reinventing the wheel again and again and waste time trying to figure out what to call those labels that should be taken care of in the UI-library.
Basically, everyone will be a winner from this.
Comment #15
Bojhan CreditAttribution: Bojhan commentedDont really think this is a feature request, nor do I think its major. After all this is just about having a more pleasant pattern for custom options, that is desirable and would make things more usable. It is not a "nice to have" nor is it a "need to have", therefor a normal task.
Comment #16
yoroy CreditAttribution: yoroy at Roy Scholten commentedLets prototype it :)