Graphic design notes for BS charts

Introduction

This page illustrates various design ideas and issues connected with presenting charts of Bright Sunshine (calculated from global solar intensity data) as web page images. There are various - sometimes overlapping - points discussed here so a reading of the whole page would be useful to gain an overview of the topic. Note that these ideas originate specifically using data from the Davis Weatherlink package, but the principles should be generally applicable.

Standard chart features

There are a set of features that probably deserve to apply to every BS chart whatever its other design variations. These are listed below and an example of the current standard chart shown to the right:
  • Size roughly around 500px square, but discussed in detail elsewhere;
  • Time-span covering approx 05:00 to 21:00 in local clock time, which should be satisfactory for locations up to 55-60° latitude;
  • Time-span shown to remain unchanged throughout the year for consistency even though winter readings will only occupy the central part of the chart;
  • An envelope shown on the chart showing the daily time-course of the maximum calculated intensity under perfect conditions;
  • Areas under the envelope shortly after sunrise and before sunset showing times excluded from BS totals for compatibility with CS measurements;
  • A line or envelope showing the changing threshold for the intensity level to count towards the BS total;
  • The set of actual measured intensity values, colour-coded according to whether an individual value classifies as BS or not. Alternative depictions of this dataset are discussed below;
  • If possible, markers or shading on the chart indicating times when a view of the sun is obstructed at the observing site because of obstacles - trees, buildings etc. (Not implemented on the current example.)
  • Text showing sunrise/sunset times and BS total so far today;
  • An informative chart key;

For many implementations, it would be nice to have the chart updating automatically throughout each day, when we would suggest one further standard feature:

  • A small but legible timestamp showing creation time of the current chart image;

 

Chart size and archive interval

If we make the assumption that we wish to plot and to designate as BS or not every measured solar intensity value (>0) then this places some important constraints on chart size, with the degree of constraint depending on the archive interval.

For a 1-minute interval (the shortest currently available) then in midsummer we're going to have around 16 hours worth of data or 960 data points. (Even if you trim the chart to cover fewer daylight hours away from midsummer you still have to deal with midsummer as the limiting case.) It's clearly impossible to show every data point with <1 pixel per point so this immediately means that the X-axis of the chart would need to be 960px wide as a minimum. And in practice and leaving aside issues around the use of large chart images, the chart could not be fitted width-wise in the window of a 1024px wide display without requiring a horizontal scroll bar (= bad web design practice). Possibly the maximum hours shown could be trimmed so that the chart would just fit into a 1024 display window but it would be touch and go with possibly an inelegant result. And in order to depict individual data points as BS or not, the chart would need to be drawn as a bar chart with 1px-wide bars, which again might not be aesthetically appealing. But we'll try to create a chart to this model in the near future for reference.

Once the archive interval moves to 5 or 10 minutes the charting task becomes somewhat simpler, because the number of data points to be plotted reduces to ~96 (10min) or ~192 (5min). So in principle the graph could be as narrow as 96px though, as argued elsewhere, tiny graphs are not very effective at communicating information - better to find ways of minimising the number of graphs required or laying them out on a tabbed layout and then use larger chart images.

We're currently working with a 10-minute interval and if we accept use of a chart approaching 500px in width (so that eg 2 can be fitted side-by-side in a 1024px  window) then this allows us to use bars 4px wide (actually 2px of colour with 1px black border either side of the bar), which gives quite a good effect. Dispensing with the border would obviously allow the bar width to be reduced to 2px, allowing a chart width of ~250px, but at the cost of limiting the clarity of an individual data point because the body of adjacent bars merges into one.. (Some of these design options will be discussed and illustrated in the next section in due course.)

Moving to a 5-minute interval obviously doubles the number of data points and means that even with borderless 2px-wide bars we need a chart 450px wide. Using the current 4px-wide bars (including a border) would require an increase in chart width to ~800-900px, which may or may not be acceptable.

Height of the chart is more flexible, but a chart might typically be either roughly square or with a height 60-75% of the width.

Single bars vs stacked bars vs other options

There is more than one option as to how colour coding of the bars reflects intensity or BS status:

The next example shows a stacked bar prototype using 5 colour categories. There's obviously a decision to be made on the number and bounds of the intensity bands. Too many bands/colours would probably confuse rather than clarify and so we'll settle on five bands . However, these don't need to reflect equal differences in intensity. Once the sky starts to clear then the relative intensity increases quickly and so we probably only need two bands above the BS threshold: bright and very bright. But it's probably true that there are subjectively more bands below the BS threshold, eg cloud-bright, overcast and very dull. Choosing colours to best represent these different bands is more of an artistic skill and only an initial stab at this is shown here.

Other features that could be changed or added: