Creating non-ugly SSRS reports #2: formatting tables
This is the second post in a new series on non-ugly SSRS reports. As I stated in the opening post:
SSRS doesn't have to be ugly
In part 1 (the use of typography & fonts), we focused on using typography (and avoiding borders) and some colors to get rid of the Office 2003-styling SSRS has by default. One of the first things we did was removing layout by borders in favor of layout by using typography. But how does this translate to styling tables and matrices?
Providing structure without borders
When you try to just bluntly remove the borders from your table or matrix and leave it that way, it's well visible that the borders had some function inside your table or matrix1. Although in some small tables the removal of borders gives a better view of the data and improves readability, in larger - and especially sparser - matrices, it definitely makes it harder to 'scan' a row or column of information:
So, is it a bad idea to remove borders from tables? Or just from sparse tables?
Although the top table is certainly easier to use, I'm not a fan using borders all around as a solution for easier scanning the table across rows and columns. IMHO there are better ways to improve the scan-ability of your table. Here are some guidelines (again, pick what you like, and leave the rest).
Providing structure to densely populated matrices
For densely populated 2 matrices, no extra guidelines are necessary. You can improve the readability as follows:
- Make sure the column header alignment is equal to the alignment of the contents of the column (in this case: make sure that 'September' is aligned right - just like the numbers below). This makes vertical scanning much easier.
- Add a visual 'connection' between the group header (in this case: '2007') and the subgroup headers (Jan-Dec.) by aligning the group header centrally and adding a line for all contents covered by the group. 3
- Increase the header row size somewhat, so the difference between headers and contents is visible through visual space.
- Set the VerticalAlign-property of the headers to 'middle' to create a neat layout 4
- If necessary, increase the row height of the contents too (this can make it even more easy for the reader to scan rows in a matrix, but makes it conversely somewhat harder to scan columns for deviations)
In the example below, I've added a line between the column headers and the column contents too. I don't think this is strictly necessary, but I like the structure it gives to the table (for example when using a 'Total' column. Still, less is often more - maybe I should try to find another solution such as more spacing between headers and content.
Providing structure to sparsely populated matrices
For sparsely populated matrices, do all the 'column tricks' mentioned for densely populated matrices, and add anything to guide in scanning rows more easily. More whitespace, lines between the rows, or altering background colors. In general, I find lines somewhat better suited for printed media - but that could be just me 🙂5
Some people like the effect of an altering row color combined with lines between. The trick is easy (pick a light rowcolor, and a slightly darker line between the rows) - the result looks like this:
Further improvements to tables - lessons of post #1
Just like in charts and other parts of your report, fonts matter. As I already mentioned in the previous post:
For table structures I tend to pick a somewhat smaller font, but leave the row size the same. This gives more room to display information, while maintaining readability and IMHO even improving design (more whitespace)
On top of that, I like to add a descriptive title to my table - and for the sake of uniformity inside my report, I tend to use the same title style in my table as I do in my charts:
Finally, I mentioned in the previous post the use of shades of grey instead of black for context. Well, same thing goes here too: the most important text are the numbers inside the matrix. Because this is the raison d'être of my table, I won't hesitate to use black here - especially not in a 'light' font like Segoe UI Light. All other context (title, categories, storenames, month names, year) needs to be a shade lighter. I'd say #888888 or #666666 - whatever suits you best. The lines, finally, are for providing structure to the months. Whatever shade the categories are, the lines need to be a shade lighter. Here are two ideas:
Whenever you're using 'heavier' fonts like Calibri, you'll often need 'lighter' colors. But more important is to keep in mind that:
- Black is the 'heaviest' shade of grey you can get (in terms of visual weight)
- Lighter colors give less visual weight (attract less attention)
- Use the order of visual weight according to the crucial importance of a fact inside a visualization
Ok, to summarize - what have we done to improve the way tables and matrices look in SSRS?
- We removed all borders
- We aligned the column headers with the column contents
- We added visual guides
- Between column headers and column contents
- a distinction using a thin line
- a distinction by increasing row height, setting VerticalAlign to 'middle' to maintain a neat layout
- Between column groups and group contents (using another thin line)
- Between column headers and column contents
- For our sparsely populated matrix we added visual guides to help the reader scan lines
- Added a title to our table / matrix in the way we add titles to charts to maintain visual consistency
- Changed fonts and font sizes (more modern font, smaller font size while maintaining the row height)
- Altered the colors of context and structure to lighter shades of grey
For a sparsely populated matrix, the result looks like this (click for full-size)
To be honest, in the picture above there's one other change: I've changed the formatting of monetary amounts. I'll leave you with this thought for today: Do you really need to display a precision of € 0,01?
Series: SSRS non-ugly