| | |
| | |
| The Evolution Of The Icon |
|---|
| Eric Sauvageau | merlin@thule.no |
|---|
[Eric Sauvageau is the current author and maintainer of NewIcons, which recently released Version 4. As someone who is deeply involved with the look and feel of Amiga desktops, he can be considered an expert. He is, of course, somewhat biased by his experience, but his insight is worth reading. -Jason]
Workbench85
One of the things in which Commodore never did much work was probably the icon part of Workbench. Be it the icon engine itself, or the look of the system icons, Commodore seemed to have always worried about the ridiculously-low-end part of things by keeping their icons 4 colors--with a no-frill engine to handle them. Fast but boring. Basically, icon imagery is nothing but actual bitplane data stored in an image structure, with no color information. All that is stored is information that some pixels will use whatever color is first in the screen's color map (Color0), other pixels will use the next color, and so on. This means the icon will use whatever colors the system palette is set to, preventing the use of any color scheme in icons for easy recognition. Thus, an icon which is supposed to show the Canadian flag (red and white) might very well come up as gray and green.
Workbench 2.04 - Things are getting better... Are they?
With Release 2 of the OS, Commodore did a complete overhaul of the GUI. A new 3D look was defined for windows and gadgets. This was also applied to icons--they were turned into large buttons that would recess as you clicked on them. While this provided a very useful visual feedback, this kinda hindered artistic efforts - you had to do something that would look nice while surrounded with a gray box. You couldn't get rid of it. As for the icon look itself, not much was done to improve the look. It was mostly left to flat black & white pictograms.
A little Magic on your Workbench
The first real effort toward improving things came probably through MagicWB. It defined an 8-color standard palette (quite an improvement over the CBM 4-color scheme), as well as more a intricate icon design. It quickly became popular, and soon hundreds of icons using the MagicWB style started to appear. However, the palette engine used by Workbench and icon.library was still a problem. A small patch was written to ensure that the 8 standard colors would be locked, preventing applications from changing them. So, you were sure your MagicWB icons would always use the same colors on any system running that pen locker. For quite a few years, people were content with it.
Newer and better
The second attempt at improving things came out as NewIcons, from Nicola Salmoria. NewIcons's revolution was that it wasn't just an attempt at changing the look - it was also an attempt at improving the actual icon engine, by allowing a palette (up to 256 colors) to be embedded within each icon, which would be dynamically remapped as it was displayed. The drastic improvement over the original palette-less icon scheme was to allow more colorful icons to be used, without having the user worrying about what color to lock in his or her Workbench palette.
The new engine (supplied as a library and a system patch) was shipped with a 16-color isometric iconset, bringing a whole new look to the Workbench. However, the silly gray boxes were still there. There was also a price to pay--more colorful icons meant higher memory requirements, and the actual remapping process slowed down icon display quite a bit as well. Today, we might find this irrelevant as we're flying with 24-bits cards and 68060, but back to these days (around 1993), the average user was still using ECS or AGA, on a 68020 or 68030.
The new Ring Bearer
Just after the release of NewIconsV2, Nicola decided to pass the torch to new developers as he migrated to another computer platform. Eric Sauvageau and Philip Vedovatti decided to take over, respectively as programmer and icon artist (former icon art was being done by Roger McVey). Work began on a major update that would push it even further. V3 finaly came out, with a welcomed surprise: gone were the gray boxes surrounding icons! Also, as people started to get faster CPUs and better graphic cards, they started to want something more colorful for their Workbench, NewIcons grew in popularity. V3 also allowed graphics card owners to have icons loaded into FastRAM instead of the slower (and limited to 2 MB max) ChipRAM.
Better, Stronger, Faster
About one year later, another incarnation of NewIcons appeared, as Version 4 was released. As 68060 and graphics cards had become popular, the included iconset got redesigned in 32 color. Also, gray boxes were totally eliminated, as icon dragging is now also box-free. It also allowed the user to select between normal, outlined or shadowed rendering for the icon's text, allowing even more freedom in Workbench look customization. And finally, it was also faster than V3.
icon.library - The Next Generation
There is no doubt that something must be done about the icon scheme in a future update to AmigaOS. The first thing that needs to be addressed is the need for screen palette independant icons - having each icons decide which colors it requires, just like NewIcons does. However, NewIcons itself isn't a long-term solution. NewIcons was designed as a patch over the old icon scheme, compromising in various areas to allow full backward compatibility, like having its new image data stored in the tooltypes. And with modern graphics cards, 256 colors for icons is no longer enough. The icon palette would need to be extended to at least 16 bits, with true transparency support.
Other features missing from the actual icon scheme is support for alternate imageries. How about less colorful images for systems with less color? Or with the advent of more powerful processors, dynamic rescaling so icons would adapt to the aspect ratio of the actual display could even become a realistic feature. Another feature popular on other platforms is the presence of an alternate, smaller image that can be used as a pictogram either in an application launcher or in some text display of a directory, like a file requester.
Finally, some form of filetype recognition needs to be integrated to the Workbench. This could be implemented as a "filetype" field stored into the icon, which would take further the idea of a "default tool", where a user could change the default tool for a given file type through some global preference editor, rather than having to individually change every icon for a given filetype. This would eliminate the chaos of every programmer finding another new esoteric text viewer to set as the default tool for their documentation icon, ruining the idea of saving the actual user the work of having to decide what to use as he double-clicks on its icon.
Who shall lead the herd to greener pasture?
Third party developers pushed farther the unfinished task Commodore had started in 1985 by bringing to the user a graphical user interface that was meant to be both easy in use and attractive. They took care of the aesthetic side of things that Commodore had somewhat failed to assert. Now, it's time to give back the torch to whomever at Amiga, Inc. will be working on the next version of AmigaOS, so they can take things one major step further ahead, farther than third parties could by just patching over an OS and an icon system that's starting to show its age.