There are 2 parts in this article, table column width guidelines for all Interact products and a sharing session on the case in Interact City.

The sharing session was done first, at the beginning of June 2019 while the guidelines were completed in May 2021. I improved the display of all columns in Interact City as the UI designer in the Interact City project and created the guidelines as a member in the Interact design system team afterward so that all tables in Interact products could get benefit from it and it is easy for all our remotely-working developers to understand and do the tables in a standard way.

Tables are often widely-used in complex data-condensed apps. That is why it is crucial in the Interact Prof system. It is super powerful to carry various dynamic data and allows our customers to manage millions of devices/assets conveniently and remotely.

Table column width guidelines

Summary

• Problems before: description of the issue
• Improvements: handing different types of columns in details
• Best practice: practical steps of how to do it
• Advanced improvements: further considerations/features to control the column widths
• Customizable tables: points around user-generated tables

Below is the spec.

Spec

We have to deal with big complex tables very often in professional applications. This document specifies how to display the information better in those tables.

Problems before 

The information hasn’t been displayed well in the tables because the space hasn’t been used reasonably. It could be separated into 2 problems for the tables.

1. The default width of the columns hasn’t been defined properly. Because the default width of the whole table was based on the width of the default screen that we did for the visual design. The predefined width for all columns was limited to this size.
2. The responsive rules haven’t been defined properly. When the screen was wider than the default (the size we create the visual design), the width of all columns increased based on the proportion of the width in default screen. Therefore, the columns were divided by wrong proportions when they gained the extra space.

As a result, the columns such as Name, Message were easier to be truncated when columns such as Checkboxes, Time took the space that they didn’t need.

When column width wasn’t predefined well and the width of the window is 2560

Though it looks fine at first glance, the potential problems in this case are,

• By default, the information in the Name column can easily be truncated, which we would like to avoid.
• As the window becomes wider, some columns (such as Nominal wattage) get extra space that they don’t need, whereas others (like Configuration ID) would benefit from that space.

Improvements 

The goal is to make the best use of the window width for the tables. It includes 3 aspects.

• Each column, by default, displays its content reasonably well, reducing the risk that user will need to manually adjust the width.
• When the width of the window changes, an optimal responsive rule for each column is defined so that some columns get the space they need in order to avoid (or delay) truncation, while others stay in their default width, or share less space.
• Users can resize the column width manually.

Now the width of each column has been defined, it should look like above when the window width is 1440.

The predefined default column width is shown in the image.

• The intention is to display all the information in the columns as complete as possible.
• When the column width changes and extra space becomes available, most of the extra space is going to be shared by Name and Configuration ID column. And the Configuration ID column would even gain more space than the Name column.

Principle

The general idea is to provide more definitions on the column width.

Defining a default width

A default width is defined for each column based on best estimation of the width of the content and possible multi-language support.

A default width is required for each column regardless of the column type. It is the width that the column adopts when no extra space is available. The default width is also a minimum width.

Therefore, the sum of the default column widths in a table is the default table width.

Defining rules on column behavior

Types of columns are invented to indicate which column(s) should share the extra width when it becomes available. Not all columns need to be enlarged. Giving extra width to a date column, for instance, could result in waste; better give that space to an address column, where truncation is more likely to happen.

Types of columns

There comes the 3 types of columns, fixed, greedy, and shy.

Fixed columns

Fixed columns, as the name suggests, never change their width. It’s always the default width, even when the extra space becomes available. Define a column as fixed when you are totally sure of how much space it will need, for instance, columns for Checkboxes, Icons, Mobile number, Percentage, etc. Simply choose a default width value that will be large enough to prevent any truncation.

For a fixed column:

• Min width = Default width
• Max width = Default width

We specify a fixed column as follows:

• Fixed (<Default width>)

Greedy columns

When the column width is difficult to estimate, either because little is known about the contained information, for instance when it’s user-created, or because the impact from the translation is too hard to predict, we specify the column as greedy, for instance, Name, Address, Message, etc. Such a column benefits from getting wider and will consume any available extra space.

Simply put, if a table contains greedy columns, they get priority to share the extra space when it is available.

For a greedy column:

• Min width = Default width
• Max width = Infinite  ∞

We specify a fixed column as follows:

• Greedy (<Default width>)

Shy columns

Shy columns are basically greedy columns but with a limit. Shy columns also “eat” extra space when it is available, but know when to stop, unlike greedy ones that keep eating forever. When a column is specified as shy, a max-width is defined. When the column reaches its max-width, it stops there, even if there’s more extra space available.

For a shy column:

• Min width = Default width
• Max width = The max-width specified for the column

We specify a fixed column as follows:

• Shy (<Default width>, <Max width>)

How it works

Let’s suppose a table is assembled. All columns are set to their default (minimal) width.

