Why there’s a need to reinvent the file browser

While web browsers have evolved amazingly rapidly over the last few years, thanks in no small part to Firefox and Chrome, file browsers have evolved at an extremely sluggish pace. Sure, over the years we’ve had some innovations like improved search and file previews, but for the average user, file managers are still woeful at their one function: managing files. That’s why people’s desktops are so crowded, why their Downloads folders are teeming with files, and why people are increasingly moving to specific file managers, like iTunes and iPhoto (or their FOSS equivalents).

But specific file managers still don’t cut it, at least not yet. They don’t exist for every file type there is, they show files only from specific folders, they don’t integrate with other applications (e.g. if you wanted to browse your Shotwell collection with Chrome), and, most importantly, they don’t allow you to associate files of different type.

My Tap proposal started out as an evolution of the LibO welcome screen into a specific file manager for LibreOffice files, much like the Google Docs file manager leads to all of the Google Docs modules. This manager would benefit from deep integration with LibreOffice and would make it easier to integrate LibO with online and mobile services, which usually lack a generic file manager. I realized, though, that this is not an optimal solution, as a LibO-specific file manager would single out every other document/presentation/image/… editor. Because this manager duplicates most of the functionality of a generic file manager, it makes more sense to just improve the generic file managers.

How?

Well, it’d be nice if there were some APIs that file managers could use to communicate with applications (I’m not a developer, correct me if I’m describing it incorrectly). The goal would be to get application commands into the file manager. For LibreOffice, these commands could include document conversion and exporting (e.g. *.doc -> *.odt), printing (you could print several files), editing document properties (metadata, security and internet options), wizards, merging and comparing several documents, creating a master file from several documents, etc.

Another welcome improvement would be leaving management of system files to “technical”/advanced/classic file managers and concentrating on managing non-system files, i.e. the files that the average user tends to come in contact with.

Various managers have been dancing around the idea of getting rid of the folder hierarchy. Personally, I find Google Docs’s solution to be the most powerful, yet incredibly simple: collections. Collections are basically tags that can have a hierarchy (i.e. you can have a single file in several collections, and collections can contain subcollections). There are many reasons to prefer collections over folders, and you may see these use cases already implemented in some specific file managers. For example, in photo managers like iPhoto or Shotwell, you can categorize photos by the people in the photo, by date, by event, and by any other custom category. In music managers, like iTunes or Banshee, you can include a single song in as many playlists as you’d like.

In a generic file manager, there is an advantage in sorting files by filetype (like Google Docs does or like many media players do). Sorting by filetype allows generic file managers to have the same kind of filetype specialization as specific file managers do. For example, there could be two kinds of collections: generic for all filetypes (akin to folders) and filetype-specific. Thus, you could use playlists with the “Music” and “Videos” sections of your generic file browser, photo albums with the “Photos” section, libraries with the Documents section, etc. The interface wouldn’t bloat up with collections too easily, as filetype-specific collections could only show up when viewing the appropriate file type.

Lastly, all file browsers could profit from built-in (or just closely integrated) file preview capabilities, à la Apple’s QuickLook and its open-source equivalent Gloobus. The improvements range from being able to use your file browser as a basic media player to just not having to launch and close an application every time you want to look at a file.

Post navigation

2 thoughts on “Why there’s a need to reinvent the file browser”

I hear you … file browsing needs innovation. You eluded to a browser that just focuses on day to day; relevant user files. This is exactly what is needed. A file browser that makes it easy for people to quickly access relevant, personal and work related files. One that has perhaps a superior paradigm than just ‘files’.

Regarding existing solutions, it’s worth noting that Directory Opus (Windows) is an amazing desktop file browser. It too uses a ‘collections’. I don’t like touching Windows machines without it. The fact that Windows 7 file default browser doesn’t even have tabs is laughable. And validates your initial statement that ‘file browsers have evolved at an extremely sluggish pace’. (though, to be fair – most *nix browsers do support Firefox style tabs)