update docs to reflect addition of monoch, and four anom* sims update docs' images/maps to reflect move of self-dup clicker to abbrev. update docs to reflect colorpicker changing with colorblind settings Note that it doesn't follow monochrome/gamma settings, just vision update docs to removal of colorcomponents table, addition of named colors add href attributes all over to give larger clickable areas in swatches for those browsers which support hrefs on arbitrary elements a checkbox in colorsim UI to make colorpicker image stay in normal color add some way (in the colorpicker palette probably) to jump briefly into the documentation, and then to restore the swatchlist when done. So, maybe a '?' icon and a reload icon? put hex/dec links in header for selected swatch title gives info, click gives alert with tidy info put "pallete full" message in render area when full so folks know they will be loosing data when they add more swatches. more title attributes: title for true color: (as seen w/o any simulation applied) title for top code and abref should be full color title title for (non-self) fgnd checks AABBCC on Full Color Name background test more thouroughly in a more recent list of browser versions. replace the existing color component picker with a color-by-name picker add "really colorsafe palette" color select tools http://hotwired.lycos.com/webmonkey/00/37/stuff2a/complete_websafe_216/reallysafe_palette.html http://hotwired.lycos.com/webmonkey/00/37/index2a_page6.html?tw=design URLs above as of 20020205 FFFFFF FFFF66 FFFF33 FFFF00 CCFF66 66FFFF 66FF33 66FF00 33FFFF 33FFCC 33FF66 33FF33 00FFFF 00FFCC 00FF66 00FF00 FF00FF FF0033 FF0000 0000FF 000033 000000 twenty-two colors maybe in the colorpicker images? maybe in the colorselection panel? figure out how to deal with IE5 (and earlier)'s lack of support for the JavaScript keyword 'in'. The colorlab can use == null instead, but (at least right now) that causes oodles of extra warnings under JavaScript strict... which makes debugging more difficult. Hmmmm... I guess that I'll probably end up doing the compatible thing, and switching dev copies to use 'in' so that I can use Mozilla's nicer JavaScript error reporting (not to mention the spiffy debugger). continue using javascript strict warnings in mozilla to find and fix more potential problems in the javascript. I haven't yet tested all the functionality with srict warnings enabled. use developer gamma instead of assuming PC in colorsim code NOTE: when i tried this, mozilla 0.9.2 barfed with a spurious error message on the *second* load of the page (first was fine) but no problems in MSIE, NN, or iCab. Very odd. For now, we'll have to skip it until I can find a workaround. create a known bugs page document bugs applicable to the whole tool as well as browser specific bugs (brands/versions/platforms) link the page from TOC, ack, quickstart (any other place that mentioned bugs) switch to css instead of using font elements all over the place, consider use of labels in forms, review accesability guidelines grumble grumble... maybe I should put the todo and changes files in html instead of plain text. They'd look prettier that way, but on the other hand, I may be more likely to keep them as current as I do when I don't have to muck about with markup and can just type. consider re-working of colorpicker graphic to more clearly indicate its use as a color-picker in the absence of any documentation reading by the user (thx to James Kolozs) platform sniff to have dev gamma menu default to appropriate option or maybe not... I know I muck with user agent strings sometimes. maybe that's popular enough w/ web developers that it's better to not bother sniffing??? write a coordiated server-side utility to apply selected color scheme to their own content (via file upload or URL). Initially, don't bother translating images. Maybe later. Hmmm... http://64.81.70.149/cgi-bin/vischeckURL.pl Might be able to imageMagik something like that for images so that IMG tags could be translated to call the CGI to fetch the image and return it in perception-modified form. (frames.html can give a direct call in noscript for some folks) (index.html can give a direct call in noframes for some folks) ((I've got working code for gifs in pure perl... jpg/png todo) add support for age-related perception changes. See http://www.agelight.org/web%20docs/Usability/color.htm and http://www.agelight.org/web%20docs/Usability/physiological.htm Possible directions to take here include: a sclerosis (yellowing) factor, scalable by degrees (hopefully I could find a good resource w/ resaonbale values) a "contrast reduction" factor, also scaleable. This would shift colors toward their lightest version, with the shift being proportionate to the scaleing factor and to how light the color already was. I think this approach would give the right result of having light text on dark backgrounds be harder to read as the strength of the effect is increased. Another link: http://www.lighthouse.org/color_contrast.htm looks like color saturation is another scale to play with. Now I just need some good numbers for this stuff, otherwise I may just put in some sort of scale and hope that some values in there are reasonable. achromatic vision. Before, I'd done monochrome monitor simulation and thought it was the same. It isn't. I want to add rod-monochromat achromatopia. (I'll pass on the three flavors of single-cone achromatopia, I think.) If anyone has good numeric data on dark- adapted response to color, I'd love to see it. consider whether to supress duplicate info when there is more than one swatch, but all swatches are identical (also, should sequences in general be handled differently?) ... think about why I pull up duplicate swatches ... continue tweaking code and layout to suit personal preferences the original motivation for this copy is still a valid one improving documentation is always productive