One theme that I’ve noticed is gaining quite a bit of popularity in information and user experience design, over the last few years, is the notion of organizing information via tagging, as opposed to the more traditional hierarchical folder structure.

Wait, whaaa…?

Picture your desktop. Not your computer desktop, the physical workspace surface you have in front of you after your computer gets stolen.

Now picture your desktop after a busy day’s work. Chances are you have papers and documents of every kind that you need to organize and put away. Unless you have a system of filing them, you’ll never find them again, when you need them most. So a good filing system is crucial if you want to stay organized.

The traditional solution has been a filing cabinet, packed full of alphabetically-, topically-, or chronologically-sorted folders, into which you’ll divvy and drop your day’s documents. Fine.

Along comes Apple, and in 1984, along comes the first Macintosh, with System 1.0. This is a breakthrough computer for many reasons, not the least of which is its great new Graphical User Interface (GUI). For the first time, users are able to switch on their computer and be presented with a graphical view of what a work area may look like. There’s a floppy disk icon where your files and documents are stored, a desktop where you can create and keep documents temporarily (spreadsheets, texts, images, etc…), and even a trash can where you drop the stuff you don’t need anymore.

And the coolest thing of all is that the virtual folders on the floppy disk icons even look like the paper file folders you keep in your filing cabinet. There’s even a little tab for labels!

The original Macintosh desktop, with tabbed folders and a trash can!

Even better, virtual folders can contain other virtual folders, and so on, which is hard to do with physical paper file folders.

(To be fair, the idea of folders existed way before the Macintosh; but I think they generally tended to be called directories, and Apple was one of the first companies to equate them to real-world file folders).

The idea of storing documents in a system of folders has been persistent and continuous throughout the history of personal computers until today. It’s a very comfortable way of working with computer files, because it’s very like the way we work with physical paper documents. When an idea like this one becomes so natural to the way we work, it’s hard to find a reason to change it.

Apple was so fully committed to the analogy of storing files in a hierarchy of folders that they even developed a filesystem format called HFS, or Hierarchical File System. (A file system is the nitty-gritty technical specification that defines how your documents and folders are stored as binary 1′s and 0′s on your hard drive.)

Today, on any hard drive, you can easily see evidence of a hierarchical file structure:

A typical hierarchical file structure - This is what is meant by hierarchical: your files and folders are "layered". The first layer consists of a single folder ("Nuclear Launch Sites"), which contains a second layer of folders ("Abuja", "Dubai", "Reykjavík", "Tallahassee"), and so on…

This works well enough for most, but there is a fundamental problem with this model of organizing information: it’s not always easy or convenient to partition information in this manner. For instance, in the example above, I’m showing a list of files related to my nuclear launch site in Reykjavík. And if I looked in my other folders, I’d find much of the same information — launch codes, checklists, strategic attack maps, instruction manuals, etc…

But what if I want to get the usage instructions for the Easy-Nuke EN53, and I don’t remember which site uses it. I can either (a) browse through each folder until I find it, (b) re-organize my files by machine type rather than by city, or (c) search for the file.

In the age of Google, the vast majority of users would pick (c), since it requires much less work and doesn’t require any tedious manual steps. So the question arises, “If I’m going to search for the information anyway, is there any point in organizing it in folders to start with?”

Since the paradigm of searching for information seems to have overtaken the outdated paradigm of browsing for information, it seems only logical to do away with the idea of organizing information in hierarchies, and in folders. Isn’t this better:

A Searchable File Folder - Since we're going to be searching for information instead of browsing through folders to find it, why even bother creating an artificial and arbitrary filing system? Why not just throw all the files in the same folder?

Gone is the need to create a classification system for your files and folders. Just throw everything in a big shoebox and have the computer search through it on a case-by-case basis. That’s what Google does with websites, and they’re doing pretty well…

However, it gets a bit messy. Since I’m not allowed to have two files with the same name in the same folder, I either have to tack on arbitrary identifiers (e.g. “Launch Checklist [2]“, “Launch Checklist [3]“, etc…), or descriptive identifiers (“Arming Procedure [Tallahassee]“). This is because I am trying to throw files together on a hierarchical (old-paradigm) file system, and these systems are limited by the concept that each file is identified by a unique file path. Therefore, no two files in the same folder can have the same name. The specifics here aren’t as important as the idea that personal computers aren’t designed to routinely use the searching paradigm, they’re designed for browsing. Google has no such limitation, as there are no rules to say that Google can’t index more than one website called, say, “My Blog”. Google was designed around the search paradigm. Those engineers knew what they were doing!

Another problem I might encounter is that unless each of my Tallahassee documents contains the text “Tallahassee”, they won’t necessarily come up when I search for “Tallahassee”. Worse yet, if one of my Reykjavík documents contains the text “Tallahassee” (since “Tallahassee” is a launch code as well as a place), it will also come up.

This is where the idea of tags comes in. Tags are an intermediary between the searching and the browsing paradigms,  a way of labelling the kind of information contained within a file (or website, photo, whatever). Probably the most widely-known examples of tags are Facebook’s photo tags — bits of information that accompany any photo, and describe what’s (who’s) in the photo.

Because tags represent information about information, they are sometimes called “metadata” (data about data). Unlike folders, however, tags / metadata don’t define how the information itself is structured, they merely give clues to anyone searching for a specific piece of information inside a file, photo, map or whatever.

Tags can generally be arbitrary bits of text, making it possible to provide a virtually limitless number of groups, and I can tag a file with as many different keywords as I desire:

A File Info Box with 4 Tags Assigned - By entering a comma-separated list of keywords, I can quickly search for any of these terms, and have this document show up in the result.

With these tags, I can now search for “Abuja”, and guarantee that this tagged file will be among the search results even though the text “Abuja” might not appear anywhere in the actual document. Likewise, I can also flag this file and others with a “Make Backups” tag, and easily retrieve them all when it’s time to make backups.

Tags are a wonderfully versatile type of metadata, because they allow for both browsing and searching, they don’t limit a file to being categorized in a single top-down manner, and they are (usually) arbitrary, meaning you can enter as many or as few tags as you want.