Since publishing my first article on tagging and appearing on MacPowerUsers, I’ve been asked many times for more specifics on my tagging system. I’ll start by telling you that I don’t have all of the answers; what I’m sharing here is what I’ve learned after a few years of constant tagging.
OpenMeta is the most useful tool in my tagging toolbox. It allows me to attach tags to anything with a filesystem representation: websites, documents, photos, source code, emails and more. Before OpenMeta we had to make do with whatever fields Spotlight would search, which was Finder comments on files, and really no options on emails and other items accessed outside of Finder.
Things I’ve learned
The goal of tagging is to associate files into groups that wouldn’t be feasible using a folder hierarchy. As I’ve mentioned before, I still use a shallow hierarchy, especially for grouping project files together. The idea of “one big pile” is as frightening to me as it is to most people. I use tags to create additional groups that might not otherwise be possible, bringing together files and other objects that might be related in ways that a folder reflects.
The primary problem you run into is that tag collections get out of control, and navigating them isn’t any faster than drilling through folders and mailboxes. This happens because multiple forms of a tag are used, or long after the object is tagged the original associations are forgotten. I’ve learned this the hard way, and on multiple occasions.
There are two basic approaches to tagging:
- Tag with anything and everything you could possibly associate with the object (file, email, photo, etc.). It’s a free-association tag-for-all that results in a huge collection of tags. This is navigable, but often results in messy tagging.
- Tag sparingly, only using tags that will be easy to associate other objects with. Anything that is searchable in text or other metadata is left out of the tags. This is the method I’ve come to use.
What I’ve learned is to do follow three obvious-sounding rules: tag intuitively, intelligently, and consistently.
I typically limit myself to three levels of tags. Top-level tags encompass an overall topic or broad scope that the object falls into. For example, if it’s a website, I tag it with the primary keyword that led me to the page, or the subject I was interested in when I followed the link. If it’s a project you’re working on, a client’s name is probably the right choice for a top-level tag. Tags such as “email,” “communication” or “research” aren’t top-level tags. If used at all, those are third-tier.
Second-tier tags divide the group into subsections. If your top-level tag is a client name, then second-tier tags would include a project name or other unique identifier that can be shared across all related files. If you consider your top-level tag specific enough for narrowing a project down in a future search, just skip to third-tier tags.
Third-tier tags are where you begin to cross-pollinate the tag groups. These tags are going to be common tags across multiple top-level groups. Tags like “research,” “approved,” “communication,” etc. can make sense here. This comes down to personal style. The only real rule is that they have to be tags you’ll consistently use elsewhere within other scopes. They’re what make this different from just using a folder hierarchy.
This pattern allows you to view your tag groups in a drill down fashion. If you tag with two or three levels, it increases the ease of browsing in various situations. If you were always going to look for a file as CSS3, you should just use a folder. It’s nice to be able to browse for all your web design articles, but maybe you’re just interested in the CSS articles at the moment.A search for bookmarks tagged “tutorial” and “CSS3” will quickly produce all of the relevant articles you’ve found in your web browsing.
Choose tags that will be useful next year
“What will I search for when I’ve forgotten this item exists?” It’s not always an easy question to answer. The basic rule is to take what first comes to mind and ask yourself that question. Is the first association you make related to current circumstances or events? You might not have that association in a year. You want to use tags that come to mind easily, but double-check yourself to make sure it will be as front-of-mind when the time comes to search.
For example, if it’s a website, tag it with the primary keyword that led you to the page, or the subject that you were interested in when you followed the link. If it’s a project you’re working on, a client’s name and the scope or project name are probably the right choices for top-level tags.
There are a lot of edge cases. You get better at it after you’ve had to deal with your own tags for a few years.
These are common sense rules that make tag collections work. You probably know them already (or have figured them out if you’ve been tagging for a while).
Don’t tag with data already available
Unless your system has no other means of searching metadata, you can always add things like dates, filetypes and even content to your search to find specific files within a tag group.
Use lowercase tags. Always
It gets messy if you’re inconsistent, and autocomplete will almost always substitute the first capital letter it comes across in a completion, resulting in your previously unused tag now being capitalized.
Don’t use “flagged” or other time sensitive tags
This one needs some explanation. Unless you are religious about removing “tickler” tags as you go, find another way to denote importance of the tagged element. Finder labels work well for files, and you can keep a “Current” folder with things that need to be attended to. Once you’ve handled whatever needs to be handled, you file it (or send it to a script that will).
I know this from experience. I tend to be pretty good at reviewing my systems, but the “flagged” and “important” tags got out of hand quickly. Pretty soon I was looking back at flagged files, emails, photos and bookmarks and I really had no idea why they were important anymore.
In a best-case scenario, you’re using a project/task management solution that allows links. If I need to reply/follow-up on an email later, I drag it into my task manager and create a new task. That gets the flag, the due date, and any notes I need to remember why. I could tag/flag the email as well, but then I’d have to untag it later. This way I just check off the task. Side benefit: assuming you don’t delete completed tasks, you can find it later and follow the link as an easy bookmark.
If a tag is used only once, you’re wasting your time. You could have found that file, page, calendar entry, etc. with Spotlight. You didn’t need a tag to do that.
Keep a list of common tags if you need to, at least until they become second-nature. Most of the tagging applications will show you common/recently-used tags when you’re tagging. The best thing in the world can be autocomplete, assuming your tag collection isn’t already a polluted mess. Autocomplete in tag dialogs means you don’t have to struggle to remember casing, plural forms, etc., just go with what you did before.
I generally try to avoid capital letters, hyphenation and plural forms. I’ll use multi-word tags frequently, but without punctuation or intercaps.
There are some obvious exceptions to these rules in my system. For example, I keep a list of things I want using a “tobuy” tag. I have to manually untag these things as I buy them or decide I don’t want them anymore. The tag works really well with Smart Folders in Finder, though, and I don’t have trouble keeping up with it. It’s not an area that changes rapidly; just a folder I can browse when I have some spending money and a shopping urge. On these occasions I just untag “tobuy” items as I go through them. It never gets out of hand and it never takes long to update. Unlike the “important” tag I used to use in all of my projects, “tobuy” is basically a top-level tag that I always search for across all topics and groups.
I also sometimes use questionable tags for scripting purposes. I prefer client→project folders to their redundant tag counterparts, mostly just because I’m going to separate those anyway for the sake of filing sanity. I’ll use client/project tags on files on my Desktop, though, and my scripts will automatically sort those tagged files based on their tags and subtags. It’s a bit of a complex system, but it lets me use my Desktop as a general bucket for everything I’m working on, and have the various elements from multiple projects all neatly filed at the end of the day. The filing tags can be removed by the script after they’ve found their home.
There are plenty more exceptions. I don’t think any two people’s tagging systems will be identical. It’s the beauty of tagging: you can build a system that works for you. It doesn’t have to be rigid, but some general, self-imposed rules can definitely make it a more useful process.
Warning: there is no guarantee that we will always have OpenMeta. OpenMeta uses extended attributes in the UNIX subsystem and it’s not impossible that Apple would pull the plug on OpenMeta’s ability to maintain tags in these xattr’s. However, the current OpenMeta implementation stores tags in two different attributes and keeps a redundant backup of all tags/file associations. It’s a safe bet for now. ↩