File Handling
2009-12-11 7 Comments
Recent discussion on the Gnome-shell list made me think about file handling in general once again.
I think it would be beneficial to Gnome (or KDE or …) to have a long term plan regarding where some fundamental things should be heading. Here’s some food for thought, knowing that everything I bring up here comes with a long tail of questions:
Uniform file handling liberated from hierarchical file systems
Every new/separate piece of interface the user has to deal with means more to learn and more to remember (several instead of one mental model). This speaks against a separation between accessing files and managing files (a design decision for Nautilus that I wasn’t aware of, previously). It also speaks against having various interfaces for documents, images, audio and video files, each designed independent of the other.
The problems of having to deal with huge numbers of items and no sane way to put each item into only one category (folder) affects not only media files, but also documents.
Meta-data (tags, categories, relations) is the answer regarding organizing and accessing files. This should be handled in a uniform way for all kinds of files (maybe with exceptions for some system files).
But there’s a problem as long as users have to deal with hierarchical file systems. Meta-data on top means there will be situations users have to understand and deal with 2 systems where on could suffice. The question where files are actually stored should be part of the meta-data in some way.
Versioning
More people should get to enjoy the benefits of versioning. You shouldn’t have to drop to the CLI or install GUI tools. Versioning should be just there as open invitation and comfortable helper.
(Heck, a whole system installation could be a clone from a distribution repo, I guess.)
EDIT: KDE’s Dolphin will have version control support, although not quite in the open, direct way I’m envisioning.
Sharing
We not only deal with more files of an increased number of types, but also have more means of transfer and more places they end up on. Time for tracking which file in which version went where or to whom right from your desktop. The same mechanism could also help with managing archives on removable media.
To link or embed?
Should images in a presentation be linked or embedded? Both have their pros and cons. How about neither? As long as all parts are on the local system, use references to files. References that do not rely on a path or filename and thus do not break. If the main document is copied to a different system, make sure all the required files follow.
Thorwil's 
Funny, the recent discussion about Nautilus had led me to have similar thoughts.
GNOME needs to provide users with a better way to organise and manage their data. That solution should be focused on metadata rather than files. I’d love to see a document management application built on top of Zeitgeist and Tracker, for example, and have some ideas about how that could be done.
What I’d disagree with is that there should be a common GUI for dealing with all types of data. A few reasons:
– Photo and music management are sufficiently specialised to warrant having separate GUIs.
– A universal data management GUI would be both complex and unable to to cater to the niche use-cases you find with specific types of data.
– A universal data management GUI would be become an obligatory passage point for pretty much all the tasks on the desktop. I think that that role should be taken by the Shell, not a specific application.
That said, feel free to prove me wrong on these points. 🙂
Allan, what I meant to express is that searching based on meta-data, applying, editing and removing meta-data should be the same for all files. There should a frame of common elements, to only change parts that are necessarily specific to a type of data.
‘It also speaks against having various interfaces for documents, images, audio and video files, each designed independent of the other.’
I tend to think in terms of GUIs. You say ‘interface’, I think ‘GUI’. Apologies… Still, I do think that the approach you are suggesting here could lead in some exciting directions for data management GUIs.
Regarding versioning, keep in mind that nowadays, only some types of files can actually benefit from versioning. Namely, only those whose filesystem representation is plaintext (this includes .txt but also .xml, .html and stuff like that). When dealing with binary files like images or documents (and a small parenthesis here: no matter what anybody says about ODF documents, still there is no effective way (at least that I know of) to version it properly, as its nature is a compressed file, and the filesystem sees it as binary), versioning leads to excessive disk space used.
GODlike: it’s true that versioning works much better with plaintext, but that doesn’t mean there’s no benefit with binaries.
Affordable disk space is still growing nicely.
Just being able to go back to older versions (without having the folder cluttered with numbered files), helped by a log with commit messages, is of great value.
There’s certainly room for optimization and specific tools, which might include things like bitmap image version patching and diff viewers.
Well, I see it like this:
The user shouldn’t really be concerned with files at all. I mean, I should be able to go through my day without touching the file browser at all.
Right now, the only real place where we *expect* this behavior is with music players. These players manage our “libraries” in a way that we would never consider digging through the file browser instead of just using the player to find our music. So, why haven’t other apps caught on?
Example:
My word processor should manage my Documents “library”. It should help me find that report I wrote for history class, or the letter I wrote to my congressman with relative ease. I want nice previews of my documents, so I can see what they are at a glance and have categories so I don’t have to look at school work to find something related to my job. It should be able to find and download new templates from the internet. etc.
DanRabbit: When I talk about files here, I concentrate on the user’s point of view. That is, a file is a thing that has a name, can be moved, copied or deleted and happens “to be” a document, image, piece of music or whatever else. There’s no way a user would not be concerned with that for all cases where he has something to save/restore.
In both of your examples, you just end up with specialized, integrated file managers. In an application centric (as opposed to a document centric) setup.