WARNING: I could be totally wrong about all of this as I haven't been able to get the ajax calls to work yet. This is just my understanding of your improvements to the module through looking through the code and your screenshot.
-----------------------------------------
I see that this version is trying to integrate better with the way default Taxonomy and form submission work already (obviously an important goal) but I would be curious what you thought about my use case:
Lay people are submitting posts. The hierarchical nature of the default vocabs is simply confusing to them and so they don't choose terms themselves when they are posting which is a major problem of mine in improving the structure of data on my site. That said, if prompted w/ a clear suggestion, users can and do agree to or eliminate those suggested terms w/ your previous user friendly, taxonomy interface. Additionally, I am integrating a medical vocab, so the sheer length of the terms that the autotagger will select is too long to work w/ the default taxonomy list UI for the user to choose "yay" or "nay."
I was also using hierarchical select, which would now be incompatible, if my understanding is correct. I feel that by being more minimalistic and doing more ajax stuff, you solved one set of problems, but are also now more tied to the default UI than you were when you were offering a big improvement for lay users to the default UI in my opinion before. Your old UI was an extension of why users need autotagging: Not only is it convenient, but also users don't get the importance of the whole concept of tagging and it prompted them to deal with the issue clearly and simply.
I would be glad to help with this effort should you be interested and need it.
Comments
Comment #1
Equinger commentedI guess what would be nice is an option in the autotagger settings to override the default taxonomy interface, with the custom UI Autotagger was using. But of course, this time, it would be on the same page. That way as a developer, I could still use "Hierarchical Select" or other user interfaces elsewhere (ie as Views filters) elsewhere on the site.
Comment #2
sdrycroft commentedI plan to get the module to work with hierarchical select, which will certainly help part of the issue.
I also appreciate that you prefer the previous version of the module, and that for you there is additional work needed before the new version of the module will replace the old one. I have a few ideas as to how I can make the current functionality work much more how you would like it, so I'll try and work these in when I get the time.
Comment #3
Equinger commentedThanks for taking a look. Check out Xmarks (which is apparently going out of business. They make a bookmark syncing firefox plugin), but it was interesting how they dealt w/ tagging once they realized people won't tag on their own. I'm not making a direct comparison, of course, but it's interesting the value of tagging, the fact that users want to give input, but won't put in any effort unless they are given options.
Comment #4
sdrycroft commentedThe drag'n'drop interface could easily be re-added via the Tag API module. Currently only one module implements the Tag API hook_tag_ui_info (tag_on_save). An additional module drag_n_drop_tag could be created which implements this hook and provides the UI. I have no plans to create this module.