Checkboxes on taxonomy edit form are confusing

I agree that it is confusing, but technically the proposed solution isn't really correct. Tagging and selection are the two types of adding terms to entities. Multiple select means that users may add multiple terms from that vocabulary instead of only one. When using a select list, this means the widget is rendered as the HTML multiple select input.

From this point of view we need to convert the "Tags" checkbox to a select list and keep the "Multiple" checkbox. Next to a UI change this also requires we update the PHP logic a little, but it should be doable without much trouble.

This could do with screenshots.

I think I'd prefer it if we could split this into:

autocomplete
multiple select
allow creation of new terms

If I can only create one tag, then that's not really tagging IMO.

If you haven't already, it might make sense to remove that 'Settings'-fieldset. It is unclear why these options are in a fieldset. The name 'Settings' is dull too.

Creation of new terms isn't changed by this patch, neither are the select widgets, apart from that the patch makes "Multiple" a settings that applies to both widgets instead of only the select list.

This patch removes the fieldset, makes "Select list" the default widget, cleans up some descriptions and adds an update path.

Forgot to attach the patch.

The patch also removes the variable taxonomy_override_selector, because contrib can define their own selectors by altering taxonomy_form_vocabulary().

I like this. Two thoughts:

- From a UX perspective, I think it would be slightly better to use radio buttons instead of a drop-down menu. There are only two options so it is preferred to show those to the user so he/she doesn't have to click on the select menu to discover the 'tag' option.

- Do we really need 'multiple select'? Why can't all vocabularies be 'multiple select'? If we think we really need this, I recommend it defaults to 'enabled'. Let's make the defaults match what most people want to do. I wouldn't be opposed to taking this feature out either but maybe that is best left to another issue.

Just my 2 cents based on the screenshot.

Just a note: modules like Hierarchical Select can add their widgets to the option with tags and the select list. In those cases we end up with more than two radios.

Fair enough. If we optimize for the 80% case, we leave it up to modules like hierachical select to form_alter radios into a select box, but I agree that this is an edge case. Either way, I'll commit this patch tomorrow, regardless of what we decide to do. This leaves some time for other to get involved and share their opinion. Thanks for running with this, Xano.

This patch converts the select list to radios after considering Dries' arguments and after talking to Nasir who attended the UX sprint as well. It renames the "Tags" selection widget to "Text input" and "Selection widget" to "Term seleciton widget".

The reason that HEAD cannot be installed is probably because the patch updates {taxonomy_vocabulary}.

The attached path updates the default install profile, some $vocabulary->tags leftovers and it prevents multiple tags from being entered if multiple terms are disabled for a vocabulary.

Field API took care of this.