In instructional design choosing colors which are safe for both the web, the printer, and software design is a constant juggling act. My favorite part in the creation that goes into instructional design is choosing the color. Many times out of a love for -- light coral -- I stick to STRATEGY 2 , in "Coping in an Unwebsafe World". Yet, it is important to remember that even though we have an agenda to complete the most important part is reaching everyone of our target audience, the students.
| |||||||||||||||
What are some of your favorite color palettes you like to use in your designs?
Webmonkey: design: Death of the Websafe Color Palette?:
My Favorite Part of the article:
Coping in an Unwebsafe World
The first thing you need to do when choosing colors is, with as much precision as possible, the distribution of technologies of your audience. The most recent numbers we've seen from StatMarket put True Color (24- and 32-bit) at about 38 percent of users; High Color (16-bit) at about 56 percent; and 256-color users are at about 6 percent. You might feel relieved by these numbers, since so few are at 256 color depth, but don't be: Unless you work entirely in black and white, approximately half your general audience won't properly see the colors you select for your site.Once you've got the distribution of your audience identified, you have a basis to choose a strategy. Here's a handful of suggestions to get you started:
STRATEGY 1 -- Use the really safe palette.
We know it's not pretty, we know it's only 22 colors, but it does give you reliable control over the colors your users see.
STRATEGY 2 -- Don't sweat it.
You're always free to run roughshod over your audience as you indulge your hearty designer appetite. But we find this a slightly unsatisfying, not to mention unprofessional, approach.
STRATEGY 3 -- Ignore 16-bit users.
If you do this, you'll regain the use of most of the old websafe palette (minus the four colors that we discovered don't work in Internet Explorer on Windows). It's a solution you can live with, except that it favors the lowest-tech 6 percent slice over the higher-tech 56 percent slice. We don't usually agree with such an approach, but in this case you could argue that the colors an 8-bit user sees when fed an unsupported color (a hideous dither) is much worse than what a 16-bit user sees (a slight shift in the color).
STRATEGY 4 -- Ignore 8-bit users.
This approach favors the group that most likely constitutes the majority of your users, but it can give the 8-bit users a rough ride. You will get the same kinds of problems you got when looking at the old 216 websafe palette on a 16-bit system: GIFs and code-generated color will shift all too regularly to inconsistent values. So when you design a site, your chosen palette will have to be tested on a whole bunch of browsers and operating system environments (congratulations, you're now in the same boat as the developers who have to test their dHTML across myriad environments, only you can't even write an API).
The only consolation we can offer you here is this tool, which will at least make it a little easier to set up your color tests. Great! I'll take it.We should warn you, though, that you're unlikely to find a set of colors that works correctly across all the environments you're targeting. We tried a few dozen colors and weren't very successful at finding palettes that worked properly. You'll probably find that once you've chosen your palette and tested it in the relevant environments, you have to go through several ever-so-slight tweaks of a color before you get it to be consistent across the relevant environments. You might try to change the value of one root color by just 1 increment (e.g., change AC to AD, or 09 to 08). Unfortunately, some colors will never be satisfactory, so you'll either have to ax them altogether or opt to let the colors shift as they may for the users of the offending environments.
STRATEGY 5 -- Keep the GIFs and code-generated color separated.
Since the shifts in color performed by the browser on 16-bit systems are usually very subtle, they won't cause a drastic imbalance in your chosen palette for the most part. But if you place a GIF and code-generated color right next to each other, the browser's bad habit of shifting the two to different values gets highlighted, and the discontinuity suddenly gets thrown into relief. If you keep the two apart, however, users will be less likely to notice the problem. (Although you should still test your colors; some differences are too distinct to ignore, no matter how far apart they are).
STRATEGY 6 -- Use transparent backgrounds.
If you do have to have a GIF and code-generated color next to each other, try this: When you export your GIF, select the color that's going to be in the code next to it and make that transparent. Then set the BGCOLOR of both the cell in which you've placed the GIF and the adjacent cell to the same value. That color will now bleed through the GIF, and regardless of which color the browser shifts it to, it will be the same for both the GIF and the code-generated color, since really it's not in the GIF at all. good to know! I will have to try this. How about you??There is, however, at least one big limitation with this approach: You can only choose one color to be transparent in the GIF, which is a problem if the GIF has to be continuous with more than one color. To be sure, you can make more than one color in a GIF be transparent, but the color that will bleed through will have to be the BGCOLOR of an HTML container (such as a DIV, SPAN, or TD), and an image can't span these containers. Therefore, no matter how many colors you make transparent in your GIF, only one color can show through.
STRATEGY 7 -- Use Flash.
Flash's colors get drawn by its proprietary plug-in, not by the browser, so there's no "GIF versus code-generated color" issue here. The colors you select will still shift when viewed in a High Color system, but the discontinuity between the way GIFs and code-generated color shift will be eliminated. Of course, Flash has myriad problems of its own, which we'll leave to you to assess. no kidding! right?!
STRATEGY 8 -- Help us!
We certainly don't know all there is to know about hardware or software. We haven't managed to test all colors on all browsers and all platforms, so our results aren't exhaustive and complete. Most importantly, we don't have the power to make the browser flaws go away. You can help us with all these shortcomings. First, you can validate our results. Second, you can try to help us piece together a palette of colors that is stable (no discontinuous shifting) on High Color systems across all common browser and operating system environments. And third, if you work at Netscape, you might look into fixing this problem for the next and all subsequent releases of your browsers. We found Microsoft to be very responsive to our inquiries, and fixes for these bugs are forthcoming. Sadly (and not to slam anyone), we weren't as successful with Netscape. If you can offer us insight into current versions of Netscape to create a temporary fix, that's great. And if you can ensure that future releases of it avoid these problems altogether, that's even better. In any case, let us know what you discover.
STRATEGY 9 -- Go back to print design.
No comments:
Post a Comment