Skip to main content

During our work on the Universal GUI Styling Update, we’ve had several discussions and deep-dives about topics like the form and grid suggestions of the Styling blog with some of you. In those meetings, and as an extra assignment, we investigated improving the data density of our Universal GUI. A common topic on the Community and during conversations is that predominantly the height of several components demands too much space.

Our challenge from the perspective of UX is finding the balance between functional presented data and preventing a visual cluttered interface. 

We are in the midst of trying to reduce the height of components such as form fields and grid rows, but we also think that we have to look into other options, where data may be offered in a different way.

Let’s take a look at the suggestions in order of expected impact.

 

Grid elements

  • The current Universal default row height is 36px. We want to bring that down to a default of 28px.
On the left, the current Universal Grid (default row height of 36px high), on the right, the new default grid row height of 28px
  • Currently, Universal only supports an adjustable lower row height for non editable grids. In the new design we aim for a minimal row height of 20px for both the editable and non editable grid (this would bring this feature to the same minimal possible row height as the Windows GUI).
    Do keep in mind though, that the controls of editable grid cells become very small and that you must prevent those grids to be presented to users on touch interfaces! We stray far away from the path of UX for touch targets, which suggests a minimal touch object of 44x44 pixels (iOs guideline) or 48x48 pixel (Material Design guideline)
The new minimal grid row height will be set to 20px
  • As stated in the UI Styling blog the headers height is also altered (the new default column header height will become 32px, vs the old default height of 44px), and will also be independent from the row height settings.
Comparison of the current Universal GUI header and the new proposed header height (with grid rows of 20px high)
  • The width of the columns is now influenced by 8px of padding around the text and the data field. 4px is the minimum, as the controls in editable grids need a surface around them to be selectable and Conditional Layout needs space around the data to be shown correctly.

What if we changed this to 4px instead of 8px?

 

The differences of 8px padding around the data in grid columns and 4px padding. 
  • Currently, we show totals in a separate row below the grid with additional text like ‘Amount’ or ‘Count’ added to the number, above the value, demanding extra space.

What if we use a tooltip instead of the text, similar to the Windows GUI?

Remove totals label and show as tooltip instead

Form

  • The current Form fields in the Universal GUI are by default 46px high. With the new Outlined Form fields, they are 41px high. This seems like a little difference, but, the header is now included in the outline, making it visually a lot smaller. Also, the padding around the group headers has been altered, which makes form a whole lot more compact.
The current Form (left) versus the new Outlined style (right)
  • A legacy styling that crawled into the Universal GUI, is the font size and padding of Grouped Tabs (Windows GUI) which are now labels in the form of the Universal GUI.

What do you think of tab headers gaining the same font size/weight and padding as standard group headers?

On the left, we see the current Universal Form setup. In the middle, the Form Tabs in a dedicated font, and on the right, Tab headers in the same font as Group Headers (with deliberate reduction of padding for the Tab Headers, as they cross the total width of the component)

 

Collapsible form tab

  • As a replacement of the tabbed behavior in the Windows GUI, we are thinking about collapsible form tabs.

Do you wish to configure for each Next tab in Subject > Component > Form whether it should be expanded or not? Do you want to set the default to all tabs open, closed, or default only first tab open?

Examples of collapsible Form Tabs

 

Collapsible components

  • Next to collapsible Form Tabs, we worked on a concept to make Screen component splitters collapsible. With this concept, splitters would become collapsible on click/expandable on click, to give users the tools to show/hide data on demand.

How do you feel about this concept?

In this example, the form is collapsible with the chevron button, attached to it. In this concept, the whole form would collapse to the side
A possible way to present the collapsed form

Improving the Data density with above suggestions aims to streamline the transition from the Windows GUI to the Universal GUI. Future UX improvements will put more emphasis on Touch interface design. As always, we are curious to hear your opinions!

Nice developments! 

