Originally, we assumed the values for the connecting lines to be
whatever the last value was.
For instance, in the little graph below, the 2 bars following the
first bar had averages of 600 just like the first bar. However, we
don't actually know what the value of missing data bars is so making
the assuming that is some value seemed dangerous. The least
dangerous thing to do was to assume zero for values that we don't
actually know.
Assuming 0 arbitrarily is just as "dangerous" (maybe call it
"erroneous" or "misleading" - dangerous sounds like someone is going
to get hurt :-). People looking at the graphs are seeing the graphs bouncing thus could
think the behavior of the metric is erratic when it could very well be very static and
flat. For example, the CPU graph: it will look like the % load goes down to 0 periodically
which is NOT a good thing to present (the CPU in all probability is being used more than
0% the majority of the time - yet, our graphs are showing 0% a lot of the time.). So if a
machine is, in reality, constantly at 100% usage (something the user should know), we will
only be showing periodic spikes to 100% but also periodically showing 0% - giving the user
the idea that at least some times the CPU is being unused.
The CPU thing is just an example - but this is a problem in general. The line showing a
downward slope to 0 and upward slope from 0 is just wrong - the data might NEVER have
trended that way for all we know.
Its a line graph - everyone knows a line graph doesn't show exact/known values on
every pixel/point along the line. It shows an approximation - but the end points should be
known values. We should connect only known values to only known values.
If we can't, then we shouldn't show the line at all - it is misleading and its
visualization of the data is virtually always wrong.