๐Ÿ“Š
Public Data Visualization Guide
  • Data visualization standards for SF.gov
  • Why do this?
    • Now you try!
  • Thoughtful design
  • Accessibility
    • Some basics
    • Color
    • Formatting Data Visualizations
    • Formatting tables
    • Alt Text
  • Mobile view
  • More resources
  • Analyst checklist
  • Using the Power BI template: A step-by-step guide
  • Data management
  • Webpage content for data pages
  • Publishing Power BI dashboards to SF.gov
  • Resources and links
  • Gallery of dashboard transformations
Powered by GitBook
On this page
  • No cells should be blank.
  • Sort tables by importance to your users.
  • Structure your table intuitively.
  • In general, donโ€™t use data bars.

Was this helpful?

Export as PDF
  1. Accessibility

Formatting tables

Tables are included in all dashboards to enable users have more than one way to access data. Format your tables with the user in mind, making all data easy to access and understand.

PreviousFormatting Data VisualizationsNextAlt Text

Last updated 3 years ago

Was this helpful?

No cells should be blank.

They should have a 0 or explain they are missing. Blank cells are confusing and unclear.

Power BI tip: To force a zero to appear add a โ€œ+ 0โ€ to your measure. Sum of Sales = Sum(Sales[SalesAmt]) + 0

Sort tables by importance to your users.

This may vary based on your data. For tables showing data over time (so each row is a date or month), sort the table to have the newest or most recent values at the top. Recent data is likely most relevant for your users.

A table below a map should be sorted by the measure or variable that is shown in the map. For example, a table below a choropleth map showing population density should sort the table by population density.

Structure your table intuitively.

If your table includes dates, they should always be rows (each date is a row). In many cases, your table will match your cleaned data structure.

While โ€œwideโ€ data can be more intuitive for users, sometimes a wide table is difficult to use. Therefore, long data is acceptable if the wide table doesn't fit within the template. For example, while this wide table of data by race may be intuitive, the long version is also acceptable because the wide format may not fit on most dashboards.

A wide table with each row as a date and each column as a different race or ethnicity category.

In general, donโ€™t use data bars.

Data bars within tables are typically difficult to ensure visibility for most users.

A long table with each row being a month and race category combination. While less intuitive, this may be necessary because of space limitations.

If you do implement data bars, you will need to to ensure that the bar contrasts sufficiently with the background, and the data label contrasts sufficiently with the bar. This is difficult to do well.

check the color contrast
๐Ÿ“Œ