David Burrowes' Blog

Here is an interesting article:

Will Short Scope Hinder Slashdot Redesign?

In this article, the author, Khoi Vinh, mentions that Slashdot is seeking a redesign of their web site. Yet, this redesign is confined to changing the look of the site, not changing the underlying architecture of the information on the site.

To my mind, this reflects a common view of user interface design. Many feel that UI design is about making some existing thing prettier. Rearranging buttons in dialogs, changing colors, adding better icons. Often, though, this is the same as putting lipstick on a pig. (which is not to say Slashdot is a pig. Just that other software projects have a certain swine-like forms).

Good UI design starts far beneath the surface. It has nothing to do with look, and little to do with feel, and almost everything to do with arranging the underling information and entities in a way that will be sensible to the user. With the right underlying structure, a good interaction model can be put on top, and then a good "look and feel" can be added on top of that. Without this, the underlying model will become aparent at all the levels above it and the resulting user experience will be problematic.

The hard part is that that underlying model is usually in the same "place" as the system architecture. And this is non-intuitive to those that see UI as just "look and feel". They don't expect that their "engineering architecture" will affect the usability.

Let's consider one example. Application delivery architecture. On Windows and Solaris, an application often consists of multiple files. A primary executable, maybe some help files, maybe some documentation, maybe an uninstaller. On the Macintosh, and application is a directory, containing all those same things. An interesting byproduct of this architecture is that it is very easy to install a very complex application on the Mac. The environment treats these "application directories" as a single "file" to the user. So, to install one of these apps just involves a drag and drop operation. Indeed, I seem to recall that "installing" the whole Microsoft Office just required me to drag one thing from the disc to my Applications folder. In contrast, almost any interesting application on Windows requires an installer to place all the files in the right place (not to mention updating the Registry and who knows what else). The inverse operation, removing an application, is generally easy on the Mac: drag the application (folder) to the trash. On windows, it requires an uninstaller.

It is interesting that the Mac application architecture is, in this spirit, the same as the NeXT application architecture, so this is an old thing. Was it created to facilitate application management like this? I'd certainly like to think that someone said "wouldn't it be great if users could install all the complex parts of an app without an installer?" and then that birthed this application architecture, rather than the more common model of creating an architecture and wrapping the user experience around that.