The main UI zones of the mockup are:
- The 4 "pulse" metrics at the top the explicitly communicate "completeness" (duplicates, losses, latency, and overall) of the messages that are flowing through a Kafka cluster.
- The heat map at the bottom which attenuates a color (in this case orange/red) to visually communicate when any of the above metrics exceeds a threshold set by the user (ie red=bad). The User is able to see all the Kafka cluster's consumer groups, related topics, possibly brokers, and producers in this area which could be on the order of thousands of entries.
- Control panel drawer on the right (slides in/out per user control) which allows the User to cull the results of the heat map down to a targeted query.
10 FT UI
Some of our users, like Executives or Network Operations Center Engineers need a high level view of their clusters or system. Some of their display contexts are tv monitors with no way to manage what they see easily ore frequently - a passive "stock-ticker" type of experience. This is an early idea of how to reduce the information to it's bare minimum to be understood at-a-glance or at distance (20 feet or so).
I've taken the metric text information from the full UI and isolated it in the center of the screen. The thought here was that A) it looks simple. There's not much going on so what was once maybe a intimidating or confusing experience to visually weed through all the noise is greatly simplified and maybe even peaceful experience. B) By directly leveraging existing UI, I am making the transition between this dashboard and the full app a bit more forgiving and coherent. The alternative is to create unique elements here and then a potentially complex (morphing) or jarring (tabs) transition which I believe negatively effects the experience.
Part of the User experience that will need some definition is how they configure the application for permissions, user information, customized alerts, and data "completeness." These are some simple mockups for how the User Preferences might look.
The main purpose of the Audit Application is to show the "health" of the data that moves through a Kafka cluster. For this product, health is seen as "Completeness" which is a combination of the individual metrics, data loss, data duplication, and latency. The rate at which the data is not complete we cast to "Severity." The more severe the deviation from Complete data, the more Severe the data is displayed in the UI. This dialog allows the User to adjust each of the 3 metrics so that they can calibrate their UI and the desired target health of their data.