I believe there are two kinds of feedback – one of them is useful, and another is not. It’s quite easy to differentiate between two – the useful feedback is a detailed list of actionable items, while the useless feedback is talking in generic terms such as “wasn’t happy with it” or “it hurts my eyes”. To put it frankly, there’s not much that you can get from these brush-off remarks, nothing you can learn and nothing you can act on to improve your library. On the other hand, when you get a thoughtful and meticulous list of specific items, you may or may not agree with some of them, but at least you have a very good direction to explore.

I consider Romain Guy’s feedback in September 2006 to be a turning point for Substance look-and-feel library – this was the point when i stopped being obsessed with what can i do with Java2D, and started being more concerned about UI consistency and elegance. The work in Substance is far from being done, and over the past few days i have been reworking the visuals of text components, combo boxes and spinners. My previous entry on this subject has brought an excellent feedback from Matt Nathan (and this is not the first time it has happened), and here i want to address each one of his points.

All of the points in his comment can be seen in the following screenshot:


Point #1: the inner border line (the dark one) of the top left corner of the lighter themes editable combo boxes looks like it’s cut off slightly.

Let’s take a closer look:


Here, the top-left corner of the inner border is painted over by the opaque editor text field – which is an internal implementation detail. This has been fixed and now looks like this:


Point #2: the roundedness of the non-editable and editable versions is different, not sure if this is intentional but I prefer the editable version.

Right now this is as designed. An editable combobox is designed to look exactly like a text field (with an embedded arrow button). As such, it has the same exact corner radius – which in the current implementation is twice that of a regular button. And since uneditable comboboxes are designed to look exactly like buttons – you have the difference in corner radius. I will experiment with different radiuses in the next few days.

Point #3: the look of the hovered editable combo box’s button looks like it has a little ridge between the button and text field that doesn’t really fit with the rest of the look.

Let’s take a closer look:


The lighter outer line on the left edge is coming from the code that is using the same border appearance for the button as it does for the entire combobox. However, it shouldn’t be here, since it just creates unnecessary visual noise. This has been fixed and now looks like this:


Point #4: the down arrows of the editable combo box doesn’t line up with the down arrow of the other states, it’s closer to the right edge than the others.

Let’s take a closer look:


Here, the internal implementation details are causing the incorrect arrow alignment. Internally, the uneditable comboboxes do not show the arrow button at all. Instead, i’m just painting the arrow icon positioning it based on the current font size of the combobox. However, the arrow icon on the editable combobox is part of the arrow button, and the button insets / bounds did not match the settings for the uneditable comboboxes. This has been fixed and now looks like this:


Point #5: the baseline of all the buttons (and the text fields from your last blog) seems to be a pixel or two too low. This could just be me but they look off center vertically, though I’m sure they are central programatically (it looks like you’re centering on the font ascent or font height without taking descent into account)

This is actually as designed. The number of pixels from the top border to the ascender line is the same as the number of pixels from the bottom border to the baseline – and not the descender. This is exactly the same as in Vista and Snow Leopard, and highly unlikely to change in the immediate future.

Once again, many thanks to Matt for his time and attention to details. I can only hope that I will only get the useful feedbacks in the future :)


Comboboxes in Substance 6.0

October 27th, 2009

One of the items on the roadmap for version 6.0 of Substance look-and-feel (code-named Sonoma) is to polish the appearance of existing components. Today i’m going to talk about visual enhancements done for the comboboxes in the latest 6.0dev drop of the library.

In Swing there are two distinct types of comboboxes – editable and uneditable. This is controlled by the JComboBox.setEditable API. An uneditable combobox behaves essentially as a menu button – no matter where you click on the control, it brings up a popup menu with available elements. An editable combobox allows typing in a new value (with possible auto-completion available from third-party libraries), as well as showing a popup with available elements by clicking a small button “embedded” in the combobox.

The latest 6.0dev drop of Substance features visual overhaul of these two types of comboboxes. It addresses the following points:

  • Bringing the appearance of uneditable comboboxes in sync with core Swing buttons and Flamingo command buttons. As i said earlier, an uneditable combobox is a menu button, and as such, it should look like a button.
  • Bringing the appearance of editable comboboxes in sync with the text fields:
    • Adding more contrast to screens that use editable comboboxes as user input fields – by creating an “inset” look
    • Modernizing the appearance of these controls – by smoothing the corners and borders

In addition, the visual appearance of both combobox types should not expose the inner implementation – this is seen in most core and third-party look-and-feels (as well as in older Substance releases) where the innards of JComboBox – namely a text field and an arrow button are clearly seen on the screen.

Here is a screenshot with a few comboboxes under the Dust Coffee skin in release 5.3:


and here are the same controls under the latest 6.0dev:


When the mouse is moved over the arrow area of the editable combobox, it fades in the fill and border:


The same comboboxes under the Business skin in release 5.3:


and under the latest 6.0dev drop:


The same comboboxes under the Gemini skin in release 5.3:


and under the latest 6.0dev drop:


Finally, the same comboboxes under the Graphite skin in release 5.3:


and under the latest 6.0dev drop:


In addition to reworking the visuals, the latest 6.0dev drop also addresses the alignment and baseline consistency of all relevant controls. I have talked about precise micro-design back in September 2006 and in September 2007 (the links show how Substance has evolved over the years). Revisiting this topic once again, i first want to show a screenshot:


Here we have four different components:

  • Swing core button
  • Swing core uneditable combobox
  • Flamingo command action button
  • Flamingo command menu button

This screenshot illustrates the precise micro-design of the latest 6.0dev drop of Substance, enforcing the same preferred height on all these controls. As Flamingo command button is a functional extension of core Swing buttons, and uneditable combobox is nothing else than a menu button, they all should have the same height – and they do. More on this subject later.

Note that this is still work on progress, and you’re more than welcome to leave comments on the new look.

Image by Donnaidh Sidhe

Every month this series is tracking the latest design trends and collecting the best examples of modern web designs. Here is the list for September 2009 with almost 2000 links from 64 aggregator posts:

And if you have some extra time, here a few extra link aggregator articles for September 2009:

Gemini skin was introduced in just-released version 5.3 of Substance look-and-feel, and it is the first skin based completely on “offline” inspiration. Gemini was created from scratch in the Jitterbug color scheme editor from this image:

Gemini shoe

This is my hand holding one of my son’s shoes. I’ve been spending quite a lot of time with him lately, and these shoes are one of his favorites to drag around the house. It took me some time to realize that i really like the colors, and some more time to analyze the color combinations and translate them to the following Gemini visuals:

The black header is coming from soles, the dark blue toolbars are from the side strip, the gray footer is from the strips around the dark blue strip, and the light gray for controls is from the upper left area. And you can see where the bright yellow highlights are coming from.

Accidentally (or maybe not), a few days ago i’ve bought a couple of winter items that use very similar navy/gray/yellow color combination:

Gemini Sweater Socks

After researching the Internet for a while it appears that this color combination is quite popular now:

Gemini shoes

So there you go – just look at the everyday things, analyze what you like and why you like it, and use that inspiration in your UIs :)