The last release (Ubuntu 7.10) was the first in which we shipped Tracker enabled by default; this service runs in the background and indexes all of your files, storing information about them in a metadatabase which can subsequently be searched. The two main ways of searching are through the deskbar-applet (press Alt+F3) and within the nautilus file manager (press Ctrl+F).
That’s all well and good, but since we now have a metadatabase and indexer, what else can we do with it?
The first thing that comes to mind is improve those applications that attempt to maintain their own metadatabase; those that tend to be the primary apps that we use because they manage our all-important content. I’m going to pick on Rhythmbox here since it’s our default music manager, but the same ideas can be applied to our default photo manager, F-Spot, or any other application concerned with content.
A no-brainer is that Rhythmbox no longer needs to worry about walking directory trees, keeping inotify watches on them, identifying media files, etc. Tracker already does all of that. All we need to ensure is that tracker collects all of the metadata that Rhythmbox will need to start with — we expect it to come along and add additional metadata, such as the last time I played the track, where the album cover thumbnail is stored, etc.
Another thing you get to eliminate is the concept of “the Library”. Your entire home directory is already indexed, why care about partitioning it? We can just show the user all of their music, or all of their photos. Immediately. With no need to import from one arbitrary location on disk to another.
Tracker should then grow removable device support, indexing files on removable devices just as it does on the primary filesystem; but keeping mount-relative paths to the files and remembering particulars such as serial number, label, etc. for the device they were found on. This has immediate benefit for Tracker anyway, I can search for a presentation and I’ll be told which USB Key I wrote it to so I can find it again — I’m terrible for losing presentation slides after I’ve given the associated talk.
All Rhythmbox then needs to do is query Tracker for removable devices containing music, and show them as icons in the panel; the contents are already indexing — or if you’ve already used that device, indexed (no more wait for it to index my 40GB media player every single time I insert it). Since there’s just one metadatabase behind this, you may as well add an “All Your Music” option to the top which amalgamates the collection of music on your filesystem and removable devices, eliminating duplicates; this would be the thing you’d share, getting rid of yet another bug.
We then don’t need import dialogs. If I plug a media player in (or a camera, this applies equally there), the content immediately shows up in my browser. The only question we need ask the user is whether they wish to add the music on the device to their local collection, and that can be done inline in the window rather than with an obtrusive dialog. For F-Spot the experience would be that on plugging in a camera of photos, the main F-Spot window would open with the photos already in place (or appearing) in the rest of your collection and a “add these to your collection?” bar at the top — since you have the full app, dealing with adjusting images on import, or removing them entirely is much easier than fiddling inside an option-filled dialog.
The only other backends we’d need would be for remote media such as shared music –why isn’t there a shared photos standard yet?–, online content such as last.fm or flickr and devices that don’t act like disks; there are still some media players and cameras out there which are designed around import/export APIs.
A common mistake of user interface design is to come up with a clever solution to a common user problem, when you should work out a way to remove that problem in the first place.
My example here is the password entry dialog, in particular the GNOME Screensaver one.
The common user problem is that their password is rejected, even when typed perfectly, because the Caps Lock key is on.
The clever solution was to display in the dialog that the Caps Lock key was on, and thus hinting to the user why it might have been rejected.
The better solution would be to ignore the state of Caps Lock in all password entry dialogs, so it doesn’t matter whether it’s on or off.
Havoc’s keynote at GUADEC was extremely interesting, especially for how it polarised the people present.
Several people seemed very upset with the notion that f-spot should be replaced by flickr, but I think that was a problem with the way that Havoc presented the message, and not the underlying idea.
Instead consider f-spot and flickr as sharing the same collection of data, and being two different ways to view and manage it; with changes from one appearing in the other. The mechanism isn’t important.
Consider the following:
- While out and about, I take a picture with my camera phone.
- On coming home, the phone is within bluetooth range of my laptop (with both enabled).
- The laptop sees the new picture, so announces the availability of the new picture.
- f-spot is subscribed to those announcements, and causes the picture to be copied into my local f-spot library, with the meta-data adjusted to indicate the local cache (as well as the origin).
- flickr is also subscribed, so the picture is automatically uploaded to my flickr account.
- At some point in the past, a friend on Facebook changed their mobile number; this was detected and the change announced.
- e-d-s was subscribed, so automatically adjusted my contacts.
- And my phone sync service is subscribed, so now my phone is in range, its contact list is updated too.
Now, isn’t that cool?