This is a relatively quick post to add to my last GoogleMaps enhancement post that put simply allows you to use what you’ve already built to drive the maps integration to add StreetView into the mix as well.

Firstly thanks has to go to Alexander Karlsson – seemingly Qliktech’s ‘Head of Geeky Experimentation’ (that’s a compliment) who mentioned using StreetView with the GoogleMaps v3 API in a comment on my previous post. This of course led me to get reading the Developer Guide supplied by Google…and guess what; if you already have GoogleMaps integration in Qlikview it will take you about 2 minutes to set StreetView up.

https://developers.google.com/maps/documentation/streetview/
Things don’t get much easier than this; all you need to do to get the StreetView integration working is to create a Text Object and drop in the following URL:
=’http://maps.googleapis.com/maps/api/streetview?size=400×400&location=’&Replace(var_mid_lat,’,',’.')&’,'&Replace(var_mid_long,’,',’.')&’&fov=90&heading=’&vHeading&’&pitch=10&sensor=false

The only variables required are “&Replace(var_mid_lat,’,',’.')&’,'&Replace(var_mid_long,’,',’.')&’” and those are lifted straight out of the traditional GoogleMaps integration.
In addition I’ve also added a further variable ‘vHeading’ that allows for some very snazzy panning of the returned StreetView image – you could also amend the Zoom (‘fov=90’) and the Pitch (‘pitch=10’) values.

I’ve set some simple buttons to control the Panning that simply use the following Expressions via an Action to update the vHeading variable:

Pan Left: =if(vHeading<=30,360,vHeading-30)

Pan Right: =if(vHeading>=330,0,vHeading+30)

(The value can run from 0-360 so using the above expression allows us to rotate continually, similar principals could be used for controlling the Zoom and Pitch within the required ranges.)
As a caveat; I’m using a full PostCode Longitude & Latitude file that I put together and not the aggregated one that most implementations use, this gives me much more fidelity and means the image returned from StreetView is (almost) certainly of the location required. Using the standard Lat/Long file will probably still show something via StreetView but it could be miles away from where you expect.

Finally I’ve used the GetPossibleCount() function to ensure the option to view StreetView is only offered when there’s only a single PostCode to show.

Note of Caution: API calls to StreetView count towards the 25,000 calls in 24hrs limit imposed by Google (also outlined by Alexander).

Obviously integrating StreetView isn’t as important as the traditional GoogleMaps setup but certainly in some places it’s useful non-the less; as I repeatedly bang on about; I’m working with insurers and providing them with a quick and integrated way to click a risk in Qlikview and straight away see an image of the local area (and in most cases the property itself) really helps build an impression of the risk…and of course it looks impressive! Certainly if I were still in pre-sales I’d be getting this setup straight away and shown off to every prospective customer.

So many thanks to Mr Karlsson and as always I hope you can put this to use.

All the best,

Matt

(All data shown has been scrambled)

Anyway onto this post. Earlier this week many of you will have noticed that your Qlikview GoogleMaps integrations stopped working, the reason being that Google stopped supporting versions 2 of their ‘Static Map API’ which Qlikview utilised and moved wholly to v3. Firstly here’s a straight like for like dynamic URL replacement provided by Alexander Karlsson (@MindSpank): http://pastebin.com/sDXzd1Yg simply swapping your old v2 for his URL should get you back to where you were.

As everyone now needs to start using v3 it seems like an apt time to share a v3 mapping innovation I developed a few weeks ago.

