I've been trying to write this article for at least six months, but after three or four false starts, it's never quite come out right. So now I'm going to just sit down and get the words out, and not try to be a perfectionist about it.
This all started back when I first tried Spaces. All credit to Diego, it's a very impressive application, bringing together a lot of diverse data and trying to present a unified interface to it. But after about half an hour of playing, it became clear to me that I had substantial philosophical problems with a program that wanted to be a RSS aggregator/blogging tool/mail manager/calendar/God knows what else.
Premise 1: Programmers like to generalise data.
To a programmer, Instant Messaging and E-Mail are the same thing. They're both structured messages sent from one user to another over the Internet. The mechanisms used are different, but the differences aren't that great. In fact, there are just as big differences between the various forms of IM. If you took Internet e-mail, replaced POP with a presence-based system between you and your ISP, and allowed other e-mail users to query that presence, you'd end up with an architecture that is closer to Jabber than Jabber is to AIM.
So why do none of the mainstream IM applications look like e-mail applications, or vice-versa? Because when you move up away from the level of data moving around, the uses to which people put the protocols are entirely different. IM is immediate and ephemeral, e-mail is asynchronous and long-lived. IM is off-the-cuff, e-mail is more formal and official. (Interestingly enough, a few years ago we were making exactly the same distinction between e-mail and snail-mail.)
Premise 2: Once upon a time, it was a good idea to have do-everything applications.
When graphical operating systems were young, sharing data between different applications was hard. Having the user switch between applications was hard, and often completely beyond the user's understanding. This led to the rise of monolithic applications that tried to be entire computing environments. Word Processors and Spreadsheets agglutinated together to become integrated suites. Web browsers sprouted fungus-like growths of mail- and news-readers. Mail readers grew calendars and scheduling applications.
Unix nerds scoffed, coming from a background where unless you were one of those emacs weirdos, your email program didn't even have its own text-editor.
These days, the problems aren't nearly as great. Mainstream operating systems are much better at running multiple applications, users are better at navigating them, and the underlying API for cross-application communication and embedding have matured (although ironically Unix programmer tend to lag behind, accusing things like Orbit of KParts as being bloatware: “if pipes were good enough for my father, they're good enough for me!”. The uncharitable side of me would suggest that it's easier to dismiss something than learn how to use it.)
Premise 3: Applications that try to do more than one thing suffer as a result.
The current generation of user-interface, which is yet to spawn a replacement, has a certain upper-limit of complexity within a single application. On a practical level, there are only so many things you can put in a menubar, toolbar or preferences dialog before it becomes user-hostile.
The situation is at its worst when an application does a number of unrelated things. Take a look at Mozilla, which should never have copied Communicator's outdated ‘everything in the one application’ approach. Take a look at Evolution, the Outlook-alike for the Gnome desktop. It does e-mail, calendaring and even RSS aggregation. The only way it can do so, is by introducing the one thing you should avoid at all costs in a graphical application: modes. The contents of the menu-bar change radically depending on what task you're performing. This, however, means if you're trying to find a particular function, you must first find how to activate the mode that function forms a part of.
Premise 4: Sharing data is good.
One of the things that annoyed me at first about iChat, Apple's AIM client, is that to add someone to your contact list, you have to create an entry in your system-wide address book for them. This seemed to me to be a complete waste of time. Then I discovered that because address-book data is shared by other applications, when I receive an e-mail from someone who is also online via AIM, a little green dot appears next to their name in the mail-client, and it will allow me to send a reply through iChat. This is only possible because the Address Book knows that the email and the AIM ID belong to the same person.
The value of a network grows exponentially with the number of nodes. So does the value of a network of applications. Each interaction between cooperating apps can add value to both the supplier and the consumer of information. On its own, the Address Book in OS X is pretty useless. But by being a central repository of contact information that all other applications (and devices, thanks to iSync) can leverage, it enables a raft of functionality in other applications that just wouldn't work without it.
Conclusion: Write apps that provide a specialised interface within a single domain, but that draw data from (and contribute data to) a system- or even network-wide datastore. (look at Apple's embrace of ZeroConf/Rendezvous, or Newsmonster's proposed P2P sharing of RSS headlines) Leverage the APIs that allow you to have applications co-operate, and always provide an open API to allow other applications to draw information from, and manipulate your program.
Generalise your data. Specialise your apps. Computing nirvana will follow.
