WeaVER Design Overview
Domain Characterization
These were the early versions of our data and task abstractions upon which much of our early prototyping was based. Throughout the prototyping process, these characterizations were updated and refined to what we presented in our paper. Including the early versions here is important, however, to provide context to certain aspects of our design process.
This was an early formulation of our data abstraction. The elements shown here did not change significantly over the course of our design process, though we did add to this abstraction. |
 |
This graphic contains the early characterization of the workflows of our collaborators in wildfire emergency management. Notably, this contains a feature we were initially interested in including, but wound up abandoning. Our collaborators were interested in being able to view past forecasts to determine what changed and how those developments did or did not match their expectations. To this end we initially developed the idea of including an integrated way to track features and issues across developing forecasts. Users would be able to set watchpoints on given field and time and be able to track changes over various model runs. The notion of watchpoints were abandoned early in the digital prototyping phase due to the data scope being too far beyond what we were prepared to handle. That said, you will see watchpoints mentioned extensively in our early design iterations. |
 |
Sketch-Based Parallel Prototyping
As described in the paper, after our initial domain characterization was complete, we moved on to a prototyping phase that began with internal parallel prototyping. This is an overview of that stage of the process.
The following sketches represent the various ideas and configurations explored during at the beginning of our parallel prototyping session. We apologize for the fact that these are hard to read; they were created using blue pencil and this is the clearest we could get the scans. |
  |
These sketches contain various ideas on how to deal with low-level design elements: how fields would be specified, how users might specify different encodings, change iso-values, etc. |
  |
The following two images show our two initial fleshed out parallel designs. The general look and feel of WeaVER was derived heavily from the first design, though the second includes certain ideas, such as tabs, which were also integrated into our paper prototype. |
 |
 |
Paper Prototype
The design ideas from our parallel prototyping session were evaluated, fleshed out, and integrated into the following paper prototype which was presented to our collaborators for feedback. This paper prototype for the application includes several elements which were later abandoned when we realized that data and processing requirements were well beyond that of the consumer desktops available to our collaborators. These elements include the aforementioned watchpoints, along with the ability to swap out and historically view changes between forecast runs; a single integrated query library, which handled the all data derivations in a single interface and provided users the ability to interactively change the data derivations; and the ability to switch between overlays and a quad-view based on user preference. The question of how to encode the various different queries eventually lead us to the notion of informed defaults presented in the paper. While direct support for inter-forecast comparisons was eventually abandoned, our collaborator’s feedback regarding the general idea of enabling better direct comparisons is what lead to our work on enabling direct comparisons of multiple features across an ensemble.
The main view. |
 |
 |
Various iterations on a historical view for comparing data across forecast runs. The first is based on a notion of cover-flow and allows users to evaluate general changes across a series of runs. The second would allow users to compare two runs side by side. The third design would allow the user to switch back and forth between either of the runs along with the difference between those runs. |
 |
 |
 |
An illustration of a drag-drop mechanism for building various queries. The notion of a unified query library was eventually abandoned due to developments in our understanding of the data and task abstractions. Additionally, because much of what is illustrated here requires significant data processing, we eventually integrated certain aspects of this into our preprocessing routines. |
 |
 |
 |
 |
Digital Prototypes
Based on the feedback that we received on our paper prototype, we pivoted our designs toward the notions of informed defaults and directly visualizing multiple features across ensembles. We developed separate digital prototypes for both these ideas. Here we include 2 iterations or each – an early version, and a late version. We are making runnable demos containing both source code and data available; they can be found in the “demos” folder included as part of this archive.
The demos are standalone Processing sketch archives. To run, first ensure Processing 2.2.1 is installed. The code may still run in other versions of Processing, but there are no guarantees. Download and unpack the archive for the demo you are interested in. Open the unarchived sketch folder in Processing, and hit the play button in the upper left hand corner of the Processing window.
An early test of the drag-drop encoding mechanism with early iterations of informed default conventions for temperature and relative humidity. |
 |
Archive: dragdrop.tgz |
A simplified demo of the prototype interface eventually presented to our collaborators. The demo includes a full data run for temperature. |
 |
Archive: dualdemo.tgz |
Ensembles of Features
An early iteration of interactive spaghetti plots. Providing users with interactive sliders was a part our original design that we eventually backed off of. This was due to the fact that we could not replicate the behavior for the interactive contour box plots; we were unable to generate the contour box plots at interactive rates on consumer hardware. |
 |
Archive: spagplot.tgz |
The final prototype for interactive spaghetti plots and interactive contour box plots, which we presented to collaborators. |
 |
Archive: iSP.tgz |
Color Map Development
In the paper we mention the fact that we hand-tweaked our color maps. Here, we explain what exactly we did and why. Our choice to use HSV space means that changing hue and saturation still have an effect on the luminance output. This is what we attempted to account for in hand-tweaking our color maps. In each of the following images the procedurally generated map is on the left and the hand-tweaked map is on the right. Upon cursory examination the color maps look very similar, but difference become more evident as one looks at the underlying luminance. We have included the corresponding luminance map next to each color map in order to help illustrate this point. As a note to the reader, we have left the categorical Haines index color map out of this discussion intentionally, as it was initially designed by hand.
Temperature |
 |
Note the luminance differences at the low end of the scale. The new color map (right side) has been tweaked to increase visual separation of the bottom three blues. |
MNSD |
 |
The new color map (right side) was tweaked to create more pronounced luminance differences at several positions. The most pronounced examples are between the second and third darkest colors and the two lightest colors. |
RH |
 |
The new color map (right side) was tweaked to have a larger luminance step. |
APCP |
 |
The new color map (right side) tweaks both the darkest and lightest colors, leaving the mid-range colors intact. |
WIND |
 |
The new color map (right side) tweaks the yellow color and the shades to either side of it. The diverging nature of luminance in this color map is intentional as 100 knots (which corresponds to yellow in our color map) is considered a critical boundary point for judgments involving wind speed. |