Currently I’m working in the Insurance industry and one of their primary concerns is the risk of flooding, they really like to see their insurance exposures plotted on a map therefore allowing them to see where they may be over exposed and the standard setup allows this to a degree but doesn’t work as well as it might. This led me to trawl through the GoogleMaps API documentation (https://developers.google.com/maps/documentation/staticmaps/) to find out what the limits of it were and it turns out with v3 the limits are beyond what standard Qlikview GoogleMaps can achieve.

After reading the documentation it became clear that with the right URL many of the map elements can be tailored to suits ones needs, for instance in my case looking at flood risk I can remove all the labels, show terrain and crucially highlight all the bodies of water in a colour of my choosing and the result’s shown below:

Its not showing anything that the standard setup doesn’t but it shows the details that my client is most interested in an enhanced manner and really helps the high risk exposures to jump out. The URL I’m using is: =’http://maps.googleapis.com/maps/api/staticmap?center=’&Replace(var_mid_lat,&#8217;,',’.')&’,'&Replace(var_mid_long,’,',’.')&’&zoom=$(var_zoom)’&’
&style=element:labels|visibility:off&format=png&sensor=false&size=400×400&Scale=2&maptype=terrain&style=feature:water|element:geometry.fill|visibility:on|invert_lightness:true|color:0x0000ff Now the eagle eyed amongst you will notice I’m using a higher fidelity scatter map chart than normal, this is because I’m using a custom Long Lat file that runs from the highest PostCode Area (AB) down to the full Post Code (AB1 2CD) via District and Sector with Long & Lats for each giving the higher fidelity that my clients need. Incidentally the standard ‘postcodes.xls’ file that many people in the UK seem to be using is a bit misleading; firstly it only covers the PostCode Districts (AB1) so everything ends up very aggregated on the map and also several Districts share the same Long Lat values (7 in central Birmingham for instance) this can therefore lead to misleading charts.

What else can be done with the new v3 of the maps API? Well I strongly recommend you go and read the documentation and experiment yourself but to guide you there’s a brilliant ‘wizard’ to get you started: http://gmaps-samples-v3.googlecode.com/svn/trunk/styledmaps/wizard/index.html tailor the map as you chose then copy and paste the URL the integrate the variables in Qlikview.

Basically you can colour elements how you choose, turn off labels and even add markers as well as the v2 ability to switch the map type which all told creates a fantastically flexible tool.

Here’s a URL I knocked together to show Lund in Sweden, with the roads highlighted in Qlikview Green and a maker showing where (I think) The Qliktech offices are – it’s an ugly map but it shows the flexibility! http://maps.googleapis.com/maps/api/staticmap?center=55.715892,13.220093&zoom=16&format=png&sensor=false&size=640×480&style=element:labels|visibility:off&maptype=hybrid&style=feature:road|element:geometry|visibility:on|color:0x00ff00&markers=color:0x00ff00|label:Q|55.716572,13.221248

So get thinking: what do your clients need to be seeing on their maps? Is the standard RoadMap really the best solution?

Hopefully when Qlikview v12 comes along this solution won’t be needed as Qliktech will have created a dedicated mapping object that takes full advantage of version 3′s functionality.

As always I hope this has been of use.

Hopefully it won’t be as long until the next post.

All the best,

Matt

The Christmas Tree Object

This being Qlikview we’ve got a little dynamism here so click away and see what happens!

The Cristmas Flexibility of Qlikview

So a Merry Xmas and a Happy New Year to everyone involved with and interested in Qlikview – I’m sure 2013 is going to be one of the most interesting years in Qlikview’s history; I for one can’t wait to see what happens (Qlikview.)next.

You can download the ‘card’ and the new Christmas Tree Object here: https://docs.google.com/open?id=0B0nQ9tZcY4wzVE1iTmdrOXFSRDQ

All the best,

Matt

Anyone who works with or is interested in Qlikview should by now have heard a little about Qlikview.next – if you haven’t you’d better catch up because your world is about to change markedly, mostly for the better but potentially for the worse.

There have been blog posts a plenty via the Community: http://community.qlikview.com/blogs/theqlikviewblog/2012/10/24/enabling-the-new-enterprise-with-qlikviewnext-in-the-age-of-empowerment, various commentary pieces from other blogs: http://www.quickintelligence.co.uk/whatever-next/ and lots of presentations from the perpetually in motion around the globe Donald Farmer at Business Discovery World Tour Events but nothing really tangible has been revealed. Therefore I’m going to mix a little hypothesis, assumption, knowledge and snippets of information together to try and look at not only what Qlikview.next is shaping up to be but perhaps more importantly what impact it’s likely to have on each and every member of the Qlikview family.

The outline of what Qliktech are trying to achieve with Qlikview.next has been covered in a recent White Paper that can be downloaded here: http://www.qlikview.com/us/explore/resources/whitepapers/the-qlikview-next-product-scenarios It’s an interesting document that pulls back the covers to reveal a little information but firm specifics remain elusive, it strikes me as being a more ‘high-level aims’ kind of document. I won’t go though each of the 5 themes as there’s plenty about each of them out there already so I’ll focus on a few key areas and the potential impact of all this change.

First of all let’s get rid of the marketing fluff; for me there aren’t 5 key themes for Qlikview.next, the areas that are going to have the biggest impact are: it’s mobile, it’s open and it’s simple.

1. It’s Mobile

Firstly in my experience when people talk about ‘mobile’ they aren’t talking about ‘mobile’ at all, they’re in fact talking about ‘Always Accessible’ – it’s only ‘mobile’ by the virtue of the fact that humans are by our very nature; mobile; we commute, we visit the factory floor, we sit at a desk in office A one day and B the next. If I’m going to have access to my dashboard at all times then it has to be mobile; having a dashboard available shouldn’t make me more mobile it simply means I can get more out of my time whilst I am mobile.

So let’s start again…

1. It’s Always Accessible

Qlikview.next is being developed as a touch (read ‘mobile / Always Accessable’) UI first and a desktop ‘point & click’ one second. Just have a think about that for a moment. A product that has I’d estimate way under 10% of it’s consumption and less than 1% of it’s creation carried out via a touch interface currently is making it’s next product primarily to suit these small percentages – it’s either madness or incredibly prescient. I certainly don’t think of it as madness; touch interfaces will continue to grow both through new hardware such as Microsoft’s Surface or through software designed for touch from the ground up such as Qlikview.next itself becoming more accepted and appropriately designed. However there’s a massive danger; do you develop a UI for touch and as a result lessen the appeal or ability of the desktop UI? I know Qliktech are saying that it will be a great interface on both but, well, they would say that. It’s akin to the situation makers of amphibious cars face; both a car and a boat share elements just as interfaces do; they need an engine, they’re controlled by a driver, they get you from A to B but you’ll never see an amphibious car out performing a car on the road and a boat on the water – it can’t happen, there has to be compromise. It’s a simple law; the more multi-purpose you get the less able you are to meet the specific needs of a particular niche; you get conflicts of requirements that lead to compromises in one or all areas. Now I firmly believe that Qliktech will get closer to a hybrid that performs well as both a touch and desktop UI than any amphibious car achieves its goal but I worry unless it’s perfect someone has to loose out somewhere.

I’ve heard it said that Qlikview.next will be the exact same UI across both areas and be great at both – I can tell you now that that’s not possible so I take it that there will be the same underlying menu and functionality options but they’ll be presented and interacted with in different ways dependant on the hardware. That sounds obvious I know but to date I’ve never seen it implemented on a 1 for 1 level ie: where you can do everything easily via touch that you can via a desktop – or vice versa. In every example I can think of where there’s a desktop and a touch version of a business app the touch one always gets dumbed down to a certain extent to make way for the casualness of touch. I have plenty of apps on my iPad that are replicated elsewhere that I prefer to use via a touch interface; a quick browse for a house on Rightmove or searching eBay for example but those are all casual ‘lean-back’ tasks not the ‘lean forward’ that analysis can demand. It seems Qliktech are trying to change this – which is great if they can pull it off; their UI designers will have to be the best in the world if they’re going to manage it.

I know 2 years from now things will be very different but I know from my Qlikview usage currently if I’m sat at a desk with a both a PC and a tablet in front of me it will always be the desktop I turn to for dashboard analysis and yes touch will be more prevalent in 2, 5 or 10yrs time but people will still be sat behind desks…and we won’t have decent amphibious cars either!. How very Luddite of me. I feel that for the foreseeable future mobile is simply something that’s to be used when ‘desktop’ isn’t available; yes it will allow more Data Discovery at the top of a telegraph pole or down a mine but come on; what about the millions of people who from here to retirement will likely be stuck behind a desk.

A simple test; how many work tasks can you currently do on a tablet? Baring access issues you can probably do most – great. Now think how many you’d prefer to do on a tablet over a desktop when the desktop is there and booted up ready to go; I’m sure there are some; updating your calendar for instance but for me in nearly all cases I’d choose the desktop – I’m typing this post on a 15in MacBook Pro and I have an iPad less than 2ft away sitting unused. It’s a case that mobile  / touch is great but only when it’s either a) casual and suited to touch or b) a desktop isn’t convenient. Don’t get me wrong; some elements of Qlikview consumption are casual and suited to touch; viewing the Global Games App for example but from my experience most usage of Qlikview in the business world goes deeper than that away from a dashboard and closer to reporting and analysis which is far from casual. Of course as touch interface design improves we’ll see more and more complex apps that become better consumed via touch than desktop but in the case of complex analysis it can’t change the data and so I feel its complete adoption will remain constrained.

