A Magnification-friendly Skin for Winamp
By Veli-Pekka Tätilä
Alasdair - broken links and unavailable files have been removed from this page and are lost forever.
Despite my sight-impairment, I recently took a uni course on image processing. As an exercise I ended up producing a magnification-friendly Winamp 2.x compatible skin for the main window, which should help low-vision users with the program. This page outlines the general accessibility principles based on my own experiences and some Web pages and has the skin for download. By the way, I only did the main window as it was very slow for me to work with Paint Shop Pro and the main window is the one I'm using most often. If you find the skin useful, it would be great if somebody could complete the rest of the skin using the basic principles outlined here. I can then put the final version online and credit you appropriately. Oh yes and I'd also be interested in designing and testing other accessible skins such as a high-contrast theme taking advantage of the XP look.
The rest of this page is the design rationale for the skin so
ordinary skin users might want to skip it. The important thing, the
20 K skin download, is right here. IF you've already got Winamp
installed the default action is to preview the skin. use the right
click menu or some equivalent to save as, rather than download and
To install the skin, simply copy it to your Winamp skins folder and change the skin in the preferences or in the context menu. If you'd like to take a look at the individual bitmaps I've changed, you can rename the skin file to zip and extract it.
Visually the skin looks like this:
And here's the standard version from Winamp:
This section is based on my own experiences and some Web articles. I've tried avoiding the pitfall for optimizing for my unique sight alone, so that the skin would be applicable to a wide variety of sight-impaired people. You might also want to check out my sight page for a more personal touch.
1. Light on Dark Color Scheme
Most of the sight-impaired people I know prefer light on dark and in my view it makes differences in color (e.g. syntax highlighting) as well as small details a lot easier to spot than dark on light. ON the other hand, using light on dark exclusively may be straining in the long run. The standard skin already adheres to this look so that made the choice more natural to me as well.
2. Avoid Extreme Contrast
Though it would initially seem that white and black would provide the best reading or watching experience, things might not be this simple. Some sight impaired people find pure white dazzling in the long run and so might prefer yellow or green for light colors, or blue for dark colors, for instance. The background color hex FFFFCC has been recommended to me as a good, accessible page background. Exception: small areas whose contrast is equivalent to black on white might not be that bothersome particularly if you don't have to check out that particular area very often. It is a compromise in the end, as I find white easier to see than green, too, but also use dark blue rather than black in the text editor. The baseline should be avoiding extreme contrast, as stated by this rule.
3. Avoid Using Red and Green
If color is the only means of conveying info, which should not be the case, red and green should not be used to distinguish items. This naturally follows from color blindness in which, as far as I've understood it, the two colors are indistinguishable from each other, that is they look the same.
4. Contrast does matter
I've found that at least in my case the contrast between colors tends to play a larger role than their hue or saturation value. The vision scientist Aries Arditi says on his Web page that one should exaggerate lightness differences between the foreground and the background, and avoid using colors of similar lightness adjacent to one another, even if they differ in saturation or hue. Arditi's color page can be visited here .
5. Clear Shapes Rather than Fancy Thingies
The Gnome accessibility guide advices using two colors and clear, minimalist shapes when drawing symbols that is icons. On the accessible icons page they broadly compare visual impairements to blurring, in which small details in images are easily lost.
6. Horizontal, Clear and Thick Text
Many sight-impaired people, again in my experience, find bold fonts or all caps text easier to read, especially if it is only a small bit of text. Theoretically I think the contrast is greater because there are more white pixels on screen as the font is bolder. Another essential factor in typography is clearness, distinguishing letters from each other, as well as horizontal layout. Vertical text is extremely difficult to read magnified one character at a time, as far as I can tell.
Design in Detail
This section outlines the design decisions I made, that is, how the above rules were applied to the Winamp skin and what each of the skin bitmaps does. I won't be going into the implementation, how I achieved things graphically, but if you are interested I can tell more about it via e-mail. If on the other hand, you'd like to know more about the skinning process, which is basically repainting bitmaps and zipping them, you should read Nullsoft's classic skinning tutorial .
Playback Controls (Cbuttons.bmp)
This image contains buttons for playing, pausing, stopping, switching tracks and opening files. Many of the buttons have standard, graphical symbols associated with them which are used almost universally in media players. There's also a second set of buttons for their pressed state. Though the contrast in Winamp is good I lightened the light colors some more to make it even better. However the button background color is still not pure white according to rule 2 but rather something akin to the MacOs 8 gray. Further more, I decided I should redraw all of the buttons to make them clear, two-color, slightly larger, and high contrast to comply with rules 4 and 5. I considered color coding but dropped it for achieving higher contrast.
Whenever I look at an image there are two levels to it. the unmagnified view gives the big picture and symbols should be as different from each other as possible, to be able to clearly tell apart elements in this overall view. The details are highly blurred in my case. In the magnified closeup, on the other hand, it is important that the function of each and every shape is clearly distinguishable and smaller details play a role, too. I've tried to balance these two interests but as I'm legally blind myself have prioritized the big picture over details for the most part.
As for the buttons the stop symbol is very large but I still find it the clearest of the bunch from a distance. I've also modded the next and prev buttons to plain large arrows, though this is not inline with the universal next and prev symbols originally used in Winamp. I reckoned their meaning would be clear enough still, particularly as they have tooltips.
Another thing I decided to patch right away both here and in many other contexts was the animation of pressing buttons. After some experimentation I concluded that though crude-looking, simply inverting the colors and slightly offsetting the bitmapp was very effective for the buttons' pressed state. This can be concluded from rules 4 and 5 by extension namely that large changes in color or shape are the easiest to see.
Views, Loops and Shuffle (shuffrep.bmp)
The controls in this image are used to toggle the EQ and playlist views as well as the repeat and shuffle functionality. The on/off states of all these buttons are shown by a status light in the image, which lights up when you turn on the functions. To be consistant with the rest of the look, I applied the same brightness boost and inverse color effects as in the previous image.
The 7-segment display like font used for the EQ Shuffle and other text seems to be highly legible so it didn't need rewriting. I did patch the fonts manually to be readable on a per pixel basis and this is also one of those activities I've done in various images as I see fit. The colored lights are a nice concept but they are all too small by default, so I revamped them, this time much larger according to rule 5. However, the light is not inverted when the button is in the pressed state. Lastly the repeat symbol has never been clear to me and it is kind of small, so I changed it to a capital letter R.
Channel Indicator (monoster.bmp)
This image indicates to the user whether the file being played back is mono or stereo. This time I've re-renddered the text in Ms Sans Serif and finetuned it by hand, though I'm no typography buff, in fact far ffrom one. TO clearly indicate the selection I added some contrast between the active and inactive text namely the colors Windows 192 RGB and pure white. The bottomline is simple, the gray should be light enough to stand against the background and the white should be distinguishable from the gray. To further enhance the selection status I've added a white frame around it. The use of white here might be a bit controversial but I reckoned it would not hurt too much in smaller quantities. the channel count is something you check only occasionally so clarity in the big picture is of utmost importance.
The Title Bar (titlebar.bmp)
This skin component has a large amount of elements in it. It contains the active and inactive titel bar text abd background, all of the caption buttons at the right end of the bar, some weird status indicator letters, the mini player buttons and finally easter egg versions of the title bar. In my modifications I've left the eastereggs currently alone and the miniplayer is also untouched because of the large amount of work it would require. It should be edited mostly along the lines of cbuttons.bmp.
The title bar is a tricky component. Ideally as it is one of the few Windows standard controls in Winamp, it should conform to the color scheme the user has chosen and use the element styles that WINdows employs. The regular Winamp title bar is far from that ideal. The problem is that the color and element information is hard coded to the title bar so conformance to user preferences is difficult unless one would like to resort to elaborate hacks, such as re-rendering the skin on the fly at Winamp startup to make it conformant.
As this hack approach is not really feasible, cool as it might be, I decided to choose likely conformance over total accessibility. Many VI people still use the plain Windows classic look so that's the basis for the look for the caption buttons and the coloring in general. There are some exceptions as well, though. THe inactive text color is white rather than 192 gray to maintain the readability of the text. Rather than being animated as in Windows, the caption buttons are inverted just like the rest of this Winamp skin in the pressed state. Lastly the font is hand-drawn because a bitmapped Ms Sans Serif pixelates easily and doesn't optimally use the space in the title bar. I'm mostly happy with my font apart from the letter M, which could be clearer. Finally, I've changed the window shade, that is title bar rolllup, buttons to up and down pointing arrows with a dash which should make them more descriptive, I hope. The symbols are from Marlett.ttf.
Regarding the od status letters, I've increase the contrast between the inactive and active colors. This time they are 170 Amiga 2.x gray for the inactive and hex FFFFCC for the active. Again the rule of the thumb is the same as in the monoster bitmaps.
Winamp Window Background (main.bmp)
This image has the bulk of the player and is one of the most easily visible components in any skin. it is the background over which the most of the rest of the bitmaps are composited. I wanted to go with the default dark look so that the buttons would stand out well. So the only thing I ended changing were the gradients. I eliminated them and repainted the skin with the brightest available Winamp background color.
Sliders (volume,bmp and balance.bmp)
These images have the slider caps as well as their background. Winamp has a fancy feature were the slider background changes as the function of the slider cap position which enables one to quickly get the slider value based on the color. I decided to keep the effect despite possible contrast problems, as I figured out this indication might be very useful to many visually impaired users. However, the colors which used red among others were less than optimal. I opted for a gray scale gradient expanding up to pure white. This does break the 2nd rule but again the white area is rarely used and is only a small portion of the whole Winamp skin. Though it might look a bit odd in places, and you may not be able to tell the center position as easily, I've used the same gradient for both the volume and balance (pan position) bitmaps. Fortunately, you can also tell the center position manually as the sliders have a rather large dead zone in which the color or the actual value of the slider doesn't change at all near the center.