Designing better file organization around tags, not hierarchies (2017) • Hacker News Board

Re: Designing better file organization around tags, not hierarchies (2017)

#11

Post by fao_ » Thu, Apr 05, 2018, 9:10 PM UTC

xchaotic wrote: post #6

Tagging is the first step, but how do you know if you don't have overlapping or duplicate tags, say country and folk music? If you need something that fits both categories, you eventually start designing taxonomies and eventually ontologies, there's just no end to it. I think tagging is a sensible, lightweight approach, but it has limitations...

> country and folk music

Folk music has nothing to do with country.

Country was invented in the 1800s by a businessman who aimed it at primarily white Americans. Folk music has a rich history dating before the 1200s and before much of written language. Many songs of Irish and Welsh descent date before record, still being played today.

Nevertheless, to answer your question:

1) metatags, parent tags, and the like provide ways to structure tag relationships to encompass and describe what you speak of.

2) There are many networks out there that share user's tags based on file hashes. A system could scrape these networks for existing tags and autotag many items without the user's interaction (beyond initiating the autotagger). Users could also get their hands dirty and ask for only tags relating to parent categories, or something like that.

Re: Designing better file organization around tags, not hierarchies (2017)

#12

Post by 39297 » Thu, Apr 05, 2018, 9:12 PM UTC

xchaotic wrote: post #6

Tagging is the first step, but how do you know if you don't have overlapping or duplicate tags, say country and folk music? If you need something that fits both categories, you eventually start designing taxonomies and eventually ontologies, there's just no end to it. I think tagging is a sensible, lightweight approach, but it has limitations...

It is similar to CSS. Either using clumsy naming convention like BEM, or use preprocessor which provide a way to define hierarchy of class. Both would work.

Re: Designing better file organization around tags, not hierarchies (2017)

#13

Post by prepend » Thu, Apr 05, 2018, 9:18 PM UTC

I find it hard to remember if Google Docs originally had tags instead of folders. Or if I just imagined it. I can’t find it through googling.

I would rather use tags than folders, but can’t find good support in an operating system.

Google used to be the closest since you could use the search bar as a command line and search queries as tags. There are no folders. But they changed now that try to guess what you’re looking for rather than what you type.

OSX has tags, but their search is slow and inaccurate.

The closest is I’ve been trying to use Gmail as an organizer with inbox infinity rather than inbox zero. Nothing organized other than tags. Using search to find anything.

Re: Designing better file organization around tags, not hierarchies (2017)

#14

Post by boffinism » Thu, Apr 05, 2018, 9:19 PM UTC

Google Drive used to be based around tags, not hierarchies. It was wonderful. Then as it matured and catered to more and more 'normal' people it introduced the concept of folders. The folders were initially tags 'really' - the same file could exist in multiple folders at the same time. But they made that harder and harder, and now I think it's hierarchical folders through and through.

I miss the old days.

Re: Designing better file organization around tags, not hierarchies (2017)

#15

Post by Benjammer » Thu, Apr 05, 2018, 9:19 PM UTC

on_and_off wrote: post #5

>But fundamentally, there is a mismatch between the narrowness of hierarchies and the rich structure of human knowledge, and the proposed system will not presuppose the features of HFSes. This hits the nail on the head ! All the fileSystems I had to work with are fine as engineering tools. By that I mean using them as an engineer works just fine, their own implementation is off topic. As a user though. What the hell…

How do you make sure things are tagged properly though? A file must reside within a folder, even if it's a default location, which forces a user to think about the folder where the file is stored. With tags, a user could very easily forget one tag on a file, and now any filtering on that tag is never going to be aware of the new file existing.

What if you find another picture somewhere from your trip, but you forget to add the tag? Or you have a tag for "cool architecture pics" or something and you miss tagging one of your Paris pics with this when you upload?

There just seems like so much friction in properly keeping tags organized, despite how much extremely better the "read" UI is for someone browsing or searching file collections.

Re: Designing better file organization around tags, not hierarchies (2017)

#16

Post by hammerandtongs » Thu, Apr 05, 2018, 9:21 PM UTC

Tags are great BUT

It's pretty important to realize that a files position is merely it's default tag (and you can tag it further with many different types of systems like extended attributes, as I think both Gnome and KDE have used at times).

Without that default tag you have a mess.