As long as the ‘lean-forward’ non-casual consumption, creation and administration of Qlikview isn’t adversely impacted by this focus on touch then it’s all good but a part of me worries Qlikview.next is going to jump too far ahead of the ‘touch adoption curve’ and devalue itself in the name of ‘consumerization’ and simplicity.

Key Point: Qlikview.next will be entirely different at every touch point, be it developing, managing or consuming and everything will be angled towards being ‘Always Accessible’ be it to access a dashboard, amend a dashboard chart or administer the Qlikview environment.

A piece of loosely related future prediction: perhaps not the next iteration but certainly within 3yrs the iMac may well look something like this: http://perceptivepixel.brandgreenhouse.com/products/active-stylus and have a totally reworked OS to support it – when something like that happens touch will really have come of age and a touch focused version of Qlikview will make total sense…until then who knows.

2. It’s Open

Until relatively recently Qlikview has always been a fairly closed walled off product – yes it can connect to a good number of data-platforms but in terms of functionality or data going the other way it’s been limited. I know it’s possible to embed charts in Sharepoint and we can create extensions to bring in new chart types but I firmly believe that as of Qlikview.next what’s available currently will appear to be miniscule. We’re already seeing with 3^rd party products like QVSource that new connectors to weird and wonderful datasources are being created almost daily and I think that will become much more core in Qlikview.next – probably through some sort of IP deal between Qliktech and Industrial Codebox. How’s all this connectivity achieved; through API’s, and it’s through API’s that Qlikview itself will open up and let other products and solutions access its core functionality. Apparently the very basest levels of API’s that Qlikview itself uses to function will be open to developers, again it’s time for another ‘just think about that’ moment. Should it be fully realized Qlikview.next will be able to connect to virtually any datasource (not just platforms like SQL or Oracle but ‘sources’ such as GoogleAnalytics, weather feeds, Twitter etc) that exposes an API and conversely all of Qlikview will be exposable via it’s own API’s – that’s monumental and quite what impact it will have I’m un-sure but it will be huge. Just think if you’re able to bring in feeds of lower level but still relevant data – a stock price feed, weather data, twitter streams – quickly, freely and easily; it opens a whole world of new types of analysis; is there a correlation between my sales of Product A and cloudy weather – who knows, but you will know when the barriers to finding out all but disappear and then you’ll be able to act accordingly.

In much the same way we’ll see more and more usage of Extension Objects in Qlikview.next. It was noticeable at this week’s Business Discovery World Tour event how many more extensions there were on show and this will only continue in the future and I expect Qlikview.next to enable their creation and usage even more. Extensions won’t merely be small objects based around one visualization, I think it will be even greater than that; for example application level integration with R – not just in an individual Extension Object but available for use across any object via traditional expressions; expressions from R seamlessly sitting alongside native Qlikview ones – to me that’s truly open and truly awesome.

I think the impact of this will be 2 fold. Firstly Qlikview apps will begin to diverge; they’ll have more bespoke elements, tailored visualizations, altered peripheral functionality etc all designed to better meet the needs of the deployment in question. The second impact will be on developers of Qlikview: as we’re seeing with Extensions a developer increasingly needs to be multi-skilled not only in Qlikview but in Java, HTML C# etc in order to get the most out of the product and as more possibilities are opened up so the range of skills demanded will increase (The actual role of the core ‘Qlikview Developer’ will drastically shrink but I’ll get to that in section 3.).

Key Point: Qlikview.next will be open, open to data from all sources and platforms and open in terms of letting its data and functionality be used by other products and platforms.

3. It’s Simple

‘It’s Simple’ refers entirely to how Qlikview is used and appears, the product won’t be simple in the background but it will appear simple to the user. This is all very ‘Apple’ in that very complex things are done in the background to make things appear simple and intuitive to the user.

Right now I can tell you Qlikview.next will look very similar to the below:

Qlikview.next? – No Tableau.now

