You are making a lot of sense. Get in touch with both freedesktop.org and GNOME developers and see if they adopt your ideas because they're very usefull.

I believe that the Storage system, when/if it will be developed will be even better - being able to first do the search as you said, but also to be able to create "virtual folders" of the type "Music by nirvana after 1990"

Other than that - you are right in pretty much all you're saying though!

Although its not a GNOME project, libferris [ http://witme.sourceforge.net/libferris.web/ ] does indexing of file metadata and fulltext right now. In the next release it will allow indexes to be held in an ODBC driven database (testing with DB2, firebird, postgresql, mysql).

I've also found in ferris that having a URL syntax for "finding" is very handy, it easily enables you to transfer a found list or bookmark a search for latter reuse. Of course it also enables searching from the command line if you have chosen a URL syntax compact enough.

On point 2: In the ego file manager it does the second "Move video files to..." type of thing which it sets up automatically by remembering what the user has done to various files. Most often you are always moving/copying files of a given type to only a few select locations. Of course you can add locations that are always targets for a file type, but having the system automatically build them works quite well.

Though its mainly a point of style, I *really* don't want a system that checks for ~Xuser/Music for all other users. I'd much prefer having shared music based on a two group gid system, a gid for reader and a gid for writer so that most users can only access a shared music pool rahter than poking around in each others home directories.

Hm. Some of that is really good.

Some of it is annoyng -- like when you go to web-enable your files, (mine are stored predominantly in ~/web/year/mo/day-name.type, with some cross-linking to ~/web/Music (shared) and ~/Music (private)

A filesystem with indexed metadata would be nice.

Actually, what bothers me is that sometimes it feels like GNOME wants to be a system that fools can use, but only fools would want to -- things like Epiphany not being able to open what you typed in a new tab with a control-enter.

Some of that organization system is perfect. Some would drive me batty. Triple that if there's things I don't use who re-create their empty folders every time a related app is started.

you make there. Some of these ideas (1,3) are part of MacOSX which i use sometimes. The second point is afaik not in MacOSX. Nevertheless the other two are very useful i can tell you that!

Good points. It would be nice to see an option to open/import music directly from the web (as an action when clicking on an MP3). OS X does this with a "Open with iTunes" action in the context menu of mp3 links in Safari.

Steven Garrity
http://www.actsofvolition.com/

There's one big problem with this approach. If you have folders called "Music", "Documents", "Screenshots" etc., people who use GNOME in other countries and don't speak English (maybe because they're only 12 years old) won't understand anything and even people who can speak English as a foreign language will be really annoyed if their folders have English names. Changing the names of the folders depending on the active language is no solution, either, because sometimes you'll want to use GNOME applications that have not yet been translated to your language. These applications wouldn't be able to find the folders if they didn't have the English names.
Mac OS X tries to avoid the issue by translating these special folder names "on the fly" (with the help of a translation file), so that the folders always have the same (English) names in the filesystem, but the Finder, Open/Save dialog boxes and applications always display the localized names. I think this is the best thing you can possibly do to save the idea of standardized folder names, but it's still confusing if e.g someone from Austria uses X11 or command line applications that do not make use of the Mac OS X specific so-called "display name API" and suddenly a he can no longer find his "Benutzer" or "Programme" folders till he realizes that they're suddenly called "Users" and "Applications".

gnome_get_apps_folder_path();
gnome_get_users_folder_path();

Also, why not call the "Temp" directory "Temporary" or "Temporary Files"? OS X uses "Temporary Items". I can easily imagine someone thinking that "Temp" has to do with temperature. Users can get really weird ideas in their heads.

The directory for that is /tmp and isnt in the users home directory. You have a valid point though. The whole unix file system confused me at first..../etc, wtf? ;)

I'd love to see this type of work done more actively. I believe it will be in time, but it seems to be slowed down by the fact that a reasonable percentage of programmers believe these types of ideas (such as not dealing directly with files) are bad ideas, or go against some almighty philosophy.

You have some great ideas here!

It's like Evolution creating a directory in /home/username/ or also like Nautilus creating directory Desktop in /home/username. No I don't want that, it will make a lot of noise in my managing of directories.

I was always upset with MS-Windows deciding for me that I had to have MyThis and MyThat directories in my place.

cheers

It's not exactly the same. I don't like the evolution directory either, and that is because I can't *do* anything with it - there is nothing clickable in there.

Whereas the folders suggested in the article is to hold documents and data usable by installed applications. I think it is a good move, and if you don't like it just change the defaults.

It would make it a lot simpler for new users, that's for sure. It would also mean that I could worry less about folders, it would all get placed in a acceptable place, which is better than using the desktop as one badass temporary directory.

Making a whole new UI for web downloads is a horrible idea. We already have a perfecetly good file chooser; just use that. If you download a music file, the default selected location in the chooser would be Music. That's put in the bookmark list which can be opened and another location chosen (like Downloads or whatnot) or the expander can be clicked to get the browser. Absolutely no need for Yet Another UI.

What could be done about this is remember the download location on a per-MIME-type basis, that way audio/mpeg files would always open the filechooser in the ~/Music (or whatever) directory.
This wouldn't be too intrusive and would provide a content based way of minimizing labor.

The one thing I think is important - and should maybe even be part of the Gnome HIG specification - is that always a user perceivable change is made, an option should be included to easily go back to the previous way of doing things. See the spatial Nautilus dillema. I like it, some people don't. If it was easy to switch back to "browser view", no one would complain about it, IMHO.
Actually, all these changes could be implemented, as long as they could be turned on/off.

One of the major problems with finding files is searching inside files to find what users are looking for. If I've got 50 documents (out of thousands) that mention Noam Chomsky and I type "Noam Chomsky", I expect to see those 50 files come up as hits. But if some or all of those hits are in OpenOffice.org format (which appears to be an archived set of files, the word processor content appears to be in an XML file), find will never look inside these files. Thus, find fails to locate what I want and find quickly becomes useless to me. File naming poses too restrictive a limit on my ability to do what I want.

What's worse is I have no other means of searching these files, so I either switch to using plain text files, RTF files, or some-such; stop using OO.org; or (if I haven't learned to value my software freedom) I'll even contemplate switching to a platform which caters better to my needs. RTF poses limits all its own (it's not totally portable, RTF can't encode everything I can do with OO.org, RTF is overkill for just text).

Solution: Nautilus or find needs to be extensible by third parties so they can supply a file format description allowing the finder to look inside the files for meaningful human content. When I install OO.org I also get this file format description for the finder installed too, thus my environment is integrated with the app I just installed.

The biggest problem this article cunningly ommits is internationalisation. This "simple" proposal is a lot more hairy once you realize all the world does not speak english.

Translating in the gui is not enough - people do and will use the CLI. And they also use stupid shell scripts that will need to work with mutable file/dir names.

This being said, you must take into account the general layout of the home dir, not only user files (I'm thinking about all the hidden junk - guys it's not because it's hidden under the carpet it's not there). The vast majority of files in a Linux file system is very well laid out thanks to efforts like the FHS. The remaining red zone is /home. Please do not forget all the other user files when you reorganise $HOME - users should not have to run screaming whenever they need to do a manual fix.

The admin has it all easier than common users - it's files have been organised long ago. Often it's easier to change a setting system-wide than at the user level !

Standardize directories with symlinks. This would enable choosy users to keep things organized exactly as they are used to (which is important in GNOME) and at the same time make possible complete, orderly standardization.

Also, WHY is the file browser (and file finder) like every other application? When it is used so often, why not keep it handy -- make it pull down (like a drawer) from the toolbar?

Finally, anyone interested in efficient file management really should play with the BeOS (http://www.beosmax.org/) for a bit... Put it on an old, crappy computer and try things in it for a little while. It's enlightened!

Will

-you have people and real situations as a starting point - not the technology

-maybe you are not a usability expert, but it seems to me that you understand usability very well

-you explain yourself very clearly and in a way that is nice to read and easy to understand even for someone who is not so familiar with the subject

I hope you keep thinking and writing (and programming?). I'm not a developer and can't comment on the feasibility of these ideas, but they surely address some issues that I have with managing my files. I would definitely give your ideas a try.

I agree with most of what you said. Coincidently, when I installed Fedora Core 2 for my girlfriend I've made the home-directory just the way you specified. Pretty convincing ;) I would also automatically add the correct emblems to those default directories, that's what I did for my girlfriend anyway. A visual help will motivate people to do the right thing and helps with navigation. -- Dag Wieers

great ideas, and i would go further with the downloading thing, the user wouldn't have to even choose the directory for his/her mp3 or pdf, just place some folders where the programs capable of opening those files will know they're there.
about the folder names... well, if on the desk you see that it says "Música" (Spanish for music) who cares if the actual folder is named "music"?... and if everything works ok, the user shouldn't even know that there are folders where all those files are saved in.
and the console shouldn't be accessible for common users either.

One thing to consider with pushing people to search is that people still need to have some idea of what they want to find. I really like search functionality within applications like rhythmbox or gthumb b/c it allows you find specifics within a specific set or type of file. When you take that option to the filesystem as a whole it becomes a little more convoluted. I know in my own experience, I have to order and keep track of files in relation to the project I am working on. I work as a web developer so I often will receive many different files that I have to use on a project. In one sense it would be nice to give files a bit of meta data to organize things by a project for example, but at the same time what happens when I need to upload a file to a server or make a back up of a site. I will have to do many searches that are really not necessary. I know this is a specific example but I think it does show some of the flaws in searching the file system as a means of finding files.

I do think freedesktop.org should standardize on a home directory structure for things like music, video, etc. as it would be very useful in application defaults.

The way files of different types cooperate in Apple's iLife suite addresses a number of the issues. And the way BeOS stores all files with a mimetype, and with each difference type a set of other attributes that might be useful and allows indexed searches on those attributes, shows that there are people involved in writing OSes that agree with you.

"shows that there are people involved in writing OSes that agree with you"

Not "writing OSes" but "writing desktop environments". It is all about applications and designing a consistent and user friendly interface. And operating system is something completly different.

Interesting ideas. I know some people who are just like the Alice you describe. However, the implementation will be very tricky.

• The directory structure has to make sense in any locale, and in Gnome, KDE, old X/Motif/Gtk1 (xmms, xemacs, various commercial and scientific apps), and command line. The system also has to be easily programmable and scriptable, otherwise the developers and power users will rebel.


• The directory structure has to be reasonably future-proof. If you've read Quicksilver, it mentions Real Character - a 17th century attempt at a hierarchical database for the world. Today, its classifications would seem very quaint.


• Problems with misclassified data. If you have some mistagged or mistitled mp3's, emails from a someone using another's email account, a text file that gets identified as a binary due to an unusual encoding (happened to me many times), etc, and the system puts them in the (wrong) default place - or encourages you to put them in the wrong place without thinking - you will never find them. It's worse than just dumping the files into a flat directory.


• Customization and editing. Suppose I am sorting a pile of documents from twelve classes, two jobs, and several threads of private correspondence. Or suppose I want to keep my soundtracks together with my movies. It should be easy for me to expand the classification system and have it properly integrated into nautilus, the web browser, and even applications I haven't installed yet.

Still, the fundamental idea is sound.

I'm very pleasantly surprised by all the positive comments here. I have great hopes for the future of GNOME :-)

I admit I didn't consider internationalization when I wrote the article. However, I don't think it makes the standard folders idea impossible to implement, just slightly trickier. I've updated the article with a proposed solution.

Cheers
Arvind

As others have already commented, your proposed internationalization scheme is not good. Directories must not change their names and they should have the same names in all locales. Otherwise scripts will break, especially backups.

Having GUI apps read a localized name from the .directory file is a good idea. This is something that is already in use anyway, for instance for showing a custom icon for the folder.

Another idea could be to have the directories as you suggest in home, but also have collections of symlinks for other locales. For instance:

Direcotries:
~/Music
~/Documents

Symlinks:
~/.MyFiles/de/Musik -> ~/Music
~/.MyFiles/de/Documents -> ~/Dokument (not sure if this is correct German, sorry)
~/.Myfiles/fi/Musiikkia -> ~/Music
~/.Myfiles/fi/Tiedostot -> ~/Documents

Then you could ice the cake with one final symlink to your locale:
~/MyFiles -> ~/.MyFiles/fi

This way an app that doesn't wan't to guess where you'd want to save your oggs could still offer ~/MyFiles as a default directory.

(The names (especially "MyFiles") in this comment are just examples to demonstrate the idea.)

henrik ingo, Finland

+1 support for your points here.

What I really don't like about Nautilus is the "Where the folder window I'm clicking on will appear around my desk?". Parent folder window and childs should be "linked" in some way. I don't like the fact that a window remebers his position. I'ld like a behaviour like this: if I click on a folder, this is opened in a window on the right of the parent, and so on clockwise... I'll describe this better in the future... maybe

There's no sense in having a music directory in every used language. Just use a single Music dir with some Mac OS X style .localized file that contains translations which are shown when using some other than default locale.

Hi Arvindn,

just another idea for the "Put into whatever folder applies" option in a file's context menu: I think it'd be cool to have that menu item read "Put into respective folders" when a bunch of files of different MIME types is selected. All the files Nautilus doesn't know about would be just left in place; maybe a dialog should be displayed, dunno.

Thanks for the thoughts! I really do hope the KDE and GNOME devs like them as well :-)

-- Raphael

"A lot of the comments to this article on gnomedesktop.org and osnews.com say: "No!! I want the choice of where to put my files!". Of course you'll have the choice. I'm only proposing using standardized directories as defaults."

Why use actual directories? A much more elegant solution would be to use Gnome-VFS and have the "default directories" you're talking about mapped to whatever the user preferes.

"Last time you logged in with de as the locale. This time its en. Would you like GNOME to rename your standard folders"?

Using "virtual" folders mapped through Gnome-VFS would solve that issue transperently without any annoying dialogs or unnecessary renaming of actual folders.