Responsive DataTables through Card UI Design for Email
Trying to fit a datatable into an email is like trying to fit an elephant into a fridge — no matter how much you try, it ain’t gonna budge!
The question quickly becomes, do we really need this? (Which is actually a great question, because much of the time, we don’t.)
Can’t we just put it on a website and have users click through to it? No, don’t make me click more than I need to, and don’t make me think! And no, don’t put my sensitive information on your website — it’s in enough places already!
It got me thinking — does it really need to be in a table? Could we transform the table? Could we force it to display in portrait mode rather than landscape? Could we colour code it so that only the relevant information stands out?
The simple answer is that it doesn’t need to in a table at all. The data could go into a ‘card’ (a box) — something the web world has been using for years (keyphrase Card UI or CSS Card).
So instead of this difficult to read, unenjoyable drivel:
Why not a ‘card’ like this?
It effortlessly responds to a smaller screen,
and is easily repeatable for even dozens of rows (a new card per row).
It’s more readable
As it is now outside of a typical table, it’s far easier to apply graphical principles to group data. Hierarchy can be visualised.
Not all the data carries the same weight, so, we can allow users to scan the data quickly by emphasising the most important parts (according to your user research).
It’s more understandable
We can use concepts that people already hold in their minds (mental models) such as a timeline: from a service, to an invoice, to a payment. It’s immediately understood as a linear timeline of events.
I’ve also (attempted) to mirror what is typical of a calendar or date icon in presenting the dates, rather than just use straight text.
With invoices, instead of “number”, we can use “#”, if your audience commonly understands that. It’s simpler and quicker to understand than reading a full word.
It’s more accessible
Currently, the best way of achieving responsive datatables is by creating multiple tables and positioning them in such a way as to make them look like a single one on desktops (see my writeup ‘Bulletproof responsive datatables in HTML emails’).
But the best way forward is to achieve accessibility by default, rather than have to fix it up surgically, almost like an afterthought.
Cards are the best way of achieving accessibility by default for responsive datatables.
Better colour contrast
Many people are colour-blind, but everyone experiences forced low-contrast with a low battery, or sunshine glare.
To overcome these situations in a traditional table, you often have to increase the font-size of the data, which is exactly what you can’t do — not having enough space.
As a card, you have a lot more freedom to increase the sizing to something appropriate, and more elements can be visual.
There are many tools to check the contrast of your colours, such as WebAIM’s colour contrast checker: https://webaim.org/resources/contrastchecker/.
Better reading by smart speakers (e.g. Alexa), screen readers
Some people are blind and use screen readers, or have English as a second language and therefore can hear a lot better than read. Others of us are temporarily blind to the screen such as when we’re driving, or doing household chores and using a voice-controlled device (e.g. Amazon Alexa).
The traditional table is hardly the best-sounding in such situations: “Table with two rows and two columns. Row one column one, 7. Column two 19. Column three 19. Row two column one, Dec 17. Column two Dec 17. Column three Jan 18.”
Ideally we’d have it read the table as normal prose, like: “Serviced 7 Dec 17, Invoiced 19 Dec 17, Paid 19 Dec 17.”
This is easily done!
We can get rid of the table nonsense by adding the attribute “role” set to “presentation” (as opposed to a table or grid). (For non-email designers: in emails, tables still have to used to get consistent rendering across email clients.)
Then, we can structure the words and tables to get the desired flow.
This will read “Claim 0123456789 Serviced 6 Dec 17 Invoice #12345 18 Dec 17 $53.30 Paid 20 Dec 17 $53.30 Owing $0.00”.
It doesn’t require any extra markup (best for maintenance, and less technical people can update it). However, you may want to include basic punctuation such as some full-stops (these could be included in the same colour as the background).
If, for whatever reason, your layout can’t make this flow occur, you may need to associate the data manually with the headers and id attributes. I played around with this but couldn’t get Outlook’s “read aloud” or Internet Explorer’s accessibility reading to change based on this markup, as opposed to standard screen readers. So it’s risky to have to rely on custom data association because less sophisticated reading software may not use the extra accessibility markup you use.
Simpler on the mind
Some people are impaired permanently with learning difficulties, or are simply of a low IQ. Many are temporarily overloaded or impaired when they are distracted, tired, stressed, or attempt to multi-task.
In these situations, we want to make something complex as easy to understand as possible. I’ve already discussed using mental models to help by piggybacking off what’s already in our minds.
Simplify language.
Instead of ‘statement total’, we could use ‘what you owe’, or just ‘owing’. I think also in this example there might be relationship between the claim and what they call ‘service’. Maybe both can be called ‘claim’, or ‘service’?
In any case, what you present to your customers does not have to use the internal jargon your business uses. As a new employee, many people experience the pain of a steep learning curve in all the acronyms and technical terms of the business. Don’t put your customers through that!
Visualise anything you can.
Our minds can process images up to 60,000 times faster than text, so it’s worth visualising anything you are able. This similar to the concept of mental models, but much wider.
Instead of forcing people to try and recall what the data was in relation to, why not include a picture of it?
If the data includes a person’s name, can their picture be shown too?
If the data relates to a location, can the card be in that shape, or can there be an iconic picture of the city, or a map with a dot on it?
If the data has a timeline element, can you include a visualisation of the timeline, with relative distances to indicate time?
With traditional datatables any visualisation is almost impossible. But by using cards, it opens up the opportunity for much simpler presentation of data.
Other examples
Don’t get stuck on my example here. Google for “ui card examples” or similar. I’ve made a few others for inspiration:
Share allocations
Plenty of questions and pauses arise: There are in fact three dates, but I’m forced to think of today’s date, and I have to hunt for the other two. The date of purchase is also unclear. It could be better arranged as a timeline (it isn’t technically a card, but it follows the same principles):
The layout enables their reader to focus on the part they want, rather than having to process the entire table first. It clarifies when the shares are purchased.
Bills
The next table is in fact responsive, but it’s so bad it deserves better treatment:
I first thought this meant the total charge was $354.07, with the $103.05 having already been added to that total. In fact, there are two separate bills. Which payment does the ref number refer to? Is the due date therefore my new due date for the total? Don’t make me hunt down my previous bill!
Now each bill is clear, being a separate card. Also if the person wants to pay the total amount, they don’t have to add that up separately. It’s clear the overdue amount does not include the new charge. Finally, the payment references are clear, and unobtrusive.
Salary deductions
This is a lot of data to process in one go. It’s fairly clear, but on mobiles it’s not going to work well. But as cards …
It’s far easier to make each line as a new card. Now, any additional information can easily be added without cluttering the table (and there is potentially a lot that could be added). In fact we can fit so much in, I’ve restricted the width!
The code
Another solid benefit of using cards is there is nothing tricky about it. I’ve just used standard tables.
It’s worth memorising, though, how to centre-align tables-within-tables by this trick:
...
<td style="text-align: center;">
<table style="display: inline-block;">
...I’ve removed other styles that you might have there, just to focus on the relevant parts.
The full code of all of the above examples are on CodePen.
