CloudPhysics 2.0
CloudPhysics offers a cloud-based SaaS application that provides valuable insights to admins about their virtual infrastructure. CloudPhysics collects large volumes of data and performs complicated transformations to derive metrics that can help an admin make critical decisions for their datacenter. The time to install and draw meaningful information is negligible which makes the product an attractive value addition to any IT team.
I've worked on many many things at CloudPhysics, but designing the dashboard and a new mode of exploration has been the salient accomplishment of my time there. An IT application is made or unmade by its dashboard, and that is where I've focused most of my attention for the past months.
Conquering the Domain
For any product designer, the obvious first step is (or should be) to experiment with and explore unfamiliar software so they can learn about workflows, interactions, and draw parallels with systems they have worked with. The eventual goal is to figure out the overall system map which becomes the foundation for the interface design.
Of course, identifying the problem is a far cry from solving it to everyone's satisfaction. It's not uncommon for there to be ambiguity about certain concepts, even among experts, when the information is encyclopedic and complex in nature. For my own learning and with the goal of providing a visual reference to the company, I created a diagram exploring relationships between virtual and physical objects that make up the VMware ecosystem. The flows helped resolve arguments and doubts in a fraction of the time compared to when a folks were trapped in meeting rooms caught in endless discussion.
A system diagram depicting core screens and relationships.
Real Data is Virtuous
Knowing the data can help reduce the number of times you have to reach out to customers to understand what they need. At CloudPhysics, I went to great extents to understand the metadata we collect, transformations performed on data, nuances and challenges of delivering data quickly and various constraints of collecting and presenting vast amounts of information without degrading the message or misrepresenting the problem. I had to understand degrees of relevance for data; how a collection of metrics can unite to serve a range of use cases.
To understand the bounds and outliers in the dataset, I first plotted several data samples in tools such as Datahero and Excel. Real data also goes a long way in identifying the best visualization for a dataset. My proudest achievement at CloudPhysics has been studying and experimenting with Tufte Sparklines and using them in our dashboard application. Are they going to be effective for comparison, are they conveying the trend and supporting the primary metric? How can I adjust them to be more meaningful when looking at two related metrics?
I modified the traditional sparkline to be colored in areas where a metric exceeds a certain threshold. In the same view, I show two additional sparklines (bottom) from which the metric represented by the top sparkline is derived.
The sparklines used in the data table design were generated in a jquery sparkline generator where I was able to tweak the height & weight for the final dimensions.
Data Density
There was initial skepticism around the density of information in our dashboard widgets. Some of this came from comparing our dashboard to ones frequently seen in business intelligence applications or other monitoring platforms.
Most popular dashboards are a collection of tiles of varying sizes organized in a fluid grid layout. Most commonly the tiles present a single large number, a data grid to rank/list top items, or simple charts to represent distribution or history. This pattern of dashboard design is rampant and often perceived as "very clean" and "simple". The focus tends to be on establishing interface elements that can support 2 to 3 patterns of design. Designers focus on the visual aspects and often use dummy content to compose the design. While this approach supports scalability, there's one major caveat: it constrains the data. Data is relegated to being a second class citizen. Given the decoupling of actual data from the container or framework that will host this information, often the content is selected or repurposed to fit the container.
At CloudPhysics, while endeavoring to create a scalable dashboard, we too adopted the approach of tiles or widgets but the main driver for this choice was customizability to allow multiplication of content. With every widget, we honed the design to extract global or common elements to establish some consistency in the experience. We continuously adjusted the design of the containers and common elements always prioritizing content.
Our current and prospective customers are delighted by the flexibility and experience of our design. They were impressed by depth and coverage of information that we pulled off.