IBM | kpeter@ca.ibm.com
value they can bring, or lack of funding to expand the team to include them.
Given the taste we have developed for more thoughtfully and elegantly designed user interfaces in both consumer and business segments, is it a good idea for software companies to exclude visual design from their project teams?
[ 1] Baecker, R.
“Themes in the Early
History of HCI -
Some Unanswered
Questions.” interactions
15, no. 2 (2007): 22-25.
January + February 2009
[ 2] Monson, P., C. Pampino, M. Gothe, N. Yuce, K. Nizami, K. Patel, and B. M. Smith. “Collaborative Application Lifecycle Management with Rational Products,” IBM Redbooks® (draft), June 2008.
The question of whether or not visual design has value in software might seem moot. For decades now, graphical user interfaces have been the dominant paradigm [ 1]. We revere the visual fruits of Apple; we delight in the graphical levity of the pervasive Web 2.0 look; and we get a visceral tickle out of the many visual and interactive effects of the Microsoft Vista, Linux Ubuntu, and Mac OS X operating systems. We like to be delighted and engaged visually. And why not? Whether our use of computer software is business or personal, we spend a lot of time with machines and the soft stuff that helps us get things done. The time spent might as well be pleasant.
This sentiment is appreciated in mainstream software, yet things have been a little different in the world of software development for programming and business tools, where user delight and the virtues of visual elegance have not been so widely or confidently embraced. Things appear to be changing, and exposure to design is a significant part of this change.
Dearth of Designers /
Dearth of Design
Each day I work with people
whom I consider sophisti-
cated users. These are the
ones who make software for
software developers and the related technical and nontechnical disciplines that use Collaborative Application Lifecycle Management tools
[ 2]. As a team we create both desktop and Web-based applications. Increasingly, we use the tools we build. We are also collectively exposed to a great deal of software, both mainstream products and the tools we use to do our work. This exposure helps to inform our expectations of our own products, as we increasingly expect them to do more and look great. As we have sophisticated and diversified audiences, we want the tools we build to offer more than the same old integrated development environment (IDE) interfaces of years running. We also need to be competitive. To do that, attention to product interface design and its level of quality are essential.
Transformation is wanted, expected, and happening. It’s a good time to be a visual designer.
Still, I do hear of designers struggling in their organizations to make a difference, to exercise their capabilities beyond the usual graphical requirements.
Additionally, there are software projects in which no visual designers are involved at all. Part of this may be lack of awareness or recognition of the
I observe in my daily work that the availability of toolkits can have an influence on whether or not a visual designer is involved in a project, or to what degree. Toolkits provide varying degrees of ready-to-use function often replete with the code that renders the UI, what I will call prêt-à-porter, or ready to wear. This is beneficial if you are a developer because coding from scratch can be much harder; it takes more time, and it can be highly experimental until a suitable and desirable solution is determined.
But do we want our software to look the same as numerous others using these prêt-à-porter toolkits, particularly those of other companies?
Consider Eclipse, an open source IDE and framework that provides the tools to create Rich Client Platform (RCP) applications as wide-ranging in purpose as Soccermaster RCP for track-
References:
Archives