As Andrew Coyle points out in his beautifully crafted article Design better data tables — The ingredients of a successful data table UI data, is becoming one of the most important commodities of the twentieth century. Century-old industries like, the wool industry of Australia, are rebuilding and innovating around the organization of their data. All of this data is pretty useless without the ability to visualize, derive insights and take informed action. Data organization and availability is not enough — successful companies in the future will combine data with intuitive experiences to help users understand more from their data.
We recently started rebuilding AWH (Australian Wool Handlers) Auction software. We learned a hell of a lot about the wool industry — including The price of wool varies hugely and is determined by a large number of factors — all of this data needs to be visualized and processed rapidly. Buyers needed to scan, compare and analyze all of this information.
Enter data tables.
Here are some of my learnings around data table best practices.
“A well-designed table can still be a thing of beauty but with the form following the function. Tables are not pictures of data: they are catalogues of data to be perused, parsed, referenced and interrogated.” — Richard Rutter
The software we were building needed to display a complex and figure dense set of information, in a clear, concise, easily digestible format. So first off I started looking at the basics around typography. Richard Rutters article: Web Typography: Designing Tables to be Read, Not Looked At is a great resource. Here is my summary of some of the fundamentals he goes through:
Don’t Stretch tables
Resist the urge to stretch your tables to full width. Stretching tables to full-width causes unnecessary spaces between columns, often resulting in data seeming lost or isolated.
Stretching tables may look better aesthetically, but will only make it harder for the viewer to read and digest information.
Keep it simple
Get rid of everything that isn’t data or white space. Avoid borders or frames and save any highlights tints or bolding until you have a clear readable table using a single typeface and alignment. Only go on to use borders if data alignment, spacing and grouping are not enough.
“Tables should not be set to look like nets with every number enclosed. Try to do without rules altogether. They should be used only when they are absolutely necessary. Vertical rules are needed only when the space between columns is so narrow that mistakes will occur in reading without rules. Tables without vertical rules look better. Thin rules are better than thick ones.” — Jan Tschichold
The guys at Dark Horse Analytics did a great example of illustrating a lot of these principles:
Design structures, interaction patterns
In Design better data tables — The ingredients of a successful data table UI , Andrew Coyle goes through best practices, UI patterns, and techniques with animated examples. This article really is a must if you are designing any kind of data table UI. The animations are incredibly easy to digest and put into practice after a very quick read.
- Fixed Headers
- Horizontal Scroll
- Resizable Columns
- Row Style
- Display Density
- Visual Table Summary
- Hover Actions
- Inline Editing
- Expandable Rows
- Quick View, Modals and Multi Modals
- Searchable Columns
Our work for AWH was a bit more on the enterprise spectrum. Users needed to input and edit fields and take actions where applicable. Designing better tables for enterprise applications by Adhithya gave a lot of good insight.
It may seem obvious, but placing your actions all the way over to the right-hand side of the table is not as optimal as it would seem at first glance. Users are forced to scan all the way across the page to locate the relevant action to take, the furthest distance from the identifying column. When you are dealing with hundreds or thousands of rows, scanning across columns will become very tiresome very quickly and could often lead to your users accidentally clicking on the row above or below.
Another common issue is around the repetitiveness of actions. This adds a lot of unnecessary clutter, especially when there is more than one actionable required. An ellipsis or verticle ellipsis menu is a great compact alternative and keeps visual noise to a minimum.
Above, the delete action is repeated in each row. Below, an ellipsis menu is used to reduce visual clutter and redundancy.
Filters and Search
Often, because of sheer volume, good search and filters are a must. Once these mechanisms are in place it will reduce the requirement of paginating significantly.
Adhithyas points out that a method proven to achieve this outcome is providing filters in the context of the user’s workflow on the current screen. Essentially, filters are the most relevant options to the current context and scenario. It does require a bit more of an in-depth understanding of your use case, so make sure to do your research — but if done well it can really take your usability to the next level.
These were just a few of the data table nuggets that stood out to me off the bat. There are a lot more resources out there that I still need to digest. I’m really looking forward to learning more about tables — and improving our enterprise solution with AWH and will update these with outcomes, findings, and iterations as we go on.
Please feel free to share any data table UI resources you may have come across :)