Launching Sparklines for iOS
CEO & Founder of Server Density.
Published on the 19th May, 2016.
Want people to understand you? Tell them a story.
Stories are narratives. They take data (events) and interpret them by placing them into context (timeline).
Unlike computers, most humans aren’t great at assimilating raw data. In order for us to understand (remember and emote to) data, we need context. A single data point, accurate as it may be, doesn’t communicate nearly as much as its relationship to other data points does. June revenue numbers mean nothing unless we stack them next to revenue numbers for April and May. We now have a progression, a storyline. It starts to make sense.
That’s where data visualisation comes in. Data visualisation is the art and craft of presenting data into context. It’s about creating meaning. And that’s great because meaning is what makes humans tick.
It’s all in the detail
Some charts are brimming with detail. To appreciate those graphs, you’d need to invest the time to notice, observe, and enjoy the detail.
Other charts have zero detail (no axes, labels, or legends). The value of such graphs is in how quickly you can extract information from them. See the sparkline in the watchface below?
That’s what Sparklines (or sparkcharts) do. They condense charts into smaller expressions. It’s no coincidence that one of the first commercial applications for sparklines was in stock trading. Sparklines provide immediate trending information, and that’s precisely what high-powered stock brokers wolf down 24×7.
Now, you don’t need to be a hero of a Bret Easton Ellis novel to appreciate sparklines. Sparklines are everywhere these days. From weather trends, production rates, website traffic, and Yankees’ current season results, everything can be presented with sparklines.
Your Server Density metrics are no exception.
Adding context to iOS alerts
Smartphones are not lean-forward devices. You wouldn’t analyse data, setup new alerts, or troubleshoot incidents by thumping around on a 4-inch display. What “sysadmins on the move” need is an answer to a simple question.
What is happening?
Sparklines are a perfect match for the iPhone because they offer instant visual cues. With system trends at their fingertips, sysadmins can quickly decide whether to go home, or whether they can finish dinner before reaching for their laptop.
With sparklines you can tell at a glance whether the alert is the result of a slow climb up, or a sudden spike. In human terms, sparklines are the EKG for your server’s health. You can instantly tell what the status of your open (and recently closed) alerts is.
To add context, sparklines include what precedes and what follows an alert trigger. For open alerts, we display the same amount of data points before and after the alert trigger (with a minimum of 30 minutes). For closed alerts, the alert duration is half of the depicted interval, and we distribute the rest of the time before and after the alert.
The number one engineering priority for sparklines was performance. Sparklines should work fast, without affecting the overall glanceability of the app.
We did not want to penalise performance in any way. In fact, some of our earlier iterations were binned because they did not meet our responsiveness criteria. We tested sparklines on everything from an iPhone 6s to a lowly iPod Touch. We didn’t release the feature until it rendered well on every device.
So here is the challenge.
How do you render several (we tested with hundreds of) concurrent sparklines, each comprising multiple data points, and refresh them every 60 seconds, without missing a beat?
Enter Operation Queues
Operations and Operation Queues allow for a network of tasks, divided into smaller interconnected (chained) tasks, executed in a predefined order.
We first fetch the list of triggered alerts from our API. Once we confirm they’re of the right type (a device alert with a numeric metric) we initiate a “chain” of Operations. These operations happen on the fly. As the user scrolls down the list of alerts, each corresponding operation jumps on their Operation Queue.
We then define dependencies between Operations. For example, one Operation fetches the last metric value for a given alert, while another renders those values. The latter cannot work without data provided by the former, so we create a dependency to accommodate that.
Operations execute on the background and as system resources allow. In fact, the nice part about Operation Queues is that they run atop Grand Central Dispatch. GCD figures out how many concurrent tasks to run taking into consideration current system load and available hardware resources.
Running off the main thread
It’s common knowledge that we are not supposed to manipulate the UI unless we’re running on the main thread. A less known fact is that you don’t need to be on the main thread to manipulate graphics. We render our charts off the main thread, and only jump back to the main thread with a finished chart image ready to show up in the list of alerts.
We follow this process with every data refresh, and what we end up with is an up-to-the-minute comprehensive, information-rich view of the system health.
Sparklines is a HumanOps feature
We recently introduced HumanOps, a set of principles aimed at improving the life of sysadmins. HumanOps features create bridges between systems and humans.
Sparklines is one such feature. It condenses significant amounts of information in a small chart that sysadmins can digest at a glance. It saves them time, energy and, most crucially, it preserves their attention.
Get the latest version of Server Density, take sparklines for a spin, and let us know what you think.
We also want to hear from you. How do you employ sparklines in your own dashboards, reports or presentations? How do you add context to your data, and how do your requirements change as you switch from desktop to mobile?