“Wow! Where did you get that exclusive!?”- simple: logic, experience, research and Tableau. Qliktech will deny it to the hilt but without doubt the biggest driver in the way Qlikview.next will look and be interacted with is Tableau, it won’t be identical; we’ll still have association and they won’t but the look and feel will be very close. How do I know this? Let me explain; Data Visualisation – what every Qlikview developer does and every dashboard presents – is a science, there’s a right way backed up by extensive research, logic and proof and a wrong way backed up by 3D charts, bad colour choices and users getting the wrong impressions of their data. Yes people will disagree as to whether an axis line should be this weight grey or that one or what the optimum distance between bar chart columns is but these are tiny differences of opinion; Tableau does visualization (largely) demonstrably right straight out of the box; they’ve invested heavily in academic research to get there ($200m more in the next few years), ergo; for any other vendor to do it ‘right’ they have to occupy the same space and present information in the same way with the same look – it’s not open for debate. Think of it this way: when flying machines were first being designed in the late 19^th and early 20^th Century there were a myriad of sizes, shapes and solutions (as with dashboard visuals now) but look at aircraft today and the vast majority follow the same design principals, not because it arbitrarily looks prettier but because it’s right; it’s safer, faster, cheaper, more efficient etc. We’re going to see the same thing in Data Visualization; a coalescence around what is inarguably right and it’s Tableau who have started this march in earnest ahead of everyone else and it’s up to everyone else to follow and follow they must.

The flying equivalent of a 3D Pie Chart

I once read a great line about using Tableau; “Don’t mess with the charts as someone who knows far more about data visualization than you has spent a lot of time thinking about what’s right and what’s wrong.”. For those that don’t know Tableau prides itself on it being easy for an end user to create their own dashboards (I feel this is also a weakness when it comes to enterprise level data), users can easily point it at a datasource, load the data, select the fields they want and Tableau will choose the most appropriate chart and create it automatically to be ‘right’. Qlikview.next will also do this through its ‘Suggestive UI’; if you select zipcode data it will know you’re likely to want a map, you want dates and sales information it will suggest a line chart and both will be correctly formatted by default once created. Others are following this route; Excel 2013 will contain the same ‘Chart Suggestion’ ethos. This is a (mostly) good way to go as to be quite frank most dashboard developers are creating the visualization equivalents of flying contraptions from the last century; they’re clueless, so it’s right that the visualization software you use guides you down the right path.

Why do I say this is ‘mostly’ good – simply put if the software and the end user (sorry Donald) can create a ‘right’ dashboard quickly, intuitively and easily then why on earth would they need a Qlikview Developer to the same extent? Undoubtedly once Qlikview.next is established we’re going to see fewer pure Qlikview Developer roles out there, yes there’ll still be people needed to set the environment up and get things rolling but the dedicated Qlikview dashboard developer may well become a rare beast indeed. This has the potential to greatly affect the Qlikview market; Qliktech Partners will see less ongoing need for their core Qlikview services and many developers will no longer be required – for the customer this is great; better dashboards with less outlay and time, but for the likes of me who consult on Qlikview dashboard creation it’s undoubtedly bad; we must therefore prepare to adapt.

A personal must have for Qlikview.next loosely in the ‘Simple’ theme is a public Qlikview cloud: it needs to be possible that anyone can download / access online a public version of Qlikview for free, load data in (perhaps from limited sources or volumes), create an app and then publish it to the Qlikview cloud for free to embed in a website or share via a blog. This would send low-level Qlikview usage through the roof and get the associative data way of thinking out there and really show people that Data Discovery is the way to go – products like Tableau get the visualization right just like any other product is capable of but Qlikview.next will have that ‘right-ness’ and the special ingredient of association which others can’t copy. Without a freely accessible cloud Qlikview risks becoming a business only backwater as SaaS upstarts take all the attention & glory.

Key Points:

 1) Qlikview.next will look a lot like Tableau; it has to. Tableau does visualization the right way, to not be like it is to be wrong – it’s as simple as that. It’s like saying “I’m going to design a new car and give it 17 wheels, 1½ engines and a joystick instead of a steering wheel” – it might work but it’s not ‘right’ and can be proven to be so.

2) With Qlikview.next there will be a lessened demand for traditional Qlikview development as the actual consumers of the information will be the ones who create more of the dashboards they use themselves with the guiding hand of the software.

Conclusions:

There are lots of other areas where Qlikview.next will differ from previous iterations as well as other dashboard and visualization solutions that have gone before; the enhanced collaboration (which I remain to be convinced about), thin clients for all, revised Access Point, offline iPad usage (available now), new charts, server based development and many more things all of which will impact the way we all create Qlikview apps. However for me the 3 high level changes outlined above are the ones that are likely to have the biggest impact both in improving the Qlikview experience and also reshaping the Qlikview ecosystem.

So when is all this change likely to appear? Donald Farmer specifically mentioned ‘entering Beta in the New Year’ at this weeks conference but personally I think it will be a little after that when the wider world gets a first glimpse of Qlikview.next; I’d estimate end of Q1 2013. After that I’d expect a relatively long Beta cycle simply due to the fact that we’re looking at such sweeping changes to the product so I’d be surprised to see the first major full Qlikview.next release before Q4 next year – there may well be more than one.

There’s one final point and it’s not a good one. I’ve head from Qliktech many times in the past things like ‘we’ve got this great new feature’ and it turns out to be something totally illogically implemented or we’ve had Service Releases rescinded due to sloppy testing, so I’m skeptical as to how they’ll cope with the wholesale changes we’re looking at with Qlikview.next. I’m hopeful that many of the challenges can be overcome; they’ve hired lots of new employees specifically for Qlikview.next in the fields that count but the aims for what Qlikview.next will be; all things to all people on all devices, is such a radical and far reaching idea that it will be impossible for there not to be problems along the way.

