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.

The Art in Ownership

Every analyst who has been called in to a consulting gig recognizes that money, the capital behind the business, carries a fair amount of power. He who has the gold makes the rules, and all that. The actual relationship between a company's owners and its employees is however substantially more sublime. The primary power at owners' disposal is hiring, firing, and purchasing, but they may only exercise these within the constraints of their detailed knowledge of the actual day-to-day operations that their employees support. This is where your role as an analyst faces its greatest challenge: in effect you are pinching the constriction of knowledge as it straddles across the employees and the management.

I have only found two ways to respectably play my cards as an agent of knowledge restructuring between these two parties. The first option is to nominally side with management, the second option is to firmly stand by the employees. In the first case you become an extension to the desires of hatchet men, using their power indirectly while pressuring the employees to reveal their knowledge. This method is best executed from the role of an outside consultant.

The second alternative, siding firmly with employees, requires that you nonetheless "package" your presentations to appeal to the baser, monetarist side of management. In either case you need to remain a bit guarded and two faced, hence in the end falling a bit short of the unrealistic expectations of both parties.

Society imposes its wishes on business owners with a large and diffuse glove, that can occasionally sprout spikes of glistening razor-sharp titanium. Enforcement can sprout as tax compliance, licensing issues, fair trade rulings, patent law, or numerous other sundry regulatory appendages. Occasionally you may find yourself defining a system with some sideways legal considerations. The safe way to approach this is to make sure that /some/ sort of audit trail exists, should management decide that at some point in the future they need to more tightly, retroactively, comply.

The symmetry between a businesses' owners and its customers is perhaps one of the most deeply studied aspects of capitalism. When all is said and done however it really boils down simply to two managed aspects of a buyer-seller relationship. The owner/seller is trying to optimize the services and products they will provide, and the buyers are choosing the best "value" given their variable and shifting tastes. As an analyst you are therefore trying primarily to implement a system that provides both immediate and ongoing value-added efficiencies. Customers can sense however when they are being manipulated; be wary therefore if your system is going to provide further margin to your employer without a concordant benefit that gets passed along to the customer.

Artful Traceability

When you are in the actual throes of day to day production… after the development is done and you work out most of the bugs… it certainly is convenient to have some sort of end-to-end Traceability. The general concept is that every change in state or activity that has a material financial impact to the company (or its customers) should be traceable back to underlying actions.

The idea is somewhat similar to how an airline keeps track of its design and maintenance records. When a portion of the avionics fails during a landing it sure is nice to look back through the records to see what parts get linked where, and what has changed.

For example, at the end of the month you send an invoice to your customers. Where do the line items on this invoice come from: what atoms of work and activity (from a systems viewpoint) do they represent? Can you trace back from an invoice number back through shipping, fulfillment, ordering, and customer options?

Many time validation is just viewed as comparing the results of production back to the functional specs to make sure all of the business rules got implemented correctly. But validation should also be enabled for ongoing activity in a dynamically changing system, and this requires designing for traceability, from the very start.