This module claims that it keeps tags separate. This is not true.

Any other member can tag his peer's content, while all tags are thrown into the same pile of tags. Hence the author has no immediate control over the tags, unless he/she goes into the node/edit area and deletes those tags.

This pretty much defies the purpose of this module, because on a site with thousands of users, this could lead to a disaster.

It would be much better if either of the following options would be adopted:
A) user's own tags are visible only to him (like with the Anotate module), while Author's tags are visible to everyone.
B) Everyone can see the new community tags, but the author has the right to easily and quickly delete those tags immediately on screen through AJAX.

Comments

Brigadier’s picture

Brigadier commented

The tags are put into the same pile but the user who created the tag is able to delete them. In that sense it keeps tags separate. The additional options you've described do sound like they'd be useful on some sites.

drupalina’s picture

drupalina commented

Yes, if such small details in granularity of this module would be improved, I'd say this would be an awesome module used across a variety of sites. For me personally this little issue was a show-stopper. I guess the whole trick is to give the Administrators more options in chosing how this module behaves.

Right now the module functions ok for a small multi-user blog, where let's say we'll have 3 very close friends and who have very strict conventions on how they tag each other's content. But in its current state it won't work for a communty site where random indibiduals meet, post articles and tag each others' articles.

Option "A" would be awesome for something like a Social Bookmarking site if this module wishes to behave like Delicious' Folksonomy. Are you planning to implement feature "A" ???
(of course, when implementing something like this some thought would need to be given on whether the nodes tagged communnally should appear under that tag in a general view to everyone else. For instance, Mary posted an article, and Tom hates Mary's politcal views, so he tags all her articles as "Bullshit". Then Joe comes along and browses through the Tagadelic Tag clouds and notices a Giant tag "Bullshit", and when he clicks it, he sees all of Mary's articles, which causes embarrassment and friction. In an ideal situation Administrators should be able to choose whether nodes should appear only under Author's tags, or under the Folksonomy tags too)

My suggestion "B" if combined with suggestion "A" would make this module truely the superstar of Drupal's Taxonomy modules. As a follow up on the above scenario, once Tom has tagged Marry's content, only 2 people would be able to see those new tags: Tom (the tagger) and Marry (because she is the author) ... and maybe also the Admins and people with special permissions to oversee and moderate folksonomies. Then Mary will have the choice of either accepting some of Tom's tags (green tick) or deleting them (red X) directly from the screen. The tags that she accepts become Author's tags and therefore can be universally visible and her article can be also listed under that new tag for everyone else to see.

What do you think?

chaps2’s picture

chaps2 commented
Version: 5.x-1.x-dev » 6.x-2.x-dev
Status: Active » Fixed

@drupalina - a nice detailed consideration of CT usage, and just as relevant now as when you wrote it 2 years ago.

Additional features added to 2.x-dev mean that all this is possible - functionally at least:

  1. Synchronisation between node terms (e.g. those added by the author on the node edit page) and community tags is now handled by a sub-module which can be configured to make community tags from added node terms but not the other way round. Users' community tags don't become node terms.
  2. Selecting "All tags" display option of "none" means that users only see their own tags on the CT form.
  3. Tag management tab on node page let's the author or anyone with permission remove inappropriate tags. This could be enhanced further to add "promote to term node" and "tag" operations.
  4. Enhanced views integration means that you can display tags in lots of different ways.

There's also Unitag integration now which makes this sort of scenario a lot more manageable. It would work like this: Tom tags Mary's article as "Bullshit". Tom sees his "Bullshit" tag under "My tags" but it doesn't appear in "All tags". The Unitag administrator sees "Bullshit" in the term suggestions queue and either agrees that it's appropriate and approves it, whereupon it becomes a proper community tag and appears under "All tags", or rejects it, optionally adding it to a blacklist to prevent Tom or anyone else from tagging content "Bullshit", and whereupon "Bullshit" quietly disappears from Tom's "My tags" list.

Unitag integration could possibly be improved further by adding an approval queue to the Tag management tab so that a node author can moderate tags per node. And further still if the author received notification when tags were waiting for approval.

Unitag integration will also work without the approval stage, it just applies synonym replacement, blacklist filtering, and rejects or accepts community tags automatically.

There's also a hook in 2.x-dev "hook_community_tags_moderate_tags_alter()" which can be used to plug-in any number of filters and modifiers.

I think I've justified marking as fixed...

Status: Fixed » Closed (fixed)

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