Tables Guidance
Over the past decade, medium and small screens have become an extremely popular (and for millions, primary) mode of consumption for Internet content. This has led to a dramatic rethinking of both, the design and the delivery of information. One obvious area affected by the proliferation of small viewports on devices is tabular data.
Recommendations
Keeping in mind that our goal is to make data readable and digestible by the user on all devices, here are our recommendations for tables:
- If the content is not truly tabular in nature, don’t put it in a table.
- If you feel strongly that the content would be served well by a table, author it that way and preview the document. If it doesn’t look good, find another way to present the data.
Examples
Hyper-V Deployment Requirements
We recommend that this kind of content not be in a table as it is not tabular in nature. Each row is a small section of content that can be laid out more simply. Here is our recommended way of laying out this content.
System Center Data Sources
We recommend splitting up “tables within tables” into multiple simpler tables, which makes the content easier to consume. Here is our recommend way of laying out his content.
Turning Network Monitoring
These tables are really hard to read. It brings to question whether the tables should have been pivoted by Type instead of by Rule, but we don’t know the user scenario well enough to say for sure. Either way, since bulleted lists are not supported in GitHub Flavored Markdown tables (for good reasons), we’d suggest collapsing the bullet lists into comma-separated lists as a first step.
This leaves us with this. As you can see, the second table looks fine but the first table is still hard to read. The browser is automatically laying out the table, and it doesn’t look good when the data in the table columns aren’t well balanced.
This demonstrates the limitations of HTML tables, and why authors should use them carefully.