Thursday, 16 April 2015

Explaining Pie-Gauges

Back in December 2013, I discussed different KPI approaches and introduced the Pie-Gauge as a form of representation. I used them in the dashboard of the winning app in the recent Qlik UK partner competition:


Last month, I described how happy I was that QlikView 11.2 SR10 was released so that we could change the segment color in a Pie chart - making Pie-Gauges look better.

Prior to that, and indeed in my entry to the partner app competition, I had used an extension object for creating Pie-Gauges. This is published on Branch.

So, what, exactly, is a Pie-Gauge anyway? It is a gauge because it is representing a KPI - one value versus a target value. However it solves one issue with gauges in that I don't ever have to worry about the scale. This is especially good when I may have several KPIs. Pie-gauges are all about ratios.

Like all pie charts, it is a part-to-whole comparison. In this case, there are always three segments, two of which are mutually exclusive, making up the whole.

The first segment represents the amount by which we have fallen short of the target. The second segment represents the lower of the target value or the actual value. The third segment represents the amount by which we have exceeded the target.

We can see that the whole is therefore the higher of the target or the actual value. We can also see that the first and third segments cannot exist together - we can't fall short and exceed the target at the same time.

The positioning of the segments is important. The first segment must be to the left of the top of the pie, and the third segment must be to the right - signifying below and above target.

The great thing about these gauges is that they will work no matter by how much we have fallen short or exceeded the target - they are always a part-to-whole comparison. Unlike gauges with fixed axes, they will just work.

The really important thing to grasp is that the actual % above or below target is not important!  It is the representation of the ratio that is important. It is whether we are above or below target, not by how much, that we are representing.

The three values can be very easily calculated using Qlik's RangeMin and RangeMax functions.

The first segment is:

RangeMax(Sum(Actual)-Sum(Target),0)

The second segment is:

RangeMin(Sum(Actual),Sum(Target))

The third segment is:

RangeMax(Sum(Target)-Sum(Actual),0)

In QlikView, we can have these as three separate expressions in a Pie chart. In Qlik Sense, we can only have one expression so I use a ValueList dimension and an expression like this:

If(ValueList(' ', '  ', '   ')=' ',
RangeMax(Sum(Actual)-Sum(Target),0)+0.001,
If(ValueList(' ', '  ', '   ')='  ',
RangeMin(Sum(Actual), Sum(Target))+0.001,
RangeMax(Sum(Target)-Sum(Actual),0)+0.001
))

Note the +0.001 on each - that stops Qlik Sense displaying the "chart contains zeros" message. The spaces in the value list are there just to stop additional text being displayed on the Pie.

The color can then be calculated like this:

If(ValueList(' ', '  ', '   ')=' ',
LightBlue(),
If(ValueList(' ', '  ', '   ')='  ',
RGB(240,240,240), LightGreen()
))

Have fun with Pie-gauges.


Stephen Redmond is author of Mastering QlikView, QlikView Server and Publisher and the QlikView for Developer's Cookbook
He is CTO of CapricornVentis a Qlik Elite Partner.
Follow me on Twitter   LinkedIn

Thursday, 9 April 2015

The vaccine effect

Sparked by Alberto Cairo's tweet sharing a blog on Recreating a famous visualisation, I decided that I would go onto the Project Tycho website and grab the data myself to play with in Qlik Sense.

It was, of course, fairly quick to import an Excel file into Qlik Sense Desktop, adding a CrossTable command to break out the data by State.  First visualization, one that I usually turn to to see what I have, was the bar chart:


By adding a color expression to highlight bars up to 1963, when the measles vaccine was introduced, versus those after 1963, the data jumped out very quickly.

I used the new pivot table in Qlik Sense to recreate the WSJ heatmap, along with similar color rules to those used by Mick Watson:


I also decided to have a look at the geographic spread, both before and after the vaccine:


Vaccines are really amazing. Just to think that just over 50 years ago, people were dying from a disease that, for most of us now just doesn't exist.

Worth thinking about.


Stephen Redmond is author of Mastering QlikView, QlikView Server and Publisher and the QlikView for Developer's Cookbook
He is CTO of CapricornVentis a Qlik Elite Partner.
Follow me on Twitter   LinkedIn

