7 ms·

The ideal implementation of tags (at least during the transition) is tags as pseudo-folders. That is, you drop a document into "Projects"->"2012"->"Foo" and th

by roc 14y ago

The ideal implementation of tags (at least during the transition) is tags as pseudo-folders. That is, you drop a document into "Projects"->"2012"->"Foo" and the flexibility of tags is simply hidden away until needed. When it is needed, that file can also be 'added to' the 'folders' "Teams"->"Alpha" and "Clients"->"XYZ Corp". So, sort of like folders by a different name. But more like folders++. With complexity hidden until desired. How files are physically stored is neither here nor there.

funthree 14y ago
This seems the most intuitive. You could have some flattened view of a folder where it shows everything with tags, or you could navigate by folders. So if you have two folders and two subfolders by the same name, with the flattened view you can see all of the similar items. However, doing away with hierarchical folder structure is a bad idea. > module-1 > views > other-thing > views > module-2 > views > module-3 > views
- roc 14y ago
  Eventually users might get to the point that the hierarchy is unnecessary. Surely it's more efficient to type out "2012, foo, xyz corp, alpha". And it's certainly easier to type out a few tags than navigate a few trees to do a search. But people have stubbornly resisted that for so long, I wouldn't hold my breath. [1] [1] It seems just about every document management system since the 90s was designed under the "search, don't scan!" assumption, stubbornly clinging to theoretical efficiency and then grumpily (and often painfully) adding back in 'artificial' folder structures built from the tags for both file->open and file->save UI.
  - secabeen 14y ago
    Not necessarily. The biggest problem I've had with tags is consistency. When I'm tagging photos of my kids, every time I have to remember "did I tag these with kids, rebecca, becky, daughter, or children?" It gets tedious. Sure, you can maintain a list of commonly-used tags, but that list often changes on a per workflow basis. Folders give you the benefits of tags with a hierarchy and smaller search space. When I open my work folder, I see a list of each of my projects. From there, I can go into that project, and see directories that are specific to that project. In a tag-based system, I have to remember all of the requisite tags from the beginning, or I have to go through an iterative process adding tags, seeing if I got the right one, and if so, then looking at the new list of suggested tags. Folders let the computer remember how things are organized and lets the human select from that organization. Also, this article gets the details wrong. For example, you certainly can nest folders in the real world. Take a personnel file cabinet, with a 2012 drawer, with a hang folder for each employee that contains a manila folder labeled timecards. That's 4 levels of nesting and it works fine.
AndrewDucker 14y ago
Of course, folders imply more of a relationship than tags do. If I'm keeping files on what multiple companies are up to I might have: Company A -> Secrets -> Company B and Company B -> Secrets -> Company A To denote the secret files that each company is keeping about the other. The tags would be identical, but the folder structures entirely separate.
- deleted 14y ago
  [deleted]
bradleyland 14y ago
I completely disagree with this based on my experiencing working with several companies who moved to Google Apps. Some of these companies are small businesses (10-25 employees), but some are large organizations with hundreds of employees and retail locations around the country. The problem with tags as pseudo-folders is that it breaks a core promise of "folders". Folders are a metaphor, and when you use a metaphor like files & folders, you're making a promise to the user. You're saying: "I'm making these things familiar to you so that you don't have to learn a new behavior." To be clear, I have no problem with tags, and I do believe that the standard "hierarchy of folders" we use today is untenable with the volume of documents we generate, but extending folders is a bad idea. The reason this breaks so badly is that users expect to preserve the basic move/copy dichotomy of a file/folder when we represent items as such. This expectation is rooted in the metaphor of a file or folder in the real world. I cannot place a physical document in to two folders without copying it. When I copy the document, changes made to the replica are not retroactively applied to the parent. I have seen many Google Docs users lose hours of work because they used the "collections" feature of Google Apps incorrectly. An example, I've seen plenty of users do the following in an attempt to copy a file to a new collection in Google Docs: * Locate an item that is already in a Collection * Check the item in the Document List * Click the "Organize" icon (it's a folder) * Check the box next to another collection where they want the copy * Click "Apply Changes" The vast majority of the users I work with assume that the "same" document cannot exist in two places at once. They assume this because that is the way that files & folders have always worked. If an action results in the appearance of two documents, there are two documents. The item has been copied. It doesn't matter whether the language "copy" is used. The action is implicit in the learned behavior of files & folders. Tags should be called tags. Users are smarter than you think. As engineers, we might be frustrated by the assumption made above, but in reality, the user is drawing an inference based on past experiences. They're applying conceptual knowledge that we taught them. That's "smart". Implement a tagging system in a way that solves users' problems and they'll flock to it, but don't make it opaque by masquerading as something they already know.
- roc 14y ago
  It's not about whether users aren't smart enough for tags. It's whether tags work the way users want them to. Tags are for organization. People like to organize things in terms of visual hierarchies and landmarks. Raw tagging systems aren't popular, because most people don't memorize precise strings. [1] They remember roughly what directories look like and 'know where things are' based on whether they believe they can confidently determine "it" from "not it" while they navigate a structure. e.g. Was the tag "RaptorX" or "2012 Predator" or "FooBird"? The user doesn't know. But they do know that when they navigate their project folders, they'll be able to pick out whichever project was fuzzily translated to "something like a bird of prey" in their mind. And they'll be able to do this as they navigate into a tree, as fast as if they had remembered exact strings. [2] So when people are looking for something quickly, they're going to like the visual hierarchy. And when they're first saving a file [3], or when they're looking to open something when they 'know' where it is, they respond very positively to a visual hierarchy. It's not about 'hiding' the fact that those 'folders' are tags. Or hiding the fact that files can live in multiple places (with multiple versions no less). We're still talking about new software that people would have to be trained on and told about its particular attributes. So the fact that, yes, you need a dialogue to capture explicit intentions when doing move/copy operations in a pseudo-folder tag system is not a problem. [1] Also why command line OSs and command line navigation are unpopular. People really like visual organization. [2] In my experience, this is what people are really saying when they insist they'd rather navigate than search, even when they 'know' where something is. It's because they "know" where something is, in terms of landmarks in the visual tree. They know in a fuzzy way. And fuzzy searching is either frustrating, or requires nailing down enough tangential data (user/date/file type) that searching isn't any faster than navigating. [3] Almost no-one wants to think about proper taxonomy or organization or an exhaustive document profile when they're drafting a new document. They just want to stash things somewhere where they can find them tomorrow and/or reasonably direct a third party to them. Proper organization is almost always a discrete mental process that happens after a document is 'done'.
