Artistic Simplicity

In an earlier post I pointed to some general principles you should abide by when developing software. Two of these, parsimony and perspicuity, could use a bit of further elaboration. Together they delineate the promotion of a simpler approach to design. Why is simpler better?

As the saying goes, "there's more than one way to skin a cat." Relax it's just a saying, I have nothing against cats. The point however is that given any coding challenge there's usually an algorithmic technical nifty way to get it done, and a more lengthy but more easily understood mechanical way around the problem. The technically elegant way will execute faster and may allow for some future bells and whistles that can be accomplished with just a couple of extensions. The more transparent, simpler to understand, lengthy code will take longer to execute and will require more lines of code when it eventually becomes time for a new feature.

But frankly the longer code is easier for a novice to understand. And in the modern corporate world of high employee turnover, constant technological change, and shifting management fads, the longer code -- because it can be maintained by newcomers -- realistically has a greater probability of staying in use.

Simplicity begets Longevity.

The Art in Beauty

Whether we are consciously aware of it or not, in the midst of development we make hundreds of tiny decisions that reflect a choice in "beauty". Mostly these boil down to a decision for what level of elegance we will apply to a design approach: whether to hack away at something until it works or whether to design the code with an eye toward easing future maintainability.

In the old days we used the shortcut terminology of "table-driven-design" to signify the latter case, but nowadays designing for maintainability is much more than this (see for example these earlier posts).

For now though consider this interesting metaphor to beauty: just as a person can suffer equally from both too much beauty or too little beauty, the same can be said for the elegance and maintainability of a software system. If something is hacked together in an ugly and hasty fashion then not only will you have to support it forever, but you will grow gray or lose all your hair in the process. Conversely if you design something that can be maintained and extended simply by adding rules to a SQL table then your employer doesn't really require your continued ongoing services.

You must therefore choose an appropriate level of elegance in the same way that people choose their level of beauty. This has all sorts of philosophical and aesthetic consequences that I examine in a different category.

Artistic Arranging

In the windows-form world menu layouts are pretty settled, but no standard has emerged yet in the web-form world.

In a windows form try to keep your menus parallel to how Microsoft has theirs laid out: always a File menu at the farthest left, and a Help menu farthest right.

Use horizontal separator lines to partition out items of similar function, and be sure to enable hot-key shortcuts to the commonly used items. You should avoid a single item alone between separators. Menus shouldn't exceed eight or so items in any dimension (per pulldown or across) and shouldn't pop-out more than two deep, although I usually require a fairly serious reason for any pop-out after the first one.

Interfaces on web forms are tending toward an artificial "tabbed" approach. This works reasonably well provided you stay consistent with fonts, vertical spacing and presentation layout. More than three levels deep of tabs looks ridiculous; at that point its better to partition master pages into separate functional groupings. Avoid mixing horizontal and vertical menus on the same page and use a consistent menuing approach throughout your application.

Laying out menus is an art all its own. It's rather like playing rhythm guitar -- take the time to do it right and your menus should look good, be clean and intuitve, and stay in the background.