• If the window is narrower than the table, the table is kept at its minimal width. It means part of the table is hidden and a horizontal scroll is shown.
• If the table fits the window, the table is also kept at its default(minimal) width.
• If the window is wider than the table, extra space is available and the table can spread. The extra space is shared among the greedy and shy columns evenly or by predefined percentages. And when the allocated quota is more than the max of the shy column, the shy one stays at its max, in the meantime, the remaining quota can be shared among the greedy ones evenly again.

Let’s see a typical example.

This example mixes the 3 types of columns.

• Fixed columns
  • Checkboxes: 48
  • Longitude/Latitude: 124
• Shy columns
  • Asset ID: 158(176)
  • Status: 262(272)
  • Installation date: 150(166, due to title)
  • Commissioning date: 178(214, due to title)
  • We set Installation date and Commissioning date as shy columns because we would like to keep some buffer for the translation of the title when extra space is available.
• Greedy column
  • Street: 238(∞)

When window is narrower, table is still in default width and a horizontal scrollbar is shown.

When window is wider, table goes responsive following the predefined rules for each column.

What happened in the window is that

• Remaining width that could be shared: 1440-1282-48(margin)=110
• Numbers of the columns that would like to use the extra width: 5
• The widths that allocate to each column: 110/5=22
• Shy columns
  • Asset ID: 158+22=180 (>176, stay on 176)
  • Status: 262+22=284 (>272, stay on 272)
  • Installation date: 150+22=172 (>166, stay on 166)
  • Commissioning date: 178+22=200 (<214, should be 200)
• Greedy column
  • Street: 238+22+22(remaining width)=282

Therefore, for the shy columns, compare its max-width with the sum of its default width and the shared width.

• Default width+Shared width=New width, for shy columns,
• New width > Max width, stick to its Max width
• New width < Max width, apply New width.

Multi-line wrapping

There are cases where the content is long and important thus users would like to read the information without any truncation at any time. But you also don’t want to define super long default widths for these columns at the same time, because it would influence the reading for other information in the same table.

Therefore, multi-line wrapping comes into the picture. These columns still have a default width and could be defined as greedy or shy columns (usually they are greedy considering the content).

The difference is that the content can be wrapped in the column till it is shown completely. It means that the height of the rows can be different when there is a multi-line wrapping column in the table. The cell height of the multi-line wrapping column depends on the content and column width.

See 2 examples.

It is a requirement to see the message completely.

The translation could make Imported column long, so multi-line wrapping is involved.

Practical steps

Below are the main steps you might experience when you define the width of all columns in all tables in the app.

1. Get familiar with the content in order to set reasonable default widths and decide on the column types. Check the content, the properties (headers) and the values (rows). If it is possible, get a property value list.
2. Categorize all columns into 3 types regardless of which table they are in based on the understanding of the content from step 1. It is possible that some properties appear in different tables so it is also good to have the same default width for them.
3. Give a default width to each column and a max-width if it is a shy column. Check the width of the content in multi-languages, no need to be precise. German, Spanish and French are known languages that could make the translation longer.

4. The widths of all columns and the rules are specified now. Take a quick look at the values and try to summarize a bit for better management.

• Summarize the widths of the columns that are hard to predict. For instance, content from the columns like message, comment and description is user-generated. It is hard to estimate a default width, maybe they could have a same default width.
• Summarize the widths of the columns when the number is very close. For instance, if control gear ID and asset ID are both shy columns. The default width is 156 and 158 when you defined them. You know there is going to be max 10 digits for both of them. The difference could be from your rough check on the multi-language circumstances. In this case, there won’t be a big difference between 156 or 158. You could simply give them the same default width (158). It could reduce a bit of the complexity for us to manage the values.

5. Re-assemble the columns to the tables and check if it goes well in each table.

• Adjust the rules for different tables when it is necessary. One common scenario is that there are only shy and fixed columns in a table, and the window is wider enough that all the shy columns have reached to their max and still extra space is available. In this case, one/some of the shy column(s) can be defined as greedy type, particularly in this table. But it won’t change its type in other tables.
• Formulate scroll behavior (Some columns/rows have to be fixed when it is scrolling), multi-line wrapping rules for specific columns.

Marking default width and types in the design (optional)

Use some simple symbols or just text to mark the column widths and types. It is a reminder for yourself and other team members, and an easy way for better communication with the development team.

It is not required and you don’t have to use exactly the same way as suggested. It would be enough as long as the ones who are closely working with you could understand.

• Fixed (<Default width>)
• Shy (<Default width>, <Max width>)
• Greedy (<Default width>)
• “Due to title” means the value is just for reference. It is recommended for the developers to consider an auto width based on the width of the header for this column. Please check more details in Advanced improvements.

Best practice 

Though it seems there is quite a lot of manual work to define all column widths. There are rules and logic. And the result is satisfying.

Rules for some typical columns

Icon/Checkbox/Visual indicator/Avatar

The widths of these columns are known. They are usually fixed columns.

	Default width
	Pointer	Touch hybrid
