next up previous contents
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: 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 up previous contents
Next: Future directions for Art Up: Art and the User Previous: The Artist-Programmer Dichotomy   Contents

sean dreilinger

copyright  ©  July 14 2020 sean dreilinger url: https://durak.org/sean/pubs/art-and-ui/node8.php