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

Friday, 16 January 2015

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.
Follow me on Twitter   LinkedIn

Tuesday, 16 December 2014

Sway to the Qlik

Microsoft have made their new Sway service generally available on "Preview".

So, what is this Sway?  Really, it is about telling stories - without having to know anything about design or building websites, you can upload some images, type in some text, and publish your story.  Your story is then viewable by any user, on device, in a responsive manner.

For example, witness the rather amusing antics of Flat Tony.

You can have your story go horizontally, or you can have it go vertically.  You can easily arrange things if you don't like the way the system presents them.  More ways of arranging things will be coming on stream quite soon.

Why might this be of interest to a Data Viz professional?  Because stories are what we tell - stories about data.

One of the features of Qlik Sense that most interested me was Stories.  One of the features of Qlik Sense that most disappointed me was ... Stories.  The concept is brilliant - easily snapshot images of my charts and then embed them in a story along with annotations to explain what is happening.  The problem is that I can only share these with other users of Qlik Sense - I can't export them to any other format or push them out on a website to non Qlik Sense users.

There is a logic to these restrictions.  The features of being able to view the charts "live" from within a story would not be available to external users.  OK, that can be an important thing, but is that the most important thing?

Here is something that I built in about 10 minutes using Sway (it may look familiar!):

Food Corp Sales Analysis 2014



It isn't earth shattering, but it wasn't several days of effort either.  I used the Windows Snipping tool to grab the images (apparently I can use APIs to get snapshots too), and just added the text.

The big deal about this link is that you can view it - and you can view it on any device.  And you don't need to have a Qlik Sense license.

I am sure that we will see Qlik Sense Stories evolving over time - this is definitely a direction that I would like to see them going.


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

Friday, 12 December 2014

Season's Greetings

This QlikView script may be the most important one that you ever see (or not, mostly not).

Follow these steps.

1.   Create a new QlikView application and add the following script:

   For i = 0 to 100 step 5

Tree:
LOAD
RowNo() as id,
1 as Period,
$(i) As Branch,
-100+$(i) as X,
$(i)+10 as Y
AUTOGENERATE (1);

LOAD
RowNo() as id,
2 as Period,
$(i) As Branch,
0 As X,
$(i) As Y
AUTOGENERATE (1);

LOAD
RowNo() as id,
1 as Period,
$(i)+1 As Branch,
0 As X,
$(i) As Y
AUTOGENERATE (1);

LOAD
RowNo() as id,
2 as Period,
$(i)+1 As Branch,
100-$(i) as X,
$(i)+10 as Y
AUTOGENERATE (1);

   Next

      Reload the document.

2.   Add a new Scatter Chart.

3.   On the General tab, set the Title in Chart to:

   =chr(8902)

      In the Title Settings, set the font size to 26 and turn on Bold.
   
4.   On the Dimensions tab, add Period and Branch.

5.   Turn on Advanced Mode on the Expressions tab.  Remove the expressions that have been added and add the following 3 expressions:

   =X

   =Y

   =10+Avg(fabs(X))

6.   Under the first expression, set the following Background color expression:

   =RGB(1, 121, 111)

7.   On the Style tab, select the flat, connected bubbles Look (3rd one down in the 2nd column).

8.   On the Presentation tab, turn off Show Legend.  Add a Reference Line on the X-Axis with a value of 0.  The color should be the same RBG as in step 6.

9.   On the Axes tab, turn off the Forced 0 option and turn on the Hide Axis option for both axes.  For the Y Axis, set a Static Min of -5 and a Static Max of 110.

10.  On the Layout tab, turn off the border (or set to 0 pt).

11.  On the Caption tab, set an appropriate caption.

With a little tweaking (using Ctrl+Shift to move bits around), you should be able to come up with something like this:




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

Friday, 5 December 2014

Searching Questions


I had the privilege recently of visiting Qlik Labs (or "Q Branch", as I like to call it) in London and listened to Alistair Eaves, the Director of Qlik Labs, give a talk on some of the work that they are doing there.

Needless to say, I can't go into the specifics of everything that was said (nothing about laser pens though!) but I can talk about one feature that has made it into Qlik Sense - global search.

I particularly wanted to talk about this one feature because I am not sure that enough has been said about it - probably because most people who are experienced with QlikView might miss the significance of it.

In the Search Object in QlikView, you can enter multiple terms.  It will then highlight where all of those terms might match in the different fields.  There is no concept though about how well those search terms have matched - do they all match, if not how many match?  If I type the query light beer minnesota into the object, then I might get some hits across some fields, but I don't really understand how well I have searched.  I don't know if there is any association between the values that have been found - and Qlik is all about association.


In Qlik Sense, however, the same query gives me far more interesting results.  It gives me qualitative information about how many hits that I have had, what fields I have hit, and how they associate together.  It also gives me information on places where I didn't have exact hits, but still might be very useful to know about.

This might appear to be quite a simple thing, but it is really very powerful.

Users are already used to asking questions of Google to find information.  In the future, they may expect to ask similar questions from their own data to discover insight.  Perhaps even verbally!

Watch this space...


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