your tool and made your investment to learn its bells and whistles, woe be the day you need to develop something that your tool doesn’t support.
I suppose you can paint a portrait out of pottery, but it’s just not the same. It looks like a portrait out of pottery. The tools that you use define you nearly as much as your accomplishments. True artists practice a unique style by developing their own set of tools. A structure, a methodology, a bunch of accouterments seem to create themselves a priori out of thin air and then this drives the subsequent creating.
When you are developing you should always strive to increase the variety of tools at your disposal and leverage them by finding ways of blending them to make them work together. Work as if you want to become the next Jackson Pollack or Andy Warhol of code.
Artistic Language
It happens pretty rarely in one’s career, but perhaps once or twice you will find yourself in the unenviable position of selecting a development language for yourself and your cohorts. Nowadays most shops use C# or Java, but back in the day when our choices were Cobol, Basic, or Fortran, I had the pleasure of making this dubious analysis. And no doubt as hardware and languages progress we’ll reach another tipping point where you may find yourself selecting between a panoply of competing next generation languages, so I share this in the spirit of support for when you need to cross that bridge.
Choosing a new language to use is as distressing as having to select a new city for relocating. You can research the weather, travel blogs, crime statistics, and a hundred other metrics, but you only fully appreciate the flavor for the place after you’ve lived there a couple years.
Languages bring to the table a variety of capabilities. Part of the challenge in making a selection is that you need to be fairly conversant in the languages you are reviewing so that you can both define the nature of the capabilities and then rate the features of the languages across those dimensions. Metrics I have used in the past include:
+ complexity of math library
+ readability of code
+ flexible variable typing
+ multithreading support
+ security framework
+ development environment tools
+ trace and debugging support
+ compilation speed and complexity
+ runtime distributable
+ execution speed
+ step-through execution
+ data entry validation masks
+ extensive sort support
+ integrated dictionaries
+ versioning
+ vendor commits to backward compatibility
Yeah it’s a lot to request from a language vendor, but then once you select them you will be making a major commitment in your vocation to the effort of using that tool. Perhaps it is precisely due to the difficulty of this decision that developers turn into pundits. If you wish to be continually marketable though it’s smarter to stay flexible and multilingual. A software language is a sophisticated tool: respect its art but be cosmopolitan.
Interface Design
Whether you use interface design as the engine to drive your software development or whether you consider it a necessary evil to providing functionality to the folks signing your paycheck, one way or another you will become enmeshed with the challenge of placing fields and designing navigation into some sort of visual interface.
This turns out to be the ultimate smackdown between aesthetics, culture, science, psychology, and your software tools.
In this chapter I provide a handful of varying approaches to this task. Absorb and understand each one fully, but for creating truly elegant and intuitive interfaces that work well you really need to internalize these separate learnings and implement them in parallel.
Artistic Menu 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 laid out theirs: always a File menu at the farthest left and a Help menu farthest right.
Partition out items of similar function with horizontal separator lines and be sure to enable hot-key shortcuts to the commonly used items. A single item alone looks wrong isolated between two separators. Limit menus to eight or so items in any dimension (per pulldown or across). Pop-outs shouldn’t be 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 remain consistent with fonts, vertical spacing, and presentation layout. Exceeding three levels of tabs looks ridiculous, as if you were a multilayered teenager with stockings, leg warmers, coolots, a skirt, blouse, vest, jacket, and a scarf. At that point it’s better just to partition off master pages into separate functional groupings. If you use horizontal and vertical menus on the same page the fashion police will arrest you; use a consistent menuing approach throughout your entire application.
Laying out menus is an art all its own. It’s rather like dressing professionally: take the time to do it right and your menus should look good, clean, intuitive, and stay in the background.
Artistic Sparsity
Even though we know it in our hearts, we still fail to account for how a software system grows and becomes more complex over time. Designing interface screens is a lot like planning an informal garden; if you want it to look great once all the plants take hold and fill out you need to think a bit about the future. Instead folks tend to wireframe a product that looks “complete” with reasonable use of the menu real-estate and a felicitous spread of field-density on the screen at the initial planting, as if the product is somehow “finished” once you implement it.
In doing this we make things look good in the /present/, yet we fail to account for system growth. When we later add significant new functionality… surprise, our screens and menus appear too overgrown and cluttered. It’s as if you planted all the apple trees two yards apart because it looked better; now that they have branched and fruited they are all atop on another.
Therefore when you are creating a new system plan for expansion by deliberately under-designing menus and occupancy: make the interface artistically sparse. And then don’t worry about it; like a garden your interface will “fill out” as it matures.
The Art of the Form
Let’s face it: programs run on data. Your software will either receive a direct supply of this data from another machine or it will be interacting with human beings. Most business programs must ultimately, however, gather input from folks who enter vast quantities of customer-related data by typing on a keyboard into an on-screen form. Hence one key to successful software design is mastering how to develop effective data entry forms.
Since humans are highly evolved toward visual processing and semiotic signaling, designing a
