Linux and usability.

I'm going to put on my l33t geek hat for a minute. The backstory is that I am a Mac fan, and have been using a Mac for a while, but I have a lot of friends who are poor and can't afford the upgrades, and also I'm frustrated that the Mac does some things really well, but still asserts a bit too much lock-in, and doesn't really let you fix the problems it has. I think that in the long run, open source software is the right way to go. So I've been using Linux for the past month or so, and I've been switching around a lot between different tools. Linux has so many different tools that attempt to do the same thing, all of them incompatible with each other.

The first thing to say is that every single important application that I've seen sets its sights too low, with the possible exception of OpenOffice. What I mean is that each application attempts to be as good as Windows. Well if you're as good as Windows, why not just use Windows? Worse, they fail - they aren't as good. In some ways they're better, frequently, but in every case they fall down on some kind of basic functionality or usability issue. So how about being as good as Apple? No, that's not good enough either. Think outside the box. Yes, there has to be a migration path from Apple and from Windows, but it has to be a path to something better, and for the average user, something better doesn't mean "comes with source code." It means "makes my life easier."

So here are some ideas for how to make the user's life easier:

1. For once and for all, deal with the problem of backups and data portability.
2. Increase connectedness.
3. Eliminate lock-in.

Backups and data portability. Currently, if you own a computer, you do backups somehow. The most popular method is "make sure my disk drive never gets trashed, because I don't even know what a backup is." Next most popular is "I burn stuff on CD sometimes." Then you get into solutions like Retrospect, which are not unreasonable, but are very old school.

Data portability is a related problem. I have a laptop and a desktop. I have data that I want replicated across multiple servers. Coda and AFS attempt to solve this problem, but they do so in ways that give me the willies.

• The solution needs to be dirt simple. No storing peoples' data in DBM files. It's got to be as solid as a real filesystem.
• It's got to be transparent. There's got to be metadata about files, so that for example when you make changes to your mail folder on one machine, there's sufficient information that when the data is updated on another machine, your mail database there is also updated. When you add a calendar entry on your laptop, it winds up on your desktop too, and appears in your calendar. When you add a file to your iTunes folder, it's got to be replicated properly to your other iTunes folder.
  
• It's got to work when the multiple copies of your data are disconnected - you have to be able to make changes on the airplane. They have to get synced when you have a good connection again, without you doing anything special. They have to not bomb your 24kbps modem connection when you dial up from a hotel. They have to not run up a huge bill with your pay-by-the-k cell phone internet service.
  
• There needs to be conflict resolution, so that if you make a change in one place, and make a change to the same file in another place, neither change is automatically overwritten, nor does the conflict simply remain unresolved.
• There needs to be history, and that needs to be configurable, so that when you delete a file accidentally, or wipe out some part of it that you need back, there's a history you can go back through. This needs to not waste so much disk space that you go crazy. But disk space is cheap these days; we can afford to waste a lot more of it than we could a few years ago, and it's worth wasting to get this functionality.
  
• It must be possible to override the backup mechanism in cases where it's not what you want - e.g., perhaps you don't want the contents of the DVDs you stashed on your laptop for in-flight viewing backed up, because the backup is the DVD, and you're never going to use them on your desktop. You don't want a backup history of your iTunes folder - you're not editing files there. One copy per instance of the data store is plenty.
  

Increasing connectedness. When I get email, it's one of three things. Trash, deal with immediately, or action item. If it's either of the first two, I just deal with it. If it's the latter, it gets lost.

• I need to be able to put an email item on my to do list. This seems pretty basic, but nobody does it.
• My to do list needs to link to my calendar.
• I need to be able to group email messages into a single to do list item. I need to be able to use my to do list to make a plan for my day.
• It would be awfully nice if when I go to a to do list item, I can say "put me in the environment I was in when last I worked on this item," and my editor windows and terminal windows would pop up with the right history and so on. This would make switching tasks so much less painful. Forget about virtual desktops that I manage myself - I want a virtual desktop per task.

I think a big step in the right direction here would be to make the data store I talked about earlier deeply application-connected. Different applications would present different views of the data store. You could send a URI to the data store dispatcher, and it would arrange for the right piece of data in the data store to pop up in the right application. So this makes links between to do lists and email easy - a to do item that references email messages does so by listing the URIs for referenced email messages. The virtual desktop I talked about is primarily a list of URIs; to do it nicely, you also have to be able to remember where you were in the document, and where the window(s) showing the document were on the desktop. So a good solution to this would require applications to speak the same language about location on screen and location in file.

Eliminate lock-in. Right now, none of the apps on Linux do anything meaningful to eliminate lock-in. There are no shared data formats. There are document interchange formats, but frequently they're insufficient - take vCards, for example, or DAV calendaring, or RTF. Nice, but limited. So:

• Shared address book format, used by all linux apps, accessible cleanly by all linux apps.
• Shared calendar format, used by all linux apps, accessible cleanly by all linux apps.
• Shared keychain. No kde keychain, no gtk keychain: a linux keychain.
• Shared email format. No more IMAP - use the data store. No mbox, while we're at it.
• I don't know if it's possible, but a shared document format (OpenDocument, for example) would be nice. People are actively working on this. It needs to be the native format, not an interchange format.
• Shared sound bus. Pick one. I don't care which one, but pick one, and use it for all gtk and kde apps.
• Most importantly, give up on winning. Make interoperability your goal, not victory.

All this is a bit grandiose coming from me, and I don't intend it as a directive toward the open source community. It's stuff I've been thinking about, and might implement, and I really really wish others were on this bandwagon too. What's been done on Gtk and KDE is really neat - I've used both, and they both have real strengths. I'm not trying to knock them. I'm just saying what I want, for what it's worth.

Hm, one last thing: in order to encourage migration, all of this stuff has to work on Windows and Mac as well, and has to work better than the Windows or Mac alternative. The way you entice new users is to offer them a step up, not a lateral step, and definitely not a cheaper step down.