Moving your content online may require thinking out of the box.

Months ago, a client contacted us at Outer Labs about moving some comparison charts from a slide deck to product detail pages on their website.

“No worries!” I thought. We had already built a standard React app on the Google Cloud Platform with Contentful as the content management system. The CMS allowed our client to easily author their own content while we handled the complexity of writing software to browse, search and access the content. Adding a table felt like it might only be an incremental improvement.

It should’ve been a piece of cake.

It wasn’t.

Contentful doesn’t support authoring of tables out of the box. It supports normal text fields, checkboxes, rich text fields, and several other intuitive components that make it easy for content authors to use. It’s also amazing to work with as a developer since the data comes back as a simple JSON blob.

For custom components, like an embedded YouTube video, there are SDKs for UI extensions that improve native functionality. With no native support or SDKs for tables, we needed a workaround or we’d have to build a custom UI extension.

I first looked to see who else had tried building tables into Contentful. It turned out Contentful itself, had. I had hopes we could build off of what they’d created, but upon digging into it further, I realized it was too simple for our needs. Contentful could support simple text fields, but our clients expected more features for their tables than just text. They needed the ability to create any kind of table:

• With and without formatting, like bold and italics.
• With and without images.
• With and without headers and sub-headers.
• With and without bulleted lists.
• Without a standard width or number of columns.

Realizing that the tooling wasn’t already out there, we settled on building our own UI extensions. We decided to split up the tables into two types:

1. Data tables that were heavy in numbers.
2. Rich text tables that were heavy in text.

The Initial Table Solutions

1. Data tables

First, we built a table optimized for simple data-heavy content like the diagram above, and named it the data table. This table didn’t contain paragraphs and was mostly composed of numbers. It had no formatting, no bulleted lists, and no images. It was pretty simple to build.

We built a UI extension for our client to upload a CSV version of their Google Sheet and show a preview of their table within Contentful. In the frontend, we rendered it to conform to the site’s styles and layout. The result was easy to use for content authors and easy to edit!

To handle tables with more formatting and text, we built a rich text table. The Contentful rich text field could handle the bolds, italics, images, headers, and bulleted lists. We built this extension linking multiple rich text entries to simulate the idea of columns and rows. It worked — but came with some other difficulties. It limited the author to three columns, and it was tedious to open up each rich text field and enter in the data.

As we ran with these first two solutions, our client was able to migrate most of their tables. However, we started coming across data tables that needed the option to add images and formatting.

There was too much text to fit inside of a data table, and some of the bulleted lists and links were not supported. But it also contained too many columns for the rich text table. How could we support complex data without constraining the columns?

What I slowly came to realize after working on these first two solutions was that the problem was not about building tables. It was a layout problem. And this layout problem has been around since the early days of the web.

The Layout Evolution

To discuss this layout problem, I need to give a bit of background.

I first started learning how to build websites from blogs like Xanga and the virtual pets site, Neopets. Sites back then were built more simply, and peeking under the hood was as simple as looking at the source HTML and CSS. So it was far less daunting than the Javascript-heavy pages of today. Through inspecting my favorite websites, I learned it was popular to structure pages with a header, a main area for content and a sidebar listing links to other pages using the HTML <table>element. To use the Xanga example, there’d be a table of blog posts and each blog post would then contain a sub table of content. Because tables are built with spacing already, the blog posts would be neatly arranged by default with the latest blog at the top and the oldest at the bottom. Each blog’s content would also look consistent because they were each organizing their content into a subtable. The <table> provided automatic spacing, fit content neatly into cells, and the browser took care of positioning and aligning.

While writing this article, I became curious why people used <table> elements in the first place. As it turns out, when <table> elements were introduced with HTML3.2 in 1997, the standards recommended them “for layout purposes.” It’s possible this is why tables were so commonly used for layouts instead of the <div> elements we use today.

Using tables for layout is the same thing our clients were doing in their slides. They solved their information layout problems with tables. Their data wasn’t necessarily tabular, but it was neatly organized where anyone could easily tell each cell was related to the one nested directly above and below it.

Google Docs and Slides have a tool for creating tables, and when I need to quickly compare some ideas, it’s always been easy to reach for that table tool to create a few rows and columns and insert what I have to say. The automatic spacing that tables provide also makes it easy to differentiate where one grouping begins and another ends without much work from the author. Our clients were using tables for layout purposes like the developers of earlier web days.

From Tables to Grids

Developers now know not to build layouts with <table>elements. They have problems with accessibility, are harder for developer maintenance, and they don’t reflow easily for different sized screens like mobile phones, tablets and desktops. To this day, the MDN web docs still warn us not to use tables for layout.

Modern web has replaced tables by creating grids from <div>elements and the massively popular CSS rule, flexbox. Responsive websites, a design that would really show the limitations of tables, became a thing in 2010 and showed us how powerful a flexible layout can be in supporting different screens and devices. These new techniques combined to achieve a table-like look, in the sense that there are vertical columns and rows with spacing in between, but they aren’t a table in that the number of rows and columns is flexible and the data they hold is not tabular.

By far the most flexible final solution we came up with was to ignore tabular layouts in favor of a grid. This helped fit the content within the web page, but also gave our authors the power to easily change the number of items per row while keeping the fidelity of the content consistent. In the end, it became a choice of which content was actually a table and which required a more flexible grid.

Getting Creative from the Architectural Space

From working as a software engineer in the architecture, engineering, and construction (AEC) industry, I’ve learned that we need to be more creative about our solutions. In the tech industry we’re working with the latest tools and software as well as the latest in web design. Much of it now hashed and rehashed over decades.

Generally when people want a feature, they can say exactly what they want and refer to examples of other beautifully designed sites. In the AEC space, we don’t always have that luxury because we’re pioneering products and solutions that were never designed to be online. More-often-than-not, we’re bridging wider gaps. The more we can assist our clients in making the transition from documents to interactive interfaces, the better we’re able to build a beautiful product that fits their needs and reaches the intended audience.

Monica Tie is a Senior Software Engineer at Outer Labs, specializing in frontend web technology. If you work in the AEC space and are interested in modern software solutions for your design and build projects, contact us at info@outerlabs.io

‍