|
|
这篇文章真是太好了。
Simplifying GNOME file management
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-> references 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 |
|
IP卡
狗仔卡
发表于 2004-6-7 22:37:36
提升卡
置顶卡
沉默卡
喧嚣卡
变色卡
显身卡