So I await the reveal of Qlikview.next eagerly, hopefully and with a slight sense of trepidation; it’s undoubtedly going to shake up the current state of play in the Qlikview ecosystem and some people will win and some will loose so you’d better pay attention and make sure you come down on the winning side.

Key Point: Business Intelligence and data visualization is going through the natural transition that all relatively new industries go through; everyone is heading towards a central homogenous point as ‘evolution’ removes the weaker players & solutions and the ‘right’ way comes to the fore. The end point for BI & data visualization is a little past where Tableau is now and it’s where I hope Qlikview.next will jump close to, if it doesn’t it will lay itself open to fresh challengers in the market who see this inalienable truth and act upon it.

Everything is going to change – it has to.

All the best,

Matt

For an introduction to the wonderful world of indexing (Now there’s a topic to introduce into diner party conversation; ‘Never mind you’re career as a brain surgeon, let me tell you about the wonderful world of indexing…why are you yawning?’) take a look at my previous index related post: http://qvdesign.wordpress.com/2012/05/09/the-indexed-time-series-chart-the-forgotten-technique-at-least-by-most-qlikview-developers/

In my last post and 99% of other cases in the wild indexing is displayed via a time-series line chart; we see how things are at a point in time compared to what they were in another, for instance changes in sales across several years: all very useful. What if we wanted to see how sales people’s performance was relative to the top performer across several product groups or how a products performance is relative to others across different markets? – we shouldn’t use a line chart as ‘Sales Person’ is a non-continuous dimension so its the Comparative Indexed Bar Chart that can show us the way.

As is the case with many of my chart examples we’re looking at British Prime Ministers and their careers selling regional British Produce in a very basic sales dataset. I’d like to know how each Prime Minister has performed (Sales wise not politically) across the 3 Product Groups we have relative to a Prime Minister of my choosing –or vice versa; how one has compared to the rest (perhaps for use in a Prime Ministerial 1-to-1!?). So to do this I can use the indexed chart below:

You can see in the above example that I’ve selected Winston Churchill, this has caused him to move to the left of the chart and to be labeled ‘Index Master’ but most importantly his sales values for each Product Group have been set to 100 via the Index Factor (see previous index related post). As with a time-series indexed chart we then simply apply this Index Factor to the sales values for the other Prime Ministers to see how they all performed relative to Winston. We can for instance see that Mr Churchill sold more Meat Products than everyone else bar The Duke of Wellington however everybody else sold more Regional Produce than he did – why is he so much better at selling Meat??. Of course this could be shown with a traditional grouped bar chart; we’d see who sold more and who sold less, but think what the chart would look like if Meat Products were sold in the order of hundreds of thousands of units whilst Pickles were only in the order or a few hundred – the Pickles bars would be tiny and the variances impossible to distinguish. That’s why we use indexing – it levels everything out, we are in effect looking at percentage difference and not actuals.

I’ve also added an ‘Average’ selection to the list of Prime Ministers and by selecting this our indexed value becomes that of the overall average which allows us to know how each Prime Minister compares to the average.

The expression used to drive the chart is a relatively straight-forward one:

=sum(Volume)/(sum(total<Product_Group>$<Name={‘$(v_Sales_Name)’}>}Volume)/100)

The variable ‘v_Sales_Name’ is simply =SalesName (our list of Prime Ministers which is set to ‘Always One Value Selected’) so what the expression is doing is: taking the sum of each Prime Ministers sales volume and dividing it by the sales volume of the selected Prime Minsiter divided by 100 – easy.

The rest is even easier than that so download the sample .qvw and have a look around, the file can be accessed here: https://docs.google.com/open?id=0BxloTMUod74tejdUbnExdDJSYjQ

*I’ve had a few people contacting me to say that the Google Drive docs aren’t accessible, I think this is down to older versions of IE not being compatible (as well as being generally rubbish) so I recommend trying Firefox if you have any problems.

So there we have it; The Indexed Comparative Bar Chart, it’s not going to change the world but I think it’s a good one to have in the proverbial Qlikview toolbox ready to quickly and easily deploy when the requirement suits. All indexed charts are not that much harder to create than their standard brethren but where standard charts tend to only show what happened adding an index can show that extra level of crucial information that would otherwise remain hidden.

As always I hope you can put it or something similar to good use.

All the best,

Matt

Firstly I need to explain what this chart shows as that will hopefully convey the usefulness and potential that’s held within. In my examples here I’m looking at customers who have bought multiple insurance products – it could just as easily be students taking various exams or baskets of goods from a supermarket. So; one insurance customer could have a Motor policy, a Life Insurance policy and Pet Cover whilst the next may well have a totally different mix from the product set and another could only have a single product. It would be useful for the insurer in this example to know where to offer discounts: “Get 10% off Motor Insurance when you buy Life Insurance”. Alternatively of course it could be to not offer discounts to purchasers of Life Insurance as you know they’re relatively likely to buy say Motor Insurance as well.

The chart is split across the middle with Male data at the top and Female at the bottom – this isn’t a requirement of that chart but shows we can add in an additional metric. There is one circle per Product – in this case 9 evenly spaced across the middle. The curves shows 2 metrics: the ‘strength’ (Saturation & Thickness) indicates the relative volume of customers buying at least both the Products at either end of the curve whilst the distance it extends from the X-axis across the middle shows the average premium earned from customers taking the 2 associated Products. Therefore a low weak line shows that relatively few customers purchase both Products together and when they do it generates a low Premium, conversely a high strong line means a relatively large volume and a high average premium.

So in the case of insurance you’d potentially look to find high faint curves (small volume but high premium) so you could decrease the premium charged to increase demand or vice versa look to increase premiums where the line is low and strong.

