Wednesday, April 1, 2009

Gnome 3.0 -- Please get rid of the file hierarchy

Beagle (software)Image via Wikipedia
Lots of peoplelove Gnome Do. Why is that? It gives them power at their fingertips. More importantly, it takes the filesystem out of the picture. It gives you the power to open a file or take action without seven clicks.

Gnome 2 does what it can to keep you from thinking about the file hierarchy, with Nautilus supplying your devices and bookmarks. The Deskbar applet lets you search using Tracker or Beagle. The filesystem is downplayed, but it should completely disappear. Why? Geeks may not understand, but the filesystem, even in $HOME, can easily become a giant mess where nothing can be found.

There are great attempts to make this situation simpler. Zeitgeist combines your files, bookmarks, and browsing history into a time line instead of a hierarchy. In a similar way, the People Project tries to combine your e-mail, IM, and social network contacts into one interface and not worry you about having multiple applications running. Soylent is also working in this direction, and seems to have recently joined forces with People.

Where do I think we need to look for answers?

Look to Beagle. Well, not actually Beagle, but any full-featured full-text search client. Beagle has a good number of features that are needed (like SPARQL and embedding tag info in the file or filesystem itself using Extended Attributes when possible), so I point there, but the Mono connectiion may keep it performing well enough. Most likely, a new one will need to be developed. It will need word stemming.

Look to Deskbar. Well, not actually deskbar, but a similar search aggregator that focuses on search and not things like updating your Twitter account. It needs a new interface, too. That interface will look a lot little Nautilus does now.

Look to F-Spot. "Whaaat?" I hear you say. F-Spot has a great interface for dealing with pictures without worrying about the underlying file hiearchy.
  • It has tags on the left, representing both intrinsic and assigned values. They are hierarchical.
  • It has a timeline on the top, and files are ordered by time, meaning that your most recently worked on files are right there at the top.
  • The browser doubles as a viewer. Double-click on the picture and you change from browse mode to view mode. Click the browse mode to go back to multi-file view.
  • It has an "Edit" button to edit the picture.
We then have full-text and tag search (Beagle-ng) using multiple plug-ins (Deskbar-ng) with a Naultilus-like interface (with the addition of a timeline) which doubles as the viewer. Double-click a video or music file and get an embedded Totem. A document will embed a document viewer. Click "Edit" to open OO.o, The Gimp, PiTiVi, or whatever. The People Project can be integrated into the tags. Here's a quick and ugly mock-up.

What about your Nautilus bookmarks? Those become saved searches, and appear in the Places menu just as before. The standard XDG locations come as reserved tags. Speaking of the menu, Applications are just .desktop files, now aren't they? Index /usr/share/applications and $HOME, and you've got your menu. Put something on your Desktop just by tagging it "Desktop." Share something just by tagging it "Public."

So where do the files really go? What about the Open dialog? The default location for files needs to be handled for the user according to XDG specs and the MIME-type. Videos automatically go in ~/Videos, images go in ~/Pictures, audio files go in ~/Music, etc with names assigned by the user, not meaningless strings. In case of emergency or migration, files hierarchies are in reasonable shape.

Le Hoang Ni has similar ideas, but he likes the Rhythmbox model.
File manager for Gnome 3.0

Where should Gnome 3.0 go? Search, that's where. Gnome added a wiki page about 3.0 in the last couple of days. Apparently, they have similar ideas for the base fuctionality, though the interface isn't really discussed.



I've written some thoughts on this as well, but took a different approach. I don't think this kind of file management should be handled by application layers, but rather by the file system itself. So rather than MIME-type decisions as to where in a hierarchical file system to store a given file, the file system applies a series of tags (user, group, type, dates, etc.,) the user can opt to add more tags, and of course, your full-text search would be indispensable.

Obviously the application layer would need some of the changes you are discussing to handle these changes.

Some of my previous thoughts can be found in these locations. (mine is solution #3)

Post a Comment

Other I' Been to Ubuntu Stories