In the past, I've written about learning that sometimes the best way to show information is in a simple graph, for example a basic bar graph of total change instead of a line graph over time. As a co-worker gently encouraged me recently, we can take this further; sometimes the simplest and most accessible form of information is in the form of a plain table of text or sometime similar to it (eg, as a list).

(The specific situation that prompted this was wanting a simple, easy to read dashboard of ZFS filesystems and pools that are currently more or less full up to their quota limit, especially ones that have recently filled up, because sometimes this causes our fileservers to become upset. We sort of had this information in our existing Grafana dashboards, but a lot of it was in line and bar graphs and so was not the easiest thing to glance at in the heat of the moment.)

I won't say that text is always the simplest and best version of information, because I think it depends on what you want out of it. If you want to clearly read what is essentially textual information, such as the names of full filesystems, then the text format is going to win; even if the information is there in a graph, it's there in labels or things you have to hover over, not the primary visual elements (the lines or bars or points). On the other hand, I think that our bar graphs make it easier to compare the magnitude of things than seeing the same values in text. It's very easy to eyeball a bar graph and see 'that is much bigger than that'; doing the same thing with numbers requires reading the numbers and perhaps interpreting the units (if, for example, we are being helpful by using 'Mbytes' for small numbers and 'Gbytes' for large ones, and so on).

(But if you want to know relatively precisely how much bigger, text is likely to be better. Human beings are good at telling 'smaller' and 'larger', but we are relatively bad at precise measurements of how much. For that matter, there are optical illusions that can fool us on smaller and larger, but hopefully you aren't putting optical illusions in your dashboards.)

The corollary of this is that at some point, I should think about what my dashboards want to say and what information people will want to get from them. I'm not going to say that I should design all of this up front, because right now I don't know enough about what sort of information is even going to be useful to us to do that, but at some point in the design of any particular dashboard I should switch from exploring possibilities to boiling it down to a focused version that's intended for other people.

(If there are elements of an experimental dashboard that are pulling in different directions about what they want to be, I can always make two (or more) production dashboards. Unfortunately Grafana doesn't make this very easy; it's hard to clone dashboards or copy dashboard elements from dashboard to dashboard.)