Think of applying this to say a supermarket’s data to look for associations in customer purchases – of course you’d see the obvious things like strawberries being bought at the same time as cream or perhaps charcoal bought with steaks but you’d start to see other less obvious but none the less relatively commonly purchased combinations…and that’s where you’d want to target discount offers: “50% off ice as we know you’re likely to buy Whisky at the same time”. It can get scarier than that; Target the US retailer was recently in trouble for mailing coupons for nursery furniture and maternity clothes to a young woman even before she’d told anyone (including her parents) – http://www.forbes.com/sites/kashmirhill/2012/02/16/how-target-figured-out-a-teen-girl-was-pregnant-before-her-father-did/ This was done thanks to Target spotting associations in their data; they had a database of women they knew to be pregnant and looked at the associated products they bought and then simply looked for the same associations in their wider unknown customer base and then mailed them discount coupons for baby related products.

Of course the vast majority of ‘associative purchases’ are false positives and nothing more than coincidental; you must have looked into you’re shopping basket at some point in life and thought something like: ‘what would someone think if they saw me buying avocados, bin liners and shoe laces?’ – there’s nothing joining the items together to explain you buying them at the same time. However, as the volume of transactions increases these coincidental associations fade and the ones that have shared common reasons (conscious or otherwise) behind them will come to the surface as they’re purchased more regularly by more people and it’s these associations that can be exploited for increased profit.

The associations could be shown simply by using the strength of the curve to point users in the right direction but the addition of the average premium metric takes things further. For instance you’d expect some people to purchase Motor Insurance and Pet Cover and others to buy Motor Insurance and Company Directors Insurance, the chart would show us where the greater volume was but also which of the 2 combinations generated the highest average premium – simplistically you’d expect the line connecting Motor and Directors Insurance to be higher as an average company director will have a higher value car (and thus more expensive to insure) than the average Pet owner, so; offer people who buy Directors cover only an incentive to take Motor insurance as well as you know it’s likely to generate a good premium. That’s an obvious simplified example but I guarantee that there are others out there hidden in the data that aren’t so apparent without the use of a chart like this. This could just as easily apply to Student Grades; do students taking Geography & Physics get a higher average % mark than those taking Geography & Media Studies? – The Associated Curve Chart can tell you.

And because this is Qlikview we can dive into the dataset – reduce the supermarket data by season; associations in the summer will be very different from those in the run up to Christmas, inner-city stores will differ from more rural locations, west coast will be different to east coast etc etc and all the while the chart responds and displays the underlying associations accordingly.

The chart isn’t perfect, for instance try plotting every possible product a supermarket sells across the x-axis and it would end up 100ft wide and be wholly impractical so it’s perhaps more suited to say selecting Strawberries and seeing what dairy products were purchased along with them – did we sell more single or double cream and which combination made the most?. Coupled to that the fact that we need to create a row of data for every product combination under each order number, customer number etc then our dataset is going to grow by several times which could well cause problems.

That said I still think it’s of great potential use from high-level indicator to deep data mining visualization and it shows information other charts would struggle to, so download the .qvw and have an experiment with it and see if you can put any of the principals to use. As a note; there are slight differences in the way versions of Qlikview and operating systems format axes and fonts so the version you open may not look 100% like those in the pictures.

*This is a bespoke chart created from bespoke tailored data so in it’s current form it can’t readily be applied to other datasets – I am working on a method to generate the chart automatically to make it quicker to deploy.

The method used to create the chart loosely follows that used to generate my recent ‘Dynamic Network Flows’ chart so the basics can be picked up here: http://qvdesign.wordpress.com/2012/06/22/new-qlikview-chart-type-dynamic-network-flow-charts/ Also there’s the Radial Chart mentioned here: http://qvdesign.wordpress.com/2012/03/05/associative-radial-chart/ that also shows associations between items purchased together in a more basic manner.

The complete .qvw can be downloaded here: https://docs.google.com/open?id=0BxloTMUod74taHpNZ1ZyS3VHZFE

As always I hope you can put it or something based on it to use.

All the best,

Matt

Of course probably the largest factor that contributed to Team GB’s success is the simple fact that a lot of cash (£250m+) and resource was thrown at the athletes involved allowing for better training facilities, coaches and physios as well as meaning the athletes could focus on training fulltime instead of having to hold down a paying job. However one of the more overlooked methods that lead to great improvements and which was employed with particular zeal in the cycling events contains a very simple methodology for all dashboard developers.

Team GB utterly dominated the Olympic cycling events especially in the velodrome, that’s not patriotic fervor on my part; the facts back it up; 10 events: 7 Gold, 1 Silver and 1 Bronze…and that’s with several controversial relegations and the sports governing body limiting the number of entrants to lessen the chance of such domination. Obviously the athletes played a huge part in those results but one man and his management played perhaps an even bigger role; Dave Brailsford CBE; the Team GB Cycling Performance Director (and boss of Tour de France winning Team Sky).

Dave Brailsford CBE

Brailsford completely transformed the performance of the Team GB cycling squad through his particular brand of micro-management to such an extent that a member of the French Olympic team suggested that perhaps some kind of secret illegal wheels were being used on their bikes to achieve the team’s performance…the wheels were in-fact made by French company Mavic so that wasn’t it!. So what did Brailsford do? The world of professional cycling is a very narrow place; all the competitors have trained and practiced for most of their lives and the equipment is relatively homogenous (bikes are hardly F1 cars) so how can you raise a batch of cyclists over and above everyone else; where there’s no obvious room for improvement; you’re not going to shave 10sec of a time by suddenly inventing a new type of bike or new training method. This is where the genius of Brailsford’s method (and the supporting cash) comes in. Team GB took the sport of cycling and blew it apart, every component was looked at by specialists; the bike, the training, the nutrition etc etc before those elements were further broken down again; the wheels, the tyres, the helmet… They ended up with hundreds of individual components that could all be improved upon even if only slightly. Even though people thought there wasn’t much room for improvement in cycling, by making small improvements to many of the separate constituent parts of the sport and then combining them all together Team GB was able to deliver the performances we saw in London.

