Just a wish: option to disable ad hoc creation of tags in the future version of DT3

I wish that there is an option to disable the ad hoc creation of tags in the future version. Depending on the purpose and stage of info management and project, some times we need the flexibility to create new tags on-the-fly at the inspector/tag bar but some times we want to limit the choices to only the existing tags.

I guess this feature is not a must have for most users, so just a wish.

1 Like

Thanks for the suggestion! Definitely a unique one, can’t remember similar requests so far.

Just the results of hitting enter too fast for too many times. And I need to be more disciplined in structuring my tags trees!
If there are just a few tags, using tag groups is a work around because the nature of assignment inherently limit the choices. However, when entering tags in inspector bar the autofill does not discriminate tags and tags group - unless only tags groups are used. Another option is to assign a tags group specific prefix to all tags group.

+1

(in my case it’s always pressing enter too quickly, creating a new tag which usually consists of the first few letters of a previous tag…)

@ngan: how would you suggest implementing that? In my use case having an error window pop up (“It looks like you’re trying to create a new tag; go see an administrator; press ok to continue working”) would slow my workflow, and so probably be counterproductive. I think I’d want something less invasive, e.g. a tip or a message in an info-bar etc. with DT simply ignoring the input until an existing tag is chosen. Or would that stump people?

This would probably affect the workflow of many, maybe even most users.

I guess it’s going to be exactly like the current DT3 way except that if the tag does not exist in the database then the available list will be the most likely matches. I don’t think any warning or flag is needed (too disrupting), just limit the choice to the most likely matches.

Now, if users really need to add new tags, they can go to the tags and add it. That’s why this “wish” will only be handy for a small percentage of time/tasks. The option is not meant to be a time saver or error checker, but a more discipline way of classifying the info by tags - which is very useful in some situations.

cheers for the clarification

that’s what I’m worried about - implementation would need to be in such a way that it was obvious what is happening (otherwise the forum will be full of unhappy posts like "why does nothing happen when I type “Z”, or why do I get tags starting with “X” when I type “Z”) but non-invasive at the same time.

some times we need the flexibility to create new tags on-the-fly at the inspector/tag bar but some times we want to limit the choices to only the existing tags.

Color me stupid, but I’m not seeing how that’s not the current behavior already.

If I type s, I have the ability to type a new Tag, like snarky, or choose from potential matches from the Tags in the database (or from all databases if you’re in the Global Inbox).

1 Like

What happens to me occasionally is that I create a new tag unintentionally:

I have tags calls e.g. abc123, abc345, abc567. Now, I type “ab” and hit enter - what happens is that a new tag called “ab” is created. Don’t get me wrong, I well aware of where the problem is sitting in this case - just sometimes my hand kinda overtakes my brain I guess :wink: so being able to set “no new tags from the inspector” would be helpful (not essential).

I think the OP however was thinking along different lines, namely limiting the scope for creation of new tags from a certain point on in a project (to avoid mess, my words, not his) - if my experience of projects is anything to go by, I could second that request. With a limit in place, users would be forced to choose from pre-prepared tags rather than creating their own; quite obviously something which would not always be appropriate, but could on some cases make tagging more effective. I think.

Perhaps you’re correct. If that was indeed the case, I would suggest having per-project databases to isolate and manage Tags in a segregated environment.

1 Like

That’s probably a clean solution, yeah

1 Like

(1) Typing too quickly and hit enter while missing a letter for a tag that I think definitely exists without checking the drop-down list gives me one extra tag at the top level in which the right one is located three levels down somewhere. So I need to “find” the location and move/change the assignment and delete the bad ones.
(2) I use “find” because I usually am more liberal and naive in understanding and building up the right categorisation of knowledge during the 1st/2nd round of review process. I kind of tagging the literature largely influenced by how the authors think. Since different authors are using different wordings and concepts, ideas begin as a messy tags tree and expand endlessly without real discipline. At this stage, ad-hoc and flexibility in tag assignment is necessary/natural.
(3) Then, when a relevant framework is established in the later stage of review/reading, the literature will be tagged according to what I think and not how the authors think. At this time, a leaner and meaner tag structure will be pre-built, and I hope I can precisely and efficiently forcing myself to categorise knowledge according to the new/modified tags tree. So disable ad-hoc creation of tags is a way to increase efficiency and to push myself to put stuff in a framework that I will finally use for analysis.

Just my way of doing research and I guess that’s why the suggestion is just a “wish”…

but also well-supported in grounded theory…see e.g. Introduction to Grounded Theory

I agree that this would be really valuable. For later rounds of coding / tagging, a finite and restricted list of tags would be preferable.

Thank you for this topic. It helped me think about better ways to structure my databases.