Community
Participate
Working Groups
I20090421-0800. The new look of the Colors and Fonts page has introduced some issues: - we normally use 'Edit...' and not 'Change...' in the preference UI - the description should not be replaced by a tool tip: at all other places we use a text field to show this information and the tool tip introduces an accessibility issue for keyboard-only users. - in the new preview for colors it looks irritating that the top and bottom borders have the selected color when we talk about Kevin, what's your take on this?
None of the issues from bug 89256 comment 11 actually made it into the patch.
+1 for the change to "Edit...", it is the standard verb we use in other places +1 on the restoration of the 'Description panel. I get your concern about folks using KB navigation not being able to -ever- see the description (no 'hover' to trigger the ttip (sorry I missed this one). I hate losing the space though... ? for the last comment, it appears to be incomplete...? From the other bug I do like your idea of placing text into the 'colored' area as well as the text in the 'white' area. Since you bring up accessibility we should also ensure that the various elements (i.e. the tree's items have valid) accessibility strings for screen readers. Note that partially blind folks are the -most likely- people to want to change the default settings (I now consider myself 'partially blind' without my reading glasses...;-). Also added Oleg for his take...
>From the other bug I do like your idea of placing text That was Markus ;-) I also like it. I just don't like the two big bars at the top and the bottom.
(In reply to comment #0) > Kevin, what's your take on this? I've not seen it, I will take a look and comment thanks.
Hi Paul, given comment 2 shouldn't this be assigned to Eric instead of triaged?
(In reply to comment #5) > Hi Paul, > > given comment 2 shouldn't this be assigned to Eric instead of triaged? It's now Kevin's to be negotiated with Eric for who would do the actual work. PW
OK, but this should be targeted for 3.5 M7.
(In reply to comment #0) > - we normally use 'Edit...' and not 'Change...' in the preference UI +1 Agree, "Edit..." is the norm > - the description should not be replaced by a tool tip: at all other places we > use a text field to show this information and the tool tip introduces > an accessibility issue for keyboard-only users. +1 Agree, this is *critical*, we need the description field reinstated. The tooltip for a list item is supposed to be the full text of the item in the case it's clipped by a narrow list view. Plus it's very distracting as you cursor around. Plus, some items have very long descriptions (e.g. counter color) which makes for too long a tooltip to be practical (and your cursor is over the very thing you're trying to read). > - in the new preview for colors it looks irritating that the top and bottom > borders have the selected color when we talk about +1 I too find this distracting. All we need is a small box of the color. For example, the XP color picker just gives you a little sample. I think the important gain is to just provide a swatch larger than the little one we did before. While I see the intent at being helpful in providing text colored as part of the preview, in some cases it doesn't make sense. For example Basic->Content Assist background color gives you white text on white background on the LHS, it looks like a bug. That's because of course it's a background color, not a text color, so using it as a text color on some unrelated background is prone to problems. In this case what you really want to see is it in combination with the Content Assist foreground color, but I don't know how we'd know to combine these in the preview. If you want to preview the color using text, you need to know what the text is going to appear over to do a proper preview. Otherwise you can't judge important things like if there's sufficient contrast, if the colors clash, if the combination is an issue for the color blind (e.g. red/green text/background, picked in isolation). I'm not sure what to recommend here other than to get rid of the text coloring and just provide the color swatch. I don't think the current preview is helping in the way intended. (In reply to comment #6) > It's now Kevin's to be negotiated with Eric for who would do the actual work. Well who did the work in the first place? :) I'm happy to help but can't at this moment and M7 is looming...
(In reply to comment #8) > > - in the new preview for colors it looks irritating that the top and bottom > > borders have the selected color when we talk about > +1 I too find this distracting. All we need is a small box of the color. The color preview was inspired by the bug 60717 comment 12: "The contents of your tooltip in the preview area would be the perfect solution (along with a preview for colors that shows a colored 1px line, a filled rectangle, and a few words in that color -- all three on a white and on a gray background)." Personally, I find it to be much superior to a simple rectangle as it shows not only color by itself but color used in multiple situations.
(In reply to comment #9) > The color preview was inspired by the bug 60717 comment 12: What can I say, everyone's a critic when it comes to UI's :) > Personally, I find it to be much superior to a simple rectangle as it shows not > only color by itself but color used in multiple situations. Yes ... I thought that it had within it a good idea, but as I said, I'm not sure it's giving the user the data they need to make a decision since the situations presented don't necessarily match the ones in which the color will be used. That's the essence of the problem and why this is very difficult to do right. Either we need to know which foreground/background color prefs are to go together and preview them that way, or we need to compute a background which at least guarantees readability (e.g. to avoid the white on white case). Another thought experiment: try to find an example in an existing product or OS which does a text color preview and see what they did (what works, what doesn't).
Since at the moment, we just don't know how a color is going to be used, the only choice we have for a good preview is to show the color in many situations (including as text color, as background behind default-colored text, etc.). Eclipse can't decide what's the right preview, so we should at least give the user a chance. > (e.g. to avoid the white on white case). A theoretical problem that every sane user can understand and handle in a second when she selects another color. We should first solve the real problems (e.g. I can't see how my color looks as background color).
Created attachment 133363 [details] Patch The patch takes care of the first two items on the list (restoring the "details" area, reverting to default tooltips, renaming button). For the third item there are several very different opinions on what it should be. From several comments I accumulated so far: a) "In the color preview, I would add a "Sample Text" label in default color (black) to one of the fat horizontal rectangles to give an impression for background colors." b) "I also like it. I just don't like the two big bars at the top and the bottom." c) "I'm not sure what to recommend here other than to get rid of the text coloring and just provide the color swatch." d) "Add RGB values to the color preview." From my side, I'd be interested in constructive comments on how to make it more "elegant" without making it busy.
I would not go back but simply remove the two bars for 3.5.
Committed in >20090427. Applied Oleg's patch. We still expect one more patch to address the color preview display so I'll leave this open for now.
Created attachment 133455 [details] Patch 2 The patch changes apperance of the color and font previews.
Committed in >20090427. Applied Oleg's latest patch...looks great to me !
Much better now :-) Some remaining issues though: 1. the description is not standard. We should not invent a new style/look at this point. Take a look at other Platform UI preference pages like 'Appearance' or 'Capabilities' for a template. Fixing this will left align the label again with "Preview:" and hence look nicer. 2. the solid black border is too eye-catchy and not used anywhere else including the preview for the theme colors. I would use the same approach for font and colors or put it into a Group without title. 3. very minor (and same issue in 3.4): the vertical spacing between description and preview should be a small bit bigger.
(In reply to comment #17) > Some remaining issues though: > 1. the description is not standard. We should not invent a new style/look > at this point. Take a look at other Platform UI preference pages like > 'Appearance' or 'Capabilities' for a template. Fixing this will left align > the label again with "Preview:" and hence look nicer. This is done to save space. One of the compaints about the 3.4 look of this dialog was: "This is becoming more and more annoying with the growing count of tree entries that are hidden behind the tiny keyhole." (bug 89256 comment 11) > 2. the solid black border is too eye-catchy and not used anywhere else > including > the preview for the theme colors. I would use the same approach for font and > colors or put it into a Group without title. Hmm but if we implement (1) when we'd have a square blue "Description" rectange that won't work with rounded greyish Group under it. Plus black border gives nice separation of the preview color from the dialog; for my eyes grey does not work as well for this purpose. > 3. very minor (and same issue in 3.4): the vertical spacing between description > and preview should be a small bit bigger. Same thing as above about the space. The real solution here would have being to have a SashForm with visible separator between the elements. In this case a horizontal line that would have a text "Preview" on it: Detail [Blah] ______Preview_______ [Preview Contents] However, there is no such standard control and making one for this page alone seemed overkill.
Using a sash is wonderful but I was only asking for a few pixels so that it looks better. But as said, very minor.
(In reply to comment #18) > (In reply to comment #17) > > 1. the description is not standard. ... > This is done to save space. One of the compaints about the 3.4 look of this > dialog was: > > "This is becoming more and more annoying with the growing count of tree entries > that are hidden behind the tiny keyhole." > > (bug 89256 comment 11) I agree it's good to leave more space for the tree, but I think we could make the color preview area considerable shorter and it still serve it's purpose (and thus free up some room to do a proper Description area). Also, I'd highly suggest that the Preview (and Description) areas be a fixed height. Presently they appear to be proportional. The change would mean that resizing the dialog taller would contribute all new space to the tree. Another space saving option is to have expand/collapse areas for Description and Preview. We do that in PDE forms but not anywhere that I know of in pref pages so I'm not really promoting the idea but thought it worth mentioning. > > 2. the solid black border is too eye-catchy and not used anywhere else ... > Hmm but if we implement (1) when we'd have a square blue "Description" rectange > that won't work with rounded greyish Group under it. Plus black border gives > nice separation of the preview color from the dialog; for my eyes grey does not > work as well for this purpose. Wouldn't we in fact have a square gray rectangle? I suggest we do the same for the preview which would provide enough of a frame (instead of the black). Note that the black frame idea was mine (to blame :>). > > 3. very minor (and same issue in 3.4): the vertical spacing between description > > and preview should be a small bit bigger. > > Same thing as above about the space. I think we're just talking a half font height space to give some visual grouping.
Created attachment 133674 [details] Quicky mockup showing a drastically shorter color Preview
Created attachment 133823 [details] Patch 3 The patch (against CVS Head): - Changes description to be just like other descriptions - Changes preview border color to grey - Changes button label from "Change" to "Edit" - Adds a bit of space on top of "Preview" Re comment 21: it won't work for contributed preview "View and Editor Folders" which is sharing the same space is already squeezed. Besides, now one can resize Preview <-> Tree areas so everybody can adjust it to their tastes :-).
Created attachment 133834 [details] Patch 4 Same as Patch 3 plus: - Border for font and color preview now is square, not rounded - The area painted by font and color previews is reduced to match Kevin's mock up
Oleg, I found a serious layout issue that I'd like you to look at while exercising the dialog: It appears that the Description field is driving the width of the dialog. To see this simply select the 'Basic->Counter color' (it has a long description) in the tree, hit OK and then re-open the pref dialog. Notice that it's now wide enough to show the description without wrapping... This thing has got 'tweakitis'...let's get together with Kevin tomorrow to go over this and put it to bed for 3.5 (i.e. done).
(In reply to comment #24) > It appears that the Description field is driving the width of the dialog. Weird, I thought this had been fixed (see bug 266018).
Is it the bug 99493? Kevin pointed that to me few days ago; that's the same as it was before 3.5 changes. (I'll try to fix that in RCs.)
Created attachment 133840 [details] Updated patch Scratch my comment 26. Eric is right, "data.widthHint" needs to be added to the description field.
Created attachment 133841 [details] Screencap showing clipped controls This is what I get with data.widthHint = convertHeightInCharsToPixels(30); added to the description field's gdata...
(In reply to comment #28) > Created an attachment (id=133841) [details] > Screencap showing clipped controls > This is what I get with > data.widthHint = convertHeightInCharsToPixels(30); > added to the description field's gdata... I believe that is the bug 99493.
Yep, you're right, I'd opened it with the long titled pref selected...ignore it.
Looks fine now, thanks Boris.
I forgot to comment... I have released "Updated patch" to HEAD so that we can look at this on all the platforms tomorrow. We can still tweak if necessary.
Looks much better now Oleg! Thanks for looking into this.
Thanks for all the work on this Oleg, looks great!
I noticed we leave some space at the bottom on vertical resize, I opened a separate bug #274583 for this.
Thank you for your contributions! Marking as fixed. Two issues with resize are tracked in the bug 99493 and bug 274583.
Verified in I20090430-2300.
*** Bug 60717 has been marked as a duplicate of this bug. ***