BitMastro 14y ago
I think that the problem with tags is the lack of intrinsic hierarchy. While you can flatten the hierarchy by enumerating all the tags, this approach is boring if done manually or requires an accurate ontology if done automatically. Another risk is a result from the paradox of choice. Which tags are appropriate? Did I use the same word as before? Will I be able to remember it? With folders you are able to further refine your lookup, and a document must be in a folder anyway, while it can lack a tag. Of course these are just points that can be overcome in a way or another by a good implementation, but folders, symbolic links and tags together are IMHO a better alternative that tags alone.
sp332 14y ago
To make them work like folders, you would need a query like "Team and Alpha but nothing else" because otherwise each pseudo-folder would also have all subfolders' documents in it.
srathbun 14y ago
Umm, there's this thing called hard/soft links...

by roc 14y ago

funthree 14y ago

This seems the most intuitive. You could have some flattened view of a folder where it shows everything with tags, or you could navigate by folders. So if you have two folders and two subfolders by the same name, with the flattened view you can see all of the similar items. However, doing away with hierarchical folder structure is a bad idea. > module-1 > views > other-thing > views > module-2 > views > module-3 > views

roc 14y ago
Eventually users might get to the point that the hierarchy is unnecessary. Surely it's more efficient to type out "2012, foo, xyz corp, alpha". And it's certainly easier to type out a few tags than navigate a few trees to do a search. But people have stubbornly resisted that for so long, I wouldn't hold my breath. [1] [1] It seems just about every document management system since the 90s was designed under the "search, don't scan!" assumption, stubbornly clinging to theoretical efficiency and then grumpily (and often painfully) adding back in 'artificial' folder structures built from the tags for both file->open and file->save UI.
- secabeen 14y ago
  Not necessarily. The biggest problem I've had with tags is consistency. When I'm tagging photos of my kids, every time I have to remember "did I tag these with kids, rebecca, becky, daughter, or children?" It gets tedious. Sure, you can maintain a list of commonly-used tags, but that list often changes on a per workflow basis. Folders give you the benefits of tags with a hierarchy and smaller search space. When I open my work folder, I see a list of each of my projects. From there, I can go into that project, and see directories that are specific to that project. In a tag-based system, I have to remember all of the requisite tags from the beginning, or I have to go through an iterative process adding tags, seeing if I got the right one, and if so, then looking at the new list of suggested tags. Folders let the computer remember how things are organized and lets the human select from that organization. Also, this article gets the details wrong. For example, you certainly can nest folders in the real world. Take a personnel file cabinet, with a 2012 drawer, with a hang folder for each employee that contains a manila folder labeled timecards. That's 4 levels of nesting and it works fine.

AndrewDucker 14y ago

Of course, folders imply more of a relationship than tags do. If I'm keeping files on what multiple companies are up to I might have: Company A -> Secrets -> Company B and Company B -> Secrets -> Company A To denote the secret files that each company is keeping about the other. The tags would be identical, but the folder structures entirely separate.

