A new Dashboard for Server Density
Today we unveil our new Server Density dashboard with a fluid layout, a re-written javascript engine and a new UI. Our main objectives for the new dashboard were to display more data in the same space, faster.
Final version of the new dashboard
The aim of the dashboard is to allow you to set up a quick overview of all your important devices and services so you can easily see where problems are. Over time, we added new features but we decided to start from scratch with this new implementation so we could consider everything Server Density has grown into over the last few years.
We have customers using just a single device or service all the way up to thousands, so it was important to be able to take advantage of the space of large monitors or TVs but also load the UI as quickly as possible. We looked at some of the interfaces we use every day to see how they deal with scaling so we could figure out what was good and bad. For example, the Terremark Enterprise Cloud control panel allows you to switch between a grid and table view. We tried several different implementations and did refactoring several times when testing with large numbers of items.
Terremark Grid
Terremark Table
With the basic tennets for the new Dashboard defined it was time to think and iterate over the UI concept. These initial wireframes would present a static view where signal to noise ratio would be easy to gauge and test. Right from the start we knew a fluid layout would be a must, then there was the matter of how to represent a device/service and lastly how to handle a huge collection of devices or services. The exploration of these needs leads to representing a device/service as a card and to introduce grouping.
Wireframe for global metric management
Representing a device/service as a card allowed us to further reduce the noise while allowing space for new information by dividing the card in front and back. The back would contain all of the configurations of the card and its data, while the front will just show the active metrics. We also tried using a table view but decided against it because it would be quite inflexible:
Table view wireframe
We tried some different options for exposing all the metrics available including an expanding horizontal panel which was grouped and ungrouped. You can see the large number of metrics makes grouping necessary.
Ungrouped metrics selection
Grouped metrics selection
In the end, a popup panel was used so as to appear over the top of the dashboard view and not move things around with expanding/collapsing.
Dashboard wireframe for inline alert options
You will also find options to dynamically sort and organize the cards, collapse/expand groups and in the card back a popover to manage the alerts associated with the aforementioned card.
And this brings us to the next action point. How could we make the dashboard more efficient for our users? From our analysis, and again considering a power user, there was a considerable time invested in drilling down (aka hunting) for metrics to add to each device, plus a rinse and repeat for each device. To cope with this problem we have transformed the metric selection into a two panes view and in coming milestones it will be possible to manage metrics globally or per group.
Dashboard initial UI.
The overall app has also been changed, mainly the header also became fluid and fixed when scrolling. Alerts are the most important functionality of monitoring so we made a Notifications panel which is accessible from everywhere in the app and updated in real time. A couple of options for this were explored including how Chrome displays notifications in the bottom right using a toaster method, similar to Growl.
However, we decided to have another popup panel partly for consistency but mainly because it can show all open alerts within a scrollable view and be clearly visible in the same location on every page. We also added a Support popover to make it easier to access our documentation because we’ve had some reports of our support site being too hidden away.
This is the first iteration of the dashboard and we’ve mocked up other ideas, including graphing, for future versions. You will notice that the rest of the app remains fixed width within content panels. Changing the entire app to be fixed width isn’t just a case of specifying width as a percentage in the CSS! We have to ensure that forms look good, elements fit in the right place and we make the most optimum use of each space. So we’ll be working through each section of the app over the coming months to improve each section individually. The next stop will be the alerts management UI, which has now finished the design stage and is in the process of being implemented.
And yes graphs are on our roadmap as well…
Enjoy this post? You may also like How to build stunning custom iOS graphs on iPhone and iPad