Redesigning UI Controls

D3 is a software family by Digitec GmbH in the b2b context used by banks. Itʼs a niece product for foreign exchange trading and the primary user are traders. The D3 software family includes several applications that use the same pattern library. During my work as a working student for the company, I did a redesign were I gave every entry-, selection- and imperative control a new look, including a new hover effect. The redesign met several goals/ requirements and I implemented it myself in CSS.

Project Approach

Goals

There were several reasons why the existing designs should be replaced with a new design:

• Modernize the user interface as a whole and establish a more contemporary visual design with flatter controls
• Standardize the possible states of the controls (normal, readonly, disabled) as a whole
• Remove controls that are only used in individual cases and replace them with more common ones
• Increase the use of cursor hinting and, where appropriate, hover states to better communicate the interactivity of a control.

Requirements

While the goals already include some requirements (like a more modern look), there were some additional requirements for the new design:

• Make the states normal, read only and disabled distinguishable for the user to make the overall usage of controls easier.
• Give the user a better idea on which controls allow interaction (aligns with the requirement above) through cursor hinting and hovers.
• The new design has to work on both a gray or a white background. Since some of the controls might appear in listboxes or other UI components with white backgrounds, while the overall software has a gray (linear color gradient) background.

New control states

Considering the different goals, the new design had to meet several requirements, which were implemented in different ways. Innershadows and strong linear gradients were removed in the redesign to modernize the interface. Additionally, one of the most important goals of the redesign was to make the distinction between different states clearer, especially between the normal state and Read only and Disabled, in order to increase the usability of the software. Furthermore, a hover state was introduced to indicate interactivity.

Left: old design, right: new design

Normal

The “Normal” state is the default state. It is used when a user has both read and write permissions to a control.

Since controls are interactive in the normal state, the main goal of the redesign was to show affordance. This is done by a dropshadow as well as full opacity of colors. The light gray color of imperative controls (buttons) was furthermore replaced by a darker gray which makes the controls stand out more.

Design Specifications:

• Selection- and Entry Controls:
  
  • Background color: #ffffff
  • Effects: dropshadow (color: 25% black)
  • Text color: #000000
• Imperative Controls:
  
  • Background color: linear-gradient(#808080, #666666)
  • Effects: dropshadow (color: 25% black)
  • Text color: #ffffff with a shadow to increase readability

Hover

The Hover state indicates that a control is clickable and interactive.

Before the redesign, this state wasnʼt used in the software and was therefore newly implemented during the redesign.

Design Specifications:

• Selection- and Entry Controls:
  • Cursor: pointer/ text
• Imperative Controls:
  
  • Background color: linear-gradient(#666666, #4d4d4d)
  • Cursor: pointer

Read only

The read only state is used when a user has read access to a control, but is not allowed to make any changes.

Before the redesign, the read only state had problems with readability because some of the controls like textfields had a reduced opacity (including the text). Therefore the usability of the UI was reduced if a user had only read only access to certain parts. In the redesign the design decision was to increase the readability by always displaying the values in the control in black, while the overall control appears as not interactive, due to reduced opacity and a missing shadow effect.

Design Specifications:

• Selection- and Entry Controls:
  
  • Background color: #ffffff with 20% opacity
  • Border: #000000 with 5% opacity
  • Effect: none
  • Text color: #000000

Disabled

The disabled state is used when a user should have neither read nor write access to a control. The content of the control is not visible because it is irrelevant for the user.

Before the redesign disabled and read only werenʼt distinguishable. This resulted also in disabled controls (like textfields) showing values that werenʼt useful for the user because they arenʼt applied. E.g. if a text field was used in combination with an on off switch and the switch was turned off, the text field would still display a value even though the setting isnʼt applied. In the redesign the design decision was therefore that no values were to be displayed in disabled controls. Additionally, the whole control lacks a shadow effect that indicates affordance and is displayed with opacity.

Design Specifications:

• Selection- and Entry Controls:
  
  • Background color: #ffffff with 20% opacity
  • Border: #000000 with 5% opacity
  • Effect: none
  • Text color: transparent, for labels: #000000 with 25% opacity
• Imperative Controls:
  
  • Background color: 20% opacity
  • Effect: none

Redesign in the Software

Since the controls are also patterns in the software the redesign could mostly be done via CSS by me. Some special cases were also removed by our developers, and the use of control states had to be standardized - with the rules mentioned above. Since the states were previously used incorrectly in the Scala code, developers also had to do this, which allowed the CSS to take effect in all controls.

A screen of the settings UI before the redesign.

The same screen after the control redesign.