Monday, 30 March 2015

Do your Apps win Michelin Stars? Do they need to?

Back in 2012, at the TED@SXSWi event in Austin, Texas, JP Rangaswami, then Chief Scientist at SalesForce, now Chief Data Officer at Deutsche Bank, challenged us to consider that information is food.  It is an interesting analogy. I especially liked the "Supersize Me" suggestion of having to watch Fox News for 30 days.

So, if information was food - what would you do differently?

If information was food, what kind of data visualization would you like to see?

Would you be happy with the daily stodge? Not too pretty to look at, and you are not 100% sure of where the ingredients come from (and you have only been ill a few times!). Perhaps of the variety sold to the residents of Ankh-Morpork by CMOT Dibbler?

Or would you be looking for the time-consuming, detail-attentive, incredibly beautiful and incredibly expensive, Michelin starred fare?

Or is it somewhere inbetween?

The reality is, boringly, that it doesn't matter how pretty nor how ugly the presentation layer is if the ingredients are suspect. As I said in a post last year, good governance prevents people from getting food poisoning.

The first step is to get the ingredients right (or as right as we possibly can!) - then we can focus on the presentation. And focus we must. A plate of great ingredients just mashed together will not encourage our diners to return. We mush present our ingredients as best we can with the tools that we have available and then the foodies will keep coming back.

You never know, one day there may be a Michelin judge with them.


Stephen Redmond is author of Mastering QlikView, QlikView Server and Publisher and the QlikView for Developer's Cookbook
He is CTO of CapricornVentis a Qlik Elite Partner.
Follow me on Twitter   LinkedIn

Monday, 9 March 2015

Segment color in pie chart

QlikView 11.2 SR10 includes one new feature change:

"Now possible to define color of the lines around the sectors in a Pie chart. In the properties Color tab of the chart, you can now find the Sector outline property. Please note that calculated colors do not work for this setting."

I know what you are thinking - "Yay!  Sector outline!"

Ok, ok, I know it is not the most fabulous thing to happen to QlikView since it was created, but it does help me with one area: Pie-Gauges.

When I first proposed the Pie-Gauge, it was difficult to get it looking really nice with the native Pie control:


For me, the black outlines detracted from the visualization.  So much so, that I ended up creating an extension object to do the job!

This new change in SR10 means that I can make one properties change, and the same visualization now looks way better.


We could argue for hours about whether this is more or less effective than the same gauge, but it is nice to see new features like this creep into the product.


Stephen Redmond is author of Mastering QlikView, QlikView Server and Publisher and the QlikView for Developer's Cookbook
He is CTO of CapricornVentis a Qlik Elite Partner.
Follow me on Twitter   LinkedIn

Thursday, 26 February 2015

Qlik Sense FR1 - A little underwhelming?

So, it is finally here.  Qlik Sense v1.1.0, Feature Release 1, is now available for download and I would definitely encourage everyone to think about updating.

So what is new in this release:

-   A pivot table!
-   A new KPI object
-   Updates to the map object
-   A new way to create calendars - declare/derive
-   A whole load of stuff around server management and APIs.

I believe that the best work that has happened is actually the last bullet. Unfortunately this is the least interesting to the vast majority of people who are interested in what Qlik has to offer.

The new pivot table is good. It is nicely done and will work well for users who need it. I have not been a big fan of having a pivot table in a self-service data discovery tool, but you have to serve the market, and the market have been asking for it.

The new KPI object is, I think, fairly limited, but I do like the option to allow click through to other sheets. It would have been good to have seen this option also added to other objects, like the gauge and text.

The map has been updated to include its own tiles so that you don't have to add the custom Slippy map - although that is still available if you want it.  They have also added the facility to snapshot the map for stories. I think that they could have added some other functionality here, but it is still a good solution for most needs.

I was initially very interested in the new Declare / Derive functionality. It allows us to create a template for fields that can be derived from other fields and then apply it to several fields. The demo example is deriving different calendar fields from a date field, which could help replace some of the calendar scripts that we create and reuse in script. However, I was disappointed to see that some functionality that was in the demo script - creation of drilldown and "collection" (cyclic?) groups is not yet released. I was also disappointed to discover that such derived fields do not work in Set Analysis.

