Tag Management Part III - adding new tags
Following up on the last two discussions, question #3 is as follows.
You add new tags in to the text field up top. Do those new tags get added to the rows at bottom, with the “Remove” checkbox empty? Or do they get added only when you click “OK”? Put in other terms, does the “New tags” textfield up top impact the rows at bottom even before you click OK (although not affecting the actual articles themselves until OK), or are the two activities separate?
For a good example of this, try the live sample we have posted (see the following blog post). The option is “New Tag Add.” To try it, select “Text Only” or “Add to Rows” followed by update. Then, go into the “New tags” textfield in the form, add some tags, and hit enter. In the case of “Text Only,” enter will do, well, nothing, since the new tags are only in the textfield. In the case of “Add to Rows,” all the new tags will be split on comma (and possibly whitespace, depending on your selection in the option of “Whitespace Handling,” and then be added to the rows.
Looking forward to your great feedback once again.
Avi
July 18th, 2008 at 7:31 am
I have tried the sample - and it seemed more intuitive to me to use the “Text Only” option, when adding tags.
I could see the concept behind adding to rows - particularly if you wanted to add a load of tags for a particular categorization scheme that you wanted to pre-load. This is not something that I can imagine myself doing, although I could quite see that someone with more rigourous thought processes than myself might want to.
However, when I add content to Surfulater, I would prefer that the tags to be added are the ones in the “New Tag” box. (Including tags that already exist in the database, because that seems more intuitive).
Perhaps there needs to be a separation between the functions of :
1. Maintaining tags (adding, removing, renaming - possibly reassigning), and
2. Adding tags to an article - The tags I enter into the “Tags” entry box (which include both new and existing tags) will all be assigned to that article.
July 18th, 2008 at 7:53 am
Does there need to be a clearer distinction between:
1)”new tags” = “tags that are new to the selected articles”; and
2) “new tags” = “tags that are new to the system as a whole”
In our conception, you rarely create new tags explicitly, without some article involved, although you certainly could from the tags tree pane. From a tag management perspective, you simply type tags that you want to add to the selected articles in the “new tags” textfield. If the tag exists (and it will show up in the drop-down as part of type-ahead), it is added to all the articles; if it does not, it is created in the system, *and* added to the selected articles.
Avi
July 18th, 2008 at 9:26 am
Personally, I agree with you, Avi - I will only create new tags when I add an article.
However, I can envisage an alternative scenario, where someone has thought out categorisation beforehand, and wants to keep tagging consistent.
However, many sites that allow content tagging have shown that real value can be generated through “emergent” knowledge (such as LibraryThing, for instance) developed through crowd-sourced tags. While this is not directly applicable to an application that is person-centric, I believe that there is still value to be created through tagging.
On the other hand, you might want a different way to organise tags - to merge/rename/delete. Some applications, for example, distinguish between case of tags (”Sheep” is a different tag from “sheep”, for example). This is unintuitive, if understandable from an implementation perspective.
July 18th, 2008 at 9:28 am
You can still add and manage tags directly from the tag tree view, which is the most direct place.
Can you expand a bit on how you would use emergent knowledge in the context of Surfulater? Think as broadly or wildly as you like.
Thanks,
Avi
July 18th, 2008 at 10:47 am
Good reminder about the tag tree view!
The use of tags in Surfulater inevitably leads to emergent knowledge about the content encapsulated therein.
When you start a knowledge base you have an idea about the sort of content you will store there. However, you usually have no idea what will actually be stored there. As tags are added (and as content is stored) you can learn more information (meta-information, if you like) about the content.
A review of your tag clusters (or tag clouds as they’re sometimes termed) can reveal information about the sort of knowledge that you are choosing to store in this particular knowledge base. Depending on the purpose of the knowledge base, this could guide your information collection behaviour. For example, you might identify that there is a particular topic that you have not captured information about. Or it might be that there is a wealth of information about one particular area, and that it might be better to spin off a separate (dedicated) knowledge base on that subject.
The use of emergent knowledge in a Surfulater context is a bit a moot point as there is no way to display your tag cloud at the moment. It would be great if there was though! Perhaps this could be considered as a later improvement?
Or it may be more simple than I think to provide an indication of how many articles are using each tag in the tag view (eg sheep (4) shows that 4 articles currently use the “sheep” tag).
July 18th, 2008 at 8:05 pm
@David,
>The use of emergent knowledge in a Surfulater context is a bit a moot point as there is no way to display your tag cloud at the moment. It would be great if there was though! Perhaps this could be considered as a later improvement?
It is on the todo list.
>Or it may be more simple than I think to provide an indication of how many articles are using each tag in the tag view (eg sheep (4) shows that 4 articles currently use the “sheep” tag).
You can do this now, but it needs a little tidy up. Right click on whitespace in the Tags Tree and select “Show Article Counts”.
There are two bits to the tidy up. First the menu item text is misleading and comes from the Normal Tree Views. Second we probably want this to be a separate option so it can be turned on/off independently for the Tags Tree view vs. the Normal Tree view.
Neville