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 :)

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

catch’s picture

If 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.

k.skarlatos’s picture

Select 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

sun’s picture

Title: add supports Select (or other) options in CORE » Interface pattern for custom option as alternative to predefined choices
Issue tags: +Usability

TBH, 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.

yoroy’s picture

Well, 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.

sun’s picture

Can we explore options before preemptively hopping onto conclusions? :)

(wow, Reverse World Order™ - isn't it you who normally asks for that? :P ;))

yoroy’s picture

Sure we can. I was saying that your argument for why this pattern is weak was itself pretty weak ;-p

Xano’s picture

I 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.

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.

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.

tsvenson’s picture

Issue tags: +ux

I 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:

  • None
  • Any

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:

 +------------+
 | - Select - |
 |   <Any>    |
 |   <None>   |
 +------------+
 |          1 |
 |        ... |
 |         10 |
 +------------|
 | Custom:    |
 +------------+

Alphabetic lists:

 +------------+
 | - Select - |
 |   <Any>    |
 |   <None>   |
 +------------+
 | A          |
 | ...        |
 | Z          |
 +------------|
 |  <Other>   |
 | Custom:    |
 +------------+

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.

Xano’s picture

My 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.

tsvenson’s picture

Yes, 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.

webchick’s picture

I'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.

tsvenson’s picture

Just 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.

User Advocate’s picture

Arguably, ‘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.

tsvenson’s picture

Thanks 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.

Bojhan’s picture

Category: feature » task
Priority: Major » Normal

Dont 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.

yoroy’s picture

Version: 8.0.x-dev » 8.2.x-dev
Issue summary: View changes
Issue tags: +Needs design

Lets prototype it :)

Version: 8.2.x-dev » 8.3.x-dev

Drupal 8.2.0-beta1 was released on August 3, 2016, which means new developments and disruptive changes should now be targeted against the 8.3.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.3.x-dev » 8.4.x-dev

Drupal 8.3.0-alpha1 will be released the week of January 30, 2017, which means new developments and disruptive changes should now be targeted against the 8.4.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.4.x-dev » 8.5.x-dev

Drupal 8.4.0-alpha1 will be released the week of July 31, 2017, which means new developments and disruptive changes should now be targeted against the 8.5.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.5.x-dev » 8.6.x-dev

Drupal 8.5.0-alpha1 will be released the week of January 17, 2018, which means new developments and disruptive changes should now be targeted against the 8.6.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.6.x-dev » 8.7.x-dev

Drupal 8.6.0-alpha1 will be released the week of July 16, 2018, which means new developments and disruptive changes should now be targeted against the 8.7.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.7.x-dev » 8.8.x-dev

Drupal 8.7.0-alpha1 will be released the week of March 11, 2019, which means new developments and disruptive changes should now be targeted against the 8.8.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.8.x-dev » 8.9.x-dev

Drupal 8.8.0-alpha1 will be released the week of October 14th, 2019, which means new developments and disruptive changes should now be targeted against the 8.9.x-dev branch. (Any changes to 8.9.x will also be committed to 9.0.x in preparation for Drupal 9’s release, but some changes like significant feature additions will be deferred to 9.1.x.). For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

Version: 8.9.x-dev » 9.1.x-dev

Drupal 8.9.0-beta1 was released on March 20, 2020. 8.9.x is the final, long-term support (LTS) minor release of Drupal 8, which means new developments and disruptive changes should now be targeted against the 9.1.x-dev branch. For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

Version: 9.1.x-dev » 9.2.x-dev

Drupal 9.1.0-alpha1 will be released the week of October 19, 2020, which means new developments and disruptive changes should now be targeted for the 9.2.x-dev branch. For more information see the Drupal 9 minor version schedule and the Allowed changes during the Drupal 9 release cycle.

Version: 9.2.x-dev » 9.3.x-dev

Drupal 9.2.0-alpha1 will be released the week of May 3, 2021, which means new developments and disruptive changes should now be targeted for the 9.3.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.3.x-dev » 9.4.x-dev

Drupal 9.3.0-rc1 was released on November 26, 2021, which means new developments and disruptive changes should now be targeted for the 9.4.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.4.x-dev » 9.5.x-dev

Drupal 9.4.0-alpha1 was released on May 6, 2022, which means new developments and disruptive changes should now be targeted for the 9.5.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.5.x-dev » 10.1.x-dev

Drupal 9.5.0-beta2 and Drupal 10.0.0-beta2 were released on September 29, 2022, which means new developments and disruptive changes should now be targeted for the 10.1.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 10.1.x-dev » 11.x-dev

Drupal core is moving towards using a “main” branch. As an interim step, a new 11.x branch has been opened, as Drupal.org infrastructure cannot currently fully support a branch named main. New developments and disruptive changes should now be targeted for the 11.x branch, which currently accepts only minor-version allowed changes. For more information, see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.