Designing Mobile Tables
Tables have an undeserved reputation for being evil and wrong in the digital environment. I saw this all happen, having coded my first Web page in 1995, and being a pretty heavy user of table based layout, since that’s all we had.
I have other thoughts on tables for layout, and dirty secret: lots of application frameworks are table based. Even listviews are pretty much just tables.
But like everything, the push for semantic web, et al has not just made table based layout a Mortal Sin, but has relegated tables to the dustbin. Woe be unto the designer who proposes a table. This is so bad, I see tabular data coded as not a table! Seriously, CSS floats to avoid using tables.
That’s nuts. Tabular data needs to be in tables. Tables are a good way to display dense information that needs to be scanned across, compared, monitored, or analyzed.
Mobiles Have Small Screens
Now, displaying dense tables on mobile, that’s a trick.
I generally ignore screen size in my design tips and other analysis. It rarely matters, and in many cases the rest of the capabilities (always on, connectivity, always present, intents, sensors, location…) more than make up for it. Hard to type on a phone? Who cares! You better use connectivity and sensors to avoid typing anyway.
But not for tables. They are really impacted by the small screen size, so we need to use all our powers of persuasion to cut down the data, display only what is needed, in the most readable way.
Responsive Tables are Neither of Those
The normal tricks to make tables into graphics, let them overflow, or the responsive table, which turns each row into a little list, are simply awful.
They are contemptuous of the user’s need to view information in a tabular format.
Tables need to be tables, with rows and columns of information that the user can scan. In the rest of this column, I’ll discuss some of the design concepts and tactics I use to make tables work on mobile devices.
Mobiles Table Design Tips
Show only what users really need and leave out data the user won’t need. It’s a battle, but fight for it, to make the table useful and usable, not just large.
Abbreviate, add icons, and remove repetition. Tables and databases are the most verbose things, for no good reason.
Remember that the table is part of a process, so use progressive disclosure. The table only needs to show enough for the current choice the user is making. They can see details later on.
If actions need to be performed, consider things like in Figure 3, little accordions that reveal the actions without taking more than one tiny icon of space.
Go to the style guide or design system, and use the smallest readable text size. Too big, and you’ll be removing margins and padding, and it will be less readable.
Use proper alignment. Left for anything that wraps, and the left column, center most things, right align the right column… usually. Top align all data! Never center or bottom align. Never. Just don’t.
Get away from responsive! Use adaptive, in concept if not in code, to modify the data displayed based on the device class. Here’s an example of how that would work for a weather app, from big screen to small:
Too much still? Cheat by adding virtual rows. See Figure 6. The alignment lets you have more “columns” than you can fit. This works. Readable, scannable.
Remove header rows, and labels with context. Often you already have it, as in Figure 2 but you can add it, as in the subtitle on Figure 7.
If you must, provide users the ability to sort, filter, and customize but never use those terms, and make sure the table loads in a way most people can use immediately. Never require them to pick fields or sort orders.
Get the details on these tips, from more about alignment to wording suggestions for sort and filter. Just read the whole article at UXmatters.
https://www.uxmatters.com/mt/archives/2020/07/designing-mobile-tables.php
Need Help With Your Design, or Design System?
I do that. Happy to chat vaguely, review, consult, or design (or redesign) your product. Just contact me.