Office 2003 uses a table of 1500 colors to render the user interface. That’s 1500 different colors designers have to choose for each color scheme. Overkill? Probably. But it says something about commercial software that sets it apart from most open-source software. Despite the greater theme/skin-ability of KDE, Gnome, and friends, open-source GUIs tend to look less “polished” than big commercial ones. To be fair, the same could be said of an awful lot of shareware and commercial software from smaller companies. The fact is, only a huge company like Microsoft has the resources to pay professional designers just to pick colors all day.
Can independent developers compete? I think they can, with a different approach. By adopting a standard API for interfaces that goes beyond the usual widget set to encompass entire interaction paradigms, developers of many different applications can all take advantage of a consistent interface. Then that interface can be beautified by a relatively small number of designers.
I’m not talking about user-interface guidelines like the Gnome and KDE projects have, I’m talking about abstracting the entire interface away from application programming.
Emacs provides a simple example that goes in the same vein: If you are writing an Elisp application to run inside Emacs, you do not need to provide an interface to set user preferences for that application. You only need to describe the user-customizable variables and their possible values, then Emacs itself renders those options in a customize buffer, which will look and act consistent with every other Emacs customize buffer.
Now, Emacs is text-based and programmer-oriented, and the customize interface reflects that. But there’s no reason why the same concept cannot be applied to graphical interfaces. Suppose, instead of writing classes for MyAppMainWindow, MyAppMenuBar, and MyAppToolBar, you just specify “My App manipulates Foo objects. It provides the following functions: Qux Bar Baz. It can read and write Foo objects as plain text or XML. It has these user preferences: 1 2 3.” In other words, specify the hooks into the application’s functionality and let the GUI framework worry about things like where to position controls in a dialog box.
Creating such a sophisticated framework would not be easy, but I believe it could be done, and would open up possibilities for faster application development with more sophisticated interfaces.
Yes! Yes! Why hasn’t this idea caught on? Even user interfaces developed with current web app frameworks aren’t usually this abstract, except for cookie-cutter stuff like Rails scaffolding which is only meant for prototyping.
A UI framework this abstract could even break away from the assumption, inherent in every GUI toolkit I’ve ever seen, that the user interface is visual. Think about what this would mean for accessibility for blind users. For that matter, an abstract UI framework like this would also make it much easier for blind programmers to develop presentable user interfaces for their apps.
Stuart, have you thought any more about this idea in the 6 years since you wrote this post?
Ha! Hello, Matt. I’d actually forgotten about this post. I’ve learned a lot more since then, though, enough to make me think that this is largely a pipe dream. In order to be useful, a user interface has to conform to a mental model of the operations it enables. Developing such mental models is incredibly difficult, creative work, not something that can be automated. Pick any web app: would you rather work with it through a generic CRUD interface or an interface specific to the application?
That’s not to say we can’t make the GUI designer’s job easier by providing more abstractions around interfaces and better languages to describe their semantic meaning. Various web technologies show some hopeful glimmers of this approach.