Journal tomhudson's Journal: The Rule of Most Specific 9
Treat your users like children, and they'll keep acting like children
I forgot that most distros now install the cpu hog known as tracker by default, so sure enough, it started indexing my files while I was doing other stuff. Of course, I killed it, then removed it, but still, this got me to thinking
The answer, of course, is that we don't take two minutes to teach someone the easiest rule for organizing stuff, whether it's files on your computer or anything else.
The Rule of Most Specific
People tend to go with the defaults. So, when creating a project called Foo, they will stick their code in Projects/Foo folder, but the documents for that project end up in a Documents/Foo folder, their backups in a Backups/Foo or Archives/Foo folder, their graphics resources in a Pictures/Foo folder, etc.
The Rule of Most Specific says that instead, since all these things are related to a specific project, they should ALL go in Projects/Foo. So, documents related to Foo go in
Of course, since designers think users are total idiots who are incapable of learning a few simple rules, they think it's much better to index everything ("let the computer do it for the user") and then force the user to wade through a bunch of search results to find the one thing they're looking for.
The end result is that people aren't given an incentive to organize things a bit, and as a result, their backups are incomplete ("gee, who would have thought that people don't want to go through a dozen different directories all over the place to assemble a backup for a specific project"), and they waste time looking for stuff because their drives are a mess.
In other words, it's the same as in real life when you were a kid - you learned the hard way that it was quicker to put things where they belong the first time than to find them after entropy takes over and you can find everything except what you're looking for. Or your place looks like an episode of "Hoarders."
"Oh, but now I can search for stuff on my drive by tag!!!" So what - now you have the extra work of figuring out a tagging scheme. It's easy to remember "The graphic I used as one of the wallpapers in project Foo" and look in Projects/Foo/Imgs/Wallpapers, or when you need to transfer a copy of all the files so you can work on another machine, just tarball the whole Foo directory and know you got everything.
Use the Rule of Most Specific to put stuff in the most specific place the first time and you'll find things quicker with just a file browser than you could using any desktop search application. Or prove the "designers" right and keep treating your file system like a kids messy room or the junk drawer in the kitchen.
While I agree... (Score:1)
Re: (Score:2)
Re: (Score:2)
Tagging, I would think, would be more efficient than many layers of folders.
Just had a little discussion [slashdot.org] about that the other day. With a little work it could be made compatible with existing software (using tag names as directory names) but there's the matter of telling all the readme.txt's apart when you don't specify all the tags.
Re: (Score:2)
This way, you could have a directory called, for example, /Tags/FunnyStuff, and if you have, say, a picture in /Pictures that you want to also be found in /Tags/FunnyStuff, just type tag filename FunnyStuff.
So you could have tags for Politics, Work, StupidPeople, Friends, Enemies, Vacation, School, Kids, Finances, Books, Videos, Music, etc. etc.
So, by typing "tag dcs9234.jpg Kids Vacation Photos Wallpapers", you can find the picture any of tho
Re: (Score:2)
Just use a bit of perl or a shell script and some symlinks.
That's not nearly as nerdy as writing your own filesystem though ;)
Also, the purpose behind it is to make the intersection of a set of tags useful. I don't want a list of all the mail, I want my mail. Or in your example, I want a list of wallpaper-sized vacation photos featuring the kids, whether they were taken at disneyland or grandma's house. But maybe I want all the photos from disneyland for something else. Thus it needs to be able to make a
Re: (Score:2)
You can then get the subset of all files tagged as pictures+wallpaper+vacation, for example.
For email, to get just yours, it would be your_name+type=email
The idea of using symlinks is four-fold
1. system portability - pretty much every OS supports some type of linking method.
2. application transparen
I organize the children's way... (Score:1)
...because the SCC systems I've used have had all our projects under a single root, and they could remember one mapping of this root to a folder on my drive but not (AFAIK) a mapping for each project.
The problem is hierarchy-only thinking (Score:2)
Things have more than one attribute that identifies them, or makes them important. Those attributes depend on context. Consider a cool picture of mom and dad at Christmas. When thinking about family, they go in one mental space. When thinking about artistic photographs, they go in a different mental space. And when thinking about Christmas, they're in a third. Do they get filed under family, art, or chronologically? Trick question: the answer is unimportant. A hierarchical file system gives the use
Re: (Score:2)
And why not, instead of indexing, and then having to wade through a ton of useless results, just use symlinks, as I proposed elsewhere. A flat system, not hierarchal, would work just fine for most people, give all the advantages of indexing, and could even be automated. Stuffing everything into a database is not always the best solution.
This way, the actual storage location of the original is irrelevant (by extension, it doesn't even need to be on the same machine).
All indexing content did was kick the