Friday, December 01, 2006

My Dream File Manager

What follows is a collection of points for my dream file manager. It was collected from notes I have been taking over the past two years so I am sorry if it doesn't flow that well together. So grab a beer and get ready for some chuckles as you read the key points for what would makes my dream file manager.

1) Hide the details from a user on how to access their files

Files are stored on volumes. Users should be able to just point and click and have access to these volumes. "Volumes" is a generic term referring to a number of things such as cameras, ipods, nfs shares, ftp, fish, zip, and more. Hardware volumes that are removable should just appear in the file manager with no effort on the part of the user by default. Software volumes must be discoverable (through a network explorer) and if possible accessible through an assistant such as in mockup on the right.

Currently in Konqueror you need to be taught about the useful ioslaves by someone else before you discover them yourself. This would not have been a problem if there was the most basic assistant to help users discover what ioslaves were available.

To accomplish this first task the file manager should have tight integration with solid and HAL to get all new hardware volumes and possibly provide an assistant to make accessing software volumes discoverable. For network browsing the mdnsResponder is also available for discovering local shares.

2) View & Edit meta information

Files contain meta information that is for the most part only relevant for a file manager. This can be broken down into two categories, the first being for volumes and the second being for files.

Volumes:
  • Volume Name
  • Free space
  • Size
  • Health status
  • etc

Files:
  • Size
  • Permissions
  • Ownership
  • What opens this file?
  • Icon
  • etc

The above two lists are very small and will change depending upon the file system, hardware, OS, etc. A modular approach is best.

Beyond the basic file system information file manager often have a plugin system for extended attributes editing such as the comment, title, and keywords on a JPEG or the rating of a mp3. This should not be part of the core file manager, but through an addon script system. The extended attributes should not provide means to edit metadata that would not normally be accessible to a type specific manager. For example in iTunes they don't let you edit the play count even though this is just another field in the id3 metadata. Extended attributes also by default shouldn't let you edit every possible metadata (image exif has quite a lot for example), but only the most common and useful.

3) Export and Import

A file manager can be expected to move files in and out of the current environment. Two common cases includes audio cd import and data DVD burning. This builds upon #1, but typically has a intermediate step that needs to be performed before a file can actually be copied/moved. In #1 you could see a CD and could copy the CDA files off the disk, but now you could see mp3's and when you copy them it will transparently encode the CDA files. Also creating a virtual folder that would then be burned to a CD or DVD. The export and import will typically be plugins that are well integrated with the interface (and not klugy addon hacks). Check out the Finder's Burn folders for an example. Another example is an iPod who when mounted is just a bunch of garbled files, but with a import layer the user could simply see a list of files with the correct file names and could drop new files in and copy old files off. Finally Trash is a nice little virtual folder that has the extra feature of emptying or restoring.

To accomplish the above today you can use dbus with k3b for the ripping and burning.

4) Basic information, but not a full blown viewer

The simplest example of this is showing a image thumbnail rather then the png icon. Other examples of this include showing a specific application icon rather then a generic binary icon. Depending upon the interface if there is a preview zone it can include extra basic information such a image dimensions and for audio basic playback.

5) Full search capability

File managers much have full search abilities, but by default only present a single line edit in the upper right of the interface. Through an assistant the user should be able to make virtual folders that contain rich search results. Some common useful virtual folders should be present on the system such as recently launched applications or files created in the last week.

Today Konqueror can integrate with strigi for search results, but Konqueror can even present the slocate ioslave until strigi is up and working.

6) Manual Grouping

To the user manual grouping is very similar to search folders. They are virtual folders that users can drop files into. The files are not moved there, but only sym linked. I hate to mention it because of the one and only one way that browsers have implemented it, but a common way that this is seen today in application is a bookmark system. To help you to see it differently think about how in iTunes you can have playlists that you build up yourself by dragging files from your library. You can have smart playlists (all songs I rank 5) and plain old playlists which you manually manage (the Norwegian audio lessons I am currently working on). A even simpler implementation of this is the OS X Finder sidebar which lets you drop folders and files on the sidebar for quick access later.

7) External interface to access the "stuff" in the manager

The first aspect of this is to be able to communicate with the file manager to perform operations such as a search, viewing recent folders, icons for files, etc. dbus is currently the solution for this. The second part is once you get the results being able to access the data which KIO/QFile do fine.

An basic example of this is a screensaver that queries the file manager for a list of the fifty most recently created images.

8) Extensible

A file manager should be extendable. Because of the wide use cases that this application is going to be used it needs to be modifiable. This can be as simple as providing a way for people to add right click actions to replacing the search system entirely.

Almost all of the above requirements for a file manager would benefit from plugin type systems and in fact many of them could be implemented in with them.

Incorporating the ability to write portions of the application in PyQt, kjs, QScript, or other scripting language should be thought about from day one.

Stressing this even more it is often time the community who when provided access to an extensible scriptable system will come up with features and capabilities that were not on your roadmap. A perfect example of this is FireFox that has countless addons. The features provided by the community will satisfy user itches without forcing the core application to become bloated while at the same time increasing the value of the application. Another benefit is that the interface can start out simple and only the most successful features can be added at a later date helping to prevent bloat.

9) Addon/intigrated tools/actions that build upon the above features

A file manager should provide by default a set of basic set of core features that enhance file management tasks.
  • History of everywhere that you have browsed, i.e. back/forward buttons.
  • compress folders & expand compressed files.
  • Wildcard / RegExp selecting.
  • .hidden file support that hides files/directories in the file system.

Some extra addon module/scripts can be provided for more advanced users
  • Drop Stack (drop your file(s) in this space, change directories and then drag it to its final destination)
  • console at the current location for advanced users.
  • renaming assistant.
  • Some sort of built in automatic backup system.
  • Ability to selectively mark folders for sharing.

10) Interface


Finally, after all that we get to the interface. The simpler the better, it should have tabs, but not on by default, there should be a search field, but only a single line edit in the top right. There Should be a single sidebar on the left that contains all mounted volumes (virtual or not), bookmarks, and virtual folders. Somewhere always present it should list the free space for volumes. As for the files there is merits to having only an icon view and a details view, but some would argue that a tree view and column view do very well. It would be fascinating to see several completely different approaches that focus on either a list, tree, or both. I will leave that up to a usability study, but no matter what the result it should be fully accessible from the keyboard. I personally love the column view in the finder for its quick keyboard access and final preview window. Also the first nine requirements generate a basic list of features that the interface should have, but they are not that interesting to debate.

Popular Posts