deleted 14y ago
[deleted]

bradleyland 14y ago

I completely disagree with this based on my experiencing working with several companies who moved to Google Apps. Some of these companies are small businesses (10-25 employees), but some are large organizations with hundreds of employees and retail locations around the country. The problem with tags as pseudo-folders is that it breaks a core promise of "folders". Folders are a metaphor, and when you use a metaphor like files & folders, you're making a promise to the user. You're saying: "I'm making these things familiar to you so that you don't have to learn a new behavior." To be clear, I have no problem with tags, and I do believe that the standard "hierarchy of folders" we use today is untenable with the volume of documents we generate, but extending folders is a bad idea. The reason this breaks so badly is that users expect to preserve the basic move/copy dichotomy of a file/folder when we represent items as such. This expectation is rooted in the metaphor of a file or folder in the real world. I cannot place a physical document in to two folders without copying it. When I copy the document, changes made to the replica are not retroactively applied to the parent. I have seen many Google Docs users lose hours of work because they used the "collections" feature of Google Apps incorrectly. An example, I've seen plenty of users do the following in an attempt to copy a file to a new collection in Google Docs: * Locate an item that is already in a Collection * Check the item in the Document List * Click the "Organize" icon (it's a folder) * Check the box next to another collection where they want the copy * Click "Apply Changes" The vast majority of the users I work with assume that the "same" document cannot exist in two places at once. They assume this because that is the way that files & folders have always worked. If an action results in the appearance of two documents, there are two documents. The item has been copied. It doesn't matter whether the language "copy" is used. The action is implicit in the learned behavior of files & folders. Tags should be called tags. Users are smarter than you think. As engineers, we might be frustrated by the assumption made above, but in reality, the user is drawing an inference based on past experiences. They're applying conceptual knowledge that we taught them. That's "smart". Implement a tagging system in a way that solves users' problems and they'll flock to it, but don't make it opaque by masquerading as something they already know.

roc 14y ago
It's not about whether users aren't smart enough for tags. It's whether tags work the way users want them to. Tags are for organization. People like to organize things in terms of visual hierarchies and landmarks. Raw tagging systems aren't popular, because most people don't memorize precise strings. [1] They remember roughly what directories look like and 'know where things are' based on whether they believe they can confidently determine "it" from "not it" while they navigate a structure. e.g. Was the tag "RaptorX" or "2012 Predator" or "FooBird"? The user doesn't know. But they do know that when they navigate their project folders, they'll be able to pick out whichever project was fuzzily translated to "something like a bird of prey" in their mind. And they'll be able to do this as they navigate into a tree, as fast as if they had remembered exact strings. [2] So when people are looking for something quickly, they're going to like the visual hierarchy. And when they're first saving a file [3], or when they're looking to open something when they 'know' where it is, they respond very positively to a visual hierarchy. It's not about 'hiding' the fact that those 'folders' are tags. Or hiding the fact that files can live in multiple places (with multiple versions no less). We're still talking about new software that people would have to be trained on and told about its particular attributes. So the fact that, yes, you need a dialogue to capture explicit intentions when doing move/copy operations in a pseudo-folder tag system is not a problem. [1] Also why command line OSs and command line navigation are unpopular. People really like visual organization. [2] In my experience, this is what people are really saying when they insist they'd rather navigate than search, even when they 'know' where something is. It's because they "know" where something is, in terms of landmarks in the visual tree. They know in a fuzzy way. And fuzzy searching is either frustrating, or requires nailing down enough tangential data (user/date/file type) that searching isn't any faster than navigating. [3] Almost no-one wants to think about proper taxonomy or organization or an exhaustive document profile when they're drafting a new document. They just want to stash things somewhere where they can find them tomorrow and/or reasonably direct a third party to them. Proper organization is almost always a discrete mental process that happens after a document is 'done'.

BitMastro 14y ago

I think that the problem with tags is the lack of intrinsic hierarchy. While you can flatten the hierarchy by enumerating all the tags, this approach is boring if done manually or requires an accurate ontology if done automatically. Another risk is a result from the paradox of choice. Which tags are appropriate? Did I use the same word as before? Will I be able to remember it? With folders you are able to further refine your lookup, and a document must be in a folder anyway, while it can lack a tag. Of course these are just points that can be overcome in a way or another by a good implementation, but folders, symbolic links and tags together are IMHO a better alternative that tags alone.

sp332 14y ago

To make them work like folders, you would need a query like "Team and Alpha but nothing else" because otherwise each pseudo-folder would also have all subfolders' documents in it.

srathbun 14y ago

Umm, there's this thing called hard/soft links...