Solid tint in the grid system

Adolf Loos held that an Architect should be able to design everything “from the spoon to the city”. Some design principles transcend medium; as Massimo Vignelli said, “Design is one”. It is to these modernist masters that I prefer to look for guidance in my work on digital products. Their writing, often many decades old, is just as applicable in this digital age as it was when first written.

I encountered one such discussion recently in Joseph Müller-Brockmann’s Grid Systems in Graphic Design (1981):

A particularly knotty problem arises when a solid tint has to be printed in a grid containing text also aligned with the grid. In such a case the area of colour and the text have the same lateral boundaries. It follows, then, that the text would begin and end at the edge of the tinted area. The impression created is unsatisfactory.

This is a situation also encountered designing for a digital medium — color blocking, cards, and UI elements, to name a few. First I will examine the solutions in abstract, and then look at how they apply to form fields.

The first solution is to align the container with the grid, and add a margin to the content:

Here, the text appears ragged. The container aligns with the preceding text and the grid, but the content within has been arbitrarily indented.

The second is to align the content with the grid and bleed the container off the grid’s edge:

We now observe the opposite problem. Our text is well-aligned to the grid, but the container extends arbitrarily off the grid’s edge, or into a margin.

Neither solution is entirely satisfactory. The choice depends on whether one prefers the type area or the solid tint to align with the preceding and succeeding lines of text.

How might we solve this acceptably?

There is a third solution, which is to do away with the containing element altogether. Design by subtraction.

In Grid Systems, it is suggested that we may need to use such a colored container to add emphasis (i.e., color blocking). To extend this principle to another common digital use-case, we can look at form fields.

The most common approach on web is to align the field to the grid, and pad the field’s value (Solution 1). This is the default configuration on the ubiquitous Bootstrap CSS framework, and can be seen across the Facebook UI.

Facebook

This is likely an artifact of the way in which a browser renders the <input> HTML element by default. In code, the simplest solution is to pad the container, which can be achieved easily. The second, and especially the third solution, require a little more CSS. Google’s Material Design implementation (which we will look at below) for example, is particularly complex.

Solution 1 is also common on mobile (but decreasingly so, in favor of discarding the container entirely).

Headspace

I have created an example iOS login UI below to demonstrate the second solution, in which the container bleeds into the grid’s margin. This is particularly problematic on mobile due to generally smaller margins into which the container may bleed. This creates unwanted tension between the container and the edge of the device. It will also lead to problems when an element is positioned in the grid adjacent to a container that has extended into its neighbor’s margin (for example, if text were set in the two left-most columns adjacent to the ‘Sign Up’ button in the screen below).

The third, and preferred solution, allows us to avoid this problem altogether, by not using a containing element at all. This is the trend in recent years, and can be observed in most modern mobile apps — but is less common in web UIs.

A notable exception to this caveat on web is Google’s Material Design, which uses a consistent container-less approach to form fields on both web and mobile (with the exception of text areas).

Material Design Input

Apple’s Human Interface Guidelines follow a similar container-less convention.

iOS Input

As suggested above, the divergence between web and mobile is likely a function of historical precedent and a more advanced interaction model on mobile devices.

Airbnb, Slack, Twitter

This simple problem comes in many permutations; I looked at form fields above to focus on an exclusively digital domain and constrain discussion. It becomes compounded when we nest containers inside containers — which should generally be avoided.

With increasingly complex and dynamic interfaces, the ability to strictly adhere to a grid system can be difficult. In some cases, we must break the grid — and in others, it may be a symptom of overly complex design. Often, the solution to improving is removing.

Follow me on Twitter.