Simplifying GNOME file management (GnomeDesktop)

Posted Jun 7, 2004 20:42 UTC (Mon) by tjc (guest, #137) [Link]

Spatial nautilus is an admirable step in the right direction:...

I finally got a chance to try "spatial" file management, now that Gnome 2.6 is in Debian unstable. To me it's more like getting into the Tardis and setting the controls for 1992. I used to like OS/2 Warp 3.0, but that was ten years ago.

Posted Jun 7, 2004 22:31 UTC (Mon) by tzafrir (subscriber, #11501) [Link]

IMHO the author's proposed solution for i18n is a pain. It creates all sorts of unexpected problems.

keep in mind that in languages with a separate alphabet range (any language whose alphabet is not latin) folders of different languages will appear way distant when sorted by name. So "Music" will not be near the Hebrew form of the word Music (editors: is it possible to change the encoding of those pages to UTF-8? I was not able to write Hebrew here).

If a user wants to experiment with a different language, the user should not "lose" data.

Not to mention that his proposal will only ease the pain: users will be used to "dump" music files under ~/Music . That will eventually become a problem. Consider the "resume.doc" example he gave in the beginning: his propsed schema does not solve it.

Posted Jun 8, 2004 0:25 UTC (Tue) by piman (subscriber, #8957) [Link]

> 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.

Whenever I see something like this, I become convinced the person has never tried to write real software. :( These "minor details" form the crux of his plan -- a (near) universal file organization schema. This has been a holy grail of UI for many years, and unless he has more than vague suggestions (i.e. is willing to work on "minor details"), all this is going to do is incite flamewars.

Posted Jun 8, 2004 4:14 UTC (Tue) by iabervon (subscriber, #722) [Link]

He seems to be missing a number of points. First, if the user doesn't
interact with directories in order to use the automatic location of
music, why does this location have to be not only human-readable but
localized? If all of my software looks in ~/share/disci-rapti, it doesn't
matter to me that the directory name is a strange latin phrase, because I
don't actually use it.

The ~/Music example is good, but the other examples don't follow from it.
It is good because it is a case where a set of applications can, by
convention, share a default location which they use such that they always
find each other's data when appropriate. The other examples seem to be
based on an ontology of file types, which is a far less compelling
organization, because the rules for what goes where are less clear. What
goes in Audio? Should I look there for a rip of a spoken-word CD? It
makes sense to organize things based on their affordances: under Music
are those files which you listen to and don't look at; programs which
produce or use such things look there.

If an image is a screenshot or a photograph, and this information is
important, it should be represented in comments in the file. If it is in
the directory structure, then a simple image viewer has to know about all
of the possible types of image.

It makes sense to have some operations that work on your whole home
directory tree, and let you do things like finding all of the files you
got within 2 hours of writing your resume, which is the file attached to
the email you sent to someone at google. Now, obviously, you're not going
to accomplish this whole chain through path names. Some of the
information isn't even files normally.

The author seems to have missed the point of the "everything is a file"
philosophy; it does not say "everything has a path" (let alone a unique
path). For that matter, the article is mainly complaining about the
difficulty of dealing with practically the only thing in UNIX which
*isn't* a file, as well as the lack of some historical information which
should really be captured in a file.

Posted Jun 8, 2004 7:17 UTC (Tue) by hathawsh (subscriber, #11289) [Link]

I'm an experienced user and programmer and I've started to fall into the habit of just putting things in $HOME. Sometimes I wonder whether the hierarchy truly saves me time overall as the article suggests. My $HOME gets too big every couple of years, and it takes a few hours to prune, but I think that's less than the total time I would otherwise spend wandering in file dialogs.

This makes me wonder if this is a case where newbies are actually doing something pretty smart. When my mom writes a letter on the computer, she might as well put it in her home directory because she probably won't write very many others. It's right there for her to find.

The scalability problem comes when some application is more successful than expected. Let's say my mom gets excited and writes a letter every week. She'll want to avoid mixing the letters with other kinds of files. It may be difficult to organize once several letters have been written. Should she have organized better from the start? No, because that was premature generalization at the time.

I think what we really need is a kind of "metadata assistant". I want to take a set of files (generally the contents of $HOME) and enter missing metadata about each one. A real-time preview of each file will be necessary. Then I want the computer to organize all of my files according to the metadata I entered. Documents that fall into multiple categorizations should appear in multiple places in the hierarchy. Searching by metadata tags should be quick--so quick that when I want to open a file, I could get around faster by searching rather than using a hierarchical file dialog.

My mom would solve her organization problem using the metadata assistant. (We'd probably call it an "organization assistant" so that people don't have to learn new jargon, but metadata assistant is more precise.) She would open files through a search dialog rather than a file dialog, falling back to a file dialog if she feels like it.

Perhaps this direction sounds radical, but some systems I've recently helped put together (Zope 4 Edu and Zope Enterprise CMS) have embraced metadata-based navigation with great success. The weakness is that people are lazy about entering metadata, but I'm convinced that even a little metadata can make the system work well.

Posted Jun 8, 2004 9:17 UTC (Tue) by janpla (guest, #11093) [Link]

I have an idea for the perfect interface - it's simple, to the point and easy to remember, stroke of genius, really:

1. start xterm
2. use cp