The extremes that this ‘micro-innovation’ concept has been taken to are bordering on ludicrous; all the equipment is tailor made for each athlete: not just the hand made carbon fibre bikes but the helmets and shoes as well, nutritionists plan every meal, training schedules are mapped out to the minute, it even goes as far as the athletes always having the same pillow when they’re away at events to aid relaxation back at their hotel. Basically everything was looked at by experts in the appropriate field and everything that could be improved was, no matter how small it seemed. This was all backed up by data that was analysed to look for further areas for improvement, this was engrained in the team; when Bradley Wiggins crossed the line of the final time trial of this years Tour de France and knew he’d won the overall race before raising his arms in celebration he first stopped the computer on his handle bars to ensure the data was accurate – nothing gets in the way of possible improvement. Each improvement on its own may be very simple and only deliver a .00001sec of an advantage but add them all up and you end up with 7 gold medals.

Tailor Made Helmet

 So how does this relate to Qlikview and dashboard development? Simple really; just like there are individual components that go into making the sport of cycling there are many individual components that go into making a dashboard (or a car or a house or a machine or pretty much anything else for that matter) and by following the same principals almost any dashboard can be improved upon.

Let’s look at just a few of the components that go into making a dashboard what it is and how they can be analysed and improved:

1. Color – are you using the most appropriate colors? There are many books that set out the rules for effective color usage it’s simply a case of applying them. This isn’t just for your headline colors it also applies to things like the hue of black you use for axes labels or the brightness of your object borders.

2. Alignment – are all your objects lined up correctly, if they’re out by even a pixel it all goes towards detracting from the overall impression of your dashboard.

3. Annotations – can small amounts of narrative information be added to any of your objects to make them easier & quicker to interpret?

4. Have you made the right object choices – this is so simple; read information from your dashboard and put yourself in the position of being a consumer of it’s information; is that chart you’ve created actually showing anything of use? If not get rid of it.

5. Fields – have you left any unused fields in the dashboard, leave too many and you risk the performance of your dashboard / server being affected – I know the chances of this becoming a major issue are low but having unused fields is going to increase the size of your .qvw meaning it requires more RAM on the server and takes longer to open, ergo; room for improvement. Download a copy of Rob Wunderlich’s Document Analyzer to help you here: http://robwunderlich.com/home/2012/6/19/new-document-analyzer-v113.html

6. Post deployment analysis – just like Team GB gathering data on their athletes we can gather data on the usage of our dashboards through the log files or simply by asking people, it’s easy to find out who’s doing what with your dashboard so amend after the fact to tune and improve it.

Those are just a few of the areas and all of the points are based on rules, it doesn’t matter who you are, whether you’re a ‘creative’ or the geekiest of developers who ‘doesn’t do layout’ you can follow simple rules to easily get the basics right and produce a great dashboard.

So here are my 3 main parallels between Team GB’s cycling team and Dashboarding:

1. There are individual components in cycling as there are in dashboard development all of which can be looked at and improved separately to greatly improve the combined whole.
2. Team GB used experts in each field to analyse the components of cycling, dashboard developers have books about the science of visualization and dashboarding that contain simple rules that can be applied.
3. Where Team GB needed and injection of cash to support all the ‘micro-innovation’, support staff and training the hard currency for dashboard development is time – it’s a limited resource but the more you devote the greater the improvement.

Time for a touch of realism.

Of course spending 12hrs choosing between rgb(20,20,20) and rgb(30,30,30) for your axis color on a dashboard that’s going to be used by 2 people when you have a client demanding 100 other dashboards isn’t a good nor viable idea but as with many things it’s about finding a balance. Lining objects up on a badly colored dashboard will improve it, conversely properly coloring a misaligned dashboard will also improve that; it’s about doing what you can and not settling as so many seem to do for ‘meh, that’ll do’. If time is pressed quickly & simply improving a few key components of a dashboard will be far more effective than trying to address the dashboard as a whole with a scattergun approach.

As Qlikview expands ever further up into the Enterprise space sloppy un-considered dashboard design will no longer be an option; you create a skewed impression of some data by using the wrong type of highlighting; you’ve just passed that skewed impression on to 500 people in a Billion-dollar global business and got an entire department closed down…well done.

As Steve Dark at Quick Intelligence blogged about recently (and Panasonic coined): ‘Everything Matters’…whether you’re riding a bike at the Olympics or sat behind a desk looking at Qlikview.

As always; all the best,

Matt

