If the tags are typed in and the user does not click add, the tags are not submitted into the node.

Comments

dragonwize’s picture

Priority: Critical » Normal
Status: Active » Postponed (maintainer needs more info)

hmm... I am inclined to make this as "by design". This is a different widget than the normal tags autocomplete and so works differently. The same goes for items like file uploads that the user must hit the upload button before saving first.

This falls in the same category as letting user enter multiple terms at the same time by using the normal comma method. Darren already included that functionality but now we have this issue #373309: Treat entry field as a single term including commas which now stops us from entering a single term that includes a comma in it like "Last Name, Frist Name". When managing terms as individuals instead of one big field as AT allows you to do, it is unintuitive to allow both clashing methods.

In my opinion, I would mark this as by design and revert the other feature to allow for easy use of any single term. We will have to wait and see what Darren has to say though.

darrenmothersele’s picture

I was conflicted about addressing the other issue regarding commas in the entry field, and after thinking about this I would quite happily revert that feature. It goes against the simple tag entry ethos that was the original use-case for this module.

Although this issue should be marked "by design" I am inclined to think that addressing this issue would improve usability. I would like to see some opinion from other users of the module. In my tests it has caused some confusion where people have entered something, not clicked add, and then found their tag disappear.

dragonwize’s picture

I had some more thoughts on this.

The users that will probably be affected by this feature the most will be those that are used to using the normal core autocomplete widget that doesn't have the add button. Those users will also probably also enter all their terms separated by commas like the normal widget as well.

If we revert the commas seperate terms feature and add this one, then they will unwilling create 1 large term with commas included when they submit the form instead of seperate terms.

We could leave the comma feature in and add this one and it would allow those users get what they expected but I would recommend against that. It would only lead us down a road that will cause us more trouble anytime we try to enhance and use the widget. It would also be more confusing that you can do things multiple ways.

I would much rather see AT stick to its guns on the single term ethos. If your users are confused when you switch to AT style, you have help text which is now displayed :), and you possibly need to alert them by email or training just like every other feature change. If your users like the general widget features better you should be using that one instead of AT and AT is configurable enough to allow you to only enable it on certain fields if that is needed.

I think mixing those methodologies can only lead to confusing behavior and operation. That is the reason there are 2 widgets to choose from now with AT and other widgets with other modules.

dragonwize’s picture

Category: bug » feature
janusman’s picture

I would suggest to "fix" this issue by providing feedback in the following way:

When the user starts typing in the text box, a new tag is added which "grows" as the user types. This way it is clear that whatever typed in the text box is a tag. "Add" would then just clear the text box and "commit" what has been typed so far into a tag.

This way, it would be instantly clear what the outcome would be when typing commas, quotes, etc.

It's good to build on previous user experience to build a new "widget". I would say the above instant feedback makes it look a bit like a Spreadsheet, or "to-do" list... in my experience many have trouble knowing what to expect from the Drupal autocomplete widget so maybe that's not a good jump-off point =)

gregstout’s picture

I have been getting some feedback from users, too, that are confused when their tags are not being accepted by the system without warning. I traced this problem back to to what Darren said "..not clicked add, and then found their tag disappear."

While some of my users have this problem because they don't click add after typing a new tag, a few of my users are confused because when they "click" on the tag in the auto-complete drop-down, they see that tag inside the field - so they assume that it was accepted and move on to the next fields in the form.

I would love to see this changed so as to help the users.

This issue doesn't involve entering multiple tags with commas (at least on my site - I tell them to enter one tag at at time). The problem arises when the user enters a single tag (by typing it or selecting from the drop-down). They might or might not have other tags selected already for that node.

I don't think we need to make this complicated - just a single fix: if there is text remaining inside the textbox, then just include that tag when the user submits the form (add it to the ones already selected). If you want to make it complicated, then provide a check-box for the configuration of that field to "accept term in field even it not 'added.'" and we can configure it to work either way.

dragonwize’s picture

Status: Postponed (maintainer needs more info) » Active

@gregstout: I agree.

I will be implementing that functionality as soon as I get #559176: Upon enabling, existing tags with commas inside quotes split incorrectly tested and committed.

brunodbo’s picture

Issue tags: +Usability

+1 for this functionality (tags being added on node submit, regardless whether the user 'added' them via the Active tags Add-button).

@gregstout: IMO it's not necessary to make this a config option, or at least I don't see why a site admin would want to require a user to click Active tags' 'Add'-button (but perhaps there is a use case for that I haven't thought of).

dragonwize’s picture

Status: Active » Fixed

Just committed this feature. I am going to let the new code brew in 1.x-dev for testing before tagging an official release. Please test and let me know if you find any issues.

brunodbo’s picture

Status: Fixed » Needs work

Confirming that in 1.x-dev, tags are added now without clicking the 'Add'-button. Thanks!

I do find it confusing though, that when I enter tags seperated with commas, and submit the form without clicking 'Add' first, the tags are accepted as one tag, instead of several ones. (I don't want to edit the node everytime I want to add a new tag, in the case where I'm not clicking 'Add').

Perhaps we should make that a configuration option :) . I.e.: allow site admins to choose to join mutliple tags seperated with comma's, or to save them as seperate tags (default Drupal).

dragonwize’s picture

Status: Needs work » Fixed

Treating text as one tag including commas in the decision of several issues including #373309: Treat entry field as a single term including commas and #559176: Upon enabling, existing tags with commas inside quotes split incorrectly. This is part of what makes AT what it is from its conception, read the project page for it's history and purpose.

