Kirill Grouchnikov's Blog

Listening to the users part II - pixel pushing

I got a very unexpected mail following my previous entry from Romain himself. It contained a very detailed list of visual problems on the new (and old) skins. He also followed up on the changes that i made during the last couple of days with yet more advice - i'm very grateful for this. Here are the shots before:

And here are the shots after (note that there are still some things to be done and this entry will be updated accordingly):

If you're like me, you wouldn't see much difference. If you're like Romain, you'd be quick to whip up the following list:

• The gradient is less dark in the middle part of buttons, scroll thumbs etc.
• Combo arrow button has all-round corners fitting better in straight-corner textfield border.
• Scrollbar track borders form seamless connection with scrollbar buttons borders.
• Scrollbar track is flat and "sunken" instead of having the same gradient as the scrollbar thumb.
• Scrollbar buttons are flat as well + they have a gradient reverse to that of the scrollbar track.
• Mark icons (checkbox, radio button, combo arrow, scrollbar arrow) use theme colors instead of strong black.
• Tabbed pane has theme-based border with extra margin. The border itself is slightly-rounded and less heavy (especially on the right and the bottom borders). The visual result is much less clutter around the content pane edges and continuity of the tab and the tab component itself.
• Tab painting does not use as much color as before to provide enhanced continuity of the tab and the tab component itself.
• Selection animations (you'll have to run the app) are twice as fast removing the perceived sluggishness.
• Unselected checkboxes are painted with flat gradient so as not to attract too much attention.
• Default scrollpane border integrates seamlessly with the scrollbars (where present). The visual result is much less clutter around the viewport edges.
• Bottom-right (or bottom-left under RTL) corner of scrollpane is painted with the background (and the watermark) of the scrollpane itself. The visual result is much less clutter around that corner.
• Split divider grip has different appearance. Romain says that it should be styled after NetBeans but i can't see too much difference :(
• Insets of the default list cell renderer place the labels farther away from the list left / right edges. The visual result is more balanced spacing around each item.
• Checkbox text is better aligned with the checkbox mark, especially on unselected checkboxes.
• (new) Unselected tabs are partially translucent, drawing less attention from the selected tab.
• (new) Lock icon on non-editable text components is partially translucent.
• (new) Non-editable text components have grayed-out background.
• (new) Slightly rounded corners on text component borders.
• (new) Brighter background for the panels (actually it was a bug that introduced discrepancy of background color of complex themes vs. the identical simple themes).
• (new) Search icon uses theme colors (identical to checkbox, radio buttons, scroll arrows, menu arrows, combo arrows etc).

As i've already mentioned, there are still things left to do before the final drop of version 3.1 (code freeze is in two weeks) - you're welcome to leave comments. And no, i have no intention to push for inclusion of Substance into the JDK (you'll have to brush up on your French) - the two-year release cycle doesn't sit well with Substance release cycle. By the way, wasn't Mark talking about removing MIDI from JRE instead of JDK?

And once again - many thanks to Romain.

Comments

• I am glad you guys divorced and made up. :-)

  You are fast on the track to catch Alloy. And Alloy does not support subpixel AA yet, which speaks for Substance.

  Cheers,
  Mikael

  Posted by: mikaelgrev on September 30, 2006 at 11:39 AM

• I like it. Good work!
  The new style for selected tabs isn't that great in my opinion, but it's better than before. Also removing the arrow icon from the "previous" button was a good idea, I think.
  Congratulation! :)

  Posted by: pago on September 30, 2006 at 12:48 PM

• Patrick,
  The style for selected tabs is exposed via API (the start and end of fade area from the active color to the tab component / tabbed pane background). Since the tab borders are now properly aligned, there is no longer need for solid fill to just show what is the selected tab component, so you can use less color for this. The old (saturated) themes continue using the solid fill on the entire selected tab. The button icon was set by the app code itself and not by the LAF and Romain suggested removing it. In addition, i also changed the app icon itself to something more interesting. But these two were not changes in LAF itself.

  Posted by: kirillcool on September 30, 2006 at 05:45 PM

• And no, i have no intention to push for inclusion of Substance into the JDK (you'll have to brush up on your French)
  Are you stalking me? :-))

  Posted by: gfx on October 01, 2006 at 09:13 AM

