Over the last few years, I’ve noticed an increasing trend for Linux icon themes to follow the lead set by the Tango and GNOME icon themes in using a naked internal hard drive with a downward-pointing green arrow to indicate “Save” rather than a diskette. The problem is that doing so does not provide any benefits and actually makes things worse.
Let’s start by exploring what criteria are actually used to evaluate the appropriateness of an icon. I’ve identified three:
- Visual Consistency (Does it fit in with the rest of the theme?)
- Learnability (How long does it take for the user to memorize the icon’s meaning?)
- Visual Distinctiveness/Acquisition (How long does it take an experienced user to pick the icon out from a field of other bits and bobs?)
Visual consistency within the theme isn’t relevant to this argument, since we can safely assume that any popular Linux icon theme will have it. However, the “arrow to a drive” icon loses to the diskette on both of the other points:
If you don’t give it much thought, it seems to make perfect sense that, now that we don’t use diskettes anymore, we shouldn’t use them in our iconography. However, over 95% of users have never seen a naked hard drive, so that component of the new look is, on the face of it, equally disadvantaged.
I’m assuming that GNOME is following Apple’s lead here, since MacOS X also uses naked hard drive iconography, but there’s a significant difference: On a Macintosh, users are trained by experience that their files live inside the naked hard drive icons on their desktop, whether or not they understand the nature of what they are looking at. Most Linux desktop environments don’t offer this convention for accessing partitions and, even on those which do, it’s an optional feature. As a result, a critical link in the learning process is absent.
Also, nobody learns in a vacuum. For decades, we’ve built up the diskette, not just as a storage medium, but as something that can be used as an abstract glyph for “Save” and, in older websites (where the two functions are often equivalent), for “Download”. (This is probably a large part of why the original concept () for the language icon failed. It looks like a pictographic representation of a diskette.)
Because of this effect, a generation has grown up recognizing diskettes as “Save”, regardless of whether they’re old enough to have used them. This effect is bolstered by the tendency of Windows and KDE icons to still use them as such.
Finally, while I wasn’t able to identify the exact page, I distinctly remember one of my old textbooks1 saying that, once a user has learned an icon, their performance is unaffected by the affordance of having the icon resemble something familiar.
Once you’ve grown used to an icon, the most relevant question is “How quickly can I find this when I want to click on it?” This is where GNOME’s choice fails multiple tests (some of which Apple’s implementation also falls short on).
First, it has poor visual contrast. Gray and green are very common colours to be used in popular icon themes, so it is difficult for the eye to quickly distinguish a save icon from other gray/green icons on a background that is often also gray. (Remember, even if light-on-dark is a common choice for GNOME-based desktops, these icon themes are also used in other desktops which have chosen to remain with the traditional dark-on-light for a default color scheme.)
By contrast, very few icons use the combination of red and blue traditionally used for diskette icons. This helps to compensate for how the ability to perceive variations in color and shape decreases as you move away from the center of our field of vision. (I have to stop and search for a drive icon if I haven’t become habituated to its position in the window. The diskette leaps out at me with no trouble whatsoever.)
Second, it is very common for green downward-pointing arrows to indicate “download” and “next page”. These two uses aren’t usually a problem, since these two uses rarely occur together in the same program and the meaning of “down as next” is disambiguated by the color of the nearby upward-pointing arrow.
However, having download and save in the same program doesn’t benefit from those same advantages. This forces the user to dedicate more of their attention to determining the meaning of the icon, slowing them down.
Finally, the icon is visually ambiguous in less-than-ideal circumstances. At small sizes such as 16×16 and 22×22, which are commonly used in toolbars, when the user is tired, has poor vision, or isn’t looking directly at the icon, it can be confused with either the Download icon or the Print icon (something I’ve encountered among less tech-savvy family members).
While I have said consistency within a theme is not relevant, consistency between themes is an issue since, even now in 2013, not all applications properly use the system icon theme.
Old applications, some 3rd-party applications, and KDE applications which need to provide icons outside the standard set still sometimes produce diskette-based icons which are not (or, in some cases, cannot be) replaced by the user’s chosen icon theme.
I am honestly curious what motivated the GNOME and Tango developers to choose drive-based iconography, given that the only advantage it seems to grant is consistency with Apple’s proprietary operating system and the single-platform applications within.
Not only does it highlight theming inconsistencies to users who might otherwise not have noticed, it throws out years of real-world experience in developing related metaphors.
For example, one derived icon which is often necessary is “Save All” or “Save Project”. With a diskette-based icon theme, this can be represented intuitively and at very small sizes as a cascade of diskettes. I have yet to see a viable metaphor for this operation when using disk-based icons. Most icon themes I’ve examined don’t even include such an icon.
As a result, this often results in toolbars for IDEs and other such programs presenting a cascade of diskettes to the right of the “hard drive with an arrow” save icon, harming the user’s ability to identify consistent metaphors.
In summary, I get the impression that the individuals involved in designing this iconography have little professional training in user interaction design and simply copied certain surface elements of MacOS X in hopes that some of Apple’s good juju would rub off on them.
1. Human-Computer Interaction, Third Edition by Alan Dix, Janet Finlay, Gregory D. Abowd, and Russell Beale