Bugzilla – Full Text Bug Listing
| Summary: | [rulers] Color blindness issue with red and gray Xs for markers in vertical ruler | ||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | [Eclipse Project] JDT | Reporter: | Wayne Beaton <wayne.beaton> | ||||||||||||||||||
| Component: | Text | Assignee: | Raksha Vasisht <raksha.vasisht> | ||||||||||||||||||
| Status: | VERIFIED FIXED | QA Contact: | |||||||||||||||||||
| Severity: | normal | ||||||||||||||||||||
| Priority: | P3 | CC: | christian.campo, daniel_megert, davymeers, deepakazad, markus.kell.r, milesparker, remy.suen | ||||||||||||||||||
| Version: | 3.5 | Keywords: | accessibility | ||||||||||||||||||
| Target Milestone: | 3.8 M3 | ||||||||||||||||||||
| Hardware: | All | ||||||||||||||||||||
| OS: | All | ||||||||||||||||||||
| Whiteboard: | |||||||||||||||||||||
| Attachments: |
|
||||||||||||||||||||
|
Description
Wayne Beaton
good point. how about removing the x-icon altogether if there is no error….. (In reply to comment #1) > how about removing the x-icon altogether if there is no error….. I would agree to this. I am not color blind, but even I sometimes wonder for a split second why the icon is still there even when though error is fixed. (In reply to comment #2) > (In reply to comment #1) > > how about removing the x-icon altogether if there is no error….. > I would agree to this. I am not color blind, but even I sometimes wonder for a > split second why the icon is still there even when though error is fixed. Hmm the icon appears after you make changes that fix the error but not yet saved. We could also make the icon green ( to easily differentiate from red) or replace it with a tick mark icon to notify that the error is fixed until the changes are saved. (In reply to comment #3) > (In reply to comment #2) > > (In reply to comment #1) > > > how about removing the x-icon altogether if there is no error….. > > I would agree to this. I am not color blind, but even I sometimes wonder for a > > split second why the icon is still there even when though error is fixed. > > Hmm the icon appears after you make changes that fix the error but not yet > saved. We could also make the icon green ( to easily differentiate from red) or > replace it with a tick mark icon to notify that the error is fixed until the > changes are saved. what is the value or the information that a gray or green icon gives you when the error is fixed ? I think that green is not better since some people have a red/green blindness. A different icon like a check mark is certainly better. But again (maybe revolutionary :-) ) the thought remains why not remove the icon if the error is fixed (even though it is not saved….) Green is not good as it will attract the eye focus more than the gray icon. We investigate how it looks if we make the gray brighter. Raksha, can you try this out? Removing has the disadvantage that you can no longer see what error (message) was there and it can also be confusing when navigating into the unsaved editor via Problems view. We could add a preference to hide the gray icon for those that get confused by it, but I'd like to avoid this if possible i.e. if we should try to find a better icon. http://en.wikipedia.org/wiki/Color_blindness - Green is obviously a bad choice, as Red-Green is one the most common forms of color blindness :) It might be useful to try a color blindness simulator, e.g. http://www.colblindor.com/coblis-color-blindness-simulator/ https://addons.mozilla.org/en-US/firefox/addon/colorblind-simulator/ +1 for making the gray error icon so bright that it really looks like "disabled", not like "gray". In the end we will request the new icon from the designers, but it helps a lot if we can show them what result we imagine. (In reply to comment #7) > +1 for making the gray error icon so bright that it really looks like > "disabled", not like "gray". +1. I've done that, see commit 8a98dd1ef1bed6e32f6423260d4cc31d8ee9a196. Available in builds >= N20110928-2000. Please have a look in one of the upcoming bugs and reopen this bug if you are color-blind and can't see the difference of the two icons. (In reply to comment #8) > (In reply to comment #7) > > +1 for making the gray error icon so bright that it really looks like > > "disabled", not like "gray". > +1. I've done that, see commit 8a98dd1ef1bed6e32f6423260d4cc31d8ee9a196. > > Available in builds >= N20110928-2000. Please have a look in one of the > upcoming bugs and reopen this bug if you are color-blind and can't see the > difference of the two icons. Can you post a screen shot? I haven't used it, but you might try something like: http://michelf.com/projects/sim-daltonism/ I think it's a very good point, and something that we often overlook when designing UI. Here's a good page: http://www.stcsig.org/usability/topics/colorblind.html. Apple also has a lot about HIG on color-blindness. Perhaps it would be helpful to update the Eclipse wiki page with information about this: http://wiki.eclipse.org/User_Interface_Guidelines. (In reply to comment #3) > Hmm the icon appears after you make changes that fix the error but not yet > saved. We could also make the icon green ( to easily differentiate from red) or For me this is valid reason to still have a marker. > replace it with a tick mark icon to notify that the error is fixed until the > changes are saved. +1 for the tick mark. I think contrasting in shape solves the issue for any type of color blindness. To make sure it is not too obtrusive the tick mark can still be gray. Also,IMHO a tick mark makes it very clear that there was an issue which is now fixed. > Can you post a screen shot?
Sure, but I would assume that color-blind people also adjust other colors and hence it's really important to get feedback from a color-blind person. Does this apply to someone on the cc-list?
(In reply to comment #12) > > Can you post a screen shot? > Sure, but I would assume that color-blind people also adjust other colors and > hence it's really important to get feedback from a color-blind person. Does > this apply to someone on the cc-list? wouldnt that be Wayne who initiated this. ? (In reply to comment #13) > (In reply to comment #12) > > > Can you post a screen shot? > > Sure, but I would assume that color-blind people also adjust other colors and > > hence it's really important to get feedback from a color-blind person. Does > > this apply to someone on the cc-list? > > wouldnt that be Wayne who initiated this. ? From comment 0: "Received via e-mail to the emo mailbox." Created attachment 204260 [details]
Screenshot
The comparison on http://www.colblindor.com/coblis-color-blindness-simulator/ doesn't show a big improvement (small in most cases but even worse in some others). I don't like the solution with the check mark. Raksha, please try to use light gray (similar to disabled) but invert the image i.e. gray cross on white background. (In reply to comment #16) > > I don't like the solution with the check mark. > Can you explain why? IMO having a contrast in color and shape (as opposed to only contrast in color) would result in a better design. For example if you use the light gray but replace the white cross with a white tick mark you have the following advantages: - the two markers (with a cross and with a tick mark) have enough in common to make it clear they belong to the same family - the tick mark clearly signals that the error that was present is solved - the slightly different shape solves the problem for any form of color-blindness (Note: changing the x was suggested in comment #0: "I would like to suggest that you ... also change the x ...") Just my two-cents. (In reply to comment #17) > (In reply to comment #16) > > > > I don't like the solution with the check mark. > > > > Can you explain why? I don't want to introduce a completely new icon for this. Also, we are not just talking about the error icon - there's also the warning and the info icon. Another reason is that other products on top of us might already use the check mark and hence we will add confusion. And finally, in the past ten years we only got this bug here, so it doesn't seem to be a big issue. Re checkmarks: The error doesn't have to be solved when the icon goes gray -- it just became stale. That means we didn't find the corresponding problem in the source any more (maybe because is was solved, but could also be that it has just moved too far from the original position).
> Raksha, please try to use light gray (similar to disabled) but invert the image
> i.e. gray cross on white background.
Good idea. We already have something similar in the Type Hierarchy view when focused on a package: Types that don't belong to the package are white with a gray letter. Please reuse those colors.
Created attachment 204328 [details]
Screenshot old-new icons
Screenshot with the new icon. Does this look better? I created it similar to the grayed type icon in Type Hierarchy view. Appears different to me in the simulator.
(In reply to comment #20) > Created attachment 204328 [details] > Screenshot old-new icons > > Screenshot with the new icon. Does this look better? I created it similar to > the grayed type icon in Type Hierarchy view. Appears different to me in the > simulator. Is this just an optical illusion: the lowest icon looks smaller. > Is this just an optical illusion: the lowest icon looks smaller.
That's because Rakha's icon is missing the white border around the circle.
I like the new style and I think we should take this up to the designers.
(In reply to comment #22) Sorry for misspelling your name, Raksha. (In reply to comment #22) > > Is this just an optical illusion: the lowest icon looks smaller. > That's because Rakha's icon is missing the white border around the circle. > > I like the new style and I think we should take this up to the designers. +1. Raksha, please do the following: - fix the border - create the warning and the info icon - adjust the code to load the icons - create a screenshot where one sees all icons (real and gray) on the normal ruler background and on the range indicator Thanks! Created attachment 205202 [details]
Patch
Patch to load new icons.
Created attachment 205203 [details]
Screenshot real-gray icons
Screenshot of all (real and gray) icons on the normal ruler background and on the range indicator
Created attachment 205204 [details]
new icons
new icons set
(In reply to comment #26) > Created attachment 205203 [details] > Screenshot real-gray icons > > Screenshot of all (real and gray) icons on the normal ruler background and on > the range indicator I don't see much difference in the info icon (1st & 3rd are real (blue) while 2&4 are grayed icons). However, others look different on the simulator. >(In reply to comment #24) > Raksha, please do the following: > - fix the border > - create the warning and the info icon > - adjust the code to load the icons > - create a screenshot where one sees all icons (real and gray) on the > normal ruler background and on the range indicator > > Thanks! Done. Pls have a look and let me know what you think of the new icons. The error icon looks good, but the others still have too much color. The content of the warning icon should be completely white, except for the !. The info icon should lose the shadow. Also make sure you have 1px wide white ring around the images, and all pixels outside of that ring are transparent (they are transparent in the original icons but white in yours). Hints for Paint.NET: - Adjustments > Hue / Saturation > S = 0 - Open the Color palette and click More >>. Then make sure that all colors used in the icon have S = 0 and V < 58 in the HSV model (V = 58 is the darkest color I see in the type icons) - To draw pixels with 100% alpha, use the Pencil tool and set the alpha to 0. Then, make sure the flask in the window toolbar is set to "Overwrite" (no green liquid in the icon). Created attachment 205345 [details] new icons set (In reply to comment #29) > The error icon looks good, but the others still have too much color. > The content of the warning icon should be completely white, except for the !. > The info icon should lose the shadow. > Done. I redrew the icons as in original so kept the content as lighter shades of gray and retained the shadow for info icon.. but yeah white gives it more contrast, removed the shadow as well. > in the icon have S = 0 and V < 58 in the HSV model (V = 58 is the darkest color > I see in the type icons) Reduced the color of the icon to match that of type icons and only made the border areas < 58. > - To draw pixels with 100% alpha, use the Pencil tool and set the alpha to 0. > Then, make sure the flask in the window toolbar is set to "Overwrite" (no green > liquid in the icon). Thanks, made the changes. (In reply to comment #30) > Created attachment 205345 [details] > new icons set The colors look good now, but the icons still don't contain transparent pixels. Created attachment 205509 [details]
new icons
New icons with transparent pixels and white 1px circle. Looks better now on range indicator.
Created attachment 205512 [details]
Screenshot new icons
Screenshot of new icons on range indicator and ruler background.
(In reply to comment #32) > Created attachment 205509 [details] > new icons Looks good now. Comment on attachment 205202 [details]
Patch
Thanks for the patch Raksha - looks good. Just two things:
1) The DESC_* constants are not used and hence not needed.
2) I don't understand is why you use "_alt" instead of "_gray". Reasoning?
Please address those issues and then go ahead and commit to master.
(In reply to comment #35) > Comment on attachment 205202 [details] > Patch > > Thanks for the patch Raksha - looks good. Just two things: > > 1) The DESC_* constants are not used and hence not needed. DESC_* constants are used to attach the prefix String org.eclipse.jdt.internal.ui.JavaPluginImages.T_OBJ= "obj16", and hence required. > 2) I don't understand is why you use "_alt" instead of "_gray". Reasoning? > The type icons already use _ALT , so I just borrowed the name to maintain consistency. > Please address those issues and then go ahead and commit to master. I will commit the patch as is. (In reply to comment #36) > (In reply to comment #35) > > Comment on attachment 205202 [details] [diff] [details] > > Patch > > > > Thanks for the patch Raksha - looks good. Just two things: > > > > 1) The DESC_* constants are not used and hence not needed. > > > DESC_* constants are used to attach the prefix > String org.eclipse.jdt.internal.ui.JavaPluginImages.T_OBJ= "obj16", and hence > required. There are 0 (zero) references to that constant. Hence it is *not* used. > > 2) I don't understand is why you use "_alt" instead of "_gray". Reasoning? > > > The type icons already use _ALT , so I just borrowed the name to maintain > consistency. Fair enough. > > Please address those issues and then go ahead and commit to master. > I will commit the patch as is. No you don't. Please deal with my review comments first. (In reply to comment #37) > > DESC_* constants are used to attach the prefix > > String org.eclipse.jdt.internal.ui.JavaPluginImages.T_OBJ= "obj16", and hence > > required. > There are 0 (zero) references to that constant. Hence it is *not* used. The prefix can be attached to keys by a call to createManagedFromKey(..), we can eliminate the constants afterall. > > > Please address those issues and then go ahead and commit to master. > > I will commit the patch as is. > No you don't. Please deal with my review comments first. Alright, done. Committed the fix : commit b031c714b439460ac139287bda9b2b9abf9f6f3f Verified in 3.8-I20111025-1800. Filed bug 362035 to track the request for getting "real" icons. |