Icon	40
Checkbox	48	52
Visual indicator	32/40
Avatar	60
Action	90	100

Digit/ID

The maximum number of digits is known. But the name of the column (header) is unknown.

• If the width of the digits is less than the header, it could be a fixed or shy column, applying auto width.
• Default width = Width of the header

• If the width of the digits is larger than the header, it is a fixed column.
• Default width = Width of the max numbers of the digits

• Metering point column: Header width < Width of the digits
• Other columns: Header width > Width of the digits

Time/Date

Time/Date are usually fixed columns. Depending on how many details have to be displayed, the widths could be different.

	Default width
	Pointer	Touch hybrid
Time+Date	228	252
Date only	118	148

Comments/Message/Description/Address/User role/Name

The width of the columns is hard to predict. They are usually greedy columns. Set a reasonable default width to them.

Reference width range: 200~400 dips

More examples in Interact products

Table – Group control commands

Table – Fault categories

Table – Project list

Table – Meters

Table – Gateways and groups

Table – Zones and standalone devices

Advanced improvements 

Auto width for headers

Considering the performance issue, it is impossible to have auto column width fully based on the content. But auto width just based on the headers is possible.

The idea is to leverage the width of the header as the width of the column. Because for those columns, the longest information is the header. In this way, those columns could make the best use of the space in multi-languages circumstances.

Therefore, if you are confident the column header will always be wider than the content, consider using auto width and mark it in the design spec.

In fact, those columns that are marked as “due to title” could be all considered auto width. “Due to title” is an indicator for the developers that they could use the header width as the column width. In this case, the developers even don’t need a default width. It could be 0. In the other words, the column type and the default width are just additional optional references. Because as long as there is content in the header, it makes sure the widths of the column. For instance,

• Shy (94, 100), due to title
• Fixed (90), due to title 

Shy, greedy, and the values are all just references when the developer doesn’t use auto width for the columns. If he/she has used auto width, he/she could ignore the defined values.

Percentages for shared width

The general idea is to give more extra space for some of the greedy columns than other greedy/shy columns.

For instance, a Name and an Address column are in the same table and they are both greedy. It could be predicted that the Address column needs more extra space than the Name column. In this case, it is worth setting the percentage for the shared space when it is given to these two columns.

Still in the initial case, table – Lamp types

When it is in an extra big window (window: 2560), what happened in the window is that

• First, there will be auto headers for Wattages and Max burning hours, so they will stay on their default width in English.
• Then set the percentage for the shy and greedy columns as 30%(Name), 10%(Lamp technology), 50%(Configuration ID), 10%(Interface type).
• Remaining width that could be shared: 2560-56(side panel)-48(margin)-1564=892
• Shy columns
  • Lamp technology: 188+892X0.1=277.2(>264, stay on 264)
  • Interface type: 136+892X0.1=225.2(>172, stay on 172)
  • Space remaining: (277.2-264)+(225.2-172)=66.4
• Greedy columns
  • Name: 322+892X0.3+33.2=622.8≈623
  • Configuration ID: 322+892X0.5+33.2=801

Column width manual control

When users hover between the headers, a divider and an indicator for manual column width control is shown so that they could drag the divider to control the column width as they want.

Once they start to drag, the predefined width and behavior of all columns in the table are broken, which means the width of the columns stays in their current width at first and will be fully controlled by the users afterward. Otherwise, there would be conflicts.

The columns are back to the predefined width and behavior when users refresh the page.

All the content within a column is displayed completely when users double click the divider between headers.

New minimum column width is introduced when the rules are broken.

	Min width
	Pointer	Touch hybrid
With carret	59	60
Text only	43	44

Density control

It is not required, usually introduced based on the requirement. 3 levels of density control is recommended.

Customizable table 

Users could choose what to display in a table manually. In these cases, the rules could also help us to display the information in a table well.

• When there are greedy columns in a table, all rules are kept, no extra effort needed.
• When there are only shy and fixed columns in a table, always make the last non-action column greedy to ensure any extra space will be filled.

Use case in Interact City

This is where the issue was initially raised. I worked very closely with the developer to do the experiment, check the values in the database, and made it work.

We did a sharing session among designers so that all designers in the Interact product team could understand the issue, the goal, and the way of doing it. Besides, they could see a live demo of the improved tables in Interact City.

Deck for the sharing session

Preparations

I attempted to understand the content first. This is where the initial idea came from. The content can be categorized into 5 categories. The logic/rules behind the width in each category are revealed.

Some of the column widths are unpredictable, they are usually user-generated content, like names and customized properties. Some are relatively predictable. Because we’ve already known most of the values, like status, properties, IDs, and time/dates. And fixed width is enough for the columns that only contain icons or avatars.

Columns were classified according to their width.

All default widths of the columns in Interact City are specified.

Examples of how the window size change has an impact on the tables

Examples

Non-greedy columns “project name” and “my role” take full advantage of the large screen.