• I have the visitor tracker stats right here, so i can see the last 100 referrers. If this is considered stalking, then yes :)

  Posted by: kirillcool on October 01, 2006 at 09:44 AM

• Great work. Although the changes seem small it does make it look a lot more polished. I'm glad to see the initial annoyance has produced some positive results.

  Posted by: jmelchio on October 02, 2006 at 07:04 AM

• 
  Interestingly enough the Java Ocean theme would benefit from some of these changes as well.

  
  Although Ocean is a lot better than the original Metal I think it would be good for the Java community at large if a bit more attention was payed to making it look more spiffy and up to date with each major release.

  Apologies if this is slightly off topic ...

  Posted by: jmelchio on October 02, 2006 at 07:51 AM

• These are small changes that I wouldn't otherwise notice, but definitely improves Substance.

  Does the netbeans plugin make netbeans use the ribbon stuff?

  Is there a real java app out there that uses the ribbon stuff?

  I'd love to play with it in a real application.

  Posted by: trcorbin on October 02, 2006 at 09:01 AM

• There is no way that a Substance plugin would make NB use Ribbon. This plugin is for look-and-feel and doesn't change the controls that the application is using (toolbars / menus). If you want a real app - push for it in the blogosphere :)

  Posted by: kirillcool on October 02, 2006 at 09:11 AM

• Definitely an improvement to make the look of Substance less intrusive.

  Now if you could come up with ambient color schemes and a bit more sparse layout (I think it's too narrow), then it could make a professional looking LaF, matching the technical advantage it already clearly shows.

  Regards,
  Christian

  Posted by: christian_schlichtherle on October 02, 2006 at 09:13 AM

• While I don't like every detail, I agree that overall it's a nicer look after. The gradients are less aggravating, that's for sure. One specific recommendation I'll make on the new look is also about the tabs. The unselected tabs have more contrast of text vs. background than the selected tab. I guess they look like your buttons, and that makes sense, but it deemphasizes the current tab and makes it relatively harder to read. Not sure about the best solution since I see why you made the change to this fashion, too. (And the continuity is nicer than the abrupt break of the saturated style.) Probably something could be done, though.

  Oh, and the down button on the combobox seems to be missing a pixel or so of padding on the right side of the arrow.

  Posted by: tompalmer on October 02, 2006 at 09:23 AM

• One more detail: Could you please rework the appearance of disabled text fields. To my opionion they should:

  
  Have a "greyed out" background colour.
  The lock position and appearance is intrusive: It would be best to omit it, or you could at least put it on the lower right of the field and make it half transparent.

  Regards,
  Christian

  Posted by: christian_schlichtherle on October 02, 2006 at 09:26 AM

• Christian,
  Thanks for the suggestions about the disabled text fields. The locks (as any other Substance-specific additional UI elements) can be removed by setting a VM flag / global UI property / control-specific UI property - but they indeed need to be less obtrusive. I'll update the screenshots when it's done.

  Posted by: kirillcool on October 02, 2006 at 10:09 AM

• tompalmer,
  The combo button will be made 1 pixel wider to have equal left/right margins. Thanks

  Posted by: kirillcool on October 02, 2006 at 10:11 AM

• "University of South California" ??

  Posted by: david_hall on October 02, 2006 at 11:38 AM

• The spacing of the three controls at the right end of the titlebar seems inconsistent.

  Posted by: david_hall on October 02, 2006 at 11:41 AM

• David,
  The list just shows the NCAAF rankings from the last week (see the USC page). I used it to create a list with entries of different length. And indeed the title buttons (minimize / maximize / close) are unevenly spaced. This is by design - the close button stands apart by a few extra pixels so as to delineate that clicking on it will close the frame. This makes it harder to accidentally click on it when you intended to click maximize.

  Posted by: kirillcool on October 02, 2006 at 11:48 AM

• I agree with Kirill on separating close and maximize buttons. I'm still not sure who the genius is at Microsoft that decided "make this window bigger" and "make it go away" should be so near each other. And Vista makes it worse if anything. That maximize button is one of the most important buttons in Windows, but they seem interested in making it a pain.

  Posted by: tompalmer on October 02, 2006 at 12:03 PM

• If you started polising this stuff, one thing I would like to point out.

  You should use either roundish corners or the sharp ones on everything. When both styles are used it just does not look consistent. Just my 2c.

  Posted by: euxx on October 02, 2006 at 12:26 PM

• Yeah, I didn't think it was likely that the substance plugin would add ribbons to netbeans. It was just a wild hope.

  Posted by: trcorbin on October 02, 2006 at 04:51 PM

• Thanks for all the comments - see the newly added fixes in the list above. Christian - the lock icon can't be moved to the right because of the comboboxes :(

  Posted by: kirillcool on October 02, 2006 at 09:17 PM

• Sexy! If I was going to get into nitpicky tweaks:
  - the background grey of your sample app is very dark. Try something like #EEEEEE or brighter!
  - your magnifying glass should have the same thickness for handle and rim, possibly using the same grey as the checkbox check
  

  Posted by: jessewilson on October 03, 2006 at 01:01 AM

• What an improvement! I think the button borders should be toned down as well - much like tab borders were.

  Posted by: wsnyder6 on October 03, 2006 at 07:16 AM

• 
  Kirill,

  you could position it a few pixels left from the lower right corner of the text field (say 5 pixels spacing between the lower right corner and the lock).

  Now to a different idea:
  Why not show the lock exactly only when the user actually tries to type something into a component which cannot receive input?

  I think this would make a good solution: On a form with many disabled text fields, the form isn't screwed by the locks. As soon as a user tries to enter text into a disabled component (which should use a less intrusive way of indicating that it's disabled) the lock appears automatically for say two seconds in order to clearly provide feedback that this component cannot receive input.

  What do you think?

  Kind regards,
  Christian

  Posted by: christian_schlichtherle on October 03, 2006 at 11:02 AM

