Siemens

Simcenter STAR-CCM+

Timeline: 2012 – Present

My Role: Senior UX Engineer (2012 – 2016) then Senior UX Designer (2016 – Present).

Significance: This is illustrates some examples of creative ways I’ve made improvements to a legacy product where, among other strict constraints, 100% backward compatible was a core requirement.

Simcenter STAR-CCM+

Simcenter STAR-CCM+ is a software tool used to simulate complex physics problems. The existing user interface is a Java client built upon the NetBeans framework.

Icon Design

Sometimes icons and other graphics need to be refreshed and redesigned. Sometimes you need to come up with a new icon for rotor blade aero elasticity.

Easy Access to Java Macros

STAR-CCM+ users automate a lot of processes by running Java macros, but there wasn’t a way to run their important Java macros with a single click.

Readable Decimal Format

By default, numbers are displayed in Simcenter STAR-CCM+ with the full double precision. Unfortunately this can sometimes make the numbers quite difficult to read.

I developed a mechanism to present the numbers in a readable decimal format. Now, the user can specify several pre-defined decimal formats or create their own custom decimal formats.

Decimal Display Format dialog previewing the custom decimal format

The full precision is displayed in the tool tip or when the user edits the value. Here is the same data displayed in double precision and a user-defined custom readable decimal format.

Data displayed in double precision
Easier to read custom decimal format with tool tip showing full precision value

Color Palette

Users used to select colors from a drop-down menu of color names sorted in alphabetical order. I replaced this with a color palette developed from scratch in Java, the colors grouped then sorted by luma coefficient (see Java method below). For backward compatibility the color palette was required to represent all 196 colors listed in the existing menu.

 /**
   * Returns the perceived brightness.
   *
   * @param c The color we're calculating the brightness (Luma Coefficient) of.
   * @return The brightness (Luma Coefficient) of the input color.
   */
  private static int getBrightness(Color c) {
    return (int)Math.sqrt(
        Math.pow(c.getRed(),2.0) * .299 +
        Math.pow(c.getGreen(),2.0) * .587 +
        Math.pow(c.getBlue(),2.0) * .114);
  }

Design Process

Showing the colors was always going to be better than the user deducing what colors the names represented.

The requirement to continue showing all of the existing 196 allowed the colors to be show in an efficient 14×14 grid, but the question still remained, how do we sort these 196 random colors so that the user can make sense of them?

These 196 colors can be sorted in 196! ways, that’s 508012211086704676250273578534744855832729752494702698292997143104359057480013603705540137242115195719262628671043031667501252088161309228461647972823682280495348903461291560889483687823263915860291345617137392657194686983749887501702176113098676677779711031060019608283576803094698692188285748113739606947612227692134400000000000000000000000000000000000000000000000 ways!

Displaying the colors in alphabetical order, the order they appear in the original menu, looked rather random.

Colors in alphabetical order.

So I sorted by the sum or red, green and blue values, then grouped the colors. This was better, but still there were colors that seemed to be out of order.

Sorted by the sum of each color’s red, green and blue values
Grouped then sorted by sum of each color’s red, green and blue values

Finally, I applied the relative luminance to sort the colors within the groups, and got something that everyone could agree on.

Sorted by perceived brightness
Grouped then sorted by perceived brightness

With the support of product management, the recommended approach, grouping the colors then sorting by perceived brightness was agreed upon, the colors grouped by grayscale, browns, pinks, yellows through reds, magentas, blues, cyan and finally greens.

The color cells needed different borders to indicate different things…

A single gray border is the default, neutral border.

A bold compound border of black, white and gray is used to indicate the current selected color.

A single black border is used to highlight cells during navigation.

Each cell needed to be big enough to easily be seen and clicked, but not so big that the overall editor took up excessive space. After testing different cells sizes, everyone agreed that 14×14 pixels was a good compromise.

Another consideration was the RGB information for the color. It was felt that this was too much information and could be overwhelming if shown everywhere, so it was displayed along with the name in the tool tip.

Since the user can define additional custom colors, we added an additional row of up to 14 of those colors.

Row of up to 14 custom colors.

Before: Original Menu

After: Color Palette