Tables at Mobile resolution

Service Design
1

I’m looking for any insights anyone might have about table design on a mobile.

I did some very basic guerrilla testing before Christmas but had inconclusive results.

We have to possible designs we’re considering for tables at mobile resolution.

The first scrolls horizontally where the isn’t room for the content.

The second breaks the table up and stacks it.

http://nswdesignsystem.surge.sh/styles/tables/index.html

Does anyone have any insights in this area?

Thanks
Mike

2

These are the tables our dev team have worked on. They do not stack, they shrink on mobile. I am not aware of any testing research produced for tables i will check and get back.

3

Thanks Nesan, they’re very similar to our non-collapsing ones, only ours scroll…

Let me know if you get anything back on testing results.

Thanks
Mike

4

tables are tricky. they depend on the information you want to display inside them.

simple information = stacking is best from accessibility standpoint as the reader can orient the header with the column and row number and helps the user to easily digest the information on smaller screens

complex data sets = stacking becomes problematic and confusing for screen readers to orient the user and scrolling can be a better experience as it allows for a greater contextual understanding of the data.

I am not sure we can have a one size fits all approach to tables. Sorry i don’t have the research to back it up as it was from a previous position.

5

Thanks @danwaters

Sounds like a good position to take…

6

Hi @tjharrop,

we’re starting to use tables more often on nsw.gov.au and were hoping to improve the way they work responsively. Currently the columns squish up to a certain point and then start to scroll horizontally. Our accessibility expert @Charissa has advised that horizontal scrolling isn’t the most accessible option for tables on mobiles.

In the design system documentation, it mentions a “Stacked mobile version” of a table, but it doesn’t seem to work. I assume it should stack like this one from VIC gov - https://www.dhhs.vic.gov.au/case-locations-and-outbreaks-covid-19 Am I missing something?

I’ve done some research and have come up with some suggestions to improve tables.

Recommendations

  • Squish - for small tables with short data

    • works well for short data e.g. numbers and single words.
    • limit of 4 columns.
    • works well for many rows.

  • Collapse rows (stacked) - for large tables with long data

    • works well for long data e.g. sentences or paragraphs of text.
    • works well for many columns.

Additional recommendations

  • Use progressive disclosure - There is usually no reason for everything to be in a table. Give the user enough information to make a decision and provide additional details on another page.
  • Left align data in the first row item and any long text that might ever wrap.
  • Centre align data in the other columns.
  • Right align data in the right column if a table is more like a list, with a single key value on the right.
  • Always vertically align data to the top
  • Don’t use borders on columns
  • Don’t use striped backgrounds for rows
  • Use ‘small text’ (14px) if needed to save space
  • Label only what you must to save space - obvious data doesn’t need a label.
  • Use only the default table style from the design system (suggest removing the other styles - http://nswdesignsystem.surge.sh/styles/tables/index.html )
    • Don’t use borders on columns or striped backgrounds for rows as it adds unnecessary visual clutter and encloses spaces between pieces of content.
  • Suggest adding sort and filter functionality to suitable tables in the future.

Thanks

7

Hey @adham

These sound like some great improvements. The stacked tables is referenced in the JS, but I can’t see a working example. As for approach is seems like the best option, we’d be really keen to include that in the DDS if you’re taking that approach.

I’ll go ahead and add your recommendations for short/long data now, this is the kind of guidance it’s great to share widely.

For the additional recommendations, is the visual style to keep a border on each row (well, between) and remove the alternate shading, and columns aren’t visually separated (except for the obvious - content alignment).

Really liking the progressive disclosure bit, great way to articulate it.

8

Thanks @tjharrop , are you able to find an example of a working version of the “stacked mobile version” as I’m unable to replicate this functionality?

Regarding the additional feedback, I’m suggesting that we only use the “default” table styling and remove the “striped” and “Bordered” options for simplicity and to match best practices.

9

Hi @adham - Ken came up with a bit of code to make this work on nsw.gov.au. I think this is what @tjharrop means? It also uses the striped format.

image
image436×882 41.4 KB

10

Thanks for sharing @jennifer.weiley . Good to see the stacking table in action, although it’s not necessary for that 2 column example. Stacking the cells in a single column makes them unaccessible as the labels aren’t repeated down the page. VIC gov has an accessible stacked version that responds down to 2 columns. I think ours should do the same e.g. https://www.dhhs.vic.gov.au/case-locations-and-outbreaks-covid-19

11

Hey @tjharrop @amy.howard , is there an example of a stacked table on mobile yet? Does the DDS support this functionality? e.g. https://www.dhhs.vic.gov.au/case-locations-and-outbreaks-covid-19

We’re looking to implement something similar. Thanks.

12

Hey @adham no unfortunately the DDS does not feature a stacked table as yet. If you’re developing one we’d be keen to work with you to build it into the Design System.