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.
 

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.
 

More on Same Day Last Year

Back in March, I published a post on calculating the same day last year.

In a recent post on the Masters Summit for QlikView LinkedIn group (the group is only open to previous attendees - yet another good reason to attend!), someone was asking about the subject so I shared a link to my original post. Another member queried the logic and suggested that it only works "75% of the time".

I expanded a bit on my logic from the original post, so I though that I would update it here for public viewing.

My assumption was that by 75% he was really just mentally rounding and actually meant 83%. In the last 100 years (04-Jan-1915 to 28-Dec-2014) there have been 17 years with 53 weeks. I assumed that this was the "25%" where he assumed that the logic broke down.

I believe that the logic doesn't break down - ever.

As an example, let us consider 2009 which had 53 weeks - 28-Dec-09 to 03-Jan-2010. What should be the correct week in the past to compare this week to? After all, there is no week 53 in 2008. Should we just forget that this week exists?

Of course not.  What we really need to do is to consider the purpose of the comparison and that is to compare performance of equivalent weeks and equivalent days in those weeks. The equivalent week, Monday to Sunday,  to make the comparison to would have to be the week of 29-Dec-08 to 04-Jan-09 - and that is actually week 1 of 2009!

This logic continues through 2010. 2010-01 is compared to 2009-02, 2010-02 is compared to 2009-03, etc., all the way until 2010-52 is compared to 2009-53. The week numbers will then realign in 2011.

In this fashion, the Date-364 calculation is always correct (leap year, 53 week year or otherwise) because it always gives you the equivalent day one year ago.

For your pleasure, here is a small script that you can run in QlikView or Qlik Sense to compare the like-for-like dates for the last 100 years:

Let vStart=Floor(MakeDate(1915,1,4));
Let vEnd=Floor(MakeDate(2014,12,28));
Let vDiff=vEnd-vStart+1;

Calendar:
Load
DateID,
Date(DateID) As Date,
WeekYear(DateID) as WeekYear,
Year(DateID) As Year,
Week(DateID) As Week,
WeekDay(DateID) As WeekDay,
WeekYear(DateID) & '-' & Num(Week(DateID), '00') As YearWeek,
Date(DateID-364) As Date_LFL,
WeekYear(DateID-364) & '-' & Num(Week(DateID-364), '00') As YearWeek_LFL
;
Load 
$(vStart)-1+RecNo() As DateID
AutoGenerate($(vDiff));

---

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.