Admins already have the option to enter a comma separated list instead of single terms, taxonomy without AT. AT is for users who find it difficult or do not understand the comma separated approach. For those that do and want that functionality there is the Drupal default. If you have both types of users using your site, then AT allows you to choose which taxonomy fields use AT and which don't. If both users are using the same fields then there is nothing AT can do for you, you have to train one side or the other.

And the example of saving the node multiple times instead of hitting the large Add button is ridiculous and completely stretching for a reason.

brunodbo’s picture

@dragonwize: We're currently working on a project where a lot of (existing) users already know Drupal's core taxonomy system, and the way tagging works. For new users though, I think it would be very helpful to have (something like) the AT widget, ie. an easier UI to the tagging system, where they can add or remove tags by clicking on them.

So yes, we have both groups of users using the same taxonomy fields. I guess we'll have to decide which approach we want to take. Thanks for taking the time to comment.

giorgio79’s picture

I was just thinking about this although from a different angle.

If the user selects a tag from the dropdown list, it should be automatically added to the tags list above the text field.

Currently, if a user clicks a word in the autocomplete list, that word first appears inside the text field, after which the user has to click add...

dragonwize’s picture

@giorgio79: That would break the normal way a user expects an autocomplete to work. If you select a term it doesn't always me that you want that exact term. Sometimes you want the term with an addition, subtraction, or other change to it prior to submitting. You can see this normal behavior in all suggestion systems.

Flying Drupalist’s picture

dragonwize, that's certainly not how it works in facebook. Once you select the term it's added. I don't understand how you can do addition or subtraction on a term?

Please look at this:

http://www.emposha.com/javascript/fcbkcomplete.html
http://www.emposha.com/demo/fcbkcomplete_2/

This is the most logical and usable system I can imagine.

dragonwize’s picture

1. Those are not Drupal. The standard drupal autocomplete seen and used by users in all of drupal from core taxonomy tags, content taxonomy, and many more modules.

2. You can see this methodology in most other places outside of drupal. Ex: http://google.com

3. If you want to tag you content "Australian chicken eggs" as 1 term. You start typing "Aus" and the term "Australian" shows up as a previous tag. You select the term "Australian", it gets placed in the box and they you type " chicken eggs". Or maybe your term you wanted was "Australia" so you select "Australian" and remove the "n" before adding. If the tag was auto added you would have to remove it then type the entire string by hand which is not the normal way of entering a open tagging system. If the terms were not tags, i.e. they were finite and users could not create more, then that might make sense, for ex. in node reference. Otherwise the user should have full control of what is added and have the ability to change the selection prior to adding.

Flying Drupalist’s picture

1. Drupal hardly sets the standard for usability. Using this module means we're interested in improving on it. On the other hand facebook has extremely excellent usability.

2. Google autocomplete is not tags... I wouldn't want it for search either.

3.
I disagree that your examples make a good case.

If you want Australian chicken eggs, you type Australian, that gets entered as a tag, then chicken eggs, and that gets entered as a separate tag.

If you have Australian as an existing tag, then you should not have to remove the n, why not use Australian?

What I'm trying to say here is, the cases of people first selecting an existing term, then needing to alter it, is small. If a term does not exist, then usually it is different enough from an existing term that you should just type it out. Most of the time, 99.99% of tag entering, does not involve these adding and subtracting operations. The current way things work forces people in those 99.99% of the time to make an extra click so that the .01% can save a typing a few extra characters.

I strenuously disagree with this decision and beg you to reconsider.

Thanks for the great module.

dragonwize’s picture

I respect your opinion but strongly disagree. If I hear from more people on the issue then I will consider it further.

garretg’s picture

I'll chime in and say I agree with Flying Drupalist on this one.

And if I'm understanding things correctly, google.com auto-complete is not operating as you are describing, dragonwise.

In FF3 and MSIE7, when I go to google.com and type "australian" in the search box, I see ten popular search terms that contain "australian." If I click on any one of them, google populates the search box with that term, and immediately executes the search.

After I see the results of searching for that suggested term, I can modify the search. But the search happened automatically when I selected a term from the list, without clicking the Search button.

Flying Drupalist’s picture

Hi dragonwize, can you explain why? It doesn't really make sense to me.

Thanks.

merilainen’s picture

I started using AT because comma-separated lists are annoying and not usable. But now we got some feedback from users and some of them really don't use the Add button -> tags are missing.

I would like to see this implemented as the fb-like fields works, they are usable and allow all kinds of tags. But I understand that it's probably more work than using the current field offered by Drupal. If we are sticking to Drupal style, then I would allow commas in the field and add the tags as comma-separated list if user doesn't click add. Commas are quite rare in tags and if you want to add them with auto-complete field in Drupal, you need to add quotes anyway ("Firstname, lastname"). This way the tags would be saved on form submit as separate tags.

giorgio79’s picture

I think we would need to add a little edit button (such as a pencil) next to the currently existing cancel (red cross) button next to each tag, to still allow the user change a term, if they do not want the already existing one. :)

dragonwize’s picture

After more testing, I do see if you *click* or press *enter* most systems will auto submit the form. My main concern with that and the feature that I am interested in most is the ability to change the term before it is submitted. I use the keyboard more than the mouse and am used to systems that let me change after I select a term, I usually do this with the arrow keys though.

All this is outside of this issue so I've created another task for it: #638848: Auto add tag on click/enter.

Status: Fixed » Closed (fixed)
Issue tags: -Usability

Automatically closed -- issue fixed for 2 weeks with no activity.