After creating the Watermark Bar Chart for my previous post (http://qvdesign.wordpress.com/2012/08/09/qlikview-watermark-bar-charts-a-bit-like-bullet-charts-but-not-quite/) I started to think about what other amendments could be made to the Bar Chart to make it even better (in certain circumstances when the data & requirement suits) and I came across the following chart via the ‘Technology’ feed within my FlipBoard iPhone App:

Not exactly The Great Leap Forward in chart evolution but none the less I like it, the chart pushes things a little further than say simply stacking as it allows you to see how 2 dimensions contribute to the Total (Product Group split along the X-axis and Sales Group as the internal stack in this case). We see what the Sales Group breakdown for the separate Product Groups is compared to the overall (the Total bar) which is also something that isn’t made easy using currently available methods.

Whilst this is a chart that’s possible to create in Qlikview currently (there’s a ‘How to’ and .qvw below) it is similar to my previous post in that it’s creation is too bespoke and complex for general deployment – however I see it as something that could be implemented by Qliktech to make it simple to deploy. Again; here’s hoping for Qlikview.next.

So how’s the chart created?

As always you can download a demo .qvw here: https://docs.google.com/open?id=0BxloTMUod74tcVBzMjRWSEhKbjA

To start with here; surprise, surprise; we’re using a Bar Chart as a foundation here (it gets more complicated). There’s a single calculated dimensional value created by my old favorite valuelist():

=ValueList(‘Pickles’,'Meat Products’,'Regional Produce’,'Total’)

These are the individual values the .qvw has in it’s Product Group field, obviously if you had a lot of unique values this method would be a little time consuming – you could instead incorporate a concat() statement to assist you although you’ll need chr() and a variable or two to make it work.

Next it’s on to the Expressions of which we have 5…which is a number determined by the number of unique values in our second ‘dimension’ in this case 3 values in Sales Group (A ‘Previous’ and a Datapoint expression makes 5).

The first expression called ‘Previous’ generates the transparent bar that creates the off-set and is calculated as follows:

=if(ValueList(‘Pickles’,'Meat Products’,'Regional Produce’,'Total’)=’Pickles’,null(), if(ValueList(‘Pickles’,'Meat Products’,'Regional Produce’,'Total’)=’Regional Produce’,sum(if(Product_Group=’Pickles’,Volume)), if(ValueList(‘Pickles’,'Meat Products’,'Regional Produce’,'Total’)=’Meat Products’,sum(if(Product_Group<>’Meat Products’,Volume)), null())))

So here we have if the dimension = ‘Pickles’ this value should be null() as Pickles are the first dimension in our breakdown if it’s ‘Region Products’ the value should be equal to the volume of Pickles as it’s the second value in the dimension and so on to the end of the dimension.

Now it’s a case of building the stacks from there and again each expression has to be bespoke to the dataset which makes this a very laborious chart to deploy.

Finally we add a Datapoint expression to display the subtotal for each Product Group value.

The end result is fully reactive to selections despite the chart’s heavy amount of customization.

So here we have another plea to Qliktech for a simple piece of functionality to be added into Qlikview.next – it’s not going to set the world alight but it all helps push the functionality that Qlikview can deliver and gives us another tool in the Qlikview Toolbox.

I don’t think this chart is perfect as for instance it can make comparing segments from each ‘floating’ bar harder than it might but then again with most other chart types the breakdown wouldn’t be shown in the first place so I think it’s one to have in the Qlikview armory.

As always; I hope you can put this to use or it helps you deliver something similar.

All the best,

Matt

Across this demo we’re going to be looking at how Sales Volume for a particular Sales Person compare to Average Sales Volume for all Sales People (this could just as easily be how Sales compare to Targets for example). In the example below I’m showing the Volume for the selected Sales Person in Grey and the Average for all Sales People via a Symbol set to default size and auto symbol choice.

As you can see the dot’s are a bit lost in the chart and don’t readily draw the eye – of course we can tweak colours etc to make them stand out but that won’t make too much of a difference. The obvious solution here is to make the symbols larger, let’s do that:

In this example the symbols are now much clearer but as they’ve increased in size vertically as well as horizontally it’s now much harder to accurately read off their values from the Y-axis. Plus annoyingly Qlikview always places the symbols slightly off centre, the reason for which eludes me.

The other inherent problem with both of the above examples is that it’s very hard to accurately judge a distance between non-parallel lines especially when looking at a chart quickly as one does with a dashboard.

As a 3^rd option we could show both measures side by side. Generally this works well and can provide accurate results however I find it can get a bit too crowded and end up confusing the picture:

Admittedly this is probably the best solution if you have plenty of space and not too many values on the X-Axis.

So what if you do have lots of values to show in a relatively small amount of space (such as an iPadf deployment)  but need a solid degree of accuracy? – I admit this is getting to be a small niche requirement – Step in the ‘Watermark Bar Chart’.

As you can see in the example below we’re showing the same volume of data as in the above examples but in a much more efficient manner:

Crucially with the Watermark Bar Chart we aren’t loosing that much information fidelity even when we get down to a really small object footprint. From this chart I can instantly see whether the selected Sales Person is above or below average for all the available Products as well as garnering a good indication of how large or small the difference is.

A note for Qliktech: The method needed to generate this is very complex when compared to the amount of benefit we gaining (yes I am doing down my own chart!) it could all be solved easily by having a ‘Line’ available as a Combo Chart symbol option.

As usual an example .qvw is available to download here: https://docs.google.com/open?id=0BxloTMUod74tUEVyRHRSa3h4LUU

The key components are 3x stacked expressions that are controlled along with the Background Colors by an if() that’s looking at whether the selected Sales Person’s Volume is greater or less than the overall Average.

Poke around in the Properties of the chart and all will become clear.

Due to the complexity of the implementation I have to admit that I probably won’t be putting this chart into action in its current guise but it’s always good to have more tools available in the Qlikview Toolbox and I hope it pushes Qliktech to deliver that new Symbol type to make this chart easy to deploy.

As always; all the best,

Matt

UPDATE: I’ve submitted this to the Qlikcommunity as a new ‘Idea’, you can vote for it here: http://community.qlikview.com/ideas/2610

There’s no wine & cheese gallery opening event so feel free to browse around at your leisure using the .qvw below.

Pointless but interesting.

As usual you can download the .qvw here: https://docs.google.com/open?id=0BxloTMUod74tUDBQbGttelNjR0U

Hope you enjoy.

All the best,

Matt