It's also important to note that Tags have a very high maintenance cost of their own.

Duplicate, inconsistently applied and redundant tags are a aggressive cancer in any of these systems.

No you can't just ignore them as they make it more and more difficult to accomplish even basic viewing /scanning over files for the system and the user.

Many many users have trouble even doing basic maintenance on their file locations (that default tag) that makes a tag based system even more prone to failure.

Re: Designing better file organization around tags, not hierarchies (2017)

#17

Post by cup-of-tea » Thu, Apr 05, 2018, 9:25 PM UTC

on_and_off wrote: post #5

>But fundamentally, there is a mismatch between the narrowness of hierarchies and the rich structure of human knowledge, and the proposed system will not presuppose the features of HFSes. This hits the nail on the head ! All the fileSystems I had to work with are fine as engineering tools. By that I mean using them as an engineer works just fine, their own implementation is off topic. As a user though. What the hell…

Didn't Windows try to do this starting with 7? It has "libraries". It was awful and I just wanted the real file system back.

Re: Designing better file organization around tags, not hierarchies (2017)

#18

Post by deathanatos » Thu, Apr 05, 2018, 9:28 PM UTC

boffinism wrote: post #14

Google Drive used to be based around tags, not hierarchies. It was wonderful. Then as it matured and catered to more and more 'normal' people it introduced the concept of folders. The folders were initially tags 'really' - the same file could exist in multiple folders at the same time. But they made that harder and harder, and now I think it's hierarchical folders through and through. I miss the old days.

Even today, Google Drive isn't strictly hierarchical, in that a file can still be in multiple folders / locations. They have, however, made it awfully hard to discover.

If you have an existing item or items selected, you can "add" them to a different folder by hitting Shift+Z; I don't think this exists in any menu. It is in the list of keyboard shortcuts (hit "?").

These feel sort of closer to some form of link than a tag, though.

Re: Designing better file organization around tags, not hierarchies (2017)

#19

Post by sli » Thu, Apr 05, 2018, 9:35 PM UTC

Benjammer wrote: post #15

on_and_off wrote: post #5

>But fundamentally, there is a mismatch between the narrowness of hierarchies and the rich structure of human knowledge, and the proposed system will not presuppose the features of HFSes. This hits the nail on the head ! All the fileSystems I had to work with are fine as engineering tools. By that I mean using them as an engineer works just fine, their own implementation is off topic. As a user though. What the hell…

How do you make sure things are tagged properly though? A file must reside within a folder, even if it's a default location, which forces a user to think about the folder where the file is stored. With tags, a user could very easily forget one tag on a file, and now any filtering on that tag is never going to be aware of the new file existing. What if you find another picture somewhere from your trip, but you forget…

I would probably use a hybrid of the two. Use the tag system for things I've tagged, and fall back to a regular filesystem for untagged files. That's basically how I have Steam setup. Most of my games are tagged, usually with multiple tags, and all untagged games just go under Games.

Once I got everything organized (via automation, not manually -- not necessarily relevant, though), keeping up on tagging new games became easy and quick.

I imagine there would be automation tools written for a tagging filesystem, that just "knows" a lot of common software, etc., and can get you started.

Re: Designing better file organization around tags, not hierarchies (2017)

#20

Post by on_and_off » Thu, Apr 05, 2018, 9:42 PM UTC

Benjammer wrote: post #15

on_and_off wrote: post #5

>But fundamentally, there is a mismatch between the narrowness of hierarchies and the rich structure of human knowledge, and the proposed system will not presuppose the features of HFSes. This hits the nail on the head ! All the fileSystems I had to work with are fine as engineering tools. By that I mean using them as an engineer works just fine, their own implementation is off topic. As a user though. What the hell…

How do you make sure things are tagged properly though? A file must reside within a folder, even if it's a default location, which forces a user to think about the folder where the file is stored. With tags, a user could very easily forget one tag on a file, and now any filtering on that tag is never going to be aware of the new file existing. What if you find another picture somewhere from your trip, but you forget…

That's a group effort.

For picture they could read metadata for something as simple as Paris.

The tech is there to search for 'architecture' pics, Google Photos demonstrates it.

Of course there is the issue of who can see this data and that's not a small one. The recognition itself could run locally, but training data would still need to be mutualized.

And most apps would need to adapt and provide more metadata to your documents