• Christian,

  That's an interesting (and certainly doable) idea. However, this poses a few questions:

  Should the non-editable (we are talking about non-editable and not disabled) text field have the border insets large enough to accomodate the lock icon when it'll be shown?
  If so - the non-editable text fields will have this "unnatural" gap on the left where the lock icon would appear
  If not - what happens when the icon appears? Do you "move" the text a few pixels to the right to show the icon? Do you overlay the icon over the first character? If you move the text, it can be very annoying for the users that started the selection at one character and suddenly that character moves to the right and the selection starts from the previous character. If you overlay the icon, the first character will be partially obscured - the icon is translucent, so it's not that big a deal.

  
  About putting the icon on the right - it still doesn't solve the problem of non-editable combobox, since the icon shouldn't interfere with the combo arrow button. Since this border is set by LAF-agnostic widget, i don't have information about the button bounds :(

  Posted by: kirillcool on October 03, 2006 at 11:44 AM

• Jesse,
  The background will be made lighter - it's a bug that makes the background of a complex theme darker than the background of the identical simple theme. About the search icon handle / rim - why would it look better if they had the same thickness? The real-world magnifying glasses have a handle that's easy to grab and the glass rim not as thick as the handle (just thick enough to hold the glass) - see some right here. I experimented with making the rim thicker / making the handle thinner and it doesn't look better.

  Posted by: kirillcool on October 03, 2006 at 01:02 PM

• Hi!

  I think changes are in right direction and everything looks better. I would lighter OK buton and slider too, but that is just my view. Congratulation, that you try to listen other people opinions too. Sometimes, it is very difficult to overcome your own vision.

  Gorazd

  Posted by: gorazd_praprotn on October 04, 2006 at 05:59 AM

• 
  Kirill,

  My proposal was based on the assumption that the layout doesn't need to change whether the lock is shown or not. Otherwise, the LaF behaviour would be annoying.

  This may be achievable though if you would make the lock half transparent. In this case, it doesn't matter that much where it's actually shown and it would disappear after a few seconds. For a transitional effect like this, you probably don't have to consider the layout issue that much.

  Anyway, just an idea. If you don't like it, forget it. :-)

  Kind regards,
  Christian

  Posted by: christian_schlichtherle on October 06, 2006 at 03:12 PM

This work is licensed under a Creative Commons License.