Anatomy of new form layout

* Few months ago we started experimenting with new form layout. The development is finished now and new layout is enabled in new applications by default. This post describes design decisions we’ve made during the development and the outcome. We’ll describe the migration plan for existing customers in the next post.

* In TeamDesk we call database tables record properties’ columns. Some databases call it fields. Here we’ll speak mostly about HTML layouts that consist of rows and columns. To avoid mixing up definitions we’ll refer to the content of HTML tables as rows and columns and to TeamDesk database columns as fields.

Traditionally TeamDesk used tables for forms. When we started developing the product in 2005 this was perhaps the only truly cross-browser way for making multi-column layouts.

Many things changed since then. Many web standards reached recommendation stage. Browser vendors switching to rapid development to support latest web specifications. Smartphones and tablets arose. We’ve added many nice features such as dynamic recalculations and form behaviors to TeamDesk.

In tables intersections of rows and columns form cells. In TeamDesk each field were occupying two cells: one for column label and another, next to the label, to display the value or provide an editor. The browser is responsible for the table layout, determining optimal size for each row and column, but the browser will never break a row if its content exceeds the screen width. This is good for tabular data, but in case of forms it is a big problem to render the layout for devices with narrow screens.

Suppose, you have the form laid out in four columns (two fields in a row, each field occupies two columns). Suppose we have long labels and wide-enough content, so each column does not exceed 320px.

This is what we had:

While, in theory, narrow screen can be detected and four columns could be broken in four rows (label above the value below, field after field), the browser will never do that:

This was the first problem to solve. Another was also caused by table layout. See, what’s wrong here?

Field 1 was hidden by either column access right or by form behavior. But, despite what you may expect Field 2 is not shifted to the left (or Field 3 is not shifted up.) In table layout hiding the cell is identical to hiding its content, the space occupied by the cell is not “freed.”

In addition to changed web landscape we had a number of various layout improvement ideas from our customers. So we decided to take on new form layout.

First of all, widely used browsers have decent support for latest cascading style sheet standard. From this standard, two things were of our interest: CSS floats to allow grid-like layout without sticking to tables; and CSS media queries to provide additional layout hints for smartphones and tablet devices. So we ended up with the following rules:

1. The form is divided into four equally sized virtual “columns”;
2. The width is always expressed in number of columns;
3. The field can occupy one to four virtual columns (Width1 – Width4). You can instruct the field to occupy new row (hard break), or to be displayed next to preceding field. If the total width of the fields in a row exceeds 4, the field exceeding the width will be displayed in a new row (soft break);
4. You can provide alternative label to a field;
5. You can specify whether to display the label to the left of the value or above it;
6. The field contained in the section. If there is no section defined explicitly we define unnamed one;
7. The width of the section is defined by the sum of fields’ widths in  row but does not exceed 4;
8. Sections are laid out the same way as columns.
9. You can apply behaviors to every form item including sections and text blocks.

Perhaps these rules need some explanations:

Why 4 columns? Customers asked us to have a possibility to define 3 fields in a row. Yet, 4 columns give more options to have a form look like  a grid: you can define 1×4 or 2×2 or 4×1, plus combinations of 3+1, 1+3, 2+1+1 1+2+1, 1+1+2. Below is an example of the form from Leads Management application laid out with new features:

Default layout is optimized to work well on a 1280px screen which we believe is a standard for most desktops and does not depend on browser’s standard support level. With sidebar hidden, it should work as well on a 1024px screen which is a standard for netbooks and tablet devices in a landscape mode.

For narrower screens we’ll provide additional layout hints. For example we can force the layout in two columns or always display label above to free more space to display the value. Yet, this is still the work in progress.

Hard and soft breaks start playing when fields and sections are dynamically shown and hidden. Hard breaks are always respected. Soft breaks are not: when you hide preceding field next field is shifted to the left. If there is enough of free space in a row we’ll try to fit the field from the next row. Preview button will give you an idea how the form will look like with various combinations of View/Edit modes, roles and behavior rules in effect.

Displaying the label above makes sense when you have either narrow section (Width1) to make more room for content or wide content by definition such as multiline text. We tried to experiment with some automated decisions, yet finally decided for default layout to leave it up to user’s consent.

But hey, tables are not gone! Some e-mail clients have limited HTML rendering capabilities, so in e-mail notifications we are still using tables to make sure our layout can be read correctly.