I originally wanted to propose it as “MAIL:tag”, because it’s for the use with emails that it’s come up. But “tags” could be useful for all sorts of things, therefore “META”.
Since the good ol’ BeOS times we’ve been using “MAIL:status” to assign custom categorizations to emails. Haiku’s Mail app can be used to set arbitrary statuses via its “Close and | Set to…” menu.
That’s really not that great. It overwrites the actual state of the email: New, Read, Seen, Sent, or Pending.
Wouldn’t be nice to leave “MAIL:status” for tracking the actual state of an email and let the user categorize them with a new “META:tag”?
I think “tag” isn’t a bad word for its usage. “Comment” or “description” suggest whole sentences that are quite specific to the contents of the file, while “tag” is a short, probably one-word, categorization, letting you group many similar files.
For example, I might tag an email with “Userguide” for some commit mail or post in a mailing list discussion. Then, before a new release, I can query for “Userguide” to see what changes the docs need.
If I gave a full description or comment on each of those mails, I’d struggle to catch them all with one query.
WRT to multi-value, that’s really up to each user. They could introduce some hierarchy, like “C++:Clipdinger”, “Docs:Clipdinger” etc. for all their projects (or use commas, semicolons or spaces as delimiter). Their queries would simply be “Tag contains C++” to get all C+±tagged mails, or “Tag contains Clipdinger” to get all mails they tagged for that project.
Or they use simple tags like “Don’t forget”, “Tax”, or “Joke” or whatever.
It would be supernice. I love the implementation of MailMate (for macOS) for example. But even among email clients, it seems extremely difficult to agree on certain standards.
Problem is, when I hear about tags, I always think of a list of strings, not just one. When searching for items with the tag Tax, I wouldn’t get the ones tagged Taxi, unless they also include Tax in theirs tags. You can use a separator and regex your way to the truth, but it gets ugly and prine to errors, and the UI would still be about a long string, not a list of items.
But then we have the same problem with artists in media files, I guess.
I think this is a great idea, but of course, I am biased (because I would want this for EmailViews).
Like @humdinger, my initial thought was a MAIL:tag that I could use in EmailViews, but a META:tag sounds like a much better idea. It would be great to see this added to Haiku.
Perhaps the developer of SEN @grexe has any thoughts on this? Just wondering…
It’s even less an issue when using the tag-attribute for emails:
You may have hundreds of artists, dozens may share parts of their artist’s name.
You most probably don’t have more than a dozen email-tags. And crucially, contrary to artist names, you have complete control over the tags. If you notice a new tag colliding with another tag, choose another tag.
You may also query for the exact tag, instead of “contains”, so e.g. query tag==“Tax”, instead of tag==“[tT][aA][xX]”) to avoid finding “Taxi” when you want “Tax”.
And I wouldn’t have the ones that include Tax and other tags. There’s a solution for that too, but it’s ugly.
I guess my only problem is that when I hear tags I picture items with possibly several coloured stickers on them. It seems like a good idea to add random strings to your files, though. I’m not trying to shoot it down. And if you think you need multi-valued tags just because of different categorizations, you can use those thingies that Haiku has… attributes. Just a different one for each category.
I’m not sure trying to shoehorn multi-value attributes into the current BFS attribute architecture is doing any good. The currently (mis)used MAIL:status is single-value, as are all BFS attributes (without resorting to “manually” adding them comma-delimited or however).
The suggestion is to let the user continue to tag their emails with a new attribute, in order to preserve the actual MAIL:status of emails. Is there a better attribute name than “tag”?
Would MAIL:tag be preferred over META:tag? Of course, nothing prevents anyone to add a MAIL:tag no a non-email file, but “META” encourages a wider use.
When it comes to naming, I’m as bad as anyone else.
I have no issue with the prefix. In fact, I have no real issue with anything. I’m just saying one might expect the ability of sticking several tags to the same file, so that has to be considered. If once taken into consideration, the conclusion is “not really” or “well, there’s nothing we can do about it, but still adding it is an improvement”, so be it. That expectation would probably be the same whatever the name, so I guess I’m just adding noise here. Sorry for that.
Perhaps adding Mail:Category would be sufficient for most? Advantage is that you can limit the number of categories and so show a selection in an interface. Another thing that would be interesting is Mail:Urgency. And I would also add a binary flag “Don’t delete” useful for messages containing credentials. The idea is to cover possible misuses before introducing Tag.
A bit of why I was wondering about multi-value is that something called a “tag” is multi-valued everywhere else, so users will expect that. And before we have another ten different ways of doing things, it might be good to spend a few minutes and figure this out first.
Alternatives to “tag”:
category
subject
topic
group
But “tag” can also mean more structured things as pointed out above (status, lifecycle, priority, importance, urgency, audience, …)
Naturally, if it is meant to handle multiple dimensions, then it needs multiple values. If it is not meant to handle those dimensions, it might be nice to include them as negative cases in a attribute description.
None of these really strike me as fitting the purpose for emails. (Let’s just introduce MAIL:tag as the more general META turns out to be surprisingly controversial).
Again, Mail allows to overwrite the Status attribute with one arbitrary string.
Maybe people using this feature can describe how they use it. I use “Userguide” to track mails concerning changes relating to the Userguide. Once I made those changes, I remove that status, it goes back to “Read”.
I used to add a “4Later” for the stuff I plan to deal with at a later time. Once dealt with, it too goes back to “Read”. Now I use the genuine status “Star” for that.
I consider adding “Prio-1”, “Prio-2”, “Prio-3” for mails I have to deal with later, and prioritize their importants. Once dealt with, they’ll go back to “Read”.
I’m open for another word but “tag” for this use of a single-value string, but nothing better comes to mind. “Status” was quite nice, because it describes a single-value state of things.
You also have to consider how the menu in Mail will be labeled “Tag as…” with a submenu of your already entered tags is quite intuitive, I think.
It’s probably just me, but when I see “flag” I expect to see a Boolean value, not a string.
Exactly. But “Flag as …” doesn’t work that way. You flag a mail as read, you flag it as spam, you flag it as High-priority. It is, in English, anyway, a synonym for “mark”. Radio button territory.
