...
I think the primary enums which we will be encountering are faults and drive states
Drive states - Letters associated with each drive state (also seen on the Near East dashboard above)
Users need to know what each letter is associated with
Enums could be displayed as banners, status boxes, or a combination of both
This is an example of an expandable status log. Most status updates will not be useful until they actually occur so they shouldn’t take up a consistent space on the dash.
They should also be easily accessible in the case where something does happen, so an alert icon can remain at a certain location on the screen.
Comparing Data
...
Comparing different graphs
Data will most commonly be compared by looking at trends instead of exact values, so I’ll focus more on comparing graphs.
Have an add graph feature?
Top-Bottom Stacking (same x-axis)
Could be stacked like an oscilloscope. Stacking the two graphs is best for comparing data over a series of time. By stacking them vertically, the x-axis times can be aligned and we do not need to be worried about different y-axis units
It is important to have a common reference point for the graphs where a user can highlight a time and a vertical line will appear for each graph.
I think that time will be the most common x-axis so top-bottom stacking should be the default format when comparing the graphs
Side-By-Side Stacking (Same y-axis) (Or neither axis is the same)
Side-by-side probably isn’t as useful but if we are comparing datasets where it is more difficult to compare the units (voltage at a specific time, for example), then users may prefer it.
Multi-Series (Same x and y axes)
Area graphs are really good for comparing two lines. When communicating overall trends, the difference in colours emphasizes the amount of increase/decrease. Also blocks in the difference between the different values.
Here is an example of a multi-series plot which toggles between a graph and table format.
Comparing Exact Values
...