Arvind Narayanan's journal - Simplifying GNOME file management [entries|archive|friends|userinfo]

Simplifying GNOME file management [Jun. 6th, 2004|12:32 am]
Previous Entry Share Next Entry
[Tags|, , ]

Anyone who has observed non-techies working on a computer would have realized that they spend a singificant chunk of their time figuring out where they put their files. Many would be totally lost if it were not for the "Find files" dialog (a key finding of Sun's 2001 usability study).

Indeed, file management today is a lot more cumbersome than it needs to be. The computer science undergrad learns the "In UNIX, everything is a file" philosophy and is blown away by the beauty of it. However, this world-view is not well suited for a user-interface. "Beauty" is not the description that springs to mind. "Kludge" is more like it.

Part of the problem is lazy users. When Alice finishes typing "resume.doc", it doesn't occur to her that creating a "job" folder and saving it there is likely to save her time later rather than just dumping it in her home directory. Nor does it strike her when she saves "application-form.pdf" or "interview_tips.html" from her browser that putting the three files together would be a good idea.

But then, users' behavior can't be changed, but we can make our programs adapt better to them. Users shouldn't be forced to think in terms of files, directories and hierarchies, and should instead be allowed to think in terms of tasks. Spatial nautilus is an admirable step in the right direction: it discards the filesystem approach and adopts the folder-as-an-object metaphor. But there's a lot more to do. Here are three proposals:

0. Enable task based integration between applications

This is already a key part of the GNOME roadmap and developer consciousness and is being actively worked on. The only reason I'm mentioning this is that it is a kind of prerequisite for the following proposals.

1. Standardize directory names for common tasks and implement them pervasively.

Use-case scenario. Alice puts her new CD into the drive. It automatically starts playing. [Its the GNOME CD player app.] Alice likes the songs, so she subconsciously clicks the "Rip CD to disk" button. A window pops up with a list of tracks. [She doesn't know it, but its the sound-juicer app.] She hits the big obvious "Extract" button. [Again she doesn't know and doesn't care, but the app is ripping her files to .wav and encoding them to .ogg. It puts the ogg files it in her ~/Music/$Artist/$Title/ directory.] All she notices is that the disk whirs for a few minutes and then its done. She closes the window.

The next day when she's working she feels like listening to music, so she subconsciously clicks on the icon that looks like music tunes. A window pops up and she sees the songs she listened to yesterday. [The app is rhythmbox. The ~/Music directory is part of its "library". On starting up it checks for new files in this directory and its subdirectories, and adds them to its playlist.] She clicks on one of the songs and goes back to work in a happy mood.

Throughout the process Alice never had to deal with files or directories. She didn't even know she interacted with three different programs. She doesn't know the difference between ripping and encoding. She doesn't know about file formats. She doesn't know about bitrates. She just wants to listen to her music.


The great thing is, most of this infrastructure are already in place. The only problems are: the CD player doesn't have a "Rip" button (task based integration. Like I said, this kind of thing is being actively worked on). And most importantly, sound-juicer and rhythmbox don't use the ~/Music directory. Weirdly, the sound-juicer documentation says it uses ~/Music but the actual app doesn't. But the exact details don't matter. What matters is that we need a standard for directory names for different tasks and all apps must respect them.

Kind of like Microsoft's "My documents", "My pictures" and "My music", but much more well defined and pervasive. It would be ideal if this were done through freedesktop.org and adopted by KDE as well. But at a minimum these should be used throughout GNOME.

Example directories include Music, Audio, Images, Photos, Screenshots, Videos, Documents, Fax, Printing, Temp, Email, Download, Books, Publishing/Writing and so on. One can easily come up with a couple dozen possibilities. You don't need to worry about cluttering up the home directory with all these because the Screenshots/ directory, for example, won't exist unless the user creates a screenshot. No single user would use all these categories.

There are issues to be worked out, for instance: is Photos/ a directory by itself or is it a subdirectory of Images/? But these are minor details. Where there's a will, there's a way.

Update: 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. Makes things a lot easier for the 90% of people who don't care what their music directory is called. The other 10% can of course specify the output directory in the Save As dialog or Edit->Preferences or whatever. They will have to do no extra work compared to what they're currently doing, and they still have complete control over the system.

Another group of comments have a fundamental philosophical difference with the premise of this article that computers should be simple enough to be used by people who aren't willing to spend any time to understand/learn them. I cannot, of course, prove my viewpoint superior to yours, and all I will say is that I hope you are either using KDE or sticking with GNOME 1.x, because that was the last GNOME release consistent with your philosophy.


2. Make "intelligent" use of directory information

Once you have a well defined directory specification in place, all sorts of clever things can be done (apart from the intended use of programs knowing where to save/look for their files):

  • When you download an file mp3 through your browser, it knows the MIME type, and so the Save dialog box gives you a choice of Download/, Music/ and Other for the destination directory. Choosing "Other" lets you browse the filesystem. If you downloaded a PDF it would let you choose between Download/, Printing/, Books/, and Other. And so on.

    This kind of thing should also be implemented in the Save mode of the file selector (to the extent possible - it may not have MIME type info.)
  • The context menu for any video file in the filesystem (in nautilus) has a "Move to $HOME/Videos/" option. Similarly for other file types.
  • The following is extremely useful on a multi-user system:
    When nautilus is in the ~/Music directory, it can do the following:

    For every user X in the system different from the current user, do:
    Check if X has a nonempty, readable Music directory
    If they do, display a link saying "X's Music" in the current directory

    Similarly for any of the special directories known to Nautilus.

Update: Internationalization is one thing I forgot about. Thanks to all the posters who raised the point. Just to be clear, the problem isn't internationalization itself: an app would put its stuff in ~/Music if your locale was en and in ~/Musik if it was de etc. Implementing this is no harder than i18n/l10n of any other app or interface. If the language you are using doesn't have the translations available, then the apps would default to $HOME, just as they do now.

The problem comes when someone wants to regularly switch between two different languages. You wouldn't want half your songs in ~/Music and the other half in ~/Musik. My solution to this is as follows - when logging in with a different locale, display a dialog box like:
"Last time you logged in with de as the locale. This time its en. Would you like GNOME to rename your standard folders"?

That would let multilingual users switch languages with a minimum of fuss without making things more complicated for monolinguals (as opposed to something like virtual folders.)


3. Make the "Find files" UI universal.

(Observe the continuting analogy with the epiphany bookmark system).

For anything more than a dozen files, a "find" interface is way better than a list or hierarchy to choose from. Finding files is good UI! The reason that so many users resort to the "Find files" dialog is not that they are stupid. Its actually efficient! Think of the bookmark search in epiphany or the "jump to file" in xmms, or the search box in rhythmbox, history in firefox - a list updated in real time as the user presses keys. Everything should have it. Nautilus, the file chooser, as well as individual apps (wherever it makes sense). Observe the popularity of find-as-you-type in mozilla.

Nautilus should let you find a file in the current directory and all of its subdirectories by typing a few characters of the filename (no point in having a separate app -- its too cumbersome. It should be integrated with the file manager). The result could open in a new window. The folder-as-a-view concept. The Open mode of the file chooser should let you choose a file in the current directory you're in by typing in a few of its characters. All apps should adopt the find UI as far as possible (such as playlists, and any other lists of reasonable size. Search could possibly be integrated into the TreeView widget?!)

When you know what you're looking for, typing in a few characters is much more efficient than struggling with a long list or a hierarchy. I really don't know why the find interface is as underutilized as it is - because it is thought to be a bad interface or because of implementation difficulties?

To conclude, I'm no usability expert, but I hope I've presented a well-reasoned and convincing case for implementing the three proposals outlined above, which I'd love to see in GNOME some day. I'd like to hear your reactions, because I have lots more ideas on GNOME and usability and I want to know if I'm making any sense.
LinkReply

Comments:
Page 1 of 3
<<[1] [2] [3] >>
From: (Anonymous)
2004-06-06 11:44 am (UTC)

Yes

(Link)

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.
From: (Anonymous)
2004-06-06 12:21 pm (UTC)

About point nr.3

(Link)

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!
From: (Anonymous)
2004-06-06 09:43 pm (UTC)

Re: About point nr.3 (and a rider for 2)

(Link)

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.
[User Picture]From: aredridel
2004-06-06 12:22 pm (UTC)

(Link)

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.
[User Picture]From: aredridel
2004-06-06 12:25 pm (UTC)

(Link)

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.
From: (Anonymous)
2004-06-06 12:23 pm (UTC)

Good point

(Link)

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!
From: (Anonymous)
2004-06-06 12:41 pm (UTC)

Good Points

(Link)

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/
From: (Anonymous)
2004-06-06 01:19 pm (UTC)

Support for different languages

(Link)

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".
From: (Anonymous)
2004-06-06 02:33 pm (UTC)

Re: Support for different languages

(Link)

gnome_get_apps_folder_path();
gnome_get_users_folder_path();
From: (Anonymous)
2004-06-06 01:20 pm (UTC)

Temporary Files

(Link)

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.
From: (Anonymous)
2004-06-06 06:09 pm (UTC)

Re: Temporary Files

(Link)

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? ;)
From: (Anonymous)
2004-06-06 01:38 pm (UTC)

Great article!

(Link)

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!
From: (Anonymous)
2004-06-06 01:39 pm (UTC)

please make these default directories hidden

(Link)

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
From: (Anonymous)
2004-06-12 11:48 pm (UTC)

Re: please make these default directories hidden

(Link)

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.
From: (Anonymous)
2004-06-06 02:24 pm (UTC)

web downloads

(Link)

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.
[User Picture]From: costela
2004-06-08 05:18 am (UTC)

Re: web downloads

(Link)

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.
From: (Anonymous)
2004-06-06 02:42 pm (UTC)

Find doesn't know enough to work well

(Link)

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.
From: (Anonymous)
2004-06-06 04:11 pm (UTC)

Two comments : i18n & all other ~ files

(Link)

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 !
From: (Anonymous)
2004-06-06 05:16 pm (UTC)

Great ideas! Mine: use symlinks widely, keep Nautilus handy

(Link)

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
From: (Anonymous)
2004-06-06 05:19 pm (UTC)

Things I like in your article

(Link)

-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.
From: (Anonymous)
2004-06-06 06:22 pm (UTC)

More power to you

(Link)

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
From: (Anonymous)
2004-06-06 06:32 pm (UTC)

excellent ideas

(Link)

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.
From: (Anonymous)
2004-06-06 09:03 pm (UTC)

Just some thoughts

(Link)

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.
From: (Anonymous)
2004-06-06 09:22 pm (UTC)

These ideas hav been observed by others

(Link)

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.
From: (Anonymous)
2004-06-07 05:20 am (UTC)

Re: These ideas hav been observed by others

(Link)

"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.
From: (Anonymous)
2004-06-06 09:51 pm (UTC)

(Link)

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.
[User Picture]From: arvindn
2004-06-06 11:12 pm (UTC)

Hi everyone!

(Link)

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
From: (Anonymous)
2004-06-08 03:36 am (UTC)

Re: Hi everyone!

(Link)

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
Re: Hi everyone! - (Anonymous) Expand
From: (Anonymous)
2004-06-07 12:51 am (UTC)

Great! Good points made.

(Link)

+1 support for your points here.
From: (Anonymous)
2004-06-07 01:33 am (UTC)

The window mess

(Link)

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
From: (Anonymous)
2004-06-07 02:22 am (UTC)

I18N

(Link)

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.
From: (Anonymous)
2004-06-07 04:22 am (UTC)

"Put into Music folder"

(Link)

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
From: (Anonymous)
2004-06-07 05:15 am (UTC)

A short reflection

(Link)

"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.
Page 1 of 3
<<[1] [2] [3] >>