Next: Future directions for Art
Up: Art and the User
Previous: The Artist-Programmer Dichotomy
Contents
Contemporary Icons?
To get an idea of what aesthetic considerations go into the designing
of a present-day icon, I consulted the Software Development Kit (SDK)
documentation for a number of operating environments. Surprisingly,
two of the newest SDK's offered little or no advice for creating
icons. These were the Microsoft Win32 Software Development Kit
Final Release, Version 3.1, and the IBM OS/2 2.1 Professional
Developer's Kit from March, 1993. The two kits, for writing Windows
NT and IBM OS/2 programs, offered technical chapters on coding icons,
but no discussion of how or why they should be used. The style Guide
for the Open Look GUI environment for UNIX advises that final
versions of all icons should be drawn by a professional artist. The
Open Look Style Guidelines ask developers to perform a sort of
`ico-analysis.' When the icons created for an application in the Open
Look GUI meet (or don't meet) certain criteria, the developer should
consider options such as combining or separating programs, designing
an entire `family' of visually related icons, or incorporating
animation into their icon design.[15] In their own version of
a SDK for Microsoft Windows, Borland has the good sense to devote
about one-half of a page to icon design issues. They ask the software
designer/programmer to answer three questions before designing an icon
for any Microsoft Windows application:
- What should the icon represent to the user?
- Is your design simple enough to fit into a 32x32 or 32x16 pixel
area?
- Will the icon look good no matter what background the user
chooses to display it on?[6]
From the SDK documentation that I could get a hold of for this
paper,
very little guidance for aesthetic design was
offered. Borland devoted a half-page to the aesthetic considerations
of icon creation. The printed documentation for the Borland SDK weighs
about fifteen pounds! ``Icons in Everyday Life,'' a paper by William
and Susan Wood, notes that even when specific graphic role-models are
provided, today's developers disregard the carefully considered
guidelines in favor of their own. The Macintosh interface guidelines
offer artists some simple `meta-icons,' on which to base their own
designs. Although some designers have adhered to the framework, many
more have strayed. Here is the table presented by the
Woods:[20]
Figure 3:
Macintosh Icon Style Guide
|
Other aesthetic considerations for each operating environment were
also omitted from their respective documentation--and this made
something clear. When designing the visual interface for a software
application in an operating system or environment, the designer is
restricted by the standard graphic elements of that system.
While custom code could probably be written to support almost any
visual feature, it is much quicker to simply `settle for' the graphic
elements or `widgets' already provided by the SDK author.
The lack of aesthetic guidance for software development was evident
during a fun exercise in which our HCI class visited a Macintosh
computer lab and played with shareware software. In the course of an
hour, we sampled dozens of home made and semi-professional software
creations. While those `constant' graphical elements of the operating
system were usually visible in each design--scroll bars, menu bars,
title bars, etc.; other interface elements were all over the map. Some
icons were way out of proportion with the others--as though they had
been stolen from their X-Windows siblings. Other applications had
elements on the screen that were drawn in shaded 3-D perspective with
the imagined light source coming from the upper left, while others put
the imagined light source elsewhere (like from the bottom right!). To
really see things pop on your eyes, try running two applications like
that side by side and staring at them for a few minutes. Other amusing
aesthetic designs included self-defeating foreground text-background
color combinations that were unreadable, and `illustrated' adventure
games with animated illustrations that ranged from `interesting' to
downright ugly. Visual artists everywhere should perform some
community service by hooking up with a local shareware author and
helping them rethink their GUI's.
Next: Future directions for Art
Up: Art and the User
Previous: The Artist-Programmer Dichotomy
Contents
sean dreilinger