Posted by beeradb on March 7, 2009 at 7:12pm
| Project: | Drupal core |
| Version: | 7.x-dev |
| Component: | taxonomy.module |
| Category: | task |
| Priority: | normal |
| Assigned: | Xano |
| Status: | closed (won't fix) |
| Issue tags: | d7uxsprint, UBUserTesting2009 |
Issue Summary
People were confused with the checkboxes under the advanced fieldset on the taxonomy edit form. It would seem the "tags" and "multiple select" checkboxes could be combined into one select field, which would contains items like tags, select list, multi-select list, etc.
Comments
#1
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.
#2
#3
#4
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.
#5
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.
#6
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.
#7
The last submitted patch failed testing.
#8
Forgot to attach the patch.
#9
The patch also removes the variable
taxonomy_override_selector, because contrib can define their own selectors by alteringtaxonomy_form_vocabulary().#10
The last submitted patch failed testing.
#11
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.
#12
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.
#13
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.
#14
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}.
#15
The last submitted patch failed testing.
#16
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.
#17
The last submitted patch failed testing.
#18
#19
The last submitted patch failed testing.
#20
Field API took care of this.