Is there also attention for cubes in this phase? Or do changes that relate to grids automatically apply to cubes?


Great improvements but the title of this blog doesn't really cover everything in this post. 

I do feel that with the reduction in line heights etc it would be good to introduce new data density user settings, currently we have comfortable and compact. If the new data density becomes compact, comfortable becomes the old compact maybe introduce a new one above comfortable?

Form

The tab headers of the second version are the best compromise of reducing the space taken without losing a clear distinction between a normal field label and the headers (especially combined with the collapsible form tabs)

Collapsible form tab 

Configurable per tab - collapsible default no
subject: start first open default

Collapsible components

Good concept but the indication of a collapsed component has to be more clear than in the current concept. Maybe leave the header in tact? That would mean it will work best when multiple components are in the same column but you would be atleast be able to shrink the width to the header/title width.

 


Glad to see the Data density is getting some love. This is highly desired for use with lots of data detail.

Reading through the article I see the mention of Touch interface. These “limitations” are usually counteractive for devices that do not need to support these methods. So no need huge everything and much white spacing. Would it not be better to also have this as a setting, like the “Compact” / “Comfortable”?

When the application created is not meant to be used on Mobile devices, it is okay to have the small buttons and perhaps other small things that one would not want on touch devices.

Assuming the developer thinks about these options, that would make it possible to create certain screens so that they work well on both options and certain screens are only optimized for one.


Looking good!

 

Currently, Universal only supports an adjustable lower row height for non editable grids. In the new design we aim for a minimal row height of 20px for both the editable and non editable grid (this would bring this feature to the same minimal possible row height as the Windows GUI).

Do keep in mind though, that the controls of editable grid cells become very small and that you must prevent those grids to be presented to users on touch interfaces! We stray far away from the path of UX for touch targets, which suggests a minimal touch object of 44x44 pixels (iOs guideline) or 48x48 pixel (Material Design guideline)

 

Could you in some way couple this on a screen type and break points? It would be more work but having the possibility to adjust this with different devices in mind would remove the possibility that it becomes too small for touch device users.

 

What if we changed this to 4px instead of 8px?

 

I think 4px is to small, 8px is as small as I would go.

 

What if we use a tooltip instead of the text, similar to the Windows GUI?

 

I would only go this route if tooltips were to be used in more places in the application in this way; if its not ‘standard’ people wont think to mouse over it.

 

What do you think of tab headers gaining the same font size/weight and padding as standard group headers?

 

I prefer the setup on the right however would like to see the tab header slightly larger than the group header to highlight that it is a ‘layer’ higher.

 

Do you wish to configure for each Next tab in Subject > Component > Form whether it should be expanded or not? Do you want to set the default to all tabs open, closed, or default only first tab open?

 

I like the collapsible forms; being able to configure it being opened or closed seems logical to me (like your example with trace closed as standard). I would default to all tabs open, however being able to configure this per application/model would also be handy.

 

How do you feel about this concept?


Looks good and doesn’t take up too much space, have you thought about how you would present both the form and the list being collapsible?


My feedback:

  • I'm all for better data density, however it would be beneficial to mingle with it per at least project ( to have at least consistency with a project). I know from experience that data density 'wishes' can vary per person/organization.  (However personally I would like to see this asap)
  • Aggregation labels as tooltip is better in my opinion than the current solution. 
  • As to the forms:
    • Most right example is preferred.. with *bold* headers. 
    • Collapsible form tab. YES! But to be set in the model if it should be default collapsed /open. 
  • As to the components
    • I'm all for collapsible components, however in a hover state. In all the examples i've seen the other component changes whilst open/hiding the collapsible component. This 'disturbs', because things change and will get attention which isn't needed. The attention should go to the opened form in the example, not the grid that gets different dimensions in the current setup. 
    • So, yes, definitely a plus to have collapsible components, but in my opinion only when it's a solution that hovers over the main component. 

Reply