ing soccer results and NASA Jet Propulsion Laboratory’s use of the RCP for its Mars missions. Currently, there is no easy way to visually skin an Eclipse-based application. The effect is that most Eclipse-based apps end up inheriting the look and feel that comes “out of the box.” This is handy if you want or need to adapt to the look and feel of the native operation system, but there is no distinction for your application from any other built with Eclipse. This could be seen as a purely aesthetic drag or a significant business problem. One might need to customize an application to align its look with brand guidelines or existing products, to distinguish it from a competing product that is also built using Eclipse, or to better suit a nontechnical audience. To a degree, customization is possible, yet it requires additional effort in design and code.

Another popular open source toolkit is the Web-based Dojo and its widget library “dijit.” These are highly customizable, yet often we see the default dijit theme “Tundra” used, as is. Why? People use the default because it looks acceptable and because the cost of change is prohibitive—it requires less effort and less cost to simply accept the standard look and feel.

Toolkits come with a great deal of useful functionality that can serve to propagate patterns, fostering not only good practice through use but also consistent presentation and interaction across suites of tools and products—something that is particularly important if there are multiple and distributed teams working on different parts of

the software. But except for the accompaniment of interface guidelines, if present, the use of toolkits does not necessarily make for the most appropriate or desirable UI presentation, much less one that is tailored to brand or audience.

Even if the toolkit provides widgets and styles to manipulate, the decisions and details around style, organization and flow of the information, composition and alignment, or appropriateness of color and other cues are typically not part of the package.

Value in Practice

Whether or not toolkits are used, these details and design outcomes are the result of certain activities and modes of thinking that visual designers contribute, in some ways uniquely, to software development projects.

A product’s brand, visual style, and the collective treatment and interplay between elements that lend to its character are a few of the obvious ways in which visual design contributes to the software user experience. More interesting are the nonobvious ways in which these things come about, where perhaps their greater value lies. It is through things like abductive reasoning, making the abstract concrete, and working with constraints that visual designers and their craft can add significant value.

Abductive reasoning is something Roger L. Martin, dean of Rotman School of Management, describes as embracing the logic of what might be rather than what is (inductive) or must be (deductive) [ 3].

• Some examples, from the Eclipse Plug-in Development form editor, of how the color adapts to native system themes.