Monday, October 31, 2005

Elegance and Design


Under Steve Jobs' fanatical regime, Apple products have always been characterized by elegance. Elegance often refers to an aesthetically pleasing quality which is a subjective estimation of something. But in the fields of mathematics and engineering, elegance refers to simplicity and parsimony; an elegant solution is often at once brilliant and simple. It is brilliant AND simple because it makes on exclaim, "why didn't I think of that?!" The solution is obvious once one is shown the way, and is often, from then on, seen as the only way it could have been done.

Apple's designs incorporate little or no fluff -- take the iPod for instance -- and yet are both beautiful to behold as well as functionally easy to use. As Matthew pointed out in class, such simplicity and beauty which seems obvious in retrospect is often the consequence of tremendous effort.

The first Powerbook -- PB100 -- took a complex configuration of laptop and externally clamped trackball and turned that into the "obvious solution" of integrating the trackball into the keyboard itself, and creating a palm rest as a bonus. The same sort of thinking can be observed in the way the Pages word processor incorporates a whole lot of what might have been separate toolbars into just one "inspector". That solution now seems "obvious" and yet one that appears to have never occurred to the towering intellects that inhabit the Microsoft campus.

It is interesting how most other vendors try to mask their poverty of design with different colors, textures, shapes and other non-functional attribues; In Apple's designs it is virtually impossible to find even one feature that does not serve some functional (as opposed to merely ornamental) purpose. This is the way Mother Nature goes about the design process.

This leads us to a Golden Rule: after an initial set of design processes, remove from your design everything aspect that is not absolutely necessary. Each and every little part of your design has to be justified or killed. This might seem risky, but IT projects get delayed and ultimately cancelled often because of the developer's inability to stop designing.

No comments: