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.


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.


To kick off the next wave, let me introduce a proposal for the successor to the Welcome screen: Tap. (Yes, the idea called LibreOffice Home is dead.)

Big thanks to DanRabbit for his elementary icon set and his Marlin mockup: they’ve really helped with the mockup.

It’s actually a file manager, inspired by Google Docs, Shotwell, iTunes, and other software. Why?

1) To close the gap between the file manager and the office suite
When you open an office suite, you either want to edit an existing file or create a new one. To do the former, you need to go to your file manager, navigate through a maze of files and folders to get to your file, then wait a few seconds while your office suite loads. (Alternatively, you can launch the suite first, then use the “Open…” dialog, but that’s a very similar experience.) To create a file, you need to launch the suite, create a blank document, immediately save it (choose where it goes and name it), and then you can edit it. Neither experience is very fluent or comfortable, because there’s a pretty big disconnect between the file manager and the office suite.

And here’s where Tap comes in. First of all, because Tap offers only select formats, it’s much easier to find a specific file. Nothing irrelevant gets in your way and there’s no complex hierarchy. Second of all, Tap loads the office suite in the background, so files open very quickly and there’s no splash screen disturbing your workflow. Creating a new file takes one or two clicks, and the user is first prompted to name it and then to edit it, much like when you create folders.

2) Sync and sharing

With the increasing popularity of mobile and web office suites, it’s becoming more of a need to sync and share files over a variety of platforms and devices. Most generic managers weren’t built with this functionality in mind, so developers of online and mobile office suites need to add this functionality to these managers. Unfortunately, generic managers tend to vary from OS to OS, meaning that if a service wants to integrate syncing and collaboration features with common file managers, it needs to develop a separate solution for all the various managers out there (Nautilus, Dolphin, Mac OS X Finder, the various Explorers, …).

With Tap, developers of both web and mobile office suites can focus on integrating sync and collaboration features with a single, cross-platform file manager that’s built with this kind of integration in mind, rather than the notorious variety of generic file managers there are.

3) Collections
Instead of folders, Tap works with collections. Collections are basically a best-of-both-worlds combination of tags and folders: they’re tags with a hierarchy (you can place a file in several collections, and you can have subcollections). If you have your files organized into folders, your folders can be effortlessly converted into collections, and so can your tags.

4) Unified experience
If Tap is ever developed, it shouldn’t be tied to LibO. All office suites should be able to take advantage of Tap, and it’d be great if Tap could actually be a standalone file manager, integrated with formats and applications of the user’s choice.

P.S. SVG of mockup here: http://rapidshare.com/files/451088143/tap.svg

Citrus: Wave 2

I’ve been gone for quite a while and it’s about time I wrote something here.

So, without further ado, I’m starting a new wave of Citrus posts. Expect a real post soon, for now here’s a mockup:

Quick summary (in the spirit of the first post):

  • the menu bar has different categories
  • there’s a search box on the same line
  • there’s a toolbar below with commands that apply to the current selection on the left and common contextual stuff that doesn’t apply to the current selection on the right
  • The ruler appears contextually, but can be enabled to show full-time or disabled completely.
  • The status bar has been reorganized.

And here’s an SVG file (it should be much more browseable than the last SVG file): http://rapidshare.com/files/451087506/citrus.svg (sorry for the RapidShare, Google Docs wouldn’t cooperate).