Dashboards

Fundemental Contract

I believe there is a fundemental contract between the user and the tools that decribe the state of a system. Users have an intent for the state of the system. Tools caputure the user's intent and convey it to the system. In addition tools also capture the reslutant state of the system and convey it back to the user - that's were dashboards come in to play. And it gets interesting when there is a mismatch between the intent of the user and the state of the system.

Complicated

Some dashboards seem overly complicated.

6 Pack

Status of an aircraft moving through a 3 dimensional space can be conveyed through six basic instruments. Vertical speed, elevation, heading, turn indication, and pitch and roll. 

Conceptual Model

There is a fairly good mapping between these 6 instruments and the conceptual model of flying, the tasks and goals.

Local Collection and Analysis

This was an on-prem port of a clould based reporting tool for highly secure networks that typically would not be connected to the internet.

Cisco

This was the style of dashboard that was typical when I was at Cisco. Sometimes it was hard to figure out what the pupose of the dashboard actually was.

Cisco UCS

A dashboard mockup that I used to fascilitate discussion with the project team.

Improving information presented in vSphere

This was an investigation I did into a competitor of VMware. I proposed a solution that more accurateing reflected the infomation that the system was usning to make decisons about how to load balance VMs accross a cluster of ESXi hosts.

It looks like we're in a parking garage :-).