This week I ran into several references to "grand unification" in software. An internal project has the name "Grand Unified (thingie)", I was reading some about GRUB (GRand Unified Bootloader). And, amusingly, as I came to write this blog entry I noticed a very new entry on blogs.sun.com called "Why not a grand unified garbage collector?"
As a developer, I love all these things. Solving many problems with one solution is often efficient, reliable and satisfying.
As a UI designer, however, I cringe when I think of this.
As an extreme, I was joking with a coworker involved with an installer project that we really just dispense with all our software and only use installers. You want to add some text to your StarOffice document? Just run the "New Text" installer ("Welcome to the New Text Installer, I agree to the License agreement, pick the document that I want to install the text into, specify the text, click "install", get the summary report (don't show me the readme) and quit). Makes the user experience very consistent. You get the same interface for everything.
Of course, that would actually be a terrible experience. While that is extreme, there's no doubt that all of us in the software field are inclined towards the conceptual elegance of unifying things.
A moderately extreme example is the Newton from the early 90's, which was basically trying to be equivalent to a desktop computer of sorts, but in a portable form. It got trounced, of course, by the Palm Pilot. While the pilot did that partially on price and size, I think it also partially did that by removing the sense that it was a "do anything" device and instead focused on doing PDA kinds of tasks well. It was, fundamentally, easier to understand and thus use.
A much less obvious example here is the JTable component which is part of Swing. This seeks to serve all tabluar needs. This seems like a good thing. As a developer you learn one class (or, one suite of classes) and you can create a spreadsheet, a multi-columned list or (if a tree is added to it) a hierarchical list. The trouble here is that when you look at the user experience of these different interfaces, they actually have slightly different requirements. A spreadsheet-like interface may legitimately allow individual cells to be selected and modified independently of all others. In contrast, in a multi-columned list each row is a single object and it really makes sense to operate on a whole row at a time. There are other similar issues here, for example, obscure keyboard navigation behaviors are a little different. The point here is that the abstracted component, in the end, doesn't do "spreadsheet" like interfaces perfectly nor does it do list-like interfaces easily, even though both ultimately display a 2dimensional grid of values, because there is too much in the way of "grand unification" here. (in consideration of the Swing team, I'm sure the JTable component was created before the different roles it might play in an interface were discovered).
So, how do you determine the right level of abstraction? (after all, you probably don't want a one word processor for 5 page booklets and another for 15 page booklets!) As always, this goes back to the issue of looking at the needs of your users and determining how your software will be used by them. Are the things you are trying to unify genuinely unified from the user standpoint (probably so in the case of GRUB, for example. Probably not in the case of JTable)?