Further thinking on the Declare / Derive will be needed because I am struggling to see a use case for them beyond the calendar example. This calendar use case should really be handled for users, especially self-serving business users, within the UI - and maybe that is where this functionality will end up.

There is some good, and some very good, stuff in this new release.  I have to say though, that I am left a little underwhelmed.


Stephen Redmond is author of Mastering QlikView, QlikView Server and Publisher and the QlikView for Developer's Cookbook
He is CTO of CapricornVentis a Qlik Elite Partner.
Follow me on Twitter   LinkedIn

Wednesday, 28 January 2015

Measuring the measures

So, how should we measure the measures?  How do we define success in a data viz implementation - using Qlik or otherwise?

Is success a pass through the UAT process?  If the client has paid the bill, does that imply success for the contrator?  Do we ever go back and find out?  What kind of post-implementation evaluation do we do?  I know that I can tell you anecdotes of several enormously successful implementations where tthe client has achieved great ROI - but I can't tell you that I learned of these by any great process of measuring that success.  Nor can I tell you about the implementations that were less successful,  or were enormously successful but we never recorded it - these have not been measured and have faded from memory.

At a basic level, a data visualization can be considered successful if the values that are being encoded can be decoded by the user. No matter how slick and technologically advanced the implementation, if the values are not decodable, then that is a fail.  However, that decoding process may be intuitive and easy or it may be complicated and hard - just ticking the box on the ability to decode can't define success.  Do we need to take the success measure up some levels and consider the user experience?

So, our measures can be decoded correctly and the users are happy with the experience.  Now, how do we confirm that the measures that we encoded were the right measures in the first place?  How well were the project goals met?  Are the users even using our wonderfully crafted displays at all?  Or do they simply go straight to the pivot table every time and spend five minutes every morning getting the measure that they actually needed?

If we have been through the process of scoping the project correctly then we will have created a list of measures and key indicators that are correctly linked to the strategic aims of the organization.  But we should go further.  We should create a list of measures of success of the implementation.  Some may not be 100% accurately measureable, but the questions should be there.

You might have a measure like, "sales margin increases by 5%".  This is easily measured.  Or you might have a success measure of "users are happier running reports" - not so easily measured but something that can be estimated.

Of course, these measures of measures are not just used as a success criteria, they become part of a feedback loop of change and improvement where there are always new goal to achieve.

We should always keep measuring the measures.


Stephen Redmond is author of Mastering QlikView, QlikView Server and Publisher and the QlikView for Developer's Cookbook
He is CTO of CapricornVentis a Qlik Elite Partner.
Follow me on Twitter   LinkedIn

Tuesday, 27 January 2015

Don't smooth the path

One of the options in QlikView line charts is to apply a smooth option so that lines look nicely curved rather than ugly and jagged. However, while it can be aesthetically pleasing, it can also be a distortion of the data.

An interesting aspect of this distortion, and one that many designers might not think about, is how we deal with interpreting curved lines that are tracking along similar paths - for example, sales versus budget. Have a look at such a chart:


Now, if I was to ask someone where these lines diverge the most, the average person will suggest that the largest gap is in and around the apogee of the curve. But it's not correct! Would you believe me if I told you that the largest divergence is at the start and that the difference at the apogee is actually half way between the maximum and minimum? Here is the data:


The problem is that our visual system is looking at the minimal distance between the lines, we aren't looking at the vertical difference between the points that define the lines. Lines in a line chart are actually there to give some shape to show us a trend, they aren't the data!

The line chart below may be a better representation:


Here there is still the temptation to look at the distance between the lines but at least we have the points to help us. We could even add some further clarity using a combo chart:


It may not be ideal, but using the gestalt principles of enclosure will at least direct our visual system to the connected dots and give us some better understanding of the differences.

You might even get away with putting the curves back in!




Stephen Redmond is author of Mastering QlikView, QlikView Server and Publisher and the QlikView for Developer's Cookbook
He is CTO of CapricornVentis a Qlik Elite Partner.
